jump to navigation

New Development, Distribution and Support Model for JBoss April 24, 2007

Posted by Sacha in JBoss, Moved from JBoss.org.

This week is a very important week for 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 it 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 (we are hiring BTW!), 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:

  1. 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
    ”. 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.
  2. 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.
  3. 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.” You can read more about these platforms and roadmap in Shaun’s blog. 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 5 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 5 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 (see Shaun’s blog on that
). BTW, 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.





1. JBoss AS is now EE5 certified! « Sacha’s Weblog - September 19, 2008

[…] OK, enough self-congratulation; what next? In 10 days, we are going to have a JBoss AS engineering meeting in Neuchâtel to polish the codebase for the official GA tagging and prioritize the post-GA tasks. Given that the GA release should happen in the next 6 weeks or so, we are working in parallel on the content of the EAP 5.0 (the only version of the software Red Hat supports). […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: