Contributor Agreements kill Contributions

A good while ago now, there was a bit of activity from others discussing the impact that contributor agreements have on contributions. Most notably, from Simon Phipps and Michael Meeks:

I’ve been around this Free and Open Source Software thing for a while now and I’ve noticed a pattern. People who hack on free software seldom have a desire to spend time speaking to the company lawyers instead of doing their jobs.

If you require a contributor agreement signed, it doesn’t involve an individual. It involves a legal department. Being a free software developer is a different mindset than working on proprietary software. No longer are you just working on one bit of software, you can work on any bit of software. Find a bug in your compiler? Well, you can fix that. Find a bug in a library you’re using? You can both work around it and submit a patch that fixes it.

There is a different between an open source project and an open source product. An open source product is easy – you just publish your source/binary packages with an open source license and do all your development and discussion inside the company. Easy and simple for most places to execute.

What is harder is having an open source project. This is where your company participates in the project, and is a trickier thing to get going – especially within large organisations that have historically been proprietary software houses. There are very few companies that have gotten this right, and even fewer that have gotten this right across the board. I would probably have to say that Red Hat is the company that consistently does this the best.

A low barrier to entry is what has made the largest, most successful free software projects what they are today. If you’re wanting your project to be an open source project and not an open source product – then you too must set a low barrier to entry. Contributor Agreements significantly raise the barrier to entry. Suddenly my 10 line patch to fix a bug turns into a discussion with my company lawyers, your company lawyers and goes from taking an extra 5 minutes to send an email with a patch to a mailing list into something that takes hours and hours of my time.

Any time I spend speaking to lawyers is time not spent improving the world. By having a Contributor Agreement you turn a 5 minute task into a several hour one, a task involving lawyers. You know what tasks involving lawyers are? Expensive. You now have developers not contributing to your project not because a lawyer said no, but because they worked out that the time and money that would be spent on contributing to your project not to be worth it for their company.

The only people who enjoy talking business with lawyers is other lawyers and the mentally ill[1]. We’re developers, not lawyers – don’t make us talk to them for orders of magnitude more time than it takes to fix some bit of code.

 

[1] I have lawyer friends, and that’s social time, not work. I’ve also worked with great lawyers, but I do wish the world was more sane to begin with and I didn’t need to spend as much time doing so.

6 thoughts on “Contributor Agreements kill Contributions

  1. This is part of the problem, yet we shouldn’t forget that GNU, Apache and OpenStack are wildly successful even if they do require your signature on an agreement. Personally I think there are many reasons why projects with contributor agreements fail, and one is that in the case where a company (like MySQL) wants my contributor agreement it is because they want to use my code for proprietary products, so of course I’m not gonna sign that!

    Otoh in MySQL, OpenOffice and Java there seems to have been cases where people did sign the paperwork, contributed code and then it didn’t go anywhere. So clearly there were other reasons (too) why these projects didn’t succeed in building a vibrant community.

  2. Although Apache was big before there was Apache foundation, GNU was kind of the start of everything and gained momentum that way and OpenStack is yet to prove widely successful in the marketplace (while Swift may be seeing big production workload, is anybody using Nova successfully in a large deployment that’s making money?)

  3. The problem with going to all the effort of signing the paperwork? You then still have to fix your code. You’ve just spent a whole bunch of time to get to the point of then spending a whole bunch of time. Hrrm…. no wonder people disappeared afterwards.

  4. Apple has been a shining example of company whose origin is pretty much rooted in a closed environment and which has nevertheless created thriving, open projects like the WebKit project. There’s stuff to be learned from their experience, I’m sure.

  5. WebKit has been an odd route to be sure… the early history at least was far from an open source project. I don’t have enough knowledge to talk about how it operates now though.

  6. Nobody is arguing that a world without CLAs isn’t a more convenient world with a lower barrier to entry. It most obviously is that. But there are a couple of flaws in your argument.

    The first is that Red Hat requires CLAs all over the place. Fedora has one, Jboss has one. The real major project that doesn’t have CLAs? Linux. The project that had massive lawsuits and doubt about the origin and dispensation of the code? Linux. CLAs exist to protect consumers of the software from those kinds of shenanigans. A world *without* those shenanigans is highly preferential, for the record – and if we lived in it, then open source products wouldn’t need CLAs.

    But if you are working on a project of sufficient size, or that is backed by multiple large corporate entities whose intent is to have a commercial presence in the market in addition to it’s open source nature, having CLAs is a requirement of the intellectually honest.

    Now, not all CLAs are created equal. I personally think that copyright assignment CLAs are pretty heinous, with the exception being those that go directly to non-profit foundations with strong charters (GNU). The mess we’re in with MySQL is a direct result of contributors signing copyright to the corporate entity. So it’s not all roses in CLA land.

    The burden is real. The core issue is that the legal burden exists at all – that we need to have this sort of clarification around contribution. But until we reform the patent and copyright systems, for projects whose aim is widespread adoption and collaboration, CLAs set the rules that ensure that won’t be any shenanigans.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.