ProductsDesktop Server Red Hat Enterprise Linux OpenStack Platform For IBM POWER For IBM System z For SAP Business Applications Satellite Management For Scientific ComputingExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportAccelerate Automate Integrate Red Hat JBoss BPM Suite Red Hat JBoss Developer Studio Portfolio Edition Web Framework Kit Application Platform Web Server Data Grid Portal Fuse Red Hat JBoss A-MQ BRMS Red Hat JBoss Fuse Service Works JBoss Operations Network JBoss Community or JBoss enterprise Red Hat JBoss Data Virtualization
SolutionsWhy Red Hat Why open hybrid cloud? The new IT Public cloud Cloud resource library Private cloud Infrastructure-as-a-Service (IaaS) Platform-as-a-Service (PaaS) Cloud applications and workloadsSolaris to Red Hat Enterprise Linux Migration overview Migrate from your UNIX platform How to migrate to Red Hat Enterprise Linux Upgrade to the latest Red Hat Enterprise Linux release JBoss Enterprise Middleware Benefits of migrating to Red Hat Enterprise Linux Migration services Start a conversation with Red Hat
TrainingPopular and new courses Red Hat JBoss Administration curriculum Core System Administration curriculum Red Hat JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing, Virtualization, and Storage curriculum
ConsultingSOA and integration Business process management Cloud and virtualization Custom Software Development Enterprise Data and Storage Systems management Migrations
New Development, Distribution and Support Model for JBoss
April 24, 2007
by Sacha Labourey
This is a very important week for Red Hat and JBoss, not only because we are announcing the strategic acquisition of MetaMatrix, but also because we are evolving our development, distribution and support model. Let me dig into what this means.
Historically, JBoss has developed and supported projects on a “single branch model.” That is, we supported every release for all of the JEMS projects. That created a natural tension between the community on one side and the business on the other side, as they both have different goals. As we see it, the role of the community is to innovate, develop new features and release early, release often. The role of the business is to support existing installations with minimal disruption, providing backward compatible fixes and this over a long period of time.
For example, if a project lead produced two minor releases in a week, for whatever reasons, it meant that our support team would have to support both of these releases for several years. Imagine how complex this gets when you mix all of possible project releases with all possible permutations of JEMS software (e.g., JBoss AS with JBoss Cache with jBPM with Drools with Hibernate), you end up with a combinatorial explosion that is very difficult to manage, even more as you expand your customer base - and that is exactly what’s happening thanks to the JBoss/Red Hat merger.
Instead of coping with that growing tension, we decided to drop it by eliminating this conflict of interest altogether. We will now work on two “branches”: i) the “JBoss.org” community branch and ii) the “Enterprise” branch. Let me explain how they relate.
The JBoss.org software is JBoss as you’ve always known it: everything you know and are used to getting from JBoss is what we will refer to as “JBoss.org” or “community” releases. Nothing will change on that front except, as we further grow our product/platform teams, project developers will have more time to focus on innovation and pure development work as they will have less productization constraints.
What’s really new is that we will work on “Enterprise” releases. Here is how it works. At very specific points in time (usually when a JBoss.org project reaches feature completeness and proved high stability – but at least every 12 to 18 months), a “product team” will branch that code base (it will be hosted in the same CVS/SVN public tree). This separate product team, with the help of the project team, will perform three type of actions on that branch:
- Sanitization: This first action is to remove from the original code base the features that we do not think our customers should be using in production. As you know, most projects have optional or experimental features as part of their code base. We want to make sure that those are not present or at least not enabled in the Enterprise branch to satisfy our support organization’s motto that “if we ship it, we support it.” Tomcat native clustering is a perfect example of this. For various technical reasons, we typically advise our customers to use JBoss Clustering over Tomcat clustering. Through sanitization, we can avoid this confusion and simply make sure that our “Enterprise-blessed” version of Tomcat includes the “recommended” version of clustering, i.e. JBoss’s.
- Productization: In this step, we will fine-tune and improve the usability of our software so that it matches the expectations of our customers. All of the improvements we will perform will be applied “upstream-first,” i.e., we will first apply the changes in the Community code base so that the next release of our software (both Community and Enterprise) can benefit from the enhancements.
- Aggregation/Packaging (optional): Today, we are also improving the way we package our software so that our offering focuses more on “customer use cases” rather than on “specific technical features” by aggregating several projects in what we call “enterprise platforms.” Essentially, our productization teams will pull together the most commonly used JEMS components in their best versions, integrate them and perform cross-testing for these components. Each platform will be available as a single download, with all components guaranteed to work together seamlessly out of the box.
From a distribution standpoint, source code and binary for Community releases will continue to be made available like they are today with no changes. For the Enterprise releases, the source code will obviously be freely accessible (we are using the exact same CVS/SVN servers/trees for platform development) but the binaries will only be accessible if you build it yourself or subscribe to our developer subscription, production subscription, or Red Hat Developer Studio (future name of the Exadel Studio Pro IDE).
Let’s be clear that the “Enterprise” software will NOT be a “blended” community version with non-open source features; it is exactly the opposite in fact. The Enterprise version is a subset of the Community version that is enterprise-ready and we can guarantee support for up to seven years. While this new development, distribution and support model looks and smells a lot like the good old RHEL/Fedora model applied to Red Hat’s Linux distribution, it is not exactly the same. While the rules are the same with regard to the binaries, the JBoss source code will remain public and accessible during the complete Enterprise lifecycle activity, not just for specific release snapshots.
From a support standpoint, we will only support the Enterprise versions of our software. This enables us to support you even better and for a much longer period (up to seven years) with quarterly cumulative patches (bugs only) and bi-annual updates. We are also offering development subscriptions where some community versions of our software will be supported, but not with the same SLA. By the way, existing users of JBoss 3.x or 4.0.x will still be able to get support for these versions. The new rules only apply to new releases of our Enterprise Platforms and Frameworks, so none of the previous releases are affected by this change.
The bottom line is that since we will be focusing on stabilizing features on Enterprise Platforms, it means in turn that the JBoss.org community will have even more freedom and flexibility and will be able to focus on what it does best: innovate. JBoss.org is where we will continue to innovate JBoss Enterprise Middleware. But now, projects are no longer tied to productization cycles. That means you can expect more bleeding edge technologies, more often. Once these technologies are enterprise-ready, we’ll integrate them into JBoss Enterprise Platforms. As a sign of that change, you should visit the newly redesigned and enhanced JBoss.org Community web site.