Lowering barriers to open source contributions with OpenShift Origin

Image by:

Opensource.com

This past week, the OpenShift Origin repository on Github saw some major code merges from external contributors that added MSFT .Net functionality to the OpenShift Origin platform. Thousands of new lines of code were tested and merged successfully into the OpenShift Origin codebase, which was then instantly made available for anyone to download and deploy.

The merge of the .Net code base showcases how successfully the OpenShift Origin community has taken advantage of GitHub's social coding services to help establish an agile and open development process. An excellent Contributor's Technical guide for getting started is available within Origin's documentation section.

Aside from making OpenShift technically easy to build, develop, and test against, Origin's open community culture also makes it easy to collaborate together efficiently. The culture has evolved from a number of historical Red Hat collaborative practices that give the community a very productive efficiency and make it more agile.

Keep Calm and Merge On At Red Hat, we believe it is important for future growth and adoption of open source projects to have vendor-neutral meritocratic processes, and proper intellectual property management in order to succeed. This is why we have chosen Apache V2.0 license - And, why we have chosen NOT to require contributor license agreements (CLAs), or to establish a foundation. These choices often raise a few eyebrows, so I thought I would address these issues with the help of Red Hat's legal advisor, Richard Fontana in this week's blog post.

Open Collaboration

When joining an open community, your first point of entry is through the technical infrastructure. In the case of OpenShift Origin, that entry point is GitHub.

With an Open Source project, the choice of infrastructure has a huge effect on the culture of the project itself. Tools like GitHub not only help us build the project by providing us version control, source code management, issue tracking, and social collaboration mechanisms - but GitHub also empowers the community to contribute and collaborate in an open and transparent manner.

Contributions come in many shapes

The recursive and open nature of the OpenShift Origin project is seen at many levels of the project's infrastructure, as contributions come in many forms. Support for dotNet-based environments was added via a contribution to the origin-server core project. However, many contributions come in the form of community quickstarts and cartridges. Filing bug reports via Bugzilla, collaborating on feature tracking via Trello, and joining the discussion on StackOverFlow's Forums, are also great ways to contribute. The public nature of these contributions is what gives life to the project itself.

Chris Kelly, in his book "Two Bits: The Cultural Significance of Free Software", talks about a “recursive public” i.e public organized around the ability to build, modify, and maintain the very infrastructure that gives it life in the first place.

As Kelly puts it:

"A recursive public is a public that is vitally concerned with the material and practical maintenance and modification of the technical, legal, practical, and conceptual means of its own existence as a public; it is a collective independent of other forms of constituted power and is capable of speaking to existing forms of power through the production of actually existing alternatives." - "Two Bits: The Cultural Significance of Free Software"

The OpenShift Origin community is a merit-based power model. It is very much a "recursive public" that drives the direction of the community efforts, sets the tone of inclusivity and ensures open and transparent processes. Power is in the hands of those members of the public who contribute. Some of those who contribute are paid to do so by their employers, but their power to shape the project is based on merit not on any pay-to-play model.

Open Licensing

Whenever there's a significant chunk of code being merged into a project the question of licenses on the contribution usually gets asked. Historically, Red Hat grew out of the Linux movement and was culturally very tied to the GPL model of open source licensing, though there were always exceptions. Over the past few years, many important Red Hat projects (oVirt, OpenShift Origin, and key pieces of JBoss), have all been released under an Apache License - which is a lot more permissive than the GPL (overall), generating less resistance from our community of contributors.

There are a number of reasons for this but probably the most significant one is the issue of trust. We have more of a chance of building a successful community around a project that starts out as Red Hat code if we are seen as giving up more control. This is related to the CLA issue, because CLAs are a mechanism for control and imposing asymmetry. When open source code is released by a corporation, the Apache License 2.0 is unusually good at signaling "trust us" to communities. It is easy to fork an Apache License project, there are few limits on how code can be commercialized even by competitors. It's safe to get involved.

Lowering the Barriers to Participation

Red Hat initiates more open source projects than any other company, and the vast majority of these have never used any sort of CLA or copyright assignment. Most of the exceptions are projects that came out of acquisitions (for example, Cygwin or various JBoss projects), although even with projects coming out of acquisitions our more recent tendency is to eliminate any existing use of copyright assignment or a CLA -- an example of this is GlusterFS. The reason CLAs are generally not used at Red Hat has to do with tradition and culture -- Red Hat is an authentic product of open source community culture and typically open source projects do not use CLAs, and indeed in the open source community CLAs and copyright assignment have been very controversial political issues for years for all the reasons given above.

There is a special additional reason why CLAs are not needed for Apache License 2.0 projects: the Apache License 2.0 actually contains an explicit license condition that says, in effect, that patches submitted to the upstream project are by default to be licensed under the same terms that the contributor received the project code under -- namely the Apache License 2.0. Even ignoring all the other points made above, if there was ever a license for which CLAs were unnecessary it's the Apache License.

We made the decision not to use a CLA when we launched OpenShift Origin, for reasons related to what has been discussed above. A CLA is not necessary and would just limit our efforts to build a collaborative and trusting community around OpenShift Origin.

Why Foundations, Trade Associations and other Walled Gardens still cling to CLAs

Some open source project organizations are slowly embracing Social Coding, but still holding tight to barriers to participation like asymmetrical CLAs. It is not always clear why such CLAs are used. Some companies use CLAs with terms that are intentionally unfair or burdensome because there is actually a desire to discourage "outside" participation based on merit.

Such companies want their projects to look like community projects while actually being walled gardens. In other cases, there seems to be a belief that CLAs are necessary for some legal reason that is never really well-explained. We've even seen one peculiar case of a project that apparently views its amassing of CLAs (especially if signed by "large cap" companies) as somehow being proof of its ecosystem health.

What most uses of CLAs have in common, however, is asymmetry and imposition of red tape for contributors. CLAs usually privilege one company or organization and create legal obstacles for those who seek to participate and contribute.

Mistaken Beliefs of Contributor Protection

We sometimes encounter the mistaken belief that CLAs are somehow necessary to protect contributors and users from IP issues. The reality is that typical CLAs do nothing to protect contributors at all. Rather, they require contributors to undertake legal obligations that go beyond the level of what open source licenses themselves require, thus if anything increasing the risk of their participation in an open source project. This is one reason why such CLAs (and similar copyright assignment regimes) operate as a barrier to community contribution. CLAs do not protect users either, at least any more so than the outbound open source license of the project. A downstream user cannot invoke a CLA for protection against some sort of IP risk. Users need for the code to be open source, with all the legal rights that implies, but it is the open source license that provides this.

The only true beneficiary of a CLA is the company or foundation that imposes it as a contribution requirement. Even there, the benefit is more illusory than real, and will almost certainly be small relative to the cost borne by the project, because adoption of a CLA will make it harder for others to make contributions or for contributions to be treated based on their technical merit.

This may be easiest to see in the case of a project like OpenShift Origin that is licensed under the Apache License 2.0. The Apache License provides very generous copyright permissions from contributors, and contributors explicitly grant patent licenses as well. These rights are granted to everyone. A number of Apache License 2.0 projects use CLAs as well, but invariably these CLAs are, from the contributor's perspective, more restrictive legal obligations that run to the benefit of one organization rather than to the community. And unlike the Apache License, which is, like all open source licenses, operational without requiring additional legal formalities or paperwork, CLAs are typically structured like conventional contracts, entailing some system of formal assent and bureaucratic procedure.

At Red Hat, we don't feel the need for such tight reins on the projects we sponsor. To paraphrase, Chris Kelly - "The material and practical maintenance and modification of the technical, legal, practical, and conceptual means of the project is hands of the very public submission process"

CLAs, for example, are not needed to give users the rights they expect to get from an Apache License 2.0 project. The rights come from the Apache License itself, granted directly by the various contributors to the project. For OpenShift Origin, those rights are granted when a github pull request is submitted by an authenticated github user. To argue otherwise would imply that the vast majority of open source software, including some of the most widely-used codebases, contains fatal legal flaws, since most of that code originates from projects that do not use CLAs or copyright assignment. Such a view is irresponsible but is also refuted by the fact that those same open source projects form the basis of vibrant community and commercial ecosystems.

Avoid the Pay-to-Play Trade Association Open Source Foundation Route

Some Open Source projects choose to go the foundation route. With major project initiatives coming out of corporations, we have been seeing a number of cases where a trade association foundation is formed in order to bring corporate resources to bear on their project and promote a more pay-to-play powered model. This foundation-based approach moves the first point of entry to a 'join the foundation first' model, before you can actually begin to participate in the project. This often entails a 'pay-to-play' model to get a seat at the table. It may be a coincidence that most such foundations also impose CLA requirements for project contributors, but the pay-to-play model represents a barrier that if anything is much more significant than asking a developer to sign an unnecessary or duplicative license agreement

The reality is that corporate subsidies do not constitute the kind of collective independently-powered project that is truly open source. The pay-to-play trade association open source foundation model are actually modeled on old-school standards consortia, which actually pre-date the rise of open source development which represents a more agile, transparent, and egalitarian way of developing technology. In some ways, open source can be seen as supplanting standards development.

Conclusions

In OpenShift Origin, rather than counting the market caps of CLA signers, we measure participation via actual contributions to the code base. This approach has landed us in the top five community projects on GitHub when ranked by number of merged pull requests. The combination of our open, social collaborative infrastructure model, our adoption of an Apache V2.0 license, and our good sense not to require CLAs (or large donations to a foundation) in order to contribute is what makes us the most successful open source PaaS available.