I thought I might publish the English version of an interview I did for the recent issue of Eclipse Magazin (with permission of the publisher, of course). The German version is a delightful bit of prose that my Mother now displays proudly.
I was asked a total of nine questions. Here are the first two:
0. Wayne you are Director of Committer Community and Evangelist in the Eclipse Foundation. What does that exactly mean? What are you doing?
The new responsibilities that I’ve recently taken on fit pretty well with my older ones. As an Evangelist, my role is that of making sure that people know about what’s going on at Eclipse and getting them excited about it. The Director of Committer Community, is still very much an evangelism role, but it’s more about helping projects develop their own community. More pragmatically, I am responsible for the Eclipse Development Process. I don’t see the role as one of enforcement: it’s more a role of making sure that Eclipse committers understand why the various bits of the development process are important and helping them implement it.
1. The tradition of the Eclipse Simultaneous Releases started in 2006 with Callisto where we had 10 participating projects. What was the reason for gathering 10 different Eclipse-Projects in one Major-Release?
Actually, if you look a little further back, you’ll find that a few projects were doing this before we formalized the concept with Callisto. On June 28/2004, both the Test and Performance Tools Platform (TPTP) and C/C++ Development Tools (CDT) projects released alongside Eclipse 3.0. Then, on June 28/2005, they were joined by Web Tools, Business Intelligence and Reporting Tools (BIRT), Eclipse Modeling Framework (EMF) and Visual Editor (VE).
If you’ve been around long enough, you’ve probably experienced one of the more pragmatic reasons for gathering Eclipse projects together into a common release: it makes it easier to adopt Eclipse Technology. Consider the very popular PHP Development Tools (PDT) project’s dependencies. In order to use the PDT, you need to have very specific versions of the Eclipse Platform, EMF, DLTK, DTP, GEF, and WST and XSD from Web Tools. Now, all of these projects are on the Galileo release train, but imagine if they weren’t. Imagine if each of these projects released on its own schedule. Imagine if all of these projects were accessible only through their own individual update sites. It’d be impossible to add PDT to an existing Eclipse configuration if this were the case. Imagine now that you want to use some other code that requires different versions of the same dependencies. In short, it’d be a mess. In fact, this is what life was like in the days before the release train.
Making it easier to get the bits was a big motivation for the release train, but so too was increasing communication and reducing redundancy across the projects. With increased communication, we’ve seen, for example, projects consolidating on a single version of a particular third-party library rather than including two different versions (or, as was sometime the case, the same version packaged in different ways). We’ve seen functionality leveraged from one project to another rather than being reinvented. We’ve seen better testing resulting in an increase in overall quality, along with a significant increase in the number valid combinations of the many plug-ins produced by these projects.
