As software developers, I think we can agree that open-source1 code has transformed the world. Its public nature tears down the walls that prevent some pieces of software from becoming the best they can be. The problem is that too many valuable projects stagnate, with burned-out leaders:
“I do not have the time or energy to invest in open source any more. I am not being paid at all to do any open source work, and so the work that I do there is time that I could be spending doing ‘life stuff’, or writing…It’s for this reason that I've decided to end all my engagements with open source effective today.”
—Ryan Bigg, former maintainer of several Ruby and Elixir projects
“It’s also been a massive opportunity cost because of all the things I haven’t learned or done in the meantime because FubuMVC takes up so much of my time and that’s the main reason that it has to stop now.”
—Jeremy Miller, former project lead of FubuMVC
“When we decide to start having kids, I will probably quit open source for good…I anticipate that ultimately this will be the solution to my problem: the nuclear option.”
What we need is a new industry norm, that project leaders will always be compensated for their time. We also need to bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer.
Let’s first review how an open-source code base works in the market. It is a building block. It is utility software, a cost that must be incurred by a business to make profit elsewhere. The community around the software grows if users can both understand the purpose of the code and see that it is a better value than the alternatives (closed-source off-the-shelf, custom in-house solution, etc.). It can be better, cheaper, or both.
If an organization needs to improve the code, they are free to hire any developer they want. It’s usually in their interest to contribute the improvement back to the community because, due to the complexity of merging, that’s the only way they can easily receive future improvements from other users. This “gravity” tends to hold communities together.
But it also burdens project maintainers since they must respond to these incoming improvements. And what do they get in return? At best, a community contribution may be something they can use in the future but not right now. At worst, it is nothing more than a selfish request wearing the mask of altruism.
One class of open-source projects has avoided this trap. What do Linux, MySQL, Android, Chromium, and .NET Core have in common, besides being famous? They are all strategically important to one or more big-business interests because they complement those interests. Smart companies commoditize their complements and there’s no commodity cheaper than open-source software. Red Hat needs companies using Linux in order to sell Enterprise Linux, Oracle uses MySQL as a gateway drug that leads to MySQL Enterprise, Google wants everyone in the world to have a phone and web browser, and Microsoft is trying to hook developers on a platform and then pull them into the Azure cloud. These projects are all directly funded by the respective companies.
But what about the rest of the projects out there, that aren’t at the center of a big player’s strategy?
If you’re the leader of one of these projects, charge an annual fee for community membership. Open source, closed community. The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.” Lock non-paying users out of the forum and issue tracker, and ignore their emails. People who don’t pay should feel like they are missing out on the party.
Also charge contributors for the time it takes to merge nontrivial pull requests. If a particular submission will not immediately benefit you, charge full price for your time. Be disciplined and remember YAGNI.
Will this lead to a drastically smaller community, and more forks? Absolutely. But if you persevere in building out your vision, and it delivers value to anyone else, they will pay as soon as they have a contribution to make. Your willingness to merge contributions is the scarce resource. Without it, users must repeatedly reconcile their changes with every new version you release.
Restricting the community is especially important if you want to maintain a high level of conceptual integrity in the code base. Headless projects with liberal contribution policies have less of a need to charge.
To implement larger pieces of your vision that do not justify their cost for your business alone, but may benefit others, crowdfund. There are many success stories:
Crowdfunding has limitations. It doesn’t work for huge projects. But again, open-source code is utility software, which doesn’t need ambitious, risky game-changers. It has already permeated every industry with only incremental updates.
These ideas represent a sustainable path forward, and they could also fix the diversity problem in open source, which may be rooted in its historically-unpaid nature. But above all, let’s remember that we only have so many keystrokes left in our lives, and that we will someday regret the ones we waste.
1 When I say “open source”, I mean code licensed in a way that it can be used to build proprietary things. This usually means a permissive license (MIT or Apache or BSD), but not always. Linux is the core of today’s tech industry, yet it is licensed under the GPL.
Thanks to Jason Haley, Don McNamara, Bryan Hogan, and Nadia Eghbal for reading drafts of this.