This week, as the group winds up its annual EclipseCon conference, it has taken the opportunity to reaffirm the fact that its mission has grown from the early days.
While the group was first known for building an IDE and plug-in model that enabled it to become the Java community’s de facto response to Microsoft’s Visual Studio offering, according to marketing director Ian Skerrett, the group has always had broader goals.
The IDE was just the first place where we could provide a proof of concept of an extensible framework, he said, noting that the common thread of Eclipse projects is the plug-in model itself.
And over the past three years alone, the number of projects has quadrupled, while the number of members has tripled. This week, Oracle became the latest high profile player to join the board.
As we reported several days ago, Oracle’s recent joining of the Eclipse board was in part a reflection of the fact that a company could get admitted to the inner circle even if it wasn’t directly involved with the IDE. In fact, Oracle’s JDeveloper IDE strategy is clearly not Eclipse-bound. Instead, it is focusing efforts on Java persistence, which reflects that Eclipse is moving from development time to a run time framework as well.
In fact, a glance at one of the slides in Eclipse executive director Mike Milinkovich’s keynote provided a roadmap of where Eclipse plans to go, at least for now. Besides the IDE, Eclipse is also looking to make a mark with tooling for SOA, Application Lifecycle Management (ALM), embedded devices, and more recently, a dual rich client path that includes conventional operating systems plus a new aim to provide Ajax tooling.
It’s on that last area where Eclipse’s role may be quite fluid. For now, it is staking out a course to deal with herding wild cats with its proposed stab in Ajax tooling. Yet it is hedging its bets as Milinkovich himself is also a member of the steering committee of the adjoining OpenAjax Alliance.
That of course evokes a number of questions. The whole Ajax area reeks of anarchy given that it emerged through repurposing a bunch of established, unstructured technologies that were repurposed for a role for which they were never designed. And so there are hundreds of tools, each of which with differing libraries and syntax. And it’s in the latter area where, for now, OpenAjax is concentrating its efforts.
Because it’s not certain whether OpenAjax will move into tools, for now Eclipse is taking a preemptive strategy to fill the vacuum. Published reports from EclipseCon indicate that Eclipse’s move into rich Ajax tooling may not be a fait accompli, as some developers might consider it overkill.
Another highlight of the conference is the growing prominence of the OSGi (Open Services Gateway Interface) as the component mechanism powering the Eclipse plug-in model and its new run time. OSGi actually replaced an earlier, Eclipse-developed effort because, according to Skerrett, it was already a standard, it worked, and it was much more flexible and had a much smaller footprint.
Like Ajax, OSGi began life with a different mission, as the home services gateway that was supposed to Java-enable your toaster, washing machine, and refrigerator. While the Java house has yet to be realized (if ever), the OSGi component model proved adept in proving a dynamic software updating mechanism that allowed you to swap components without having to take the system offline. Key to that capability is the fact that lifecycle management is built in: an OSGi component can automatically decommission itself when a replacement is being plugged in.
Driving the mission home, the OSGi Alliance sponsored a track at the Eclipse conference showing how it powers the Eclipse run time.
Nonetheless, as Eclipse begins filling out its mission, the question is whether it really knows where to draw the bounds. When we questioned Skerrett, he admitted that the organization had not fleshed out its response. Stating that the universe of open source projects that can take advantage of the Eclipse plug-in model is growing, Skerrett said that the organization had not gotten around to drawing the lines of where its mission begins and ends.
For anyone that has followed Eclipse, such a development might not be surprising, but it’s certainly ironic. Although the organization was initially spurred by IBM to promote a Java GUI widget technology that rivaled Sun’s, IBM’s real issue was Sun’s control over the Java Community Process.
One of IBM’s beefs was that, with the JCP mission growing so broad, that the community was getting snarled in red tape and bureaucracy and losing its focus. Ironically, if Eclipse cannot clearly define the boundaries of its expanding mission, it could fall prey to the same disease.
