The Eclipse Foundation is going to start allowing its projects to host their mainline development on third party forges such as GitHub, and (eventually) Bitbucket. This means that an Eclipse project will be able to leverage the great development tools provided by those vendors. The first project that we are going to work with on this is Vert.x, which has been hosted on GitHub since its inception. Our intent is to start small, and continually improve this program and our support of it. This is an important new option for open source projects which have matured to the point where vendor-neutral governance, meritocratic processes and proper intellectual property management have become important for future growth and adoption.
It’s hard to believe that it was almost two years ago when Mikeal Rogers penned his “Apache Considered Harmful” post, stirring a decent amount of controversy at the time. Although I disagreed with many of Mikeal’s points, his key point that open source foundations need to change to maintain their relevance resonated strongly with us in the Eclipse community. We listened, we’re learning, and we’ve been working hard to change our processes and infrastructure to stay relevant for open source developers. Here are a few examples:
- We switched to git: Last December 21st we shut off CVS at Eclipse, and we have migrated basically all of Eclipse to git. (There are a few projects still on Subversion.) Using a modern distributed version control system at Eclipse has already helped a great deal in increasing contributions and reducing barriers to contribution to our projects. Among other things, it has allowed us to mirror Eclipse projects on github, which has attracted some interest from the development community there.
- We adopted Gerrit: Using git has also allowed us to start using the Gerrit code review tool at Eclipse, which has been a great addition to our contribution workflow.
- We implemented the project management infrastructure (PMI): We now have a database-backed system which tracks all of our project metadata, such as committer lists, release dates, project plans, and the like.
- We started using contributor license agreements (CLA): Using CLAs further reduces the barriers to contribution, as we no longer have to have a discussion on each contribution about the IP rights.
The last two of those items are extremely important because they put us in a situation where we can begin to automate workflows, thereby reducing the amount of effort by our commmitters and contributors. So, for example, by the end of June we will have automated the CLA check on all of our contributions which flow to us via Gerrit, or directly into our git repositories. We will have all of the data in place to determine that the author, committer, and signed-by fields on a contribution map to a person who is either a committer or who has signed the Eclipse Foundation CLA.
And then along came Vert.x.
Early in January 2013, there was a very active discussion about the future of the Vert.x project. The project had reached a point in its progress where it was clear that it should move to a vendor-neutral home. After quite a bit of discussion, the Vert.x community decided that the Eclipse Foundation would make a good home. The discussion was particularly interesting because the relative merits of moving to Eclipse, Apache, OuterCurve and the Software Conservancy were debated in an open and flame-free manner. Now that the Eclipse Foundation is open to projects which are implemented in any language or technology, without requiring linkages to our eponymous IDE, it is a good home for innovative new projects like Vert.x.
Since its inception, Vert.x has been hosted on GitHub, and is one of the most watched Java projects there. During the process of discussing how to migrate Vert.x to the Eclipse Foundation, we had a bit of an epiphany: if Eclipse projects could mirror to GitHub, what would happen if we simply flipped things around and mirrored projects hosted at GitHub on eclipse.org’s git repos? After some discussion, we decided that this was a really good idea. Complementing the great developer infrastructure at GitHub with the governance and meritocratic processes that an open source foundation like Eclipse brings to the table will be the best of both worlds for some projects.
Projects which choose to take advantage of this will be hosting their mainline development remotely, but all of their code will be mirrored back to Eclipse’s git repositories. The full Eclipse development and IP processes will be applied to these projects. Project metadata, plans, committer records and votes will be maintained in the Eclipse project management infrastructure (PMI). Admin rights to the repos will be owned by the Eclipse Foundation webmaster team.
Initially, most of this will be maintained manually, but over time we expect to automate a great deal of it. For example, initially checking that a pull request’s author has signed an Eclipse CLA will be done manually by the project committer accepting the contribution. Over time that will be automated using git commit hooks. We will continue to automate these interfaces, so that things like committer lists, etc. will be automatically updated based on changes in our PMI.
The last year and a half have been extremely busy at the Eclipse Foundation, as we have done a lot of work to modernize our infrastructure, and to make it more attractive than ever to become part of the Eclipse community. This is part of an on-going effort to remain relevant as the expectations of developers and open source committers rapidly evolve.
If you are interested in learning more about this, please read our FAQ.
