In January 2022, a developer named Marak Squibb corrupted two of his own npm packages, colors.js and faker.js, pushing broken updates that caused thousands of applications to print gibberish or crash on startup. Squibb had maintained both packages for years without pay. He was, by some measures, supporting tens of millions of weekly downloads. Before he sabotaged his own work, he posted a message to GitHub: ‘Take this as a warning. I am no longer going to support Fortune 500s and other large enterprises with my free work.’

The incident made headlines for a day or two, then the software world largely moved on. That is the problem.

The Setup

Open source software is not a charity project. It is the load-bearing infrastructure of the modern economy. The Apache web server, the Linux kernel, OpenSSL, curl, log4j, Node.js, Python’s packaging tools: these are not hobbyist experiments. They run inside the products of companies worth hundreds of billions of dollars. A 2015 study by the Linux Foundation estimated the total replacement cost of the open source software in a typical Linux distribution at over $5 billion. That figure is conservative and almost certainly dated. A later study commissioned by the European Union, published in 2021, estimated that the open source software used across the EU’s economy would cost roughly 65 billion euros to rebuild from scratch.

The people who build and maintain that software are, in the vast majority of cases, not compensated in proportion to the value they create. Many are not compensated at all.

What Happened

The Marak Squibb story is dramatic, but the more common story is quieter and ultimately more damaging. It is the story of a maintainer who simply stops.

Heartbleed, the OpenSSL vulnerability disclosed in 2014, is the canonical example. OpenSSL encrypted a substantial fraction of all internet traffic at the time. When the bug was found, the project’s entire full-time staff consisted of one part-time developer. The OpenSSL Software Foundation was operating on annual donations of less than $2,000. Companies whose products depended on OpenSSL, companies worth billions, had contributed essentially nothing to keep it running.

The vulnerability required an emergency patch and affected an estimated 17 percent of secure web servers. The eventual cleanup cost, across every organization that scrambled to update, ran into the hundreds of millions of dollars. The annual cost to prevent it would have been a rounding error on any major tech company’s IT budget.

More recently, the Log4Shell vulnerability discovered in late 2021 exposed a flaw in Log4j, a Java logging library used in an extraordinary range of enterprise software. The Apache Software Foundation, which maintains Log4j, is a volunteer-driven nonprofit. The developers who responded to Log4Shell worked through weekends and nights to patch the vulnerability and field questions from panicked companies they had never heard of and certainly never invoiced.

These are not fringe cases. They are the system working exactly as designed, which is the point worth dwelling on.

Small figure supporting an enormous architectural structure

Why It Matters

The economic structure of open source creates a classic free-rider problem, and the tech industry has never seriously grappled with it. The incentive for any individual company to fund open source maintenance is weak, because every company benefits whether or not it contributes. If your competitors are getting the same library for free, paying for it feels like a unilateral tax on yourself.

This logic, applied by thousands of companies simultaneously, produces an outcome nobody actually wants: critical infrastructure staffed by volunteers who burn out, drift away, or, occasionally, break things on purpose.

The burn-out rate among open source maintainers is not a soft, anecdotal concern. A survey conducted by Tidelift in 2021 found that 46 percent of maintainers had considered quitting their projects in the prior year, and the leading reasons were not technical. They were emotional exhaustion from managing user demands, lack of recognition, and the absence of any financial return. Many maintainers described fielding abusive messages from users who treated free software as a service they were owed.

The irony is that the companies most exposed to this risk are often the most profitable ones. A startup with three engineers probably cannot afford to fund an open source project. A company with $10 billion in annual revenue absolutely can, and often doesn’t.

What We Can Learn

The solutions that have emerged are partial and fragile. GitHub Sponsors, Open Collective, and Tidelift all attempt to create funding channels between companies and maintainers. The results have been mixed. GitHub Sponsors has distributed meaningful money to some high-profile projects, but the distribution is wildly uneven. Projects with celebrity maintainers or visible drama attract support. The unglamorous utilities that do essential work quietly attract almost none.

A few companies have taken the problem seriously on their own terms. Google, Microsoft, and others have employees whose explicit job is to contribute to open source projects their products depend on. This is better than nothing, but it is not the same as funding independent maintainers who are not employed by large companies and have no interest in being.

The most structurally interesting experiment is Tidelift’s subscription model, which attempts to aggregate funding from companies and route it to maintainers who agree to maintain their packages to certain standards. It is essentially insurance. Companies pay a subscription, and the maintainers of the packages they depend on get paid to keep the lights on. The model is not perfect, but it is the closest thing to a genuine economic solution that has appeared.

The lesson from Heartbleed, from Log4Shell, from Marak Squibb is not that open source is broken. Open source has produced extraordinary software precisely because it lowered the cost of collaboration and sharing. The lesson is that ‘free to use’ has never meant ‘free to maintain,’ and the industry has spent decades pretending otherwise.

At some point, the correct analogy is not charity. It is infrastructure. Municipalities pay to maintain roads not because road maintenance is profitable but because the absence of roads is expensive. The companies building products on top of open source have the same relationship to the maintainers keeping that software alive. The funding model just hasn’t caught up to that reality yet.

Marak Squibb’s packages were eventually forked by others, the damage repaired, the crisis absorbed. The next maintainer who burns out will probably just disappear. No one will notice until something breaks.