And then there were three (three open source J2EE servers)

In the "what sand was my head in" department, by way of Bob Sutor's blog comes a reminder that the Apache Software Foundation's Geronimo J2EE server project has cleared the biggest hurdle towards earning its official J2EE 1.4 wings.   My colleague at News.com, Martin LaMonica, had the story on June 30, but somehow, it slipped below my radar (better late than never).  A  few formalities remain before the ASF's J2EE server actually gets certified.  It's sort of like how Lance Armstrong is assured of winning the Tour de France once he makes it through the Pyrenees and the Alps with the race leader's Maillot Jaune (the Yellow Jersey) still on his back.  Once Geronimo gets certified, that will raise the number of open source servers to attain official J2EE certification to three as it joins JBoss' namesake application server and the ObjectWeb Consortium's JOnAS -- the only two Java application servers to have achieved the honor so far. 

It may take a while before the impact of Geronimo's certification will be felt.   There's been a bit of shaking and moving in open source J2EE circles.  Earlier this year, IBM acquired Gluecode.  Some regard the acquisition as being the equivalent of Big Blue acquiring Geronimo (or at least taking over its ongoing development) since the employees of Gluecode were some of the most significant contributors to the Geronimo project.   IBM also donated its Derby-embedded database to Apache and things could get awfully interesting once a single open source entity starts to offer both a Java application server and a database.  It's also not absolutely clear how IBM will play the Gluecode card long term.  But a few things are relatively certain because of IBM's involvement in Geronimo.  First, in addition to JBoss and JOnAS being out there, it puts significantly more open source pressure on .Net -- Microsoft's answer to J2EE.  Second, because of IBM's involvement in both the Eclipse and Geronimo, you can expect a significant amount of support for Geronimo and anything IBM's Gluecode boys add to it in Eclipse (my prediction). 

Also on the open source J2EE shaking and moving front, under the moniker GlassFish, Sun open sourced a reference implementation of Java EE 5.   "Java EE" is the new rendering of the "J2EE" brand.  Although GlassFish appears to be a fourth open source Java app server (in addition to the other three), Java EE 5 is actually a future Java application server specification that's not even finished yet.   While the move won't have too much impact on the current crop of J2EE servers (both commercial and open source), the effects of GlassFish could be felt once certification testing for Java EE 5 starts and GlassFish turns out to be both the first Java EE 5-certified server out the door (which I'm guessing it will be since Sun routinely beats all other offerings to the punch on such certification) as well as the first open sourced Java EE 5 server out the door.  If the code that Sun is open sourcing is top notch and the developers of the other open source Java EE servers see value in it, they may realize that it's senseless to pour precious resources into a commoditized codebase (sort of reinventing the wheel) when they could be poured into building  Java EE competitive advantage in some other way.  In an earlier blog, I rhetorically asked the question of whether it makes sense for JBoss to continue developing its own code now that Sun's Glassfish is in play.   Then, in the first podcast to go with his Information Manager Journal blog, Scott Mace passed the question along to Marc Fleury during his interview of the JBoss CEO at JavaOne and here's what Fleury said:

Sun's stewardship of the JCP has been good and their track record is very good. They're a company you can trust and they've done a good job of balancing so far the natural tensions that arise when you have coopetition-driven standards.  So, let's give to Sun what they rightly deserve. On the implementation side, they've never been there and somebody commented to me the other day that the more they sucked at their implementation, the more their steward status was in touch because they had no competing interest from a commercial standpoint.  For us to go and work on their codebase at this point makes very little sense. Right. We have a very mature codebase.  We cover ten times the ground in terms of features than their introduction open source offer, we have a portal offering, we have object/relational mapping, we have BPM.  Today, JEMS (JBoss Enterprise Middleware System) is a super platform and that's our strategy going forward.  If there are good pieces that are open sourced over there at GlassFish, then obviously, we'll take a look at it and we may cherry pick things that are good. So far, we're in a wait and see mode. We don't need to do anything with respect to that. 

So, whereas Fleury seemed disinterested at first, he conceded that it might make sense for JBoss to cherry pick select code.  My take? It may have no choice.  In today's environment, there are very few companies that can afford the luxury of home-growing software that doesn't add significant competitive advantage over that which already exists, for free. 

The real rub in adopting Sun's codebase, not just for JBoss but for the other open source Java EE servers as well, would be on the licensing front.  Whereas Sun's implementation is available under the Open Source Initiative-approved and Sun-authored Common Distribution and Development License (the CDDL), the others including JBoss', are available under other open source licenses that would prevent any intermingling of source code.   In other words, they'd have to switch their licences to the CDDL.  Although such switches are not unprecedented, that would be a difficult if not a bitter pill for JBoss to swallow.  On the other hand, if the codebase is simply too irresistible to JBoss and JOnAS, GlassFish could turn out to be a shrewd move on Sun's behalf that not only commoditizes the core codebase of Java EE, but that also sparks a small wave of open source license consolidation around the Eclipse Mozilla Public License-derived CDDL.  Depending on how big that wave is, especially if existing commercial Java EE providers like BEA and Oracle join it (and if other big software companies not in the Java EE space decide to climb aboard), Geronimo and Gluecode SE (neither of which are available under the CDDL) could end up somewhat isolated from the majority of Java's open source community.