Sponsor pools: a new funding model for open source software

Check out the HN discussion here.

This article has been translated into Japanese and Russian.

The existing open-source funding models don't work well for small projects.

Big projects — 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 — an apt term, given the infrastructural role these projects play in the world. It is 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 any meaningful amount of money from 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 project you want to support. 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?!"). This has a huge dampening effect on total donations to open source. And 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 player in OSS has implemented it for facilitating open source donations.³

This would achieve the holy grail of OSS sustainability: the one-click sponsorship.⁴ Once a person has funded their sponsor 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.

Why this works better

Why do I think this will dramatically increase the total amount donated to open source? To answer that, consider a hypothetical question.

How much of your income would you be willing to donate to open-source software every year?

I suspect the typical overpaid HN lurker reading this post (👋) came up with a number in the hundreds of dollars. Compare that with how much you’re actually donating — is there a difference? There is for me. That's because there's currently no way to make a donation to the abstract concept of "open source software". But with sponsor pools, donation amounts will reflect an honest answer to the question posed above.

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 most projects live so it's 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 sponsor 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. Larger donation sizes means GitHub pays a proportionally smaller amount as fees.

Note that I said proportionally smaller. If more total donations are being processed (which is the goal of this proposal!), they may still end up paying more in total fees, even if the ratio of fees-to-donations is smaller. If the sponsor 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 criticize any existing approaches; they've all done a lot for maintainers, including myself, and I don't mean to minimize that. There may also be major implementational or regulatory hurdles to building something like this that I'm not aware of. This is merely a hypothetical exercise.

I write proposals like this one every month or so. Put your email in the box to get future proposals delivered to your inbox. ✌️

Footnotes

¹ Some examples of financially successful large projects.

• operating systems: Red Hat, Elementary OS
• frameworks: Livewire, Next.js
• CMSs: Ghost, Wordpress
• Full-featured applications: Sentry, Blender, Discourse

² It's worth noting that currently GitHub Sponsorships actually correspond to a given user or organization, NOT a particular repository or project.

I think it's important that the sponsorship pools themselves are comprised of projects, not users or organizations. This gets complicated if multiple entities/organizations are listed as the maintainers of a particular project. There would need to be a mechanism in place to split the incoming donation money among the set of maintainers as they see fit.

³ It's been pointed out to me that Flattr uses this exact model! Unfortunately they're not intended for open source software specifically and simply don't have enough awareness to really move the needle. For this model to reach it's potential, it needs to be implemented by a visible, trusted, established player.

Other organizations trying interesting things: Snowdrift ("crowdmatching"...very cool concept), Flossbank (a Tidelift-like model), Gitcoin.

⁴ The even holier grail: a zero click sponsorship! An example of this approach is Brave Browser's token-based micropayments system. Brave lets you fund your "wallet" with various cryptocurrencies, which are then distributed to creators proportional to the time you spend on their site.

It’s a great idea, but surveillance is necessary to gather the requisite information. This is implemented ethically by Brave, but that’s only possible because they control the full browser experience. For this to work across browsers would require an extension with full access to your browsing patterns. So probably a non-starter.