Many enterprise development teams often struggle with releasing software projects on time. That doesn’t seem to be the case with the multi-vendor open source Eclipse Foundation, which for the last seven years has consistently shipped releases from multiple projects on time.
This week, Eclipse Helios shipped with 39 projects in what is known as the Eclipse release train. How does Eclipse manage to organize so many projects and year-after-year hit their release targets? What’s the secret?
The Eclipse way for ensuring its trains arrive on time involves a series of best practices, agility and some organizational governance that is driven by the community of projects.
“Projects participate because they choose to and not because there is anyone telling them to,” Mike Milinkovich, executive director of the Eclipse Foundation, told InternetNews.com.
Milinkovich added that the Eclipse Foundation staff does not overly govern the process either and it is possible for projects to drop off the release train cycle if they choose to — though that hasn’t happened.
From a development perspective, the annual release train is the culmination of a regular and continuous Agile development process.
“Every six weeks we go through a milestone build, so that throughout the year the projects are practicing shipping together,” Milinkovich said. “So six weeks from now M1 Indigo release will happen. I think that regular drumbeat of milestones is a big help in terms of getting everybody lined up.”
While the Eclipse Foundation doesn’t force projects to participate, there are things that release train projects must do once they’re on board. Milinkovich explained that there are technical requirements that each project must comply with in order to be part of the release train. He noted, however, that the list of technical requirements is pulled together by the community of Eclipse projects themselves and isn’t something dictated by Eclipse Foundation staff.
“I think that doing just enough governance is a key part of the success of the release train,” Milinkovich said.
Having so many projects on a common release cycle has had multiple benefits for the Eclipse Foundation and its member projects. Milinkovich noted that one of the successful side effects of the release train is that it has helped to bring more commonality to the Eclipse development community. The commonality is reflected in terms of how projects do development and learn best practices from some of the more mature projects that have been around longer.
As part of the Eclipse process, there is an effort to ensure continuous improvement.
“Every year part of the process is that the community does a retrospective on the release,” Milinkovich said. “So there are tweaks every year, but there hasn’t been any fundamental changes over the years to the process, but we’re always trying to do better and the purpose of the retrospective is to talk about what worked and what didn’t and to figure out what we can do better. “
In terms of measuring the relative success of the release train process, Milinkovich noted that the key things the Eclipse Foundation is looking for are stability and predictability.
“For us a release train is a success if the projects are picked up and used in products and the quality of what we ship encourages rapid adoption,” Milinkovich said. “We don’t have a particular set of metrics where we judge one year’s release better than another’s — frankly, as an open source community we’re happy to get the release done and out the door.”