If you’re looking for guidance on how best to manage your open source project, don’t worry: There is no shortage of unsolicited advice. Use CLAs! Don’t use CLAs! Foundations or die! Foundations are useless! And so on, until your head explodes. The reality is that successful open source projects follow a wide variety of governance models, licensing schemes, contributor models, etc.

This is why the best advice may well be that “It depends.” And yet, there are some principles that seem reasonably safe to embrace. For James Bottomley, one cardinal rule is to never, ever sign a CLA, or contributor license agreement. But even this isn’t necessarily as clear-cut as it seems. Even so, Bottomley does offer one principle for open source governance that seems sage: less is more.

SEE: A guide to The Open Source Index and GitHub projects checklist (TechRepublic Premium)

Balancing power in open source communities

I am a lawyer by training, though not by practice. Many open source developers, by contrast, seem to be lawyers by practice, though not by training. At least, that’s how it feels to me whenever I stumble into a tweet thread like this one, kicked off by Bottomley. 

Bottomley, the Linux Kernel maintainer of the SCSI subsystem, has a lot of experience with DCOs, as it was The Linux Foundation that introduced the concept of a Developer Certificate of Origin back in 2004. A DCO, wrote Bottomley, “explicitly grants to all downstream recipients only the exact rights the Open Source licence requires (and nothing more).” It’s a lightweight way of conveying rights without developers having to get a lawyer to interpret their obligations. One significant downside is that it becomes cumbersome if the project maintainers later need to relicense the project: chasing down each contributor to get formal assent to the change can be tedious or impossible.

A contributor license agreement, by contrast, is often used by corporations or foundations to concentrate rights to the code. This makes ownership cleaner than in the DCO case, but it also means that “CLAs by their nature force a power imbalance between the contributor and the receiving entity,” according to Bottomley. Why? Because developers assign their rights in the code to someone else, and that “someone else” can then unilaterally relicense code to the benefit of that corporation or foundation, and not necessarily to the benefit of the wider community. 

Sounds bad, right? We have plenty of recent corporate examples of dramatic changes in licensing, but Bottomley goes further and argues that even foundation-driven CLAs are problematic because they require you to place absolute trust in others (“…[H]ow sure are you of the power you’re handing to a foundation which, after all, is an entity governed by some type of board, all of whom likely have political agendas, won’t be abused?”). He concluded:

[Y]ou should never sign a CLA under any circumstances.

The bottom line is that if you do sign a CLA some decision will happen at some point that you don’t agree with but which you already gave away the power to block because of the rights imbalance inherent in the CLA you signed. Inevitably this decision will cause you to feel betrayed because your views are being ignored and as a contributor you feel you should be heard, so you’ll sour on the project. This is the community corrosion catalyst buried deep inside all CLAs.

Bottomley surfaces a deeply held belief by many developers, but there are problems with the argument. As Van Lindberg, an experienced intellectual property attorney with deep roots in open source, has argued to Bottomley, DCOs are still largely unproven:

Corporate acceptance of DCOs is 98% Linux kernel code by volume. Nothing else comes close….For corporate contributors, the DCO is a placebo only, designed to make devs feel happy and “compliant” without actually doing anything….[T]he vast weight of prior precedent [respecting DCO-like legal constructs] is such that I believe that such an argument would lose.

In other words, CLAs might be bad, but it’s not clear that DCOs are better, as they may simply not work. 

Less is more

Nor do some other “cardinal rules” in open source play out without exception, like foundations. For years, foundations were seen as safe havens for code; a place to minimize the potential for any particular corporation to exert undue influence on a project. On many occasions, however, we’ve seen foundations simply used as a Potemkin village of sorts, masking corporate influence. As I’ve written, “[F]ar too many open source foundations are simply facades for their sponsoring companies to feign openness for the marketing benefits, all while retaining effective control over the underlying project. This kind of foundation-washing is no guarantee of source code freedom.”

And yet…Bottomley is probably correct in his assertion that the best way to govern an open source project is always with “less.” This “less” could involve a foundation. It might rely on DCOs. Or not. He wrote:

The way to avoid the community corrosion problem is to do everything minimally: use a DCO to take only the rights the downstream requires and to avoid all the heavyweight recipient, signing and tracking infrastructure. Don’t set up a foundation unless you absolutely need an entity, say to handle cash, and if you must set one up, never give it any control over the project (like appointing a change control or architecture control board for instance) everything you set up should be as small as possible and clearly serve the project and its community. 

I like this principle. “Just enough” governance/license assignment/etc. to help communities develop trust in the project maintainers, but not so much that the project gets weighed down in bureaucracy. 

Disclosure: I work for AWS, but the views expressed herein are mine.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see