Archive for the ‘Foundation’ Category
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!
Community Review of the Eclipse Public License
The Eclipse Public License, and its predecessor the Common Public License have been in existence for around 12 years now. A lot has changed since the EPL’s introduction in 2004, and the time has come for a review to ensure it remains current. As a result, we are going to kick off a public process to solicit input on the license, and discuss possible revisions. Once we’ve arrived at a set of revisions which have a broad support, the Eclipse Foundation Board of Directors would have to unanimously approve the new version. And, of course, any revisions would be submitted to the Open Source Initiative to have them certified as compliant with the Open Source Definition.
I don’t want to steer the conversation in any particular direction, but as a sampler of issues, here are a couple:
- The distinction drawn between object code and source code aren’t really helpful when you’re talking about scripting languages like JavaScript.
- The use of the term “module” is confusing to some.
There are a few things that we already know we don’t want to change. First and foremost is that the EPL will remain a copyleft license. Another is that we want to continue to enable a commercially-licensed ecosystem based on Eclipse technologies.
We are going to be starting these discussions soon on the epl-discuss@eclipse.org mailing list (subscribe here), and will be tracking individual issues in the Eclipse Foundation/Community/License component in the Eclipse bugzilla.
If you are interested in the future of Eclipse licensing, please join in the conversation!
The EPL as a Platform License
Yesterday’s announcement of the OpenDaylight project has gotten very wide coverage. It looks like a well-done announcement, and the industry support for this important new collaboration is stellar. Yet another great example of how open source is facilitating collaboration on new and innovative industry platforms.
In my opinion, one important detail of the announcement has not received sufficient notice:
OpenDaylight … is structured and governed using open source best practices and is licensed under the Eclipse Public License (EPL)…
So OpenDaylight is flying in the face of a lot of recent conventional wisdom that the Apache License is the default license of choice for new industry collaborations. (See here here and here.) Frankly, I thought I would see pigs fly before seeing Microsoft fully participating in an EPL-licensed open source community.
I think that this could be the start of a new trend, because as we’ve seen platform fragmentation in the Android ecosystem is becoming bit of an object lesson for the industry.
The EPL has a couple of really important features that make it a particularly good platform license. It strikes the perfect balance between the competing interests of the collaborative community who is building the code, and the commercial interests who want to use that code in their products and services.
- The EPL is copyleft, which means that if a company forks the code to further their interests, they need to make that code available under the EPL. This is a powerful incentive to simply do the work in the main project, in collaboration with the other players.
- The EPL is commercially friendly, allowing corporations to build products on top of EPL-licensed code and use their own End User License Agreement when selling to their customers. This provides the ability for companies to leverage EPL-licensed open source code in traditional software business models.
The combinations of those two main features has been a big part of the success of the Eclipse community. We’ve seen remarkably few forks at Eclipse (aka fragmentation), while enjoying massive amounts of commercial adoption of our technologies. Will the OpenDaylight announcement make other industry open source collaborations think a little bit harder about their license choices? Time will tell, but I think this could be an interesting trend to watch.
Public Review Drafts of New IP Documents Now Posted
A few weeks ago, I talked about a major overhaul of our IP processes. As part of that, we have posted our Public Review Drafts of our Eclipse Foundation Contributor License Agreement (CLA) and our Contributor’s Certificate of Originality (CoO).
I was asked why we needed both documents. I will repeat the explanation here:
The two documents are complementary.
The CLA is something that a contributor signs, and is a legal agreement.
The CoO is a statement that clarifies what we expect from contributors when they use the “signed-off-by” feature in git.
There is a saying that many lawyers use: “belts and suspenders”. Yes, there is some overlap between these two approaches, but there since the DCO is not something that a contributor is expected to sign, I don’t think that it adds any extra burden to the process.
Your comments and feedback would be greatly appreciated. However, please don’t do it in the comments here. We would prefer the community’s feedback on bug 401349.
Update: s/DCO/CoO/ in blockquote.
Life at Eclipse 