We tend to describe open source in the language of software: licences, repositories, pull requests. But the most important word in the phrase is the one we rarely examine. A commons is not a giveaway. It is a shared resource that a community holds in trust, governs by custom, and maintains through ongoing effort. Understood that way, open source stops being a clever distribution model and becomes something older and more demanding — a question of stewardship.
The tragedy that wasn’t inevitable
The classic warning about a commons is that it will be overgrazed — that individuals, each acting rationally, will exhaust a shared pasture. The lesson usually drawn is that shared resources fail. But the economist Elinor Ostrom spent a career documenting the opposite: communities that managed forests, fisheries, and irrigation systems for centuries without collapse. They did it not through markets or top-down rule but through shared norms, clear boundaries, and the steady labour of maintenance.
A commons does not fail because it is shared. It fails because no one is left to tend it.
Software is an unusual commons because it does not deplete. My using a library does not leave less of it for you. Yet it can still be overgrazed in a subtler sense: the maintainers can be exhausted. The pasture is fine; the shepherds are burning out.
The invisible labour of maintenance
Most of what keeps open source alive is unglamorous and unpaid. It is the triage of a hundred issues, the patient explanation to a confused newcomer, the security patch released quietly on a Sunday. Writing a feature is creative work that feels good. Maintaining it for a decade is a different kind of labour, and our culture barely acknowledges it.
The dependency graph of a modern application is a map of borrowed trust. Somewhere near the bottom is a package maintained by one person in their spare time, depended on by millions who have never heard their name. When that person stops — through burnout, illness, or simply life — the consequences ripple upward through everything built above.
Every npm install is an act of trust extended to strangers, and a debt of gratitude we rarely repay.
On the modern supply chain
What stewardship asks of users
If open source is a commons, then using it carries obligations — not legal ones, but ethical ones. They are not onerous, and they are widely ignored.
- Report well. A clear, reproducible bug report is a gift; a vague complaint is a tax on someone’s evening.
- Give back what you can. Documentation, triage, and answered questions are as valuable as code.
- Fund the foundations. If your business runs on a project, paying its maintainers is not charity; it is maintenance of your own infrastructure.
- Be kind in public. Maintainers read every issue. Entitlement drives them away faster than any technical problem.
Governance is the hard part
Code is the easy part of a commons. Governance is where projects live or die. Who decides the roadmap? How are disputes resolved? What happens when a corporate sponsor’s interests diverge from the community’s? The projects that endure are the ones that answer these questions before a crisis forces the issue — with foundations, transparent decision-making, and a deliberate spreading of authority so that no single departure can sink the whole.
This is why the healthiest open-source projects can feel almost boring in their process: codes of conduct, request-for-comment documents, elected committees. It is not bureaucracy for its own sake. It is the institutional memory that lets a commons outlast its founders.
Funding models that actually work
For years the open-source funding conversation was stuck on donations — a tip jar beside a project that millions depended on. Tip jars rarely work, because they ask individuals to pay for something they correctly perceive as free, and because generosity is not a sustainable substitute for structure. The models that have proven more durable share a common trait: they connect the people who derive value from a project to the people who maintain it, with as little friction as possible.
- Foundations pool money from many companies and employ maintainers directly, insulating critical projects from any single sponsor’s whims.
- Open-core companies give away a strong common base and sell hosting, support, or advanced features around it.
- Direct corporate employment puts maintainers on a payroll to work on the dependency their employer relies on.
- Tiered sponsorship lets businesses pay in proportion to the value they extract, rather than the loose change a tip jar collects.
None of these is perfect, and each introduces its own tensions. But all of them beat the default, which is to assume the work will simply continue to be done for free by people whose names we never learn.
The corporate paradox
Large companies have a complicated relationship with the commons. They are simultaneously its greatest beneficiaries and, often, its most demanding consumers. A company can build a billion-dollar product on a foundation of volunteer-maintained libraries and contribute nothing back but bug reports filed with the tone of a paying customer. This is not malice; it is the ordinary blindness of treating infrastructure as a given rather than a gift.
The healthier corporate posture treats open-source dependence as a relationship with obligations. The companies that get this right assign engineers to upstream work, fund the foundations that govern their critical dependencies, and measure their contribution not by press releases but by the unglamorous patches and reviews their staff submit. They understand that a commons they rely on is, in effect, part of their own supply chain — and that letting it decay is a risk to their business, not an externality.
What maintainers actually need
Ask maintainers what would help and the answers are seldom about money first. Money matters, but so does relief from the relentless, low-grade pressure of being permanently on call for something the whole world uses and few people support.
- Co-maintainers, so that a holiday or an illness does not become a crisis for everyone downstream.
- Permission to say no, so a project can have a scope and keep it.
- Patience and warmth from users, which costs nothing and prevents more burnout than any grant.
The thread running through all of this is that maintenance is a human activity, not a mechanical one. A commons is kept alive by people, and people need rest, support, and the occasional sign that the work is seen. The most radical thing most of us could do for open source is not to write more code but to make its caretakers feel less alone.
A brief history of enclosure
To understand why the commons framing matters, it helps to remember what happened to the original commons. For centuries, English villagers held the right to graze animals and gather wood on shared land. Then, over a few generations, that land was enclosed — fenced off, privatised, removed from common use — in the name of efficiency. Efficiency arrived; so did dispossession. The enclosure movement made some people wealthy and stripped many others of a resource they had relied on for generations.
Software has its own quiet enclosures. A beloved open project is acquired and slowly closed. A permissive licence is exploited to build a proprietary product that gives nothing back. A community’s work is absorbed into a platform that then changes the terms. Each enclosure follows the same logic: take something shared, fence it, and capture the value the community created. The open-source licences we rely on are, in part, an attempt to prevent exactly this — to keep the pasture open by making its openness legally binding.
Licences are necessary but not sufficient
It is tempting to believe that the right licence solves the problem of the commons. It does not. A licence governs what you may legally do with the code; it says nothing about whether anyone will maintain it, whether the community is healthy, or whether the project can survive its founder losing interest. A permissively licensed project with one exhausted maintainer is far more fragile than a well-governed project with a stricter licence and a thriving community. The legal layer is the floor, not the structure.
What actually sustains a commons is the social fabric around the code: the norms about how decisions are made, the rituals of review and release, the shared sense that this is ours to tend. Licences can be written in an afternoon. That fabric takes years to weave and an instant to tear. This is why the most durable projects invest so heavily in things that have nothing to do with code — mentorship, documentation, governance, conduct — and why a newcomer’s first good experience contributing matters more to a project’s longevity than almost any technical decision.
There is a hopeful corollary. Because the fabric is social, anyone can strengthen it. You do not need commit access to make a project healthier. A patient answer to a beginner’s question, a bug report written with care, a word of public thanks to a maintainer who will never expect it — these are the threads from which a resilient commons is woven. The code is the easy part. The community is the commons.
Tending what we share
The romance of open source is the lone hacker releasing brilliant code into the world. The reality, and the more hopeful story, is communities patiently tending shared resources across decades. That work is less photogenic but more important, and it depends on a culture that values the gardener as much as the inventor.
The next time an installation completes in seconds, pulling in libraries built by people you will never meet, consider it for a moment as what it is: a commons, held in trust, and quietly waiting to see whether this generation of users will tend it or simply graze.
It is easy to take the commons for granted precisely because it works so well. The libraries load, the builds pass, the dependencies resolve, and the whole invisible scaffolding of modern software holds us up without ever asking for thanks. But scaffolding that no one maintains eventually fails, and it fails at the worst possible moment, all at once, for everyone standing on it. The work of this generation of builders is not only to create but to conserve — to leave the commons a little healthier than we found it, with more maintainers supported, more newcomers welcomed, and more of the quiet labour of upkeep recognised for what it is. The code will take care of itself. The community that tends it will not, unless we decide to be the ones who tend it.
None of this requires grand gestures. The commons is not saved by a single heroic donation or a viral campaign; it is sustained by countless small, repeated acts of care that never make the news. A maintainer who feels supported stays one more year. A newcomer who is welcomed becomes the maintainer who welcomes the next. A company that funds its dependencies makes it normal for the next company to do the same. These are slow compounding loops, easy to start and easy to neglect, and the future of the software we all depend on is decided, quietly, by how many of us choose to keep them turning.
Leave a Reply