JavaOne Scoreboard: Who Eclipsed whom?

OK, this is my last JavaOne post.  I hope. Who were the front-runners and who were the also rans?  If you read the rest of my coverage, then it should come as no surprise to you that the fabled IDE (integrated development environment) lives at the heart JavaOne's big story this year.  But, if there's one factor that was even more important, that factor was open source.
One thing that's clear to me, at least from the posturing that took place at this year's event, is that it doesn't matter whether or not a vendor's main plays are its servers (eg: BEA with WebLogic) or its IDEs (eg: Borland with JBuilder), or both.  The bottom line is that  they're all trying to figure out how they'll worm their way to success in an increasingly open source-oriented world.  Part of their problem is the symbiotic relationship that often exists between their development tools and their servers -- in other words, how one often promotes use of the other -- and how the open source-based Eclipse IDE's rise to superstardom has fouled things up a bit.
In the early days of the enterprise edition of Java (was "J2EE," now just "Java EE"), you had vendors like BEA, IBM, and Oracle who sold J2EE implementations.  At their core, these implementations were 100-percent compatible with each other (by virtue of Sun's compliance program) while on the fringes, through the use of proprietary extensions, they each offered some functionality that the others did not.  To easily take advantage of any vendor-specific functionality, developers were best off with their J2EE vendor's matching IDE.  For example, for BEA, WorkShop goes very nicely with its WebLogic application server.  For Oracle, JDeveloper went with Oracle's iAS.  For IBM, WebSphere Studio Application Developer (WSAD) went with WebSphere.
In and of themselves, each of the vendor-specific IDEs were capable of creating portable Java applications that would run on any of the other vendors application servers.  Developers, for example, that liked Oracle's JDeveloper could theoretically create applications for BEA's WebLogic. But they had to be very careful not to invoke any of Oracle's J2EE extensions -- ones that JDeveloper makes it easy to invoke.  If they did, then WebLogic would choke.  So, already, you can see the method to the madness.  If you're Oracle and you expose developers to your IDE, and your IDE has some stuff in it that developers can't use on their non-Oracle application server, then they might start thinking about switching to Oracle's application server. 

Likewise, if you're on BEA's application server and it has some really cool features that you want to take advantage of and you're not using BEA's IDE (or an IDE like Borland's JBuilder that's designed to support WebLogic), then using those features could be painful enough that you'd end up switching to a more supportive IDE. It's a one-two punch in either direction and it was an effective formula for J2EE ("Big Java") vendors.
But this multiple IDE environment created a big problem for both third-party tool makers as well as developers.  The beauty of IDEs is that third-party tool makers -- for example, ones that specialize in version control -- can plug into them, thereby offering their specialized functionality from within the same context that the developer is developing in.  The problem, if you're such a third-party tool maker, was that with so many IDEs on the market, you couldn't easily support all of them. The plug-in architectures -- aka the "frameworks" --  were different enough that a plug-in for one IDE had to be rewritten to work on another. So, not every third-party tool was available for every vendor's IDE. For developers, this made it even more difficult to pick IDEs.  If, for example, the IDE you wanted most (because of its support for a specific application server) didn't support the version control plug-in you wanted most, you'd be in a catch-22, forced to make some sort of compromise.
Then, IBM, which from a Big Java marketshare perspective was far back in BEA's rear view mirror,  took things up a notch by open sourcing a significant part of WSAD.  The move gave birth to the Eclipse IDE.  Not only did that move expose J2EE developers to some Sun-despised ways of developing Java applications, it also exposed them to the functionality they could have if only they had WebSphere.   The move was at least partially responsible for the way WebSphere has so signficantly closed or overcome the marketshare gap with WebLogic (and it has done one or the other no matter what research you look at). It was a brilliant stroke by IBM. So successful has Eclipse been that it has taken on a life of its own as an independent IDE and, because of its open source nature, it's now a force to be reckoned with for the other IDE/server providers.
For starters, with Eclipse's rise to near de facto standard status, the old one-two punch bond that existed between similarly bloodlined IDEs and J2EE servers has been signficantly weakened if not wiped out altogether. "Free" worked.  Now that so many developers are staring at Eclipse on their displays versus some vendor specific IDE, the vendor specific IDEs are no longer very effective at marketing J2EE servers.  To make matters worse, now, there are open source servers too (like JBoss and JOnAS).  To get the proprietary features back in the faces of developers again (in hopes of selling more servers), they only have one choice and that's to make their tools compatible with Eclipse.  And this, much to the chagrin of the Eclipse's rival (the Sun-backed NetBeans), is what J2EE vendors are doing.  Only they're doing it to different extents, some better than others, which leads me to my scoreboard for this year's JavaOne.  Unfortunately, I'm only scoring a few vendors -- the ones I spoke to.  But when you see how they're positioned on what's best described as a spectrum, you can figure out where your favorite vendor fits in.
At the extreme right end of the spectrum (scoring the best) is BEA.  In hopes of wagging the dog by the tail, BEA has long given away its WorkShop IDE.  So, like Eclipse, WorkShop is free.  But now, it does something else like Eclipse.  It uses the same underlying framework.  This means that plug-ins designed for Eclipse will also work in WorkShop and vice versa.  Now, Eclipse developers can try Workshop without sacrificing Eclipse plug-ins.  If they like it, they might even see some WebLogic stuff that they want to try out, which could mean new WebLogic customers.  But just in case Eclipse developers don't want to give WorkShop a try, BEA is making sure that they still have access to largely WebLogic-esque technologies like Beehive.   Still not enough?  Well, to get people interested in WorkShop (which in turn might get them interested in WebLogic), BEA is making sure that WorkShop supports Apache's open-sourced Tomcat and Geronimo too, as well as two other popular open-sourced Java frameworks known as Struts and Spring.   Those "support" offerings could end up as revenue on BEA's bottom line since there aren't many places for developers to go for such support.
Next down the line (heading to the left) is IBM.  IBM doesn't have to do anything to be Eclipse-esque.  Given Eclipse's roots in WSAD, it is already natively so.  But, whereas BEA's WorkShop is free, the full-blown version of WSAD is not.  BEA may be forcing IBM's hand; and,  to develop interest in WebSphere, IBM may end up making WSAD available for nothing.  It will be interesting to see where this heads.
Next down the line is Oracle.   At JavaOne this year, Oracle announced that it was going to start giving away its IDE.  So, yet another free IDE.  Only there's a problem.  It's not based on the Eclipse framework and Oracle has no plans to go there.   This is a problem from a plug-in perspective because "free" is simply not enough incentive to draw away developers who are already using Eclipse or one of the other Eclipse-based IDEs from BEA and Borland.  In a move that saves some face -- slightly bridging Eclipse to JDeveloper -- Oracle is making sure that both Eclipse and JDeveloper developers have access to the same Java Server Faces (JSF) and Enterprise Java Beans 3.0 tools.  This equates to a third-party developer developing separate plug-ins for two IDEs where it could have stuck to one. Since JDeveloper is free, the EJB and JSF support probably won't cost you anything as a part of JDevelper. But when asked if the corresponding plug-ins for Eclipse will be open-sourced, the answer was that pricing wasn't yet set.  Prediction: With Borland and BEA on the Eclipse framework and with Workshop also available for free, "free" did not put JDeveloper into the game.  Expect Oracle to look for ways to get JDeveloper on the Eclipse framework so it only has to worry about one plug-in architecture (and that all the existing Eclipse plug-ins work on it).  They'll give that away and they'll also give away some plug-ins that work on Eclipse in hopes of wagging its dogs by the tails: selling more of Oracle application and database servers.

Then there's Sybase--one of the other vendors I spoke to.  Sybase appears to be in the rather unfortunate position of just now figuring out it has to play in an open world.  Sybase is an example of a company that remains nearly entirely proprietary -- virtually all the way on the left end of the spectrum.  To get some game, the company announced that it will be building an SOA plug-in for Eclipse called WorkSpace.  That's it.  No open sourcing of any tools.  Nothing new for free.  Just an announcement that it has some plug-in that itself represents some several integrated tools that Sybase saw no value in unbundling as separate Eclipse tools.  In my interview of Sybase's executives, I was told that the integration that Eclipse does between plug-ins wasn't good enough.  By itself, the announcement isn't all that bad.  But looking off to the right end of the spectrum.....