A short story: No good deed goes unhampered
You're an open source developer or someone who primarily uses open source to build your projects. You know your favorite projects need financial support, even as a casual observer. While you might have avoided the log4j troubles and enjoyed your eggnog while others diligently patched their systems last December, you're uneasily awaiting your turn of the vulnerability musical chair game.
You open Hacker News, click the first link, and nod approvingly as you read the blog post highlighting the awful state of open source funding. That's it. You'll do something about it now, provided the following article isn't a comparison of "Rust vs. Zig," so you find yourself on GitHub for a favorite project.
You make a $25 donation, refresh the list of sponsors, and won't you believe it; your avatar joins the list of supporters. It's satisfying, but you are not done. The problem is bigger than just one project, so you browse to another of your handful of projects.
You land on project no. 2, and again it's a no-brainer to fund. GitHub has your credit card details, and you're just a click away from supporting it. You look at the suggested donation amounts and pause. Hmm. You think, "I like this project, but I just donated $25." Do you really like this project as much as the first? Maybe you think, you should donate to yet another project after this. The cursor settles on $20. Click, refresh, avatar, followed by a feeling of accomplishment but less than the first time.
That feeling of indignation isn't completely gone, so you'll make one last donation. You browse several projects, see if they're accepting donations, and then pick one on a whim because GitHub issues are calling your name. Bam, another $20, you close the tab, hoping you're not alone in taking action, but not so deep down you know others probably aren't that fired up about it -- the article only has 50 comments.
You're happy to have given something to three projects you care about, but the magnitude gnaws at you, and the sinking feeling stops you from really enjoying the meaningful donation you made today. It's another six months before you donate again.
Something in the way
Our story is the state of open source funding today: GoFundMe for open source projects but mostly without the virality of life-altering tragedies. What open source lacks in virality, it makes up with millions of developers using and investing in open source software.
Unfortunately, the current model isn't meeting the needs of potential supporters or open source projects. While both Open Collective and GitHub annually pass on millions of dollars, still too few critical projects receive adequate funding.
So, why isn't the current model for funding open source adequate? For us the story above exposes these key hurdles that evey supporter has to clear:
- Which projects should I fund?
- Are they accepting funding?
- How much should I give to each of these projects?
Because of these hurdles, at no point does a supporter attempt to fund all of their open source dependencies.
Open source maintainers have their own friction. The nature of the current model requires structuring tiers of sponsorship, crafting marketing copy for your sponsorship page, and then promoting it. Shockingly, this isn't high on the developer todo list.
Not just a faster horse
With all of that in mind, StackAid set out to fund all your dependencies while eliminating the hurdles for both open source maintainers and supporters.
It starts with the monthly subscription. Your monthly subscription divides equally among your dependencies, so there is no need to figure out how much to donate per project. StackAid resolves the dependencies to their repositories and evenly distributes your monthly fee among the direct dependencies.
Since the funding is automated, StackAid takes allocating your fee two steps further.
First, after evenly distributing your subscription fee among the direct dependencies, each direct dependency shares up to 50% with its dependencies (indirect dependencies).
Second, StackAid accrues money for dependencies for two months. Outside the accrual window, unclaimed money reallocates among other StackAid claimed dependencies.
Why do this?
Well, by funding indirect dependencies, you're funding projects you rely on but that otherwise would not get funded. Two thirds of indirect dependencies never occurred as direct dependencies in thousands of projects we sampled.
And, temporary accrual decouples funding and receipt of funds. Once funds have accrued (for example: eslint), the maintainer can see their public profile page and choose to claim funds before being redistributed.
Here's an example from our homepage assuming we have just two dependencies, bootstrap and sass.
Assuming you're funding at $20/month, StackAid shows you how the money distributes among your direct and indirect dependencies.
- ├
- ├
- └
- ├
- ├
- ├
- ├
- ├
- └36 more
Proof is in the pudding
To understand how StackAid's model for allocating money would work, we created a complete
simulation of StackAid with 5,000 subscribers using real
world JavaScript projects.
The simulation includes 5157 projects in the JavaScript ecosystem, each using a package.json found
on GitHub (thanks to SourceGraph) that wasn't published to NPM.
Quick stats
| Package.json files | 5,157 |
| Unique dependencies | 23,027 |
| Direct dependencies | 13,036 |
| Indirect dependencies | 15,950 |
The primary question we wanted to answer was how the money would be distributed among all the direct and indirect dependencies, and how does this compare with GitHub Sponsors and Open Collective.
We chose to calculate the number of accounts on each platform that reach 25%, 50%, 75% and 95% of all funds. The percentiles tell us how funds are distributed over the population of accounts. In the extremes, we have two undesirable outcomes: winner-takes-all and equal share for every project. The desired outcome looks like a sound economy meaning broad participation in the open source upper and middle class.
With the 5K subscriber simulation in hand, calculating the percentiles of total funds for accounts was straightforward. To compare with Open Collective, we fetched all the transactions from Open Collective for the past year (6/1/2021 - 6/30/2022).
For GitHub, we collected which GitHub Sponsors accounts associate with the 23K repos and the number of supporters for each of those GitHub Sponsor accounts. We estimated funding for GitHub Sponsors accounts by running a Monte Carlo simulation sampling transactions from the Open Collective data set. We assume that for projects with similar number of supporters, GitHub and Open Collective should have similar distributions of donation amounts and one-time vs. monthly supporters.
Below are the results comparing cumulative percentage of funds for each platform broken down by accounts.
Cumulative percentage of funds
| # of Accounts | 25% | 50% | 75% | 95% |
|---|---|---|---|---|
| StackAid | 10 | 51 | 283 | 2305 |
| GitHub Sponsors | 5 | 27 | 69 | 186 |
| Open Collective | 2 | 7 | 19 | 45 |
| # of Repositories | 25% | 50% | 75% | 95% |
| StackAid | 38 | 197 | 1070 | 7693 |
Note: The chart and table count the top accounts that get 25%, 50%, 75% and 95% of all funds. When we say cumulative, we mean that the accounts in the 50% group also contain all the accounts in the 25% group.
There are several takeaways from this data.
- The power law is very much present in all three platforms.
- Open Collective has a handful of projects that dominate funding.
- The GitHub estimations fare better than Open Collective because of the slower drop-off in number of supporters in the top 75 percentile of projects.
- Hundreds of accounts on GitHub Sponsors and Open Collective for our sample set received no support. These are accounts that are able to receive funding today but have no supporters but are depended upon by hundreds of subscribers.
- StackAid, while not immune from the power law distribution, brings many more projects into each of the percentiles.
In the near future, we'll share the data and the process for the calculations above.
Be sure to check out the simulation blog post and browse around the simulation to get a feel for funding using StackAid.
Not just the founders, we’re also members
We built StackAid to support open source, so of course, we're subscribers. We each have a subscription under the StackAid organization as well as our personal accounts.
Here is my personal subscription to StackAid. After OAuthing
with the GitHub app, I'm able to see my repositories in the dashboard that contain either a
stackaid.json or a package.json file.
StackAid lets you choose which repositories contribute dependencies for your subscription. By default all repositories with either JSON file will be included.
Once the repositories are selected, you can see how much you will be funding direct and indirect dependencies over the course of a year.
Lastly, your organization will also get a public profile page, like the one below, showing contributions to date for all your dependencies. If you click through, your organization is listed as a supporter of that repository.
What's in it for StackAid?
StackAid is an implicit dependency for each account, but unlike other direct dependencies is capped at 7.5% of the subscription. To align incentives, StackAid's percentage is no better than the percentage received by other dependencies.
Happily after alpha
We're excited to open StackAid up to the public, starting with a limited beta. Please join the waitlist if you're interested in subscribing as an open source project or a supporter. The beta period is a chance for us to hear more people's feedback and give out free t-shirts.
And while the beta lasts, StackAid will match money contributed by subscribers and the money received by open source projects. For subscribers, StackAid matches upto $100 per month. For open source maintainers, StackAid matches upto $100 per month across your projects based on referrals.
In the meantime, we're working on supporting ecosystems besides NPM and access to GitLab for supporters. More to come on that front soon!