JBuilder Moving to Eclipse
Borland's recent announcement that it is donating portions of the JBuilder IDE's codebase to the Eclipse project portends an intriguing set of developments in the Java IDE space.
The first trend is consolidation. Today’s Java IDE market is awash in seemingly identical products. Ten million or so Java developers do not necessarily need dozens of functionally equivalent development environments. By moving JBuilder into Eclipse, Borland simultaneous reduces the total number of IDE competitors, as well as clearly acknowledges this trend. In effect, Borland is taking an approach nearly identical to IBM and Sun - offer the basics for free, charge for the rest.
While Borland's move is not a wholesale departure from their drive to generate revenue from IDE products - the company continues to produce it's Enterprise Studio for Java, and has stated plans to provide commercial support for Eclipse - the migration of JBuilder into Eclipse represents the first line of demarcation between IDE products which are openly available, and those distributed only within the commercial enterprise. From here on out, any company selling a Java IDE must make a decision: Throw in the towel completely, handing the crown over to the open source crowd, or offer a product or suite of products whose feature set departs so radically from what is freely available that it justifies the purchase price.
Along these lines, Oracle’s JDeveloper and JetBrains’ IntelliJ IDEA make for interesting case studies. IntelliJ has long been an underdog favorite in the developer community. The rationale behind this sentiment is evident to any programmer who has developed in IntelliJ - in a nutshell, IntelliJ handles mundane tasks for you in such a seamless manner that you’re able to simply concentrate on the code. JetBrains has found that magical combination of features that separates it from both the standard freely available IDEs as well as many commercial IDEs, justifying its price and existence. JDeveloper is a superb example of how not to build a Java development environment. With a few minor exceptions, no single feature of JDeveloper is unique enough to justify the cost. Oracle would have served its clientele better by aligning itself with an IDE vendor with an already established application (much as they did with their J2EE app server OC4J by relying on Orion), rather than churning out a cliché, redundant product.
This brings us to the second trend, which is not isolated in the commercial Java IDE space, but extends to all commercial software development. That is, the introduction of a quality open source application into any previously wholly commercial product space has the impact of changing the competitive dynamics, where the open source product becomes the baseline by which all remaining commercial versions are judged.
Take Firefox and Opera, for example.
Both browsers offer a more secure browsing platform than Microsoft’s Internet Explorer. Both offer tabbed browsing, integrated search, side panel menus, downloadable extensions, theme customization, download managers, etc. On the features where Opera distinguishes itself from Firefox, most users judge that these differences are not significant enough to justify paying for Opera, when Firefox is freely available.
The same statement is true in regards to Java IDEs. Comparing the feature set of Eclipse or NetBeans to the aforementioned JDeveloper, it can be said that, where JDeveloper’s features differ, these in general are not significant enough to rationalize investment in the latter. Borland has realized that this argument also applies to JBuilder; rather than attempt to sweep the tide, they’ve decided to ride it.