Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Council Meetings

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.

Advertisements

Written by Mike Milinkovich

May 19, 2005 at 11:12 pm

Posted in Foundation

3 Responses

Subscribe to comments with RSS.

  1. I’d like to point out that you’ve left out the Visual Editor project from your list. The VE team plans on delivering the 1.1 release shortly after 3.1 comes out.

    Jeff Myers

    May 20, 2005 at 5:27 pm

  2. I like this list. Especially the last point about community involvement is very important. Also, coordinating releases across all Eclipse projects is a good idea. As a software vendor that builds a solution based on several Eclipse projects it’s important for us to have all major components updated in one single step. This brings a lot benefits to our development. We have a better planning for our roadmap and we are up-to-date with the latest Eclipse releases.

    Gunnar

    May 21, 2005 at 4:43 am

  3. Jeff – you are right, I ommitted Visual Editor by mistake. My apologies.Gunnar – yes, the release co-ordination was largely motivated by a desire to help those who build software products on top of Eclipse. It should definitely make their lives easier.

    Mike Milinkovich

    May 22, 2005 at 7:54 am


Comments are closed.

%d bloggers like this: