Skip to main content

Funding open source

I strongly agree with Isaac Schlueter’s thoughts on funding open source software:

There are a few pitfalls that I see many of these ideas fall into, all of which seem reasonable, but lead to failure:

  1. A focus on "donations" and "community" as the ideological framing.
  2. A focus on getting newcomers introduced to OSS and successful.
  3. Marketing primarily to developers as the consumers of the products (ie, the ones paying money).
  4. Overall, making payment optional, or for something other than use of the OSS products (eg, consulting, support, etc).

I thought about going through these in turn, but really, the fourth bullet point is the key one. Don’t make it optional. If your solution is a nice-to-have or depends on altruism in some way, it’s dead in the water. People who can pay should have to pay. It’s the only way to guarantee an income.

I also think I’d add a fifth bullet: conflating all open source software into one category. Clearly, an open source encryption library designed for use as part of an application is a different kind of software to, say, WordPress. Both of the high-use open source projects I’ve co-founded, Elgg and Known, have fit into that latter category, and I don’t have a good solution for it. Even WordPress struggled financially until it figured out how to (1) sell anti-spam solutions, (2) become a custom page-builder for agencies.

It’s also a mistake to try and solve the open source funding problems in all domains at once. There are too many variables; there’s too much to consider. How can you possibly create a business model that covers all software libraries?

So let’s not. Let’s focus our attention on one particular place.

Let’s focus on GitHub.

GitHub, a wholly-owned subsidiary of Microsoft, is the largest repository of open source software in the world. It has $1 billion in annual recurring revenue and 90M active users. Most projects use it as their hub.

If you’re building software as part of an enterprise, you care about picking high-quality, well-maintained libraries, and you care about security. You might want to pass a SOC audit and demonstrate that you pay attention to library updates.

If I’m an open source developer, I probably want to have the resources to be able to spend more time working on my project, and I probably want people to use what I’ve built.

Imagine you could opt into a GitHub program for each open source repository you build. You pick one of a few approved licenses; you commit to updating the library and keeping on top of issues that people file; you agree to take part in a security bug bounty program. In turn, as long as you fix any disclosed security issues within a reasonable period and don’t let the library go unmaintained, you receive funds for every enterprise GitHub user that uses your library, GitHub will add a verified icon next to your repository name, and it will promote your library to potential paying users.

This won’t please open source purists. But in this scheme, all code will remain open for anyone to use. Enterprise GitHub users will continue to pay their existing fees, and developers will pay nothing to take part, and potentially make money. GitHub, meanwhile, gets higher quality open source code in the process, will see more development activity on its site, and can make a compelling sales pitch to gain more enterprise customers.

Over time, this might lead to GitHub developing a new license where corporate users must pay for an enterprise subscription. I don’t see that as necessarily a bad thing, as long as personal, educational, and nonprofit users can continue to use the code. While fully free software has been broadly beneficial to society, it has too often led to financial gain for large companies at the expense of individual developers. It also has led to a demographic problem where only a very narrow set of people (wealthy white men, generally) can afford to build open source software, while it is often used as part of a hiring assessment process.

There’s a more equitable middle ground where the source can be open but the use is not free for those who can afford to pay. Dare I say it: from each according to their ability, to each according to their needs.

· Posts