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.
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.