In-Depth

Europa a Triumph of Process

Sneak a peak at the process by which the Eclipse Foundation makes possible synchronized project releases.

• By Peter Varhol
• June 1, 2007

As the Eclipse Foundation gets set to make available its omnibus "Europa" package of Eclipse projects, it is worthwhile to look at the processes that made it possible to develop, test and simultaneously distribute 21 projects, developed by 25 organizations in 19 different countries. For the second year in a row, the Eclipse Foundation has orchestrated a massive delivery of software built by dozens of different teams and hundreds of individuals around the world.

This is the fourth year in a row that Eclipse has shipped a new version at the same time (the actual date in each year may vary by a few days). In the last two years, the base Eclipse platform has shipped with other Eclipse projects, last year as the Callisto release and this year as the Europa release.

In an era of incompatible software, long periods between releases and dependencies that drive development teams crazy, Eclipse has seemingly accomplished the impossible, or at least the difficult to imagine. The Redmond Media Group (RGM) spoke with Eclipse Foundation Executive Director Mike Milinkovich on how the foundation manages these complex development and delivery efforts.

RMG: How would you rate the complexity of the Europa release over last year's Callisto release?

MM: It's more complex, certainly, but I wouldn't say that it was double the complexity, despite almost doubling the number of projects involved. We learned a lot of lessons from last year and, in doing so, greatly reduced our workload. We'll get better still at it in the future.

RMG: Why do you do this type of release?

MM: Not so much to prove we can do it as to address some of the issues of making our various projects compatible with each other. By shipping together, we are able to do some interoperability testing on the projects. This ensures that all of the project versions being released do, in fact, work together.

RMG: I've attempted to assemble Eclipse configurations to run specific tools. Because of version mismatches and quirks when different components come together, it can be a challenge.

MM: Right. And we've also created the Eclipse Packaging Project. Rather than provide a single Eclipse download with source code, this project offers four prepackaged configurations — for Java development, enterprise Java development, C/C++ development and Rich Client Platform plug-in development. The lion's share of Eclipse downloads are used for one of these purposes. We've tested the components of these configurations together and can provide a level of assurance that they work together well.

RMG: That's significant. In these broad cases, Eclipse users won't have to do their own integration. Have you publicized this?

MM: No, this is relatively new, and we haven't made a big deal of it. But we do pay attention to what our community tells us, and this is one of our responses. By downloading the tested package that best meets your needs, you should be farther along in your use of Eclipse than in the past.

RMG: I'm interested in the processes by which you are able to undertake and deliver on such a wide-ranging development effort as Europa. I imagine that OSGi (the Open Systems Gateway initiative that forms the foundation of the Eclipse plug-in model) is the key to that success.

MM: From a technical standpoint, that's true. But there's also the part of the process that deals with team communication and agreement on shared goals. Both the technical achievements and the social and communications achievements are probably equally responsible for our success.

RMG: That's a good point. How do you achieve such communication with these diverse projects around the world?

MM: Probably the most important thing we do is have milestone meetings on a six-week cycle, and use that cycle to get feedback from the community. Through experience, we found the six-week review cycle to be optimal. It was infrequent enough to get meaningful information back from the community from the previous milestone, while frequent enough to foster communications between the teams responsible for the projects.

RMG: What's in store for next year?

MM: I'm told that our next release has been named "Ganymede," and the timeframe is the same for next year. It's still too early to talk about what that release will consist of, but we're already starting to do the planning for it.

Since you wanted to talk specifically about the process behind these releases, I'd like to add that software is built by people, and it is the people we have working on Eclipse that makes this process work. We have over 600 committers who are doing an outstanding job at making sure that these projects are not only on schedule, but also deliver quality code to Eclipse users.

Ganymede, incidentally, is the largest of the moons of Jupiter. If that trivia fact has any bearing on next year's Eclipse release, we will likely see a still larger collection of projects on tap to ship at this time next year. Should the Eclipse Foundation manage to execute on a multi-project release for the third year in a row, it will indeed be a triumph of the unique structure and process used by the organization in achieving its ambitious goals.