New Development, Distribution and Support Model for JBoss April 24, 2007Posted by Sacha in JBoss, Moved from JBoss.org.
1 comment so far
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:
- 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.” 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
topic). 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.
JBoss Telegram (aka .— -… — … …) April 6, 2007Posted by Sacha in JBoss, Moved from JBoss.org.
add a comment
I’ve decided to regularly provide “quick info” on the various JBoss projects (new features, numbers, etc.). As this information is usually scattered across various projects, URL or blogs, I hope this unified entry will make it easier for you to find what you were not looking for.
New product releases…
JBoss Messaging. On the new product releases first, Ovidiu and Tim have been working at 50% in the last few months, i.e. ~12 hours a day, in order to release JBoss Messaging 1.0. I am very proud of the team and of the result of their work. This implementation is fully JMS 1.1 compatible and already shows great performance improvements. Clustering features are next on the roadmap.
From a deployment standpoint, JBoss Messaging
- can be deployed in JBoss 4.x in order to replace JBossMQ (it is backward compatible with JBossMQ configuration files),
- will become the default JMS implementation as of JBoss 5.x, and
- is a key component of JBoss ESB (first release due later this year).
Speaking about JBoss ESB and new product releases, the last days have seen a flurry of new releases with JBoss jBPM 3.1, JBoss Rules/Drools 3.0 and JBoss Transaction 4.2 (acquired from Arjuna Technologies and HP in December 2005). I will speak more about those in another telegram…
Some interesting tools have also been implemented recently. First, Adrian has been working on JBossRetro, a retro-weaver that we use to retrofit JDK5 classes in order to execute them under JDK1.4 environments. While it is not the only tool that provides such features, Adrian has been investing significant resources in testing it to make sure it is rock-solid (like anything Adrian does). As an example, JBoss 4.0.4CR2, which was just released a few days ago, incorporates the new JBoss WS implementation which will also be our EE5 implementation. Given that JBoss 4.x is our EE 1.4 branch, it had to work with JDK1.4 and hence had to be retroweaved for that release. That’s what JBossRetro did.
JBoss Serialization, which aims at improving the performance of the Java default serialization implementation, is currently being rolled out in many JEMS projects (starting with the AS). If you need to perform deep object copy or object serialization in your project, you should consider this tool as it can provide up to a 10 times performance increase over the default “byte array” Java serialization.
JBoss Profiler is a log based profiler that can remotely analyse JVM events and provides access to key information through a Web browser. While JBoss Profiler doesn’t exhibit the sexiest interface out there, it does provide some unique features. For example, Clebert has been recently implementing a new feature that will help you find memory leaks much more easily and much faster (across re-deployments of applications in JBoss AS for example).
Last but not least, I recommend to regularly check the status of a fast growing project: JBoss Mail Server. Andy Oliver’s baby is gaining great traction. As an example of its adoption, one of the European largest phone operators is using it for all of its European mobile-to-e-mail traffic. Tempted? Click here and you will have it configured and running in less than 10 minutes (thanks to Java Web Start)
I will be back soon with a new JBoss telegram…