Life at Eclipse

So we are preparing for our Phoenix project Creation Review next week. There has certainly been a lot of interest in this project and in improving the eclipse.org website. If you don’t mind a little strong language, you can check out these comments from one frustrated user. His comments are strongly worded, but certainly poke at some well known deficiencies. I laughed so hard I had tears in my eyes the first, second and third time I read it. But then again, I do have a fairly twisted sense of humour.

Apparently, we have no where to go but up. 😀

Like I’ve said before, our website is showing its age. What started out three years ago as basically a one project community has grown to be something quite a bit larger and more complicated.

Getting rid of frames and moving to an F/OSS content management system are two key requirements we have. Right now it looks like Xoops is leading the pack for us. Has anyone out there had either positive or negative experiences with Xoops?

So this week in Mike’s excellent travel adventures, I am in Portland, Oregon for the gathering of the Eclipse Councils. We’ve just wrapped up three days of meetings of the Requirements, Architecture and Planning Councils.

I am not sure how widely recognized Eclipse is for the ground-breaking work it is doing in creating a commercially-friendly, predictable open source community. Some of the things we are working towards are truly unique.

First, Eclipse is interested in co-ordinating the activities and release schedules of a great number of projects within its community. What we agreed to this week is to attempt to ship pretty much all of our mainline projects on a single combined release schedule. We are already doing this in many ways. This year Eclipse 3.1 is shipping in late June and CDT, EMF, GEF, BIRT, TPTP and WTP will be shipping very soon after. Where “very soon” = 30 days or less. For future major releases we are going to try to pull that in to within 15 days or less. The highly ambitious goal is same day. AFAIK, this is unparalleled within the open source world. In fact, given the quantity and complexity of the software involved, this would be a huge accomplishment for a single -vendor commercial software project.

A large part of the conversation this week was centred around what quality means for Eclipse projects. The Requirements Council came up with this broad outline:

• Production quality: the usability, performance, scalability of the software must be production-ready quality
• Long term API stability
• Predictability: it matters a great deal to our consumers that Eclipse releases are shipped on a predictable schedule
• IP due diligence: Eclipse is setting the high water mark in open source IP due diligence
• Demonstrable community involvement and participation

I would certainly be interested in hearing any feedback on this list.

The Councils also spent a lot of time focusing in on APIs and what our expectations are for API quality for new projects.

The common perception is that Eclipse builds tools. In fact, what our projects do is far more ambitious. Eclipse projects are expected to build frameworks and extensible tools with well-defined APIs which allow for others to build world-class tools. Then we build an exemplary tool to demonstrate what can be built on the API. This is much harder than just building tools.

But it is this focus on APIs, plus the Eclipse plug-in architecture, that have made Eclipse so attractive for commercial tool builders. They know that Eclipse projects are going to provide them well designed APIs which will be maintained and supported for the long term. This can be a tall order for a new project, but everyone has bought into the commitment and are marching towards this goal.

NetBeans just shipped their 4.1 release. Congratulations guys. By all reports it is a much better Java IDE than its predecessor releases.

But this statement included in InfoWorld’s coverage of their release certainly has me stumped:

The Sun executives also expressed doubts about whether the Eclipse Foundation actually is independent of IBM, which founded Eclipse but spun it off into a separate organization last year.

I really don’t know what more the Eclipse Foundation could possibly do to be more independent than it is. From where I sit, I cannot understand how any reasonable person could assert anything other than Eclipse is independent.

But what do you think? Is there something more that the Foundation could be doing to be independent?

I would have thought that having IBM competitors like BEA, Borland and Computer Associates would have put this to bed. Each of these companies are investing $250,000 per year and eight developers into Eclipse. Why would they possibly do that if Eclipse was IBM controlled? Believe me, those companies did their homework before they made those kids of investment decisions.

BTW — here are some numbers that you may find interesting. Since September 2004, the number of Eclipse committers who work for IBM dropped from 79% to 58%. And the percentage of top-level projects led by IBM employees dropped from 66% to 33%. And based on the new proposals that we already have in process, that will soon drop further to 22%, along with the total IBM committer ratio dropping below 50%. (I wonder what the equivalent numbers are at NetBeans?)

We here at Eclipse will gladly take every developer IBM is willing to put onto our projects. The changes in percentages above are the result of growing the Eclipse pie, not by sending away IBM contributors. That would be silly.

But anyone who takes a look at our governance model and Bylaws will not find anything that gives IBM a special position within Eclipse.

Read my lips. Eclipse is independent.

I read this morning an interesting blog entry by Bob Foster entitled Eclipse is not Apache.

I certainly agree with Bob’s conclusions, which I summarize as:

(a) it would be exceedingly hard to use Eclipse as a dumping ground for code (you can also see my post on TheServerSide on the topic. Look for “We’re not a dump”)

(b) Eclipse does a pretty decent job of managing the scope and overlap in its projects.

(c) Eclipse should never attempt to pick winners in the projects. It’s a Darwinian ecosystem, and the best projects will rise to the top. In the end, it’s the consumers who will decide which projects are best.

Yep. Makes good sense to me.

But often I think that the whole “Apache is a dumping ground” or “Eclipse is a dumping ground” conversations are usually just plain wrong. Or at least misinformed. Both of these communities have pretty stringent development processes that weed out the wheat from the chaff early.

There is nothing inherently wrong with a company wanting to contribute existing code to an open source project. But the real test in our minds is always whether there are committers and contributors who are willing to form and support a vibrant project. Frankly, we would not take a wad of code that did not come with a development team, because code without developers is not an asset, its a liability.

But a code contribution accompanied by its developers and a commitment to continue to invest in its evolution is a pretty decent start for a project.

So I have been on the road again this week. First stop was Germany where I was speaking at the JAX conference. The buzz and energy around Eclipse is huge in Germany. Based on a show of hands, at least 90% of the crowd at JAX are using Eclipse for their Java development.

Germany is now the proud home of the world’s first Eclipse print magazine. The EclipseMagazin current edition is focused on using the Rich Client Platform, along with a preview of Eclipse 3.1. There are also articles on AspectJ and developing Python applications using Eclipse.

Today I was in Paris speaking to the Java Club here. Along with me were presentations from BEA, Ilog, Awoma, Versant, Omondo and ObjectWeb. It was certainly pretty cool to see this mix of large and small companies talk about the products they have been building with Eclipse.

Vladimir Varnica of Omondo really helped to get this event pulled together. Omondo is a pretty interesting company in that it is an Eclipse “pure play” venture. Not only are their EclipseUML Studio products built on Eclipse, but in a way their company is named after Eclipse. When Vlad and his team-mates wanted to start their company in 2002 they were searching for a name. There was a solar eclipse that year, so they searched for geographic landmarks which were under the full eclipse. And voila, Omondo it was. Now that’s a company dedicated to Eclipse!