Red Hats JBoss to Adopt Fedora Model

The JBoss division of Red Hat is slated to move to a model in which its source code control system will be public and backward compatibility is not guaranteed, sources say.

Red Hats JBoss division is planning to move in June to a model similar to that used by RHEL/Fedora model, said sources close to the company.

The move would mean that JBoss would deliver a Fedora-like community edition of its core software that only looks forward. As with the Fedora Linux project, no backward compatibility is guaranteed—Fedora is focused on the future and new features.

Typically, a Fedora release is targeted as the next Red Hat Enterprise Linux release. RHEL forks or branches a specific Fedora release. The RHEL team stabilizes the Fedora code tree it branches, productizes it and certifies it for a number of different platforms.

/zimages/3/28571.gifFormer JBoss insiders team up to form a demand-generation startup called LoopFuse. Click here to read more.

However, the difference with the JBoss Fedora-like offering will be that the JBoss source code control system will be public, sources said. RHELs source code control system is private and not available to the community, although the source code itself is published. And RHEL binaries are only distributed to subscription holders.

According to sources, JBoss will follow the same model except that the source control system will be public. And community releases—JBoss Fedora equivalent—will have binaries distributed.

The change means little or nothing to JBoss customers, except that they will get more stability. The community releases drop as quickly as possible, following the open-source software mantra of "release early, release often." As is the case with RHEL, the product releases are stable. There tends to be no feature creep, no SPI or API changes, just bug fixes. Yet RHEL releases come more slowly than the community releases.

Although the switch has its benefits both to customers and to JBoss developers, the planned new strategy has generated mixed feelings inside Red Hat, sources said. One thing the shift will do is enable the individual project leads to work more on the future of the platform and focus on innovation rather than be bogged down with backward compatibility and supporting the base product. Under the new system, those efforts can be shared more broadly.

/zimages/3/28571.gifCheck out eWEEK.coms for the latest open-source news, reviews and analysis.