Archive for June 2013
Embracing Social Coding at Eclipse
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.
Eclipse Contributor License Agreements Are Live
As we started talking about back in February, the Eclipse Foundation is doing a major overhaul of our IP processes. With the Kepler release now firmly in its end-game, the time has come to start rolling this out.
In February, I identified three major pieces of work that needed to get done:
- First, we are going to implement Contributor License Agreements (CLAs) for all contributors at Eclipse. The CLA will be a short document that essentially asks The Three Questions once. We will collect some information about the contributor so that we have a record on file of who is giving us code or documentation. Note that the Eclipse Foundation CLA will be quite different from those in use at other organizations. For example, Apache’s CLAs basically give the ASF a license equivalent to ownership for contributions. The Oracle Contributor Agreement (OCA) used by OpenJDK community gives Oracle joint ownership of contributions. The Eclipse CLA is much more modest. In terms of licenses, all it says is that the contributor agrees that their contributions will be provided under the license(s) for the project they’re contributing to. You can review and discuss the draft CLA on bug 401349.
- Second, we are going to support signed-off-by for contributions which flow to Eclipse project via git and Gerrit. The goal here is to make it as simple as possible for Eclipse projects to accept contributions via the community best practices which have grown up around git. As part of this, we will be developing a contributor certificate of originality, inspired by the one used by the Linux community.
- And finally, we are going to automate as much of this workflow as possible. Our CLAs will be presented and completed on-line. There will be Gerrit support so committers get an immediate indication as to whether a contributor has a CLA on file. There will be git triggers which will reject a commit where there is no CLA on file for the author of the code commit.
Ever since then, we’ve been working on getting all of the pieces lined up to go live with these capabilities. Today is the first step!
The Eclipse Contributor License Agreement is now live. This means that contributors can execute a CLA, and get theirs on file. Committers will be able to use the PMI (project management infrastructure) to look up whether a particular contributor has a CLA on file. So starting immediately, you will be able to refer to a CLA rather than asking the “three questions” on a bug. This is basically delivering on the first item above.
For the second item, the Eclipse Foundation Contributor’s Certificate of Origin has been published, and contributors and committers should start using the signed-by option with git.
In order for a contributor to sign their CLA, they need to do the following:
- Obtain and Eclipse Foundation userid. Anyone who currently uses our Bugzilla or Gerrit systems already has one of those. If they don’t, they need to register.
- Login into the projects portal, select “My Account”, and then the “Contributor License Agreement” tab.
Navigate to the CLA
The day after Kepler ships — Thursday, June 27th — we will deliver on the third item, which is automation. On that day, we will start automatically enforcing CLAs. This means that every time a contribution arrives at one of our git repositories (including Gerrit), the author field will be checked to ensure that there is a CLA or Committer Agreement on file for the author. If there isn’t, the contribution will be rejected.
Progress!
Life at Eclipse 