A proposal for open source sustainability

Let’s not waste any time. Open source funding is a huge problem that remains unsolved.

GitHub Sponsors is a step forward, but it’s far from a panacea. There’s currently a groundswell of optimism surrounding it in the wake of Caleb Porzio’s enrapturing post recounting his journey to $100k of annual recurring sponsor revenue.

But it’s worth taking a step back to qualify the viability and repeatability of his approach:

1. He created two massively popular web frameworks in different language ecosystems (PHP and JavaScript) within a year. This is hard.
2. He’s been working full-time on open source since January 2019.
3. He had an audience of ~7K Twitter followers before GitHub Sponsors launched in May 2019.
4. He presumably has fairly high sponsor churn, since most sponsors signed up to receive a specific, consumable benefit — access to his set of instructional screencasts. His success here is analogous to creating a particularly successful e-book or programming course — albeit one where he a) also created the technology he is teaching, b) charges a recurring fee for access, and c) uses GitHub as his payment processor.
5. His projects are “framework-scale” projects that — in many cases — provide the backbone upon which a company’s entire product is built. That puts him in a more powerful position than other maintainer. It’s not clear how his approaches translate to smaller, simpler “utility libraries”.

I don’t mean to minimize Caleb’s accomplishments here. Quite the opposite: what he’s pulled off requires a rare combination of talent, dedication, ambition, and influence.

For anyone who is tempted to quit their day job and join the GitHub Sponsors gold rush, I would advise moderation. I refer you to arguably the most successful open-sourcer on GitHub, the legendary Sindre Sorhus. His repositories have accumulated over 479,000 total stars and his packages are downloaded nearly 2 billion times a month.

By my estimation, he’s making roughly $27k per year from GitHub Sponsors (computed from his available Sponsor tiers and his “thanks” page), a little over $10k from Open Collective, and $6k annually from Patreon. It’s harder to estimate his earnings from Tidelift but presumably they’re in a similar ballpark. This is the #1 guy on GitHub and he’s making less than an entry level engineer, from donations at least.

But I don’t write essays just to spout pessimism into the world!

So below I propose a novel-ish approach to OSS sustainability. I aim to apply what I know about incentive design, conversion rate optimization, and human psychology to bring the typical technologist’s financial contributions in closer alignment with the actual value they derive from open source projects.

Theoretically you, dear reader, could take these ideas and implement them. I wouldn’t advise it; there’s not much money in open source, and even less in open source donation processing. The most likely (and likely best case) scenario is that GitHub implements something to this effect under the GitHub Sponsors umbrella.

The proposal

Annual donations

GitHub Sponsors frames their sponsorships as month-to-month commitments.

A point of clarification: GitHub Sponsors supports (or at least used to support) annual billing for sponsorships, but all tiers are still framed as monthly commitments. That framing is what I’m concerned with.

This is a problem. You see, we developers are too clever for our own good. Consider these questions:

1. How much would you be willing to donate to react-router every month?
2. How much would you be willing to donate to react-router every year?

I’m reasonably confident that the average answer to the second question will be more than 12x the average answer to the first. To bastardize a quote from my old pal JCR Licklider (maybe):

People underestimate the value they get from an open source library in a month, and overestimate the value they get from it in a year.

“Hmm, I really love react-router, maybe I’ll sponsor it. Ten bucks a month? Okay, seems reasonable. But wait, that’s more than I pay for Netflix! Do I really get more value from react-router than from Netflix? Plus, if I forget to unsubscribe I’ll be paying $10 a month every month for the 53 additional years I can reasonably expect to live! That’s $6,360! That’s, like, two Chipotle bowls a day for a year! If I invested that in the S&P 500 now, I could turn it into $50k by 2060!”

Like I said, too clever for our own good.

We’re conditioned to be stingy about monthly donations by the sheer number of products and services we pay for on a month-to-month basis. There are too many points of reference.

I’m acutely aware that the above discussion is far from rigorous or evidence-backed. For my closing argument, I refer you to the most successful donation scheme ever devised by mankind: Tithing. And it’s (framed as) an annualized donation. 🎤💧

(If you know of any decent research/studies about annualized vs monthly cost/value perception, tell me about it in the comments or on Twitter (@vriad) and I’ll link it here.)

Sponsorship pools

So now let’s consider a new question:

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

Now we’re getting some nice big numbers! The wording of this question is very deliberate. By drawing an implicit comparison to your annual income, you’re anchored high. 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”.

It’s something we all value immensely, but at the moment of truth (“I’m gonna sponsor React Router!”) it’s too easy to logic our way out of donating (“but what if it’s replaced by some new hotness next week?!”).

So what’s the fix? The donor’s contributions should go into their personal “sponsorship pool” — a pot of money they can allocate to the various projects they want to support. This way, donations will reflect their perceived value from open source software as a whole. This is a massive and qualitative difference.

Financial considerations

GitHub has a financial incentive to switch to a system like this. 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 they implement a sponsorship pool-based system and it 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.

Pool allocation

There are a number of possible mechanisms for distributing the contents of these sponsorship pools.

The brute force solution

The brute force solution would involve some simple interface for searching across GitHub Sponsors/Patreon/Open Collective and selecting a pool of recipients. Seems reasonable, if a bit obvious.

This would likely require buy-in from all of those entities, since their APIs don’t support programmatic creation of donations/sponsorships. In fact Patreon just deprecated their entire API 😑

Attention-based distribution

Let’s get clever! You could distribute donations proportional to usage or attention.

The most successful precedent for this is the 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.

A stellar proposal

So here’s a better idea: what if your donation was distributed evenly between all the repos you’ve starred on GitHub?

More specifically — each month, 1/12th of your annual pool will be paid out across the projects you’ve starred (or otherwise added to your pool). The payouts should be run on a monthly schedule — not annual! This regularizes the income stream for maintainers and gives donors more granular temporal control over how their money is distributed. If you discover a great new library, you shouldn’t have to wait until the next annual cycle before your changes take effect.

If GitHub implemented something to this, they would undoubtedly divorce the mechanism from Stars. They want to keep the concept of a “star” as ambiguous and unencumbered as possible. Perhaps instead, users who have created and funded a sponsorship pool can be presented with an “Add to Pool” button in place of the standard “Sponsor” button.

This would achieve what I consider to be 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 add a new project as a recipient of your your sponsorship pool. The marginal cost (both psychological and financial!) of supporting additional projects would drop to zero. That’s a game changer.

To allow the awarding of different fractional amounts to different projects, a Medium-style “claps” metric could be used instead. The pool would be distributed proportial to claps.

A comparison to GitHub Sponsors

Currently it takes four clicks minimum to sponsor an OSS project on GitHub — and that’s if you already have a payment method set up (most don’t).

But without a structural change to the GitHub Sponsors program, it will never approach the holy grail of 1-click sponsorship.

Social proof

I’d love to see embeddable badges that are “unlocked” at different levels of donorship. I can 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.

You 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 the GitHub Sponsors program; it’s a huge win for maintainers (including myself). This is merely a hypothetical exercise.

For now.

If you want to know when I publish new essays, sign up for my mailing list or follow me @vriad.