The Eclipse Foundation has evolved a pretty impressive application lifecycle management story. Based on what I’ve observed over the years, I believe that it’s completely reasonable to say that our ALM story is one of the best in the world: the envy of hundreds of open source projects and closed source development shops around the world.
I believe that our success comes from a combination of great people, well-defined process, and a powerful stack of open-source tools.
We started from humble beginnings: issue tracking with Bugzilla, CVS for source code management, PDE Build and Ant scripts for build, cron for orchestration, and the Eclipse Development Process for guidance. Over time, all the the pieces have evolved resulting in the world-class whole that we have today.
Process
The Eclipse Development Process describes the structure of projects and teams at Eclipse. It provides guidance to help projects run in an open, transparent, and vendor-neutral manner. It provides a framework for processes around releases and other important stages in project lifecycle (e.g. creation, graduation, and termination). From a process point of view, it’s a pretty high-level document that provides a framework for day-to-day work; individual projects, however, are given flexibility to decide how they run their day-to-day development.
Eclipse projects have the benefit of the most comprehensive IP management and due diligence process available to open source projects. In fact–based on my experience working with many dozens of companies over the years–it is one of the most comprehensive IP management processes available to anybody.
IP Management is important when you care about adoption of your open source project. Adopters need to know that they can safely use the output of your open source project in their own projects and products.
Tools
The tools story has evolved considerably since those humble beginnings.
We still use Bugzilla for issue tracking. We have a second Bugzilla instance, called IPZilla, that we use for tracking intellectual property contributions and use of third-party libraries.
And we’ve added a few new pieces:
Subversion (SVN) was added as an alternative to CVS for source code management, but both are now being phased out in favour of Git. In fact, CVS is meeting its end-of-life at Eclipse on December 21/2012 and Subversion is no longer an option for new Eclipse projects. Moving forward, it’s Git or nothing.
Hudson provides build orchestration. As of EclipseCon 2012, we have 337 build jobs that have run a total of 86,000 times on Hudson: ninety-eight run daily, and 218 have run in the last month.
Gerrit was recently implemented by our noble Webmaster team to provide code review for projects that opt to use it. Using Gerrit streamlines the contribution workflow: contributors can push their commits directly to Gerrit where project committers can quickly and easily process them. Gerrit has a lot of very cool tricks including the ability to invoke Hudson builds to confirm that new contributions will actually compile (Hudson, in effect, gets a vote on whether or not a contribution should be accepted).
With the introduction and subsequent development of Tycho–technology that lets Maven understand and build Eclipse plug-ins and OSGi bundles–Maven-based builds are quickly becoming the gold standard for Eclipse projects.
Tying it all together is, of course, Eclipse. The Mylyn project provides integration from Eclipse to Bugzilla (along with many dozens of other issue trackers), Hudson, and Gerrit. The EGit project provides integration with Git, and the m2e project provides support for maintaining Maven build artifacts.
People
None of this would be possible, of course, without people. The implementation of Git at Eclipse was not a trivial matter. We had a lot of questions that needed to be be answered, and the Eclipse Committer community stepped up to help us answer those questions. There are similar stories for the other technologies that have been adopted at Eclipse.
We’re still working on our Maven story. Like everything else at Eclipse, this isn’t being driven from the top-down, but rather it is being driven by the developer community.
One of the most important things that keeps all this technology and process moving forward is communication. We have a strong ethic of transparent communication and open discussion across all 250+ Eclipse projects.
Of course people drive both the evolution of technology and process. The Eclipse Architecture Council–a group of old and grizzled veterans of open source development–provides assistance to projects who are just learning the process, and are responsible for evolving the process as necessary. The Eclipse Development Process is considered a living document and so is subject to change. We tweak and adapt our processes and practices on an ongoing basis.
No discussion of the Eclipse ALM story is complete without discussing the simultaneous release. The simultaneous release, which is coordinated by the Eclipse Planning Council, is as much about people as it is technology. Every year, many of projects join together to coordinate their development schedules and combine their releases into a single mega-event. This year’s Juno release includes 71 separate Eclipse projects and (total SWAG) 60 million lines of code.
The size of the simultaneous release has been growing over the years. Something as massive as the simultaneous release can only happen with free-flowing lines of communication among developers working together with common goals.
Evolution
Are we there yet?
No. There is no “there”. The ALM story at Eclipse continues to evolve. It will always evolve. We still need to solve the Maven question, and projects are pushing us into the continuous integration space. And there may be more changes ahead.
Who knows what the future will bring?
