Proposing a new funding model for open source software

Existing open source funding models don't work for small projects.

Big projects — think operating systems, frameworks, CMSs, or fully self-hostable applications — are in a privileged position to extract more value from their users, especially corporate ones. Since entire APIs and products are built on top of them, they inspire enough appreciation (or, more likely, fear of obsolescence!) to net a sustainable income from one-off or monthly donations.

But most OSS projects aren't big. The typical project on GitHub is better described as a utility. It's a small tool that does one thing really well. Over the course of building a complex application, you may end up using dozens of these utilities — and they'll save you hundreds of hours of development time.

Unfortunately, utilities like these rarely bring in a non-negligible amount of donations, no matter how widely used or beloved they are. Consider react-router. Even with 41.3k stars on GitHub, 3M weekly downloads from NPM, and nearly universal adoption in React-based single-page applications, it only brings in ~$17k of donations annually.

The root of the problem is that open-source donations are made on a per-project basis. To support a project via GitHub Sponsors or OpenCollective, you must create yet another auto-renewing monthly subscription for each and every project you want to support. There's a major psychological cost associated with that. Moreover, at the moment of truth ("I'm gonna sponsor X!") it's easy to "logic" yourself out of donating ("But what if it gets replaced by some new hotness next week?!"). In the end, only the projects that are massively, insanely, indisputably useful get funded. And those projects are usually the "big stuff" — frameworks, self-hostable software, etc.

A new model is needed; one that works for the small- and medium-sized projects, not just the huge ones. So I propose a novel(-ish) approach to OSS sustainability.

Introducing "sponsor pools"

1. Every month, you donate some amount into a "wallet".
2. Your funds are then distributed to the projects in your "sponsor pool". Your sponsor pool is just the set of open-source projects you want to support.
3. Adding new projects to your pool should require one click — as easy as starring the repo on GitHub.

That's it. It's hardly ingenious, which is why it's surprising that no major company or organization that has implemented it.

This would achieve the holy grail of OSS sustainability: the one-click sponsorship. Once a person has funded their sponsorship pool, it would take a single click to financially support another project. The marginal cost — both psychological and financial — of supporting additional projects would drop to zero. That's a game changer.

GitHub

The best case scenario, in my opinion, is for GitHub to natively support this model as an extension of GitHub Sponsors. It's where the code lives (usually) so it is best positioned to create a zero-friction donation system like this.

Of course, if GitHub implemented something like this, they would likely divorce the donation mechanism from stars. Perhaps instead, users who have created and funded a sponsorship pool can be presented with an "Add to Pool" button in place of the current "Sponsor" button.

GitHub has a financial incentive to switch to this approach — sort of. They're currently eating the cost of all processing fees for transactions on GitHub Sponsors. So if you sponsor a project at $1/mo, the maintainer gets $1/mo...and GitHub pays $0.30 to the credit card companies. Switching to larger, annual donations means GitHub pays a proportionally smaller amount as fees.

Note that I said proportionally smaller. If more total donations are being processed, they'll still end up paying more in fees, even if the ratio of fees-to-donations is smaller. If the sponsorship pool concept is massively successful — say, cumulative donations of $1B annually — GitHub will be eating nearly $20M in card fees. I suspect that would ruffle some feathers at Microsoft.

As a final addendum — I'd love to see embeddable "badges" that are unlocked at different levels of donorship. Imagine a world where you see a "GitHub Sponsor Gold Badge" in the footer of someone’s website, indicating that they donate, say, $1000+ annually to open source. Clicking on this badge would bring you to a trusted site that lets you verify the claim. Here's my quick-and-dirty attempt at a badge design:

Some may cry "virtue signaling" but approaches like this are a proven way to establish positive reinforcement loops that a) increase awareness and b) encourage more folks to donate to open source.

Wrapping up

This is a hard problem with a vast array of potential solutions. I don't mean to come off as critical of any funding platform mentioned; they've all done a lot for maintainers, including myself, and I don't mean to minimize that. This is merely a hypothetical exercise.

My name is Colin and like writing proposals like this one. There are lots of things that should exist in the world, and it's easier to describe them than to implement them! If you want to know when I publish new proposals, join my mailing list or follow me on Twitter. ✌️

from Hacker News https://ift.tt/3ga4CiS