The Seventy-Year Favor: How the Software Industry Learned to Take and Never Learned to Pay

The unwritten contract that was never signed#

A developer in Nebraska, or Bangalore, or a small town in Poland, spends a few evenings a week building a tool. It solves a real problem, so they push it to GitHub under a permissive license because sharing feels obviously right, and because it’s genuinely satisfying to watch strangers find your work useful. Three years pass. That tool is now inside the dependency tree of three Fortune 500 companies, two government agencies, and a fintech startup valued at $2 billion. It processes payment data, authenticates users, and sits close to the edge of systems that matter. The original author hasn’t touched the code in eight months. They changed jobs, had a kid, or just moved on to something else.

Then a CVE drops, or a security researcher finds a flaw that could become the next supply chain headline. The issue tracker fills with demands. Blog posts call the project abandoned. The author’s name turns into shorthand for “unmaintained dependency risk,” and their inbox fills with messages ranging from politely entitled to outright hostile.

All because they didn’t volunteer fast enough to protect someone else’s revenue.

Open source under a permissive license (MIT, Apache, BSD) comes with no warranty, no support obligation, and no service-level agreement. The license text says this outright. The industry has still built a commercial ecosystem on top of volunteer labor while acting as though those words don’t apply to them. A company downloads a library, ships it inside a product that makes money, and treats the original author as a free tier of technical support, security review, and long-term maintenance. When that free tier doesn’t respond to a vulnerability disclosure within 48 hours, the company rarely asks why it never paid for an audit, hired a maintainer, or forked the project. It’s easier to blame the person who gave the code away for nothing.

None of that is sustainable. The industry keeps assuming otherwise because, so far, it has mostly gotten away with it.

The XZ Utils backdoor should have forced a rethink, but the industry drew the wrong lesson from it. Coverage focused on the social engineering of a lone, burned-out maintainer, rather than asking why critical infrastructure worldwide depended on the unpaid labor of one person who had already said, on the record, that he was struggling. The backdoor didn’t succeed because the maintainer was careless. It succeeded because the entire supply chain had quietly outsourced its security diligence to a volunteer nobody had ever resourced to provide it.

Older than the industry that exploits it#

People firing off angry tickets at maintainers tend to talk as if open source were some 2010s invention, a GitHub-era novelty that showed up alongside CI pipelines and free tiers. It isn’t. Sharing source code predates the commercial software industry by decades.

In 1955, users of IBM’s early mainframes around Los Angeles formed SHARE, a volunteer-run user group. IBM shipped its operating systems in source form, so systems programmers modified them locally and traded the results by mail: printouts, punched card decks, magnetic tape. Those exchanges became the SHARE library, one of the direct ancestors of open source as we know it today.¹ Notice what the arrangement was for. Engineers pooled their effort so no institution had to rewrite the same file-handling routine from scratch. Reciprocity was the whole point. Everyone contributed, and everyone benefited.

That reciprocity broke down long before the licenses did. Software got unbundled, then licensed, then locked away. Stallman’s GNU project in 1983, and the GPL that came with it, were a deliberate attempt to legally restore a norm the industry had already abandoned. Linux followed in 1991. Then, in February 1998, at a strategy meeting in Palo Alto prompted by Netscape’s decision to open its Navigator source, Christine Peterson proposed the term “open source” specifically because “free software” sounded too political for businesses to feel comfortable adopting it. The Open Source Initiative was founded days later, built explicitly to make the model palatable to industry.²

Read that history honestly and the modern complaint about maintainers flips around. Open source was rebranded for the convenience of commerce. The whole point of the naming exercise was to make corporate adoption easy. It worked far beyond what anyone expected. Open source components now sit inside 96% of commercial codebases, and the industry took the adoption half of the deal while skipping the contribution half.

Seventy years on, the commons is still doing the work it did in 1955. The difference is that in 1955 the people on both sides of the exchange were peers. Today one side is a company with a trillion-dollar market cap, and the other is one person with a laptop and a day job.

What the numbers say#

Researchers at Harvard Business School and the University of Toronto tried to put a price on open source software. They estimated it would cost about $4.15 billion to build, once, the open source code that’s in widest use today. Then they asked what it would cost every firm on earth to rebuild that code internally if it vanished tomorrow: $8.8 trillion. Their conclusion was that companies would need to spend roughly three and a half times more on software than they currently do if open source didn’t exist. Ninety-six percent of that value comes from about five percent of contributors.³

Now hold that next to a different number. In Tidelift’s 2024 survey of more than 400 maintainers, 60% still described themselves as unpaid hobbyists, the same figure as the year before. Forty-eight percent felt underappreciated. Sixty percent had quit maintenance work at some point, or seriously considered it.⁴ Socket’s read of the same landscape found that unpaid maintainers are also the most likely to be working entirely alone: 61% maintain their projects solo.⁵

Trillions of dollars in enterprise value rest on a workforce that is mostly unpaid, mostly solitary, and, by its own account, mostly thinking about quitting. Calling that a community is generous. It runs more like an extraction economy that happens to have good branding.

The reputation trap#

There’s a particularly unfair bind at the center of this. An open source author can’t win.

Stay active on the project, and you become an unpaid employee of dozens of companies at once. Feature requests pile up. Security expectations keep rising. The list of platforms and versions you’re expected to support grows until maintaining the project turns into a second job with no salary and no equity attached.

Step back, even briefly, and you become a “bad maintainer.” Automated scanners flag the project as unmaintained. Security vendors add it to their abandoned-dependency dashboards. Recruiters quietly mark down your GitHub profile. Conference organizers stop reaching out. The reputation you built by being generous becomes a liability the moment you stop being generous on someone else’s schedule.

The author never asked for a weekend project to become infrastructure. They never sold it to your enterprise. They never signed anything with your procurement team. They wrote some code, put it out there, and got on with their life, which is exactly what the license allows them to do.

Your company’s decision to build a commercial product on top of that code was your risk calculation. Not theirs.

Four maintainers, four warnings#

1. core-js. Denis Pushkarev’s library sits behind an enormous share of the modern web, used by a majority of the top thousand sites and downloaded billions of times. His first attempt at asking for money, a note in the README, brought in about $57 a month. When he added a funding notice to the installation output, the response was hundreds of hostile messages, posts, and comments a day. His income from a library the web genuinely cannot function without fell from roughly $2,500 a month to around $400.⁶ The reaction to a maintainer asking for money was to punish him for asking.

2. XZ Utils. The industry filed this one under “sophisticated nation-state tradecraft,” which is true, and also a convenient way to skip the uncomfortable part. The attackers didn’t break any cryptography. They wore down a tired man. Lasse Collin maintained a compression library shipped in nearly every Linux distribution, mostly alone, and had said openly that long-term mental health struggles were slowing him down. Sock-puppet accounts spent months pressuring him on the mailing list about the project’s pace and the patches piling up in the queue, pushing him to hand off maintenance to a new co-maintainer. That co-maintainer was the attacker.⁷ The attack vector, in the end, was the industry’s own behavior, aimed with intent. Entitled, impatient nagging at an unpaid maintainer is common enough, ordinary enough, that a state-level adversary could use it as cover and nobody noticed for two years. Every team that has ever let someone post “any update on this?” for the third time on a volunteer’s issue tracker helped build the conditions that made that operation work.

3. curl. Daniel Stenberg has maintained curl since 1998. It runs inside your car, your phone, and your build pipeline. In 2025, his security team got buried under AI-generated vulnerability reports: confident sounding, well formatted, and mostly empty. He described it as being effectively DDoSed. The confirmed-vulnerability rate, historically above 15%, dropped below 5%. Roughly one in five submissions that year was pure noise, and one week alone brought eight times the usual volume. On January 31, 2026, curl shut down the bug bounty it had run since 2019, after paying out more than $100,000 across 87 confirmed vulnerabilities.⁸ It reopened a few weeks later. Then the models got better, which made things worse. The reports became technically accurate and stayed enormous in volume, with duplicates piling up because different people prompt the same model and land on the same finding. Machines now generate findings at industrial scale. Humans, unpaid ones, still have to judge each one, assign severity, and write the patch.⁹

4. FFmpeg. In late 2025, Google’s Big Sleep agent reported a memory bug in FFmpeg’s decoder for a LucasArts codec used in a 1995 video game, under a Project Zero policy that publishes the report and starts a disclosure clock before a fix exists. FFmpeg, which powers video playback in Chrome, YouTube, Firefox, and most of the internet’s media stack, patched it and then pushed back publicly: security matters, but the fixes are written by volunteers, and maybe trillion-dollar companies shouldn’t run AI to find bugs in volunteer code without also shipping the patches. The maintainers called the whole pattern “CVE slop.”¹⁰

That’s the modern arrangement, in one incident. A company with effectively unlimited engineering capacity uses that capacity to generate work for people it doesn’t pay, on a public clock, and collects the credit for taking security seriously.

Why this is a security problem, not an ethics problem#

If the moral argument doesn’t move your board, the threat model should.

Attackers already understand that the maintainer, not the code, is the softest part of the supply chain. The Shai-Hulud campaign proved it at scale. It started in September 2025 with phishing aimed at npm maintainer accounts, then used stolen publish tokens to self-propagate: infect a package, harvest the maintainer’s credentials, publish trojanized versions of every other package that maintainer owns, repeat. CISA issued an alert, and hundreds of packages were hit.¹¹ A second wave in November 2025 moved execution earlier in the install process, added a destructive fallback if credential theft failed, used GitHub Actions self-hosted runners for persistence, and exposed tens of thousands of repositories.¹² By May 2026, Microsoft was tracking a resurgence spanning npm and PyPI at once, with more than 170 packages and 400 malicious versions.¹³

Every one of those campaigns runs on the same premise: an individual maintainer’s account is a high-value credential guarding a low-resourced perimeter. Collectively, the industry created millions of single points of failure and then declined to fund any of them.

Meanwhile the regulatory floor is rising, and not under the maintainers’ feet. The EU Cyber Resilience Act entered into force in December 2024. Starting September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents on a 24-hour, 72-hour, and 14-day cascade, with full application landing December 11, 2027.¹⁴ The legislators were more careful here than the industry has been: an individual volunteer developer can’t be classed as an “open source steward” at all, and stewards face lighter duties, no CE marking, and no fines. The obligations land on the commercial entity that places the product on the market.¹⁵

For a CISO, the translation is simple. The law has already assigned this to you. When a component in your product gets exploited, the regulator isn’t writing to a volunteer in Helsinki. It’s writing to you, on a 24-hour clock, and “upstream hadn’t patched it yet” isn’t a filing.

Public funders have started doing what the private beneficiaries wouldn’t. Germany’s Sovereign Tech Agency has put over €23 million into roughly 60 projects in its first two years, and there’s now a serious proposal for an EU-level fund with a €350 million floor.¹⁶ Taxpayers are subsidizing the maintenance of infrastructure that generates private commercial margin. That’s a real transfer of money, and it exists only because the companies benefiting from it wouldn’t pay voluntarily.

What security and engineering leaders should do about it#

From a security standpoint, this matters because a supply chain is only as strong as its weakest assumption, and right now the weakest assumption most companies make is that someone else, unpaid, is doing the security work so they don’t have to. Calling that efficiency is generous. It’s an unpriced risk sitting on your balance sheet.

If your organization runs an open source component in a system that touches customer data, revenue, or anything critical, the security of that component is your responsibility, not the original author’s and not the community’s. A few concrete controls cover most of it.

1. Know your top twenty. Not an SBOM you generate once and never open again, but a ranked list of the components whose compromise would hurt the most, noting how many people maintain each one and whether any of them are paid. If the honest answer is “one person, unpaid,” that belongs on a risk register with an owner and a date, not as a fun fact in a slide deck.
2. Fork it and read/audit it. If a project is critical to your business, fork it, actually read the code, and maintain your own branch. The license permits this explicitly. It’s what taking ownership looks like when you can’t wait on upstream.
3. Fund the people who wrote it. If forking isn’t realistic, pay the maintainers. Not a one-off sponsorship that covers a coffee, but sustained funding that buys their time for security reviews, disclosure response, and the kind of upkeep you’d expect from any vendor you pay six figures a year. Fund in proportion to how much you depend on something, and do it as a contract. A sponsorship button is charity theater. A support contract, a retainer, or a funded maintainer seat is procurement, and procurement is something your finance team already knows how to run. If a project’s failure would cost you seven figures, a four-figure donation isn’t a control.
4. Check who’s actually behind it before you adopt it. Pulling a new dependency into your build pipeline should come with a quick look at who maintains it, how responsive they’ve been, and what you’d do if they stopped tomorrow. Skipping that step isn’t a shortcut, it’s a gap in your due diligence.
5. Pay for the work you create. If your team, your scanner, or your AI agent files a finding against someone else’s project, ship the patch along with it. A report with no fix attached is a bill you’ve handed to a volunteer.
6. Treat maintainer accounts like tier-zero identity. Phishing-resistant MFA, scoped and short-lived publish tokens, no install-time scripts running unreviewed in CI, pinned dependencies, and egress restrictions on build systems. Shai-Hulud’s entire propagation model falls apart without harvestable tokens.
7. Make sure insurance and legal have caught up. Your cyber insurance should cover supply chain compromises, and your legal team should understand that “it was an open source dependency” won’t hold up as a defense after a breach. A court, your customers, and your board will all want to know what you did to validate the code, not what the volunteer failed to do.
8. Have an actual answer to “what happens if they stop?” For every component on your top-twenty list. If you can’t name a plan, you don’t have one.

Who carries the cost#

Open source was never meant to subsidize commercial software margins. The original idea was collaboration and shared progress, not free labor extracted from people who never opted into anyone’s business model. The security of your stack is your problem. If your company chose to build on volunteer-maintained code because it was cheaper than licensing or building in-house, that was a business decision, and it came with consequences attached. Don’t make the maintainer pay for that cost optimization with their reputation, their time, or their burnout.

The people who built the software your revenue depends on did the industry a favor that started in 1955 and never really stopped. They were peers once. Then the industry industrialized the taking, renamed the movement to make adoption frictionless, hired lawyers to read the licenses and nobody to read the code, and, in the current moment, started pointing machines at volunteer codebases to generate work faster than any human maintainer can absorb.

There’s no version of this where volunteers hold the line forever. Sixty percent of them are unpaid, and sixty percent have thought about walking away. Attackers have already learned to target them specifically, and regulators have already decided the liability sits with you, not them.

The next CVE in a “neglected” open source project will be a story about a company that treated someone else’s passion project as enterprise infrastructure and was surprised to find the warranty was exactly what the license always said: none whatsoever.

Pay for the infrastructure you depend on, or own what happens when you don’t.