Planning for Eclipse 4.0

Earlier this week, the teams and developers working on the various projects of Eclipse began an intense debate regarding the next steps in the future of Eclipse, all triggered by the announcement of the incubation project titled 'e4' on the Eclipse committer mailing-list:

The Eclipse Project PMC is announcing a new component, called E4, as part of the Eclipse Project Incubator.

Component Description: 

During the Eclipse Project 3.4 release cycle, one of the important plan items was "Create the Eclipse 4.0 Plan". The intent of this work was to identify the most pressing issues that would impact the ongoing success of Eclipse, and come up with a plan to address them.  The result was the design of a new platform "e4", which will be the basis for Eclipse 4.0. 

The goal of the e4 component is to provide a public venue for the initial explorations that were done, leading up to the e4 design. We expect to continue to work in this area until we have reached consensus on how the full e4 effort will be structured.

The e4 moniker is a reference to Eclipse 4.0, which would be the next major release number for the classic Eclipse distribution and platform projects. The last three major Eclipse releases shared these version number relationships: Callisto corresponded to the Eclipse platform v3.2, Europa corresponded to the Eclipse platform v3.3, and the upcoming Ganymede release corresponds to the Eclipse platform 3.4.

Historically it has been common practice for these plan documents to outline the thematic goals for a given release of what is commonly called the Eclipse top-level project. Traditionally, the top-level project has encompassed the Eclipse platform, the Java development tools, the Plug-in development tools, and all other components of the commonly referred-to Eclipse 'classic' distribution (the Java and Eclipse Plug-in IDE). This plan format has been used since the 2.1 release of Eclipse, and each prior plan is available on the Eclipse top-level project site. The e4 announcement is a somewhat different approach in that community involvement is being asked prior to the drafting of any plan.

Initially, the e4 project is little more than a community gathering point; a place to track early changes and ideas in code. The goal of opening this project now has been described by many of those involved as an effort to get community input and ideas at EclipseCon 2008, and to then begin drafting a plan based on the community input after that point. Kevin McGuire, an Eclipse committer who primarily works on the Platform UI team, described e4 in this way:

We on the platform team care passionately about Eclipse. We know you do too. We want to see it live a long, healthy life. We want it to serve its community as best it can. When we can’t achieve that it makes us sad. It’s clear to us that for Eclipse as a platform to remain long lived, vibrant, and relevant, it must be able to change. But the weight of a zillion plug-ins, projects, and API means the path of least resistance is stagnation, and the effort to effect change given the current constraint system is becoming monumental.

Therefore, two things must happen:

1. A new space must be carved out in which experimentation can happen, leading to change.
   
2. New people must get involved, bringing with them their energy, ideas, requirements, knowledge, passion.

These two are intrinsically tied.

That is e4.

While there was some heated discussion over the format and approach of the initial project announcement, the e4 project is likely to become a central test-bed for the various transformations that Eclipse will go through to reach its next major milestone. In the past, major version number increments for Eclipse have represented significant changes for the Eclipse project. The transition to Eclipse 3.0 encompassed the move of Eclipse to the OSGi platform, the announcement and creation of Eclipse rich-client platform, and both a look-and-feel and performance overhaul. The expectation is that Eclipse 4.0 will also represent such a major shift.

InfoQ will continue to cover future Eclipse planning decisions as they become available.