Company Contributions to Open Source

Somewhere in my basement I still have a copy of a memo I wrote in 1989 explaining to my boss why we could safely ignore all this "free software" nonsense that people were talking about on Usenet. Sure, a few zealots might make contributions, but programmers need to eat: they weren't just going to give their code away.

I've rarely been so glad to be wrong, but I wasn't completely wrong. As the authors of Butler2019 point out, many contributions to major open source projects are made on behalf of companies, who employ core developers, make direct financial donations, and "donate" staff time to steering committees to make sure their corporate interests are represented. These actions aren't nefarious (though as many people have pointed out, companies like Amazon, Google, and whatever Facebook is calling itself these days get hundreds or thousands of times more value out of open source than they put in).

Through interviews with contributors to projects ranging from Apache CloudStack to Papyrus and examination of their governance documentation, the authors build a picture of how paid developers contribute, how their contributions differ from those made by volunteers, and how they prioritize their work. The short answer to all these questions is, "It's complicated," primarily because projects vary so much from each other. However, the authors note that:

A major influence on the type and level of engagement with an OSS project is the way in which the business deploys the software created by the project. In some deployment contexts the software requires little or no modification to create revenue for the company; the revenue comes from selling the expertise required to deploy the software. At the other end of the spectrum the software is deployed in a context where ongoing development of features is required to support the generation of revenue. In such usage contexts the software may be deployed to provide services to customers who have evolving requirements, or it may be that the software is in a rapidly evolving domain.

I don't expect most volunteer contributors will get a lot out of this paper, but it will give projects leads (and those who want to become leads) a sense of how many different collaboration models there are and what drives them. As such, this paper is a useful extension to Fogel's definitive Producing Open Source Software.