Open Source Software = Predictable Software

The stereotypical image of an open source project is a bunch of hackers working in dark rooms, scratching their itches and releasing software “when it is ready.” Of course, this is far from reality for many of the mainstream, mature open source communities like Linux, Mozilla, Eclipse and others. These open source communities have very mature and sophisticated release processes that deliver new updates in a very predictable manner and are the envy of the software industry, including commercial software vendors.

In the Eclipse community we are very proud of our annual release trains – a great example of predictable open source software. For the last 8 years, Eclipse has shipped a release at the end of June; this past year, our release included 62 different project teams and over 400 developers from 50 different organizations. According to Ohloh, this represented 46 million lines of code, over $700 million R&D investment, all released on the same day, at the same time! And since we have done it for the last eight years, our community has come to expect it and plan for it.

Many people ask why and how Eclipse does the release train. First the why: many companies embedd Eclipse technology into their applications and products. In fact, we want people to use Eclipse technology to build innovative software – it’s something we encourage. However, Eclipse is not just one project; there are over 200 different open source projects at Eclipse, many which are inter-dependent on each other. Organizations will incorporate many of these Eclipse projects into their applications and products. To support this ecosystem of adopters, we need to have a predictable release schedule to allow for downstream planning. We also need to ensure the inter-dependent projects are compatible with a new release and available on a similar schedule. The release train makes it possible to ship quality software to a large community of adopters.

How we do the release train is a combination of three best practices: 1) good development process, 2) governance and 3) architecture.

1. Good development processes. The Eclipse way of developing software is to have a milestone release every six weeks. We have already had our first milestone release for June 2012, this being less than two months after our June 2011 release. The project teams essentially practice doing a release every six weeks, which allows us to get the bugs out of the system long before the final release. We also have a very open communication channel, using wikis, bug tracking systems, mailing lists and conference calls to ensure all projects teams are coordinating requirements.
2. Distributed Governance. Each project team is responsible for their project plan and release requirements, and each project volunteers to participate in the release train. While there is a set of release train requirements that each project agrees to adhere to, there is no central decision making authority.
3. Architecture. Eclipse is based on a common architecture model based on the OSGi standard. This allows for a modular architecture instead of a monolithic release. Projects might have dependency on other projects, but the interfaces and extension point are well defined and documented in an open manner.

Open source software has changed many aspects of the software industry. One aspect is demonstrating how to deliver large-scale software projects in a predictable manner. Eclipse and other projects have shown open source software is also a source of predictable software and we expect it to remain that way.