The curious case of JBoss AS 7.1.2 and 7.1.3

At the moment of writing, JBoss AS 7.1.1 is the latest version of JBoss AS that can be downloaded from their usual download page.

This release is nearly 1 year old, and contains quite a lot of really serious bugs. There is a JBoss AS 7.2 in the works, but since not even an alfa, milestone or beta version has been put on the download page, it might not be unrealistic to surmise a release of that is still at least some time away. For JBoss AS 5 it took over two years (2006-11-17 to 2008-12-05), for JBoss AS 6 one year (2009-12-02 to 2010-12-28) and so on. Although for smaller releases the time is typically shorter, e.g. 7.1 was just below three months (2011-11-22 to 2012-02-16).

JBoss AS 7.2 will undoubtedly fix many of the open bugs in 7.1.1, but because it will contain many exciting and fancy new features, it will almost surely also contain many not so exciting new bugs.

So, why doesn’t JBoss just fix a bunch of bugs in 7.1.1 without introducing any new features? Why isn’t there say a JBoss AS 7.1.2, 7.1.3 etc. Why do we have to wait so long for a new version only to get more new bugs?

Well, actually, this is exactly what they do. There is a 7.1.2 and 7.1.3 in which an enormous amount of bugs are fixed. The only thing is, those aren’t put on the regular download page, but on a ‘special’ download page that’s behind a login. Oh, and to make it kind of look like it’s another product the name is changed from JBoss AS to JBoss EAP and the version numbering is changed as well. 7.1.2 becomes 6.0.0 and 7.1.3 becomes 6.0.1. The WTP server runtime offered by JBoss Tools also plays this game along and puts the runtimes for those EAP builds under a different category. So with the “JBoss 7.1 Runtime” you can start JBoss AS 7.1.0 and 7.1.1, but for something that’s effectively JBoss AS 7.1.2 you need the “JBoss EAP 6.0 Runtime”.

Downloads are available from access.redhat.com/downloads, from which you have to click on “Evaluations and Demos”, and then on “JBoss Enterprise Application Platform Evaluation”. The download of the actual Application Server can then be found all the way at the bottom, called “Application Platform 6.0.1” in the case of JBoss AS 7.1.3 (aka EAP 6.0.1). There is a direct link, but it probably won’t work directly as you have to accept an evaluation license first.

But wait, evaluation license? Doesn’t that mean this is a derivate that’s not open source anymore? As it appears, this is not the case. These EAP builds are still fully open source, and a source archive is even provided as a download from the same page. But despite the fact that it’s still open source, the binary build cannot be used freely. I’m not a lawyer, and thus it’s a bit difficult to understand how this can be true. How something can be a derivative of a fully open source product, be a fully open source product it self, but still can not be used freely. Undoubtedly JBoss has this legally covered, but for a simple user such as myself it’s not easy to understand.

There is a large discussion about this on the JBoss community forum and Jason Greene (project lead) goes to great lengths to explain the situation, but a lot of questions remain. One way around the restrictions imposed by the evaluation license is to build the code from source:

Jason Greene:

Self build and support EAP – You get some of the benefits of the enterprise releases (e.g. patches to older major versions and so on), but you have to invest time and energy to build and maintain/verify your app server distribution bits.

However Rich Sharples remarks:

Right now we do not have a way of making EAP easily buildable for the general public (nor does the L-GPL or GPL require us to)

Until thus far this situation has not been resolved. One detail that comes up often is that EAP provides patches for “older” releases. In that thinking, if you want the latest and greatest you can get the community edition (AS), and if you want stability and accept older functionality, then you can buy the enterprise version (EAP). However, for nearly a year now, the EAP version is the latest and greatest. The last community release as mentioned is 7.1.1, so for all intends and purposes, the EAP versions corresponding to 7.1.2 and 7.1.3 are both the latest and greatest as well as the most stable release.

But about how many bugs are we exactly talking? Is all of this really worth the trouble? Let’s take a look.

There were 400 bugs fixed for JBoss AS 7.1.2.Final.

Then there were some 234 fixes for JBoss AS 7.1.3.Final.

Additionally there are even more fixes done. Namely, the mentioned 7.1.2.Final and 7.1.3.Final are just tags in the JBoss AS repository. This tag is presumably cloned into another repository, and there more fixes are done. Eventually, 7.1.2.Final became 7.1.2.Final-redhat-1 when it was released and 7.1.3.Final became 7.1.3.Final-redhat-4. Those additional fixes are mostly publicly tracked. Mostly, because there seems to be some tracking going on at restricted pages.

For 7.1.2.Final-redhat-1 there are 40 issues mentioned.

For 7.1.3.Final-redhat-4 there are 36 issues mentioned, but there are 3 intermediate versions with 126, 34 and 86 issues fixed.

Of those additional issues, further complicating the AS/EAP split is that an amount of them are direct clones from issues in the JIRA for AS. Those start with the word “CLONE”.

In total we have thus at least 634 fixes, and then some estimated 150 additional fixes (guessing the overlap is about 50%). So this are approximately 750 fixes, among which are some that are just by themselves a blocker for using JBoss AS 7.1.1 (depending on your use case). It thus definitely seems to be worth it to go for the 7.1.3 release instead of the 7.1.1 one.

Even though the EAP builds are open source and have their source available for download, there doesn’t seem to be a public repository for those ‘additional fixes’. The 7.1.2.Final and 7.1.3.Final tags however are directly accesible on Github. Since those are just tags, and not actual releases, there are no artifacts available for them in a Maven repository. For the EAP builds, there is as mentioned above no source repository available. Instead there is a public FTP server where the source is hosted (this is the same source as is also available as an archive from the restricted download page). Additionally, there is a Maven repository. There is the following somewhat disheartening disclaimer though at the root:

Red Hat reserves the right to modify the behavior and content of this repository or remove it completely with little or no notice.

The question after all of this is though, why does JBoss do all of this? Why does it hide the releases with bug fixes and why does it try so hard to keep up the illusion that JBoss AS and JBoss EAP are two completely different products?

The answer as stated in the above referenced forum discussion is that it mostly has to do with monetization. JBoss as any other company does have to pay its developers. Even open source developers of course need to be able to buy food at the end of the day. The thinking goes that if all binary builds were freely available, then less people would be inclined to buy a support contract. The support contract not only provides you with support, it also gives you access to the binary builds without the restrictions as opposed by the evaluation license. So with this setup, JBoss benefits from open source in that a lot of people from the community are able to report bugs with a detailed analysis of where things go wrong in source, possibly even with patches attached that fix said problem. Simultaneously they also, kind of, benefit from the closed source model, where you can charge customers for the software itself.

It’s undoubtedly a difficult balance, since as said even the restricted JBoss EAP builds are still open source and JBoss remains an open source company. The split between AS and EAP must eat away at least some resources as well. The clone into another repository, the merging of changes done there back to the mainline, keeping duplicated (cloned) issues, creating Eclipse server runtimes that are nearly identical, a separate Maven repository, etc etc.

Personally I wonder if in the end all of this is really worth the trouble. Why not just release every version as “JBoss AS”, put every version on the public download page, and then offer a support contract independent of access to the binary builds. If it’s really needed, some versions could be tagged as being specifically allegeable for support. Just like Canonical does with Ubuntu. Every version is freely downloadable and support can be bought separately. Some versions are supported for a longer time and get the “LTS” tag.

At the very least, JBoss could probably do a better job in advertising that there even is a 7.1.2, 7.1.3 etc available that are bug fix releases. I’ve been a JBoss user for some time and it wasn’t after some years that I finally discovered what was going on with EAP. Before that I just thought that EAP was the name of their support program. I literally had no idea that there were entire series of JBoss releases that were only available via EAP and thus didn’t appear on the public download page.