Open Source Is the Largest Act of Generosity in History

I run maybe forty pieces of open-source software in my homelab on any given day, and I have paid for approximately none of them. That sentence should bother me more than it does. Somewhere out there, a person spent a weekend, or a year, or a decade, writing code that solves a problem I have, and then instead of selling it to me they published it under a licence that lets me take it, run it, read every line of it, and modify it, for nothing. Multiply that by the millions of packages sitting in every package registry on Earth and you get something that doesn’t have a good economic name, because economics assumes people mostly act in their own material interest and this, at scale, quietly doesn’t.

The standard explanation is that open source is really just enlightened self-interest: developers scratch their own itch, companies open-source their internal tools to attract talent, and everyone benefits from network effects that make their own product more valuable. All of that is true and none of it is the whole story. It doesn’t explain why someone still answers GitHub issues on a project they finished solving their own problem with years ago. It doesn’t explain the maintainer of a niche parsing library used by three companies who fixes a security report on a Tuesday night for free. Self-interest is the seed. It isn’t what keeps the tree alive.

The economics that shouldn’t work

A piece of proprietary software recoups its development cost by charging every user a slice of what it cost to build. A piece of open-source software recoups nothing directly from most of its users, and yet the collective value produced is enormous — most of the modern internet runs on a stack where the operating system, the web server, the database, the language runtime and the container tooling are all free to use commercially. The reason this doesn’t collapse is that the cost of copying software is zero and the cost of building it is the only real cost, so a single person’s labour can serve an unlimited number of users at no additional marginal cost. That’s the same economic property that makes public radio and lighthouses work, except open source scales to a level lighthouses never had to.

What makes it generosity rather than just cheap distribution is that most maintainers get nothing measurable back. There’s no royalty cheque, no ad revenue, frequently not even a thank-you email, because most users never surface — they clone a repository, use it, and move on. The maintainer wrote something for an audience they will mostly never meet and will mostly never hear from, knowing that going in, and did it anyway. I’ve seen decade-old commit histories on tools I depend on daily where the last visible interaction from a grateful user was a one-line GitHub issue titled “thanks” that never got a reply, because the maintainer had already moved on to the next thing that needed fixing.

Where the generosity actually costs something

The romantic version of this story stops at “people are nice.” The honest version has to include what it costs the people doing it, because unpaid maintenance is not a victimless arrangement.

• Burnout is common and rarely visible from outside. A maintainer answering issues at 11pm after a full-time job is not sustainable indefinitely, and plenty of critical infrastructure projects run on exactly one person doing this.
• Security fixes land unevenly. A widely-used library maintained by a single unpaid person can sit on a known vulnerability for months, because triaging a CVE properly takes uninterrupted hours that person doesn’t reliably have.
• Corporate consumption without corporate contribution is the norm, not the exception. Companies with revenue in the billions routinely depend on libraries maintained by nobody on their payroll, and the dependency graph of most production software makes this invisible until something breaks.

None of that is an argument against open source. It’s an argument for taking the generosity seriously enough to notice its edges, because a gift economy that quietly runs some of its participants into the ground isn’t as healthy as the marketing suggests.

What actually sustains it

The projects that survive past their founder’s initial burst of interest tend to share a specific pattern: they found a way to convert some of the value they create back into support for the people creating it, without abandoning the free-and-open part.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

Sustaining patterns that actually show up in the wild:
  - Foundation stewardship  → Linux Foundation, Apache Foundation, CNCF
                              take legal/financial custody so no single
                              person is a bus-factor-of-one
  - Dual licensing          → free for personal/small use, paid for
                              commercial deployment at scale
  - Sponsored maintainers   → a company pays one engineer's salary to
                              maintain a dependency everyone relies on
  - GitHub Sponsors / OpenCollective
                            → direct, small, recurring support from
                              users who can afford it
  - Corporate upstreaming   → companies contribute fixes back instead
                              of maintaining private forks forever

None of these fully solve the problem. Foundation-backed projects can still be under-resourced relative to their blast radius if something breaks. Dual licensing works for tools with an obvious enterprise tier and badly for a five-hundred-line utility nobody would pay for. Corporate sponsorship is the strongest lever and the rarest one, because it requires a company to notice that a dependency is load-bearing while it’s still working, a moment of attention most organisations only spare in hindsight.

The dependency you’ve never heard of is the risky one

Every widely-publicised open-source security incident follows the same shape: a piece of infrastructure that millions of systems depended on turns out to have been maintained, in practice, by one person doing it unpaid in their spare time, and the world only finds out when that person is overworked, unwell, or simply exhausted enough that a bad actor’s patch gets waved through. The library itself is rarely obscure to the systems using it. What’s obscure is the maintenance capacity behind it, because a GitHub star count tells you how popular a project is and nothing at all about how many hours a week its one maintainer has left to give it.

This is the part of the generosity story that’s easiest to romanticise and most important to get right. The maintainer is very often a single named individual whose day job, health, and patience are the only thing standing between your production stack and an unpatched vulnerability, a long way from the faceless collective people tend to imagine. I’ve traced dependency chains in projects I run at home down through four or five layers of “who actually maintains this” and landed, more than once, on a single contributor account with a commit history that goes quiet for months at a time. That’s not a criticism of the person. It’s a structural fact about how much of the software world’s foundation rests on unfunded, unrewarded labour, and it’s worth sitting with rather than looking past.

What this looks like from the maintainer’s side

I’ve spent enough time on the receiving end of open-source contributions — small utilities, a couple of Hugo shortcodes, nothing load-bearing for anyone but me — to have a rough feel for what the asymmetry looks like from inside it. A single well-written bug report with a reproducible case takes minutes to act on. A vague one (“doesn’t work on my machine”) can eat an entire evening of back-and-forth before you even confirm what the actual problem is, and that evening was entirely unpaid, offered up for free out of the same sense of obligation that keeps most maintainers going. Multiply that by a project with real adoption and you understand why maintainers burn out on triage long before they burn out on writing code — the code was always the part they enjoyed.

The maintainers who last longest tend to be ruthless about boundaries in a way that looks unfriendly from outside and is actually the only sustainable posture available to them: closing issues that don’t include a reproduction, redirecting support questions to a forum instead of answering them personally, saying no to feature requests that don’t align with the project’s scope. None of that is rudeness. It’s the only lever a single unpaid person has for keeping a project alive past year three, and users who read it as rudeness are usually the ones who’ve never tried to maintain something with a userbase larger than their own household.

What you can actually do about it, practically

If you run open-source software in production — and if you’re reading this you almost certainly do — there are concrete, low-effort things that move the needle more than a one-off donation.

File useful bug reports, not vague ones. “It crashes sometimes” costs a maintainer far more time to triage than a reproducible case with a stack trace, and a bad report is sometimes worse than no report because it consumes attention without moving anything forward.

Fix your own small bugs and send the patch back. You already understand your own use case better than the maintainer does; a five-line fix with a test attached is one of the highest-leverage contributions available to someone who isn’t a full-time open-source developer.

Sponsor the projects you’d be in genuine trouble without. Not the ones with the flashiest README — the boring ones quietly running your DNS resolver, your backup pipeline, or your certificate renewal. GitHub Sponsors takes less time to set up than reading this paragraph did.

If your employer depends on something, tell them. Most engineering organisations have no idea which open-source projects sit under their production stack until someone runs a dependency audit after an incident. Surfacing that before the incident is the highest-leverage thing an individual engineer can usually do.

Troubleshooting the “but I don’t have anything to give” objection

The most common reason people don’t contribute isn’t stinginess, it’s the belief that contributing requires being a better engineer than the maintainer, which is rarely true and almost never the actual blocker.

• “I don’t know the codebase well enough to submit code.” Documentation fixes, reproducible bug reports and honest user feedback on a beta release are all real contributions that don’t require reading the whole source tree first.
• “My company won’t let me contribute on work time.” Ask anyway — a surprising number of legal teams will approve a small, defensive patch (bug fix, not new feature) faster than you’d expect, because it reduces the company’s own maintenance risk.
• “I don’t have money to sponsor anything.” Time is the scarcer resource for most maintainers, not money specifically; a well-triaged issue or a tested pull request is worth more to a solo maintainer than most one-off donations.
• “I already tried contributing and got ignored.” Check the project’s contribution guidelines before assuming neglect — a lot of “ignored” pull requests are actually sitting behind a maintainer’s backlog of a hundred others, and a polite follow-up after a few weeks is standard, accepted practice among regular contributors.
• “The maintainer seems hostile to new contributors.” A terse response to an incomplete bug report is usually triage efficiency, not hostility; read the project’s issue templates and match their expected format before concluding the maintainer is unwelcoming.

Is it worth caring about

Yes, and not in an abstract, feel-good way — practically, because the software your business or your homelab depends on is being maintained by people whose continued goodwill is not guaranteed and not infinite. I’ve moved my own homelab further toward self-hosted tools over the years precisely because the alternative, what open source doesn’t guarantee you, is a set of assumptions worth being honest about before you build something load-bearing on top of a project with one maintainer and no funding. The generosity is real. So is the fact that it’s finite, unevenly distributed, and mostly invisible until the day it isn’t there.