Funding Models
Open source software powers the modern internet. Linux runs most servers. OpenSSL secures most connections. curl moves most data. Yet the people who maintain these critical projects are overwhelmingly unpaid. The gap between the value open source generates and the revenue it captures is one of the most significant structural problems in the software industry.
The Sustainability Crisis
In 2014, the entire internet was vulnerable to Heartbleed, a critical bug in OpenSSL. The project was maintained by two people, one of whom worked on it full-time for a salary of about $20,000 per year. OpenSSL was used by every major tech company on earth, yet almost none of them funded it.
This is not an isolated case. The pattern repeats across the ecosystem:
- Log4j (2021): a critical vulnerability in a Java logging library maintained largely by volunteers, used by virtually every Java application in production
- core-js: a JavaScript polyfill library downloaded billions of times, maintained by a single developer who publicly described going broke
- OpenPGP.js: encryption library used by ProtonMail and others, maintained by a small team with minimal funding
The economics are stark. Companies build products worth billions on top of open source dependencies they pay nothing for. The maintainers absorb the cost of bug fixes, security patches, and support.
Sponsorship
Sponsorship is the most direct funding model. A company or individual pays a maintainer or project on a recurring basis, usually without expecting specific deliverables.
GitHub Sponsors
GitHub Sponsors allows anyone with a GitHub account to sponsor developers or organizations directly. The platform takes no fee (as of 2024), meaning 100% of the sponsorship goes to the maintainer.
How GitHub Sponsors works:
1. Maintainer creates a sponsorship profile
2. Defines tiers (e.g., $5/month, $25/month, $100/month)
3. Sponsors choose a tier and pay monthly
4. GitHub deposits funds directly to the maintainer
Real-world example: Caleb Porzio, creator of Alpine.js and Livewire, earns a full-time income through GitHub Sponsors. He provides sponsor-only screencasts and early access to features as incentives.
Open Collective
Open Collective differs from GitHub Sponsors in a key way: it provides fiscal transparency. Every transaction is public. This makes it suitable for projects that need to show how funds are spent, which matters for organizations contributing to open source.
Open Collective model:
- Project creates a Collective
- Fiscal host manages legal and tax obligations
- All income and expenses are public
- Contributors can submit expenses for reimbursement
Projects like webpack, Babel, and Vue.js have used Open Collective successfully. webpack raised over $1 million through the platform, funding multiple full-time contributors.
Tidelift
Tidelift takes a different approach. It sells subscriptions to companies that want guaranteed maintenance, security updates, and licensing compliance for their open source dependencies. Tidelift then pays the maintainers of those dependencies from the subscription revenue.
Tidelift model:
Company pays Tidelift subscription
-> Tidelift identifies dependencies
-> Tidelift pays maintainers
-> Maintainers commit to security and maintenance SLAs
Donations
Donations are the simplest funding model. A project puts up a "buy me a coffee" button or a PayPal link and hopes people contribute.
When Donations Work
Donations work for small projects with passionate user bases. A developer tool used by a tight community can generate enough donations to cover hosting costs and perhaps a few hours of maintenance time per week.
Donation platforms:
- Buy Me a Coffee
- PayPal donate buttons
- Patreon (for ongoing support)
- Ko-fi
- Liberapay
Why Donations Do Not Scale
Donations fail for most projects because of the free-rider problem. If 10,000 developers use a library, perhaps 50 will donate. The rest assume someone else will pay, or they simply do not think about it. The per-user value is too low to generate meaningful revenue.
The math is brutal:
Library with 100,000 monthly downloads
Typical donation rate: 0.01% to 0.1%
Average donation: $5 to $20
Monthly revenue: $50 to $2,000
Cost of a full-time maintainer: $8,000 to $15,000/month
Gap: enormous
Crowdfunding
Crowdfunding platforms like Kickstarter and Indiegogo have occasionally been used to fund open source development. A maintainer proposes a specific feature or milestone and asks the community to fund it.
Crowdfunding for open source:
- Works for specific, well-defined goals (new version, major feature)
- Requires strong community engagement
- One-time funding, not ongoing
- Examples: Godot Engine, elementary OS
Crowdfunding shares the limitations of donations but adds urgency and specificity. It works when the community deeply wants a particular outcome and is willing to pay for it upfront.
Grants
Grants provide larger one-time or multi-year funding, usually from foundations, governments, or corporations.
Sovereign Tech Fund
The German government's Sovereign Tech Fund invests in open source infrastructure that the government and society depend on. It has funded projects like curl, OpenSSL, and the Linux kernel. The fund recognizes that critical digital infrastructure needs public investment, just like roads and bridges.
Google Summer of Code
Google Summer of Code (GSoC) pays students to contribute to open source projects over a summer. It has been running since 2005 and has introduced thousands of new contributors to open source. While it does not fund maintainers directly, it reduces the maintenance burden by bringing in new contributors.
Grant sources for open source:
- Sovereign Tech Fund (Germany)
- NLnet Foundation (Netherlands)
- Google Summer of Code
- Mozilla Open Source Support (MOSS)
- Chan Zuckerberg Initiative (science-focused)
- Ford Foundation (civic tech)
- NumFOCUS (scientific computing)
- Linux Foundation grants
The Limitations of Grants
Grants are competitive and time-consuming to apply for. They typically fund specific work, not ongoing maintenance. A grant might pay for a new feature, but it will not pay for the years of bug fixes and security patches that follow.
Most grants also have reporting requirements. For a solo maintainer already stretched thin, writing grant reports can consume time that would be better spent on the code.
The Challenge
The fundamental problem is structural. Open source creates massive positive externalities. Every company that uses Linux benefits from it, but none of them are obligated to pay for it. This is the classic free-rider problem applied to software.
Some approaches to addressing this:
Supply-side solutions (help maintainers get paid):
- Sponsorship platforms
- Grants and foundations
- Corporate employment of maintainers
- Bounty programs
Demand-side solutions (make companies pay):
- License changes (see open core and dual licensing)
- SaaS offerings
- Support contracts
- Social pressure and awareness campaigns
The most sustainable path for most projects is not any single funding model but a combination. A project might have GitHub Sponsors for individual supporters, an Open Collective for corporate sponsors, and a grant for a specific large feature.
Bounty Programs
Bounty programs pay contributors for completing specific tasks. A project posts a bounty (say, 2,000 for implementing a feature), and any contributor can claim it by submitting a working solution.
Bounty platforms:
- IssueHunt: bounties attached to GitHub issues
- Gitcoin: bounties for web3 and open source projects
- BountySource: general open source bounties
- Custom: project maintains its own bounty board
Bounties work well for discrete, well-defined tasks. They do not work well for ongoing maintenance, architectural decisions, or community management. The risk is that bounty hunters optimize for getting the bounty, not for code quality. Clear acceptance criteria and thorough code review mitigate this.
Corporate Employment of Maintainers
Some companies hire open source maintainers to work on their projects full-time. This is arguably the most sustainable funding model because it provides a stable salary, benefits, and the institutional support of a company.
Examples of corporate-employed maintainers:
- Linux kernel developers employed by Red Hat, Intel, Google, Microsoft
- Node.js contributors employed by various companies
- Rust compiler team members employed by AWS, Google, Microsoft
- Python core developers employed by Microsoft, Google
The risk is dependency on a single employer. If the company changes priorities, the maintainer might be reassigned. The project loses its primary contributor through a corporate decision, not a community one.
Common Pitfalls
- Expecting donations to fund full-time work. They almost never do. Treat donations as a supplement, not a salary.
- Applying for grants without a clear scope. Grant committees fund specific, measurable outcomes. "Maintain the project" is not specific enough.
- Setting sponsor tiers too low. A company getting 500/month. Do not price yourself at $5/month for corporate sponsors.
- Ignoring the sustainability problem until burnout hits. Many maintainers only think about funding after they are already exhausted. Start early.
- Assuming funding will come from users. Most funding comes from companies. Target your fundraising accordingly.
- Not being transparent about finances. Projects that show how funds are used attract more sponsors. Open Collective exists for this reason.
Key Takeaways
- Open source generates massive value but captures very little revenue, creating a sustainability crisis that affects the entire software ecosystem.
- Sponsorship through platforms like GitHub Sponsors and Open Collective is the most direct funding model, but requires active cultivation of sponsors.
- Donations work for small projects but do not scale due to the free-rider problem.
- Grants from organizations like the Sovereign Tech Fund and Google Summer of Code provide larger sums but are competitive, time-limited, and require reporting.
- The most sustainable approach combines multiple funding sources rather than relying on a single model.
- Most open source maintainers are unpaid, and the gap between value created and revenue captured remains the central challenge of the ecosystem.