Don't look to donations to solve open source maintainers' money woes. They just need to be connected to the companies that need them to make a buck.
There's a swelling chorus suggesting that we need to do more to make open source sustainable and, specifically, to enable developers to maintain a project and a living at the same time. While there are various ideas of how to do this, here's a shortcut to what should become the guiding principle: Don't rely on charity. Rely on self-interest.
SEE: How to build a successful developer career (free PDF) (TechRepublic)
Selfish is as selfish does
Call it greed. Call it selfishness. Call it whatever you want, but self-interest has always been the heart of open source. From the day Eric Raymond first declared that "Every good work of software starts by scratching a developer's personal itch" to Linux kernel maintainer Greg Kroah-Hartman's more recent suggestion (around minute 17:00) that "We want everyone to contribute selfishly because it helps everyone else."
That first part ("contribute selfishly") is easier to grok than the latter ("helps everyone else"), because people and corporations tend to look out for their own interests without much prodding. But it's seeing how self-interest naturally can lead to community health that is the real magic of open source. In Kroah-Hartman's words, "Everybody contributes to Linux in a very selfish manner because [they] want to solve a problem for [them]." He goes on to say that this is exactly how he wants open source to work because "it turns out everyone has the same problems."
It's natural, though incorrect, to believe that self-interest in open source would lead companies to fork projects and hoard improvements they might make--this is the opposite of self-interest. When people contribute, they end up contributing in a manner that makes it less needful for them to do the onerous work of maintaining a fork because that costs time and resources. There are some exceptions to this rule (Kroah-Hartman calls out Nvidia and the Linux kernel, and notes that they spend a lot of money maintaining their fork), but they are exceptions. It's always easier and less costly to contribute back rather than fork a project.
So self-interest is the way to go, apparently. But how does that pay the rent for developers?
Same as it ever was
Ever since open source became a thing, companies have paid developers to work on code that matters to them. This is perhaps most visible with marquee projects like Linux or Kubernetes, but it has also been true of lesser-known projects like Gnome, back in the day. The self-interest is clear: If I'm an enterprise that depends upon, say, React, I'll be better able to serve my customers if I'm actively involved in that project.
More recently, different companies have attempted to fund developers through what Linux Foundation executive Chris Aniszczyk derisively dubs a "tip jar" or, more politely said, donations. Not only has this approach largely not worked, failing as it does to hit that "self-interest" button, but some, like Aniszczyk, "consider these platforms exploitative and perpetuating the unfair gig economy for open source maintainers." So that would be a "no" from Aniszczyk.
However, amidst all the creative experimentation of late, the earliest funding model is still the best one: Hire developers and let them use some or all of their time contributing to the open source projects that matter most to their employer. No, this won't work for every developer--some prefer to remain independent. But the key to making open source sustainable, and to enable open source developers to thrive, is to help pair their expertise with the self-interest of a corporation.
Tidelift is working on something like this, and we need more efforts like theirs. Not on open source as charitable work, but open source as inherently self-serving.
- GitHub: A cheat sheet (TechRepublic)
- Software licensing policy (TechRepublic Premium)
- Third party vendor policy (TechRepublic Premium)
- It's MongoDB's turn to change its open source license (ZDNet)
- Open-source licensing war: Commons Clause (ZDNet)
- GitHub makes open-source project licensing easier with an open-source program (ZDNet)
- Why novelty open source licenses hurt businesses more than they help (TechRepublic)
- Why Redis Labs made a huge mistake when it changed its open source licensing strategy (TechRepublic)
- More must-read coverage about open source (TechRepublic on Flipboard)