In case you are wondering this has nothing to do with the recent Java security vulnerability. That vulnerability is pretty specific to Java Applets and does not affect GlassFish or Java EE in general. More on that soon...

We are currently focusing hard on pushing out the GlassFish 4/Java EE 7 release. So hopefully it's understandable that we do not plan to do a separate Open Source maintenance release of 3.1.x. For similar reasons, there is also no plan to do another Open Source release of 2.x. As a rule, we typically only forward patch on the Open Source releases (i.e. if an issue in 2.x applied to 4, we would forward port the fix in the Open Source release).

Now, I'm sure this is not what you wanted to hear. There really isn't an easy way to say this, so I'm just going to say it (and honestly, I'm not sure there is a reason not to be totally direct and straightforward on this):

At the end of the day, the people that work on GlassFish (including me) need to go home, feed their families and pay their bills :-). The only way to make sure that happens is keeping GlassFish commercially viable instead of being at the total mercy of Oracle's managerial discretion. The way GlassFish is monetized has been very transparent for a long time and it seems to work well - we maintain periodic open source public releases, make patches available to commercial customers sooner and support older versions for as long as the customer wants or until the version is end-of-life.

Personally, I don't think that's too unfair or significantly different from how JBoss (I mention them only because I've worked with their software extensively as a consultant) or Caucho (I mention them only because I've worked with them) tries to make a modest, sustainable amount of money from Open Source.

Reza, thanks a lot for your clear statement. There is of course nothing wrong or unfair about this update policy, it has been explained before in the second "useful link" in your original post, but I believe many GlassFish users, including myself, have not realized the full impact of this policy.

In fact, as long as there used to be a not too frequent but regular update release cycle for GlassFish Open Source 3.x, it wasn't so obvious, but it is now clear that GlassFish Open Source 3.1.2.2 users only have the following options:

- stick with this release and survive without any maintenance or security updates until GF 4.x is stable enough for production

- build GF 3.x from source, doing their own dependency upgrades and developing their own patches

Regarding JBoss, I do see a significant difference. They follow a similar dual strategy with their JBoss AS 7/EAP 6 releases, and they have stopped publishing binary builds of the latest 7.1.x releases, but at least all sources remain public and anyone can build their own binaries by git clone & mvn install. And an EAP support contract is more or less affordable even for small and medium enterprises.

To sum up, I've enjoyed working with GlassFish 3.x in the past three years, but this is now a dead end where the business model of the company I work for requires an alternative platform.

You should by all means choose the vendor/implementation that best meets your needs. As you know, allowing for vendor and implementation choice is a central goal of Java EE after all. JBoss is a very good Java EE implementation and Red Hat is a great vendor. I personally have many good friends that work on JBoss.

I really feel I should comment on a few things though:

* Patches are not made available in the community version of JBoss either. In fact, neither forward ports nor backwards compatibility is guaranteed outside of JBoss EAP and no QA of the community version takes place. In case of GlassFish Open Source releases, all of these things are available. You can read further details about JBoss community vs EAP here: http://www.redhat.com/products/jbossenterprisemiddleware/community-enterprise/. If you look around a bit, there are also blogs about GlassFish vs. JBoss patch management.

* While it is hypothetically possible to build JBoss EAP from source, the build process is far more complex than the community version or even impractical, for a number of reasons that you can research yourself.

* The release cadence for GlassFish has remained the same for quite a long time - about twice a year. We fully intend to keep that cadence going forward.

* We feel GlassFish is quite competitively priced. If you want to learn more details about it, I am happy to get you in touch with somebody knowledgeable in sales. They can explain to you in detail what the options are and how they stack up.

Reza mentioned this thread to me. There are actually several ways to gain very inexpensive access to the frequent patches and updates to GlassFish. If you like the product and it meet your needs, this is one way to show support for the team that builds it, while also making your own life easier.