Life at Eclipse

It is always great when the Eclipse community works hard on communicating a new and novel idea and then runs into someone who really understands it. James Governor‘s blog post today on RCP is a great example of that.

James is focused on the potential for RCP to dramatically change the playing field for rich client applications. We are starting to see lots of examples of applications popping up all over. And developers are comparing Eclipse RCP against some alternatives that we hadn’t even thought of, such as XUL. (Note that this is not in any way meant as a slight on XUL. I just find it fascinating that a development team even considered them competitive technologies.)

So where is this going?

Amongst other interesting possibilities, Eclipse RCP has the potential to be the best friend the Linux desktop has ever had. For Linux to really take off on the desktop, it must dramatically increase its share with both ISVs and enterprise developers.

ISVs need RCP because it allows them to build native applications which run on Linux and Windows. No ISV that cares about either expense or quality is going to maintain completely different code streams for products on both Linux and Windows. RCP offers them a great technology for building truly native applications which run on multiple platforms.

Enterprise developers face a similar issue. It will take a long time for large enterprises to roll out Linux desktops in their organizations. Co-existence with the incumbent (usually Windows) for their applications must be a key part of any strategy to migrate to desktop Linux. Not only does RCP provide IT managers the ability to build and deploy multi-platform native apps, but it allows them to manage those deployed applications.

The resurgence of Apple as a client platform that really matters makes this even more interesting, as ISVs in particular would like to ideally target all three of these platforms. Which makes the RCP story better still.

But the best part of the Eclipse RCP is that it is here now and it is very real. No waiting on Longhorn or Mustang required. The new Eclipse 3.1 is bringing better tooling support and loads of new features in just a few weeks.

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.