IBM and the Meaning of The

IBM says it is "making a major commitment to Apache Geronimo as the Open Source application server of the future." Sounds good. But what is the meaning of the?

If I said The Hitchhiker's Guide to the Galaxy is the movie of 2005, you might assume I'm recommending it, using the movie as a shorthand to mean "the best" movie. Is that what IBM means by "the Open Source application server of the future"? Or does IBM mean Geronimo is the open source application server of the future? That is, IBM will work to ensure Geronimo is never quite finished or stable so as not to eat into sales of WebSphere Application Server Express.

I'm sure IBM realizes its purchase of Gluecode Software last week -- and thus its acquisition of Gluecode's five staffers who have been key architects and contributors to Geronimo -- fomented discomfort in the open source community. IBM is the 500-pound gorilla. Geronimo contributors and potential Geronimo users are wondering just what are IBM's intentions toward Geronimo. Even Gartner said "some users will ... suspect IBM of attempting to control the open-source community" with its Gluecode purchase.

As of today, IBM has been mostly silent on its intentions. Last week, IBM said it will:
  • Donate an Eclipse plugin to help developers target Apache Geronimo as their J2EE server
  • Devote an unspecified number of IBM employees to work on Geronimo
  • Keep the former Gluecode developers working on Geronimo
In addition, IBM has released some documentation aimed at Geronimo. These actions all benefit the Geronimo open source community.

On the optimistic side, IBM's goals for Geronimo will mesh with the goals of the current team of Geronimo developers and its users -- to create the best available open source J2EE application server. IBM will devote smart developers to working full-time on Geronimo, and Geronimo's features and capabilities will outshine the other two open source J2EE servers, JBoss and JOnAS. Many developers and companies would like an alternative to JBoss Application Server, especially those concerned about JBoss's restrictive license, so IBM's commitment to Geronimo could end up being beneficial to everyone, except perhaps JBoss Inc.'s consulting services.

On the pessimistic side, IBM could use its Gluecode brain trust to swing Geronimo in a direction that benefits IBM and not average users. IBM now controls, through its new Gluecode employees, about half of the active committers to the Geronimo project. The chairman of the Geronimo Project Management Committee, Geir Magnusson Jr., is one of the new IBM employees. The Geronimo PMC controls the direction of the Geronimo project, deciding what features are added and who may contribute to the project.

I think we all want to assume IBM's involvement will benefit all users, not just IBM customers. I think we all want to assume IBM wants Geronimo to be the best open source J2EE server on the market, not the best server for IBM Global Services consulting income. I think we all want to assume IBM will allow the former Gluecode employees to continue their excellent work on Geronimo.

To allay concerns, the solution for IBM is to announce just what it wants to do with Geronimo and what influence it will try to wield over the project. Do they plan to fork the Geronimo project to create a separate version aimed at IBM customers? Will IBM's commitment to Geronimo fade over time, similar to IBM's previously strong commitment to Apache Axis? Do they plan to create add-on tools to make Geronimo easier to use and deploy in the enterprise, and make them available only to IBM customers who purchase 1-year support contracts? Do they plan to restrain its employees from adding powerful features to Geronimo that would make it a WebSphere competitor?

If IBM is truly committed to open source software, it would do the open source community a favor by announcing its Geronimo strategy with a clearer statement. Saying IBM is committed to Geronimo as "the Open Source application server of the future" hasn't done much to quell unease.

Maven 2 will hurt Maven’s adoption

I think it's fair to say that Maven has yet to catch fire among Java developers. Maven is complicated to learn and its documentation is lacking. Most Java developers who are using Ant probably have heard of Maven and its promise of easier automated builds. In fact, a fair number of Ant users probably have it on their To Do List to check out Maven to see whether it will save them time.

But the Maven team's technology preview release last month of Maven 2.0 almost certainly will hurt Maven's adoption, at least in the short term. Maven 2 will slow Maven's adoption probably for at least six months, and probably into 2006 as the new Maven stabilizes.

Why my pessimism? Maven developers shot themselves in the foot by scrapping the goal of Maven 2's backwards compatibility with Maven 1, and introducing new technologies just as obscure as Maven 1's technologies. Barriers for Ant users to adopt Maven have always been Maven's steep learning curve, its scripting language (Jelly), and its semi-enforced ways of organizing a project's files. Now, Maven 2 will change Maven in drastic ways. Maven 2 scraps Jelly in favor of (I'm not kidding) Marmalade. And the favored way of writing Maven 2 plugins will be Mojos, which seems to be Java classes that get inserted into a Maven 2 Plexus IoC container. Not only does Maven 2 introduce an IoC container, it uses one that almost no one has heard of.

In short, why would an Ant user today even considering switching to Maven? If you aren't using Maven today, going to the trouble of learning Maven 1, only to be left with a tool that quickly becomes outdated as Maven developers leave it in the dustbin, would be a waste of time. For those who hate Maven to the point of bile or poetry, Maven's slower adoption won't mean anything. But for Ant users interested in learning Maven today, the Maven team seems to be saying "don't bother, wait for Maven 2."

If you think I'm exaggerating, here are quotations about Maven 2 from the Maven web site: On the positive side of Maven 2, once it matures it might help solve the complexities and slowness in Maven 1 and eventually win over more Ant users. That is, maybe they must kill Maven in order to save it.