The Eclipse Phenomenon – Lee Nackman

This keynote covers the history of Eclipse.

Started off with a vision, which was discussed within IBM.

In November 1998, the OTI team was given the go ahead because they had experience building several generations of IDEs. Also, another IBM team was going to build the first product on this new platform.

Why two teams? To ensure that there was a clean interface. Also, the two teams were separate organizationally within IBM. There also needed to be a strong advocate for the platform (John Weigand?) to protect platform integrity. I guess the opposite is Microsoft Windows APIs which have all sorts of secret hooks for their apps which are documented in several books on the market.

An interesting feature was that they wanted to build a great Java IDE to attract people to the platform. Good strategy. Come for the Java IDE, stay for the platform.

An interesting goal was that they wanted to be competitive with Visual Studio, especially on Windows. This drove the SWT decision for example. I guess this also drove the platform decision to loosely couple the JDT from the Platform, which as far as I know, is one thing why it makes it different from NetBeans.

What’s behind the name? e-Anything was good at the time, which is right around the height of the Internet bubble. However, the lawyers didn’t like the name since it couldn’t be trademarked. Eclipse.org was actually owned by a girls soccer team in Illinois. The name actually means “to eclipse Visual Studio.”

Circa 2001: Microsoft Visual Studio was growing. Java tools and application servers market was becoming fragmented. IBM needed developers to come to its Java middleware (WebSphere.)

So: the decision was made to open source in November 2001. IBM had a good experience with Apache. They also had an investment in Linux.

When Eclipse was first open sourced, there was an Eclipse consortium with 9 members and eclipse.org. An important principle was established, which was a separation of concerns between the open source community which controlled the code and the consortium.

Eclipse 2.0 and 2.1 later was what drove widespread adoption. I’d add here that 1.0 was only on Windows, I think. Later, Linux with Motif came out, but looked quite bad in my view. 2.x added more platforms which helped Eclipse along. Also, IBM funded some seeding programs to help spread Eclipse.

Eclipse was a new model – open source with committers that are employees of a few vendors + leadership from one company. This needed a balance so that IBM wouldn’t dominate, but also the platform maintained conceptual integrity. In my opinion, this is an extension of the “benevolent dictator” pattern that most successful open source projects exhibit, but at the company level instead of at the individual level.

As Eclipse grew and became more well-known, there were growing pains: It seemed that IBM was controlling it, so vendors were wary of joining. The ones that did join were not that serious yet. It also did not make sense to write a check to IBM (even with a memo for “eclipse”) for many companies.

So, the Eclipse Foundation was created in February 2004, right before last year’s EclipseCon. This seems to have been a good decision. Eclipse 3.0 was a huge hit (and I think the #1 Java IDE now.) There was a big growth in membership, with BEA one of the newest and biggest. From my perspective, the transition has been quite smooth, especially from an operational viewpoint. The perception of Eclipse organizationally as a whole has changed greatly too.

IBM itself has adopted Eclipse aggressively, not just the SDK, not just the Platform, but also EMF, GEF, Hyades/TPTP, and others. I’d also note that they donated even more code in the form of WTP.

One concern of growth: “Will Eclipse do too much?” Too much that there will be no room for tool vendors. Lee’s thought is that there will be a continual raising of the bar. Vendors will have to constantly innovate to keep succeeding.

Another concern: “How to maintain conceptual integrity?” Of course, one way is to maintain the “benevolent dictator” pattern, but I don’t know if that can continue given the way that the Eclipse Foundation is structured. Note that this is one reason why the JCP is structured the way it is. Maybe we could have a “benevolent meritocracy” instead?

One more concern: “How to maintain quality?” Great concern, since one of the dangers of having a platform is that components that are somewhat bundled get a halo effect from the platform. Lee notes that projects can be rebooted, refactored, and/or rearchitected to ensure quality.