Note: I previously scheduled this post to be auto-published on Friday June 30th but something went haywire with my Typepad account and it didn't happen according to plan. I had to fiddle with a couple of admin settings to get it to republish.
To start with a bit of background, last week I was granted a briefing about (what was at the time) the upcoming Eclipse Europa release, thanks Ian. Nevertheless, I made a mental note to put together a blog post on what I took from the briefing and publish it sometime after the official release date this week. However, things didn't go according to plan through the remainder of last week and the early part of this week was marred by a re-injuring my lower back (once you hurt it the first time, it's much easier to throw it out of place again) so I wasn't able to get a timely post done.
Anyway, by the time I got around to writing this, the details of the Europa release had been pretty well dissected, analyzed by a good mix of those who were aware of it (Cote' put out a really sharp post on Wednesday). As a result, I thought it appropriate to take a bird's eye view of not only what Europa is as an Eclipse release train but its significance as a model for the evolution of software development and delivery.
In my eyes, the way in which the Europa release train was assembled represents a sort of uber effective form of open source software development and delivery. As an open, inclusive, distributed, collaboration-driven effort it is what has become an emergent option for developing high quality software products. Granted, Eclipse isn't the only or the first open source community to have successfully embraced this model. Yet, I think what allows it to stand out are several things:
- Eclipse is an open development platform: Meaning its not only a platform in the theoretical sense, but also from an architectural perspective.
- Releases contain significant feature changes: Eclipse hasn't (and may never) reach the point where the priority is maintaining stability at the expense of adding/improving features. When the size (17 million lines of code from 19 countries for Europa), of the code base is factored in, the scale and scope of organizing a release train becomes quite lucid.
- Serves as an umbrella for significant sub projects: Whether they target, enterprise development (SOA Tools Platform, Mylyn, BIRT, for example) or exist as runtimes/frameworks (Graphical Modeling Framework, Equinox) Eclipse must integrate a number of significant individual projects without impeding on their independence.
- A significant user base: The numbers don't lie...3.7 million downloads of the production release of Eclipse 3.1 and 3.2 SDK during the first 7 months of 2006, alone.
You could make the argument that one or all of the above are shared by a number of notable open source projects (the Linux kernel might be considered as one), but would be hard pressed to identify very many which do so at the same proportion as Eclipse. For this reason, the efficiency of the process which brings a single release together is altogether striking. Of course, there are shortcomings but considering the breadth and depth of the Eclipse community they are to be expected. By tying methods, that include frequent milestone releases, independent project governance, and incremental run-throughs for builds, together, Eclipse has emerged as a community-developed, integrated product fully equipped for downstream use.
If you take a look at what Stuart Cohen, the ex-CEO of the Open Source Development Labs is attempting to do with the Collaborative Software Institute, you'll see an approach which is attempting to reap the same benefits, enjoyed by efforts like Eclipse, of open collaborative practices within the context of IT-business partnerships. Even if it's difficult to forecast how successful the initiative will be in duplicating a similar set of elements towards equally analogous outcomes, the model has proved worth the consideration.
Yet the context of what Eclipse has accomplished shouldn't be limited to the amplitude of the open source universe, but can be viewed as a portrait of massively distributed software development done correctly. Those with experience in the corporate development arena can relate to the fact that large scale software engineering is fraught with more than its share of pitfalls. Coordination of sizeable teams is no easy task, especially across different geographic locations. So perhaps the fact that an open source project (in this case Eclipse) is able to make pre-appointed release dates fit with aligned version compatibility, says as much about the strengths of open source as a productive force than anything else...a reality which will, most likely, continue to shape the next phase in the evolution of both closed and open source software development and delivery.