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.
