Open source is a commons. Many companies use the same code and benefit from it, but few pay for its upkeep. Heartbleed in 2014 made that visible: a library protecting a large share of the web had only a handful of maintainers and almost no money. The fix is to fund what you depend on.
What Heartbleed revealed
According to the Wikipedia account of Heartbleed, OpenSSL was maintained by a handful of volunteers when the bug was found, only one of them working full time. Yearly donations were about US$2,000. Core developer Ben Laurie called the project completely unfunded, and Dan Kaminsky said the world was building critical technology on shockingly underfunded infrastructure. Donations in the two or three days after disclosure totaled US$841.
The Linux Foundation announced the Core Infrastructure Initiative on 24 April 2014, a multimillion dollar project to fund critical parts of the global information infrastructure so that lead developers could work full time and audits could be paid for.
The commons logic
Garrett Hardin's 1968 essay described a shared pasture where each herder gains the full benefit of one more animal while the cost falls on everyone. Applied to code, each company gains the full benefit of free software while the cost of maintaining it falls on a few volunteers. Free riders do well; contributors carry the load.
Hardin later said he should have called it the tragedy of the unregulated commons. That correction matters.
What Ostrom added
Elinor Ostrom and colleagues found that the tragedy was neither as common nor as hard to solve as Hardin argued. Communities often devised their own rules. Success was more likely with defined boundaries, real dependence on the resource, a stable community and local rules with consequences for overuse.
Open source projects have some of these traits already: clear scope, a core of committed maintainers and shared norms. What they often lack is money and a formal link between users and upkeep.
What a dependent company can do
- Know what you depend on. An inventory comes first. See a dependency policy on one page.
- Rank by criticality, not by popularity alone. A small library used in your authentication path matters more than a large one in a test script.
- Check maintainer health. Maintainer health signals tell you where the single points of failure are.
- Pay or contribute. Sponsor, fund an engineer's time, or send patches.
- Plan for loss. Decide in advance what you will do if a key project stalls.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many indirect packages sit under a direct dependency: those are the ones nobody on your team chose.
Quick check
Is open source funding a tragedy of the commons?
It has the same shape: shared benefit and concentrated cost. Ostrom's work suggests it is solvable with clear rules and committed communities.
What is the first practical step?
Build an inventory of what you depend on, so you can see where funding or contribution would reduce your own risk.
Sources
Last reviewed: 19 October 2026.
