🎧 Prefer to listen? Audio version below — approximately 68 minutes.
Every year, companies download more than ten trillion open source code files (Sonatype, 2025). That is not a typo. Ten trillion — a number that dwarfs Google’s annual search queries by a factor of two. The software that runs your bank, your hospital, your government department, and your phone almost certainly arrived via a handful of websites you have never heard of and could not name.
Those websites are staffed by volunteers. They run on donations. Their infrastructure is subsidised by cloud providers who could withdraw that subsidy at any point. The people who maintain the code those websites distribute are, in many cases, unpaid. The ones who are paid are, in many cases, underpaid. Sixty percent of them report feeling burnt out. More than half have considered quitting in the last year.
Nobody planned this. Nobody is in charge of fixing it. And almost nobody in the organisations that depend on this infrastructure — the banks, the hospitals, the government departments — has any idea it exists.
This is the story of the infrastructure the internet forgot to fund. And of the people holding it together with goodwill and spare time, wondering how much longer they can keep going.
One day, one of them will close their laptop and not open it again.
Nobody will notice until something breaks.
On 14 February 2023, a software developer named Denis Pushkarev published a message on GitHub. It was not a release note or a bug fix. It was something closer to a distress signal.
Pushkarev maintains core-js — a foundational JavaScript library that provides the basic building blocks modern web applications depend on. At the time of writing, core-js had been downloaded more than nine billion times. It underpins a significant proportion of the commercial web. You have almost certainly used software that depends on it today without knowing it existed.
Pushkarev was broke. He had served time in a Russian prison. He was being harassed by users demanding fixes, features, and faster responses. He was receiving no meaningful financial support from the corporations whose products ran on his work. He named no names. He did not need to. The companies in question know who they are.
He kept maintaining it anyway.
That is not a happy ending. That is a warning.
Pushkarev is not alone. In November 2020, a developer named Marak Squires updated the README file of faker.js — a widely used library for generating fake test data — with a single line: “No more free work from Marak — Pay Me or Fork This.” He had spent years watching large technology companies extract value from his work without contributing a penny. He had done the mathematics. He did not like the answer.
When that ultimatum was ignored, he did something more dramatic. He corrupted his own library — deliberately introducing broken code into a release that was subsequently pulled into production environments around the world. GitHub banned him. npm removed the package. The community forked it and carried on without him.
Squires was characterised as a vandal. The companies whose pipelines he disrupted were characterised as victims. The question of why a developer who had given years of free labour to commercial enterprises might eventually lose patience received rather less attention.
Then there is the event-stream incident. In 2018, a developer named Dominic Tarr handed maintainership of his npm package to a stranger who had volunteered to help. Tarr had not used the module for years. Someone wanted to maintain it. He said yes.
The stranger injected a backdoor designed to steal bitcoin from specific targets.
When the backdoor was discovered, Tarr was asked why he had handed a widely depended-upon package to someone he did not know. His answer was, in its way, a more damning indictment of the ecosystem than the attack itself.
Pay the maintainers, he said. Only depend on modules you know are definitely maintained.
Nobody did. Nothing changed.
Three developers. Three different breaking points. One handed over the keys out of exhaustion. One burned the house down out of frustration. One is still inside, keeping the lights on, waiting for someone to notice.
The infrastructure did not fail in any of these cases — not catastrophically, not yet. But each incident was a signal. Each one was logged, discussed, and then quietly filed under lessons learned.
The lessons were not learned.
There is a particular kind of institutional memory that forms after a disaster. Inquiries are held. Reports are written. Recommendations are made. Budgets are allocated, at least initially. The community of people who work in the affected area spends several years citing the incident as a reason to take the underlying problem seriously.
And then, quietly, the memory fades. The budgets are redirected. The recommendations gather dust. The underlying problem remains. Until the next incident, when the cycle begins again.
The software supply chain has been running this cycle for years. The incidents are well documented. The lessons are well understood. The learning has not occurred.
In December 2020, security researchers discovered that SolarWinds — a company whose network monitoring software was used by thousands of organisations including multiple US federal agencies — had been compromised. Attackers had inserted malicious code into a software update that was then distributed to approximately 18,000 customers. The attack was attributed to a Russian intelligence operation. It had been running, undetected, for months.
The SolarWinds attack was not, at its core, a story about a single company’s security failures. It was a story about trust in software supply chains. The customers who downloaded the malicious update did so because they trusted SolarWinds. SolarWinds had been compromised because someone had found a way into their build pipeline — the automated system that takes source code and turns it into the software that customers download.
The response was significant. Executive Order 14028. SBOM mandates. CISA guidance. Congressional hearings. The language of software supply chain security entered the mainstream policy conversation for the first time.
Five years later, the SBOM mandate has been rescinded. CISA is being defunded. The policy response to SolarWinds has been systematically dismantled.
In December 2021, a vulnerability was discovered in Log4j — a Java logging library maintained by the Apache Software Foundation. The vulnerability, designated CVE-2021-44228 and quickly named Log4Shell, was catastrophic. Log4j was embedded in an extraordinary range of software products, many of whose developers and operators had no idea it was there. The vulnerability allowed remote code execution — an attacker could, in many cases, take complete control of an affected system simply by sending a specially crafted string of text.
The response to Log4Shell introduced millions of people in technology, security, and management to a concept they had not previously considered: the dependency chain. The software running your systems does not exist in isolation. It depends on other software, which depends on other software, which depends on libraries maintained by volunteers in their spare time. Log4j was maintained by a small team at the Apache Software Foundation. It was embedded in products used by banks, hospitals, governments, and technology companies around the world. Most of those organisations had never heard of it.
The Apache Software Foundation received a significant increase in donations following Log4Shell. CISA published guidance. The industry had a conversation about dependency management that it should have had years earlier.
The conversation faded. The donations tapered off. The dependency chains remain largely unaudited.
In March 2024, a Microsoft engineer named Andres Freund was investigating an unusual performance issue on a Linux system. The SSH daemon — the software that handles remote login — was consuming slightly more CPU than expected. Most engineers would have noted the anomaly and moved on. Freund did not.
What he found, and disclosed to the Openwall oss-security mailing list on 29 March 2024, was a backdoor in liblzma — a compression library that is a dependency of OpenSSH on many Linux distributions. The backdoor had been introduced by a contributor using the handle Jia Tan, who had spent approximately two years cultivating trust within the XZ Utils project before being granted commit access.
The technical sophistication of the attack was significant. But the human element was more significant still. Jia Tan — almost certainly a state-sponsored actor or team operating under that identity — had identified a project with a single, overworked, underfunded maintainer. They had offered help. They had been patient. They had built trust over months and years. And then, when the moment came, they had used that trust to introduce a backdoor that would have affected a significant proportion of the world’s Linux infrastructure.
The maintainer they targeted was Lasse Collin. He had been maintaining XZ Utils alone. He had, by his own account, been struggling. The social engineering worked not despite the open source community’s values — its culture of welcoming contributors, its reliance on volunteer labour, its assumption of good faith — but because of them.
The XZ Utils backdoor was caught because one engineer noticed a performance anomaly. It was close. Uncomfortably close.
Three incidents. Three different failure modes. One pattern.
In each case, the vulnerability was not primarily technical. It was structural. The software supply chain is built on a foundation of trust — trust in the integrity of build pipelines, trust in the provenance of dependencies, trust in the good faith of contributors. That trust is reasonable. It has, for the most part, been warranted. The open source community is overwhelmingly populated by people acting in good faith.
But trust without verification is a vulnerability. And the structural conditions that make verification difficult — underfunded maintainers, unaudited dependency chains, volunteer labour stretched beyond its limits — are precisely the conditions that sophisticated actors, whether commercial free riders or state-sponsored threat actors, are best positioned to exploit.
In each case, the response followed the same arc. Alarm. Inquiry. Recommendations. Initial action. Gradual forgetting. The underlying structural conditions that produced the vulnerability were acknowledged, discussed, and then left substantially unchanged.
The XZ Utils incident produced post-mortems from OpenSSF, CISA, and multiple security research organisations. All of them identified maintainer burnout and underfunding as contributing factors. None of them resulted in a sustained, structural change to how the open source ecosystem funds its maintainers.
There is a reason this pattern persists. The structural changes required to address it are expensive, politically difficult, and do not produce visible results until something fails. The organisations that would bear the cost of change — the large technology companies whose pipelines extract the most value from the ecosystem — have no immediate commercial incentive to incur that cost. The organisations that would benefit most from the change — the maintainers and the foundations — have no leverage to compel it.
The incidents produce enough alarm to generate activity. They do not produce enough sustained pressure to generate structural change. The alarm fades before the change arrives. The cycle resets.
The next incident is not a question of if. It is a question of when, and how bad, and whether this time the memory will last long enough to matter.
On current evidence, there is little reason for optimism.
To understand why package registries are in crisis, you need to understand what they were built to be — and what they were never meant to become.
In the beginning, they were simple. PyPI — the Python Package Index — launched in 2003. npm followed in 2010. Maven Central had been serving Java developers since 2002. These were not commercial ventures. They were not products. They were infrastructure built by communities for communities, in the same spirit as the early web itself — the idea that knowledge, code, and tools should be freely available to anyone who needed them.
Nobody sat down and wrote a business plan. Nobody modelled the revenue. Nobody asked what happens when the thing you built for a few thousand developers starts serving a few hundred million automated requests per day. The answer to “how do we fund this?” was, broadly, goodwill — donations, volunteer labour, and the occasional infrastructure credit from a cloud provider who wanted to be seen as a good citizen of the open source ecosystem.
It worked. For a while.
To understand the philosophy, you need to remember what the technology landscape looked like in the late 1990s and early 2000s. Microsoft owned the desktop. Apple owned the premium end. Proprietary software was the default assumption — you paid for a licence, you got a binary, you did not see the code and you did not modify it. The source was the product, and the product was locked.
Open source was, in this context, explicitly political. It was a movement as much as a methodology. The GNU Project, Linux, Apache — these were not just technically superior alternatives in many cases, they were acts of defiance. The argument was simple and powerful: software that everyone could read, modify, and distribute was inherently more trustworthy, more resilient, and more democratic than software controlled by a corporation whose interests might not align with its users.
Richard Stallman had been making this argument since the 1980s. Linus Torvalds had demonstrated it at scale with Linux. By the time PyPI and npm were being built, open source had won enough battles that its philosophy felt not just defensible but obviously correct. Of course infrastructure should be open. Of course code should be free. The alternative was handing Microsoft or Apple — or whoever came next — the keys to the foundations of the internet.
This was not naive. It was battle-tested. And it worked.
The problem is that the enemy changed.
Microsoft and Apple did not win. But the companies that emerged to replace them — Google, Amazon, Meta, the hyperscalers — were not the proprietary software vendors of the 1990s. They did not sell you software you could not read. They gave you software for free and made their money from your data, your attention, and increasingly, the infrastructure they built on top of the open source foundations the community had spent decades constructing.
The open source movement had been built to fight a particular kind of proprietary lock-in. It was not built to fight a world in which the most powerful technology companies on earth enthusiastically embraced open source — contributed to it, funded it selectively, built their empires on top of it — while systematically externalising the cost of maintaining the foundations onto the volunteers who had built them.
The philosophy survived. The threat model did not.
“Open by default” had been a weapon against Microsoft. Against the hyperscalers it became a gift.
Nobody sat down and made this calculation deliberately. The shift was gradual, structural, and by the time it was visible it was already entrenched. The registries that had been built as acts of liberation became, quietly and without anyone quite deciding this should happen, the unpaid infrastructure department of the global technology industry.
Compare this to how a competent operator would approach the same problem today. You build something valuable. You make it accessible. You identify the point at which commercial consumers are extracting disproportionate value and you introduce a pricing model that reflects that. Free for individuals and small teams. Paid for high-volume automated consumers. Enterprise contracts for the organisations whose entire production stack depends on your infrastructure.
This is not a revolutionary idea. It is standard product thinking. It is, broadly, how sustainable software gets built.
The registries never did it. Not because the model was unavailable to them — it was available, it was obvious, and several people suggested it over the years. They did not do it because doing it felt like a betrayal of the founding philosophy. Because the loudest voices in the community consistently framed monetisation as ideological surrender. Because by the time the scale made the conversation unavoidable, the ecosystem had built so many workflows around the assumption of free access that changing the model meant breaking things.
And because, as we will come to, some of the loudest voices against monetisation were employed by the companies that benefited most from free access.
What these registries became — what they are today — is something their founders never designed for and could not have anticipated.
They are not download mirrors. They are not file servers. They are security-critical infrastructure sitting in the path of almost every modern software build on the planet. When a developer at a bank writes code, their build pipeline pulls dependencies from npm or PyPI or Maven Central. When a hospital’s patient management system is updated, it pulls from the same places. When a government department deploys new software, the same registries are involved. When an AI company trains a model on code, it consumes registry infrastructure at a scale that would have seemed science fiction to the people who built these systems.
The registries are, in any meaningful sense, critical national infrastructure for every nation that runs software. Which is every nation.
They just were not built that way. They were built as village wells — open, communal, maintained by whoever showed up to dig. The village has since become a city of several billion people, all drawing from the same well, most of whom have never met the people doing the digging.
The enemy the well was built to fight has long since moved on.
Nobody told the diggers.
In the early days of package registries, the typical user was a developer. A human being, sitting at a keyboard, typing a command. pip install requests. npm install express. One person. One package. One download. The registries were designed around this assumption — that the entity on the other end of the request was a person who needed something and was fetching it.
That assumption has not been true for years.
Today, the majority of traffic hitting package registries does not come from humans. It comes from machines. Continuous integration pipelines that rebuild software automatically every time a developer commits a change. Deployment systems that pull fresh dependencies every time code goes to production. Security scanners that systematically download packages to check them for vulnerabilities. And increasingly, AI systems — training pipelines, code generation tools, automated analysis frameworks — that consume registry infrastructure at a scale and speed that no human developer could approach.
Sonatype, which operates Maven Central and tracks consumption patterns across the ecosystem, has found that 82 percent of all open source component demand is concentrated in just one percent of projects by popularity. Read that again. Eighty-two percent of the load on these systems comes from a tiny fraction of packages being pulled, repeatedly, automatically, at machine speed, by pipelines that never sleep and never stop.
This is not developers fetching libraries. This is industrial machinery treating public infrastructure as a private CDN.
The companies doing this did not ask permission. There was no negotiation, no agreement, no moment at which someone at a large technology company called the Python Software Foundation and said “we are about to route fifty thousand automated build requests a day through your infrastructure — is that acceptable?” They pointed their pipelines at a public endpoint and pulled. The registries had no authentication requirements worth the name. No rate limiting that could withstand serious automated traffic. No mechanism to distinguish a developer fetching a library from a Fortune 500 company’s CI system hammering the same endpoint ten thousand times a day.
The door was not just unlocked. There was no door.
This was not an oversight exactly. It was a consequence of the philosophy described in the previous section. Locking the door — introducing authentication, rate limiting, metered access — felt antithetical to the open source ethos. Every time someone suggested it, the community pushed back. The registries were for everyone. Friction was the enemy. Open access was the point.
What nobody modelled was the arrival of a class of consumer for whom open access was not a philosophical commitment but a financial opportunity. The hyperscalers and their pipelines were not part of the open source community in any meaningful sense. They were not contributors. They were not maintainers. They were consumers — extraordinarily large, extraordinarily demanding consumers who had discovered that someone else was paying for infrastructure they could use for free.
By the time the scale of automated consumption became undeniable, the ecosystem had built so many workflows around the assumption of free, frictionless access that introducing controls would have broken things. Real things. Production pipelines. Build systems. The daily operations of thousands of companies. The registries were trapped — unable to charge for access they had always provided for free, unable to refuse service to consumers who had built critical dependencies on their infrastructure, unable to fund themselves adequately from the donations of a community that represented a fraction of their actual user base.
Then came the AI wave.
If CI/CD pipelines were the first industrial-scale consumer the registries never planned for, AI training systems are the second — and they make the pipelines look modest. Large language models trained on code consume package registries not to fetch libraries but to harvest data. Every package, every version, every commit history is potential training material. The consumption is not incidental. It is systematic. It is the entire point.
The registries have no way to charge for this. They have no way to refuse it. They have no way to even measure it accurately, because the traffic looks, from the outside, like any other automated download request.
This is the sustainability gap the industry is finally, belatedly, beginning to acknowledge. It is not a hosting bill. It is a structural extraction problem — a class of consumers taking significant value from infrastructure they do not fund, at a scale the infrastructure was never designed to support, with no legal or commercial obligation to contribute anything in return.
The door was never locked.
They walked straight in.
And they are still there.
There is a term in economics for what is happening to open source package registries. A free rider is someone who consumes a shared resource without contributing to its maintenance — benefiting from the commons while externalising the cost onto those who do pay. The term is usually applied to public goods: clean air, national defence, public broadcasting. It was not coined with software infrastructure in mind.
It fits perfectly.
The scale of corporate extraction from open source registries is not a secret. It is not even particularly controversial. The companies doing it know they are doing it. The maintainers know it is happening. The foundations know it. Everyone in the ecosystem knows it. What makes the situation remarkable is not the extraction itself but the near-total absence of shame attached to it.
Consider the numbers. Core-js — the library Denis Pushkarev has been maintaining alone, for free, through financial hardship and personal crisis — has been downloaded more than nine billion times. The companies whose products depend on it include some of the largest and most profitable technology corporations on earth. As of May 2026, not one of them has made a formal public commitment to fund its continued maintenance.
Nine billion downloads. Zero corporate response.
Core-js is not an anomaly. In 2021, the maintainers of Babel — a JavaScript compiler used by millions of developers and depended upon by companies including Facebook, Netflix, and Airbnb — published a public statement asking a simple question. Babel is used by millions, they said. Why are we running out of money?
The question was not rhetorical. The Babel team were genuinely struggling to fund basic operations while their tool was embedded in the production infrastructure of companies generating billions in annual revenue. The statement landed with a thud in the developer community. It generated discussion, sympathy, and a modest uptick in donations.
Facebook, Netflix, and Airbnb did not materially change their behaviour.
Then there is Maven Central. The Java package registry serves hundreds of billions of downloads annually. It is, by any reasonable measure, critical infrastructure for enterprise software development globally. Banks, insurers, and government systems around the world depend on it.
Maven Central is operated by Sonatype. Sonatype is owned by Vista Equity Partners — a private equity firm. Internal sentiment within Sonatype, confirmed by public reporting, is that Maven Central is maintained as a marketing expense. Not a public good. Not a foundation-supported commons. A line item on a PE-owned company’s budget that exists because it generates goodwill and brand recognition for Sonatype’s commercial products.
There is no charitable endowment protecting Maven Central. There is no international legal framework guaranteeing its availability. There is no regulatory designation requiring its continuity. If Vista Equity Partners decided tomorrow that the marketing return on investment was insufficient, there is nothing — legally, structurally, or financially — to stop them from changing the arrangement.
This is critical global infrastructure held at the pleasure of a private equity spreadsheet.
The free rider problem has a particular irony in the open source context. The loudest voices against monetising registry access — against introducing authentication, rate limiting, or tiered pricing for high-volume consumers — have often been engineers employed by the companies that would pay the most under any such model. The philosophical commitment to open access, genuinely held by the developer community, has been systematically amplified by people whose employers had a direct financial interest in that philosophy prevailing.
This is not a conspiracy. It does not need to be. It is simply what happens when commercial interests and community values align conveniently — the commercial interests get amplified, the community values get weaponised, and the people actually paying the price are the maintainers who never had a seat at the table where these arguments were made.
The open source community was built on the principle that code should be free. The hyperscalers took that principle and ran a global logistics operation on top of it, at someone else’s expense, while their employees argued passionately in community forums that introducing any friction would betray the founding vision.
The founding vision did not include them. They moved in anyway.
PyPI presents a different but equally precarious version of the same problem. The Python Software Foundation’s annual cash revenue is approximately five million dollars — a figure that sounds reasonable until you understand that PyPI’s infrastructure costs are largely covered not by that cash but by in-kind donations from Amazon Web Services and Fastly. AWS provides storage. Fastly provides the content delivery network that serves more than a billion package downloads every day.
If either company decided to end those arrangements — for any reason, commercial, political, or otherwise — the PSF could not cover the resulting costs from its cash reserves. PyPI would face an immediate, existential funding crisis with no fallback position.
The most widely used Python package repository in the world is one corporate decision away from a crisis its stewards could not resolve without either shutting down or introducing paid access overnight.
This is not a funding gap. It is a single point of failure dressed up as a sustainability model.
The free rider problem has no elegant solution. You cannot simply invoice the companies that have been consuming your infrastructure for free — there is no contract, no agreement, no basis for retrospective billing. You cannot block them without breaking the ecosystem that depends on the access you have always provided. You cannot shame them publicly without risking the goodwill that produces the modest donations you do receive.
What you can do is what the Sustaining Package Registries Working Group — launched by Sonatype and the Linux Foundation on 6 May 2026 — is attempting to do. You get the registries in a room. You agree on a collective position. You present that position to the industry. You make the argument, as a unified front rather than a series of individual hat-in-hand appeals, that the current arrangement is unsustainable and that something has to change.
It is the right instinct. Whether it is sufficient is another question entirely. And that question leads directly to the governance vacuum at the heart of this crisis.
In 2003, when PyPI was being built, nobody appointed a board of directors. Nobody wrote a five-year plan. Nobody hired a product manager. A developer named Richard Jones built a simple index for Python packages because the community needed one, and the community used it because it was there and it worked.
This is how most of the critical infrastructure of the open source ecosystem came to exist. Not through planning. Not through governance. Through necessity, goodwill, and the compounding effect of thousands of individual decisions to use a thing that someone had built for free.
The governance came later, if it came at all. And when it came, it came in the form best suited to a volunteer community rather than critical infrastructure — foundations, boards, working groups, consensus processes. Structures designed to be inclusive and democratic. Structures that are, by design, slow.
A foundation is not a company. It cannot move like one. It has no founder who can make a call at 11pm on a Tuesday and have it implemented by Wednesday morning. It has a board that meets quarterly. It has a community that expects to be consulted. It has a mission statement that was written for a different era and a governance structure that treats any significant change as a potential betrayal of the founding principles.
This is not a criticism of the people running these foundations. Many of them are exceptional. They are doing difficult work under impossible constraints with inadequate resources. The problem is structural — the governance model that serves a volunteer community well is precisely the wrong model for operating critical infrastructure at industrial scale.
Consider what competent product management would have looked like applied to these registries over the past decade. You track your consumption metrics. You notice that automated traffic is growing faster than human traffic. You model the cost trajectory. You identify the point at which your current funding model cannot keep pace. You design a tiered access model — free for humans and small teams, metered for high-volume automated consumers, enterprise contracts for the organisations whose production systems depend on your infrastructure. You implement it gradually, with transition periods and clear communication, before the crisis arrives rather than after.
None of this is complicated. None of it requires technical innovation. It requires someone with the authority to make decisions, the mandate to implement them, and the commercial instinct to recognise that “free for everyone forever” is not a business model.
The foundations had none of these things. Not because the people involved were incapable — they were not — but because the governance structure they operated within made commercial thinking feel like a category error. You do not hire a product manager for a public good. You do not model revenue for a commons. The vocabulary of sustainable business was, in the open source foundation context, the vocabulary of the enemy.
The foundations had another problem. Their boards were increasingly populated by engineers employed by the companies that benefited most from free access. The governance was not just slow. In some cases, it was compromised. Not through malice — but through the entirely predictable result of allowing the largest consumers of a resource to occupy the governance structures of the organisations managing it.
The irony is that the model existed. It had been proven. The open source world had already produced examples of projects that managed the transition from community infrastructure to sustainable operation without betraying their founding principles.
Red Hat built a billion-dollar business on Linux without owning Linux. Canonical did the same. The Apache Software Foundation developed a governance model that has sustained dozens of critical projects for decades. These were not perfect solutions but they demonstrated that the binary choice between “free forever” and “sold to the highest bidder” was false.
The registries did not follow these examples. Partly because their governance structures made change difficult. Partly because the moment for change — the moment when the revenue model could have been adjusted without breaking the ecosystem — passed while the community was still debating whether it was appropriate to have the conversation.
By the time the debate was settled, the ecosystem had grown too dependent on free access to tolerate a sudden change. The window had closed.
There is a particular governance failure worth naming directly. Several of the registries have, over the years, received significant funding from the very companies that benefit most from their free operation. Google, Microsoft, Amazon, and Meta have all made donations to open source foundations at various points. These donations are real. They are not nothing.
They are also, in every case, a fraction of the value those companies extract from the infrastructure they are funding. A hundred thousand dollar donation to the Python Software Foundation from a company whose products depend on PyPI for billions of downloads is not generosity. It is the cheapest possible form of reputational insurance — enough to be cited as evidence of good corporate citizenship, not enough to materially change the sustainability picture.
The foundations accepted these donations because they needed the money. The companies made them because they were cheaper than actually paying for the infrastructure. Both parties understood the arrangement. Neither party said so publicly.
This is the governance vacuum in miniature. Not a conspiracy. Not even bad faith necessarily. Just a system in which the incentives aligned perfectly to produce an outcome that was good for the large companies, tolerable for the foundations in the short term, and structurally disastrous in the long term.
The Sustaining Package Registries Working Group is, in one sense, an admission that the governance model has failed. The registries should not need a working group to have a conversation about sustainability. They should have had product managers, revenue models, and commercial strategies years ago. The fact that they are only now — in 2026, when the crisis is acute and visible — forming a collective body to address it is not a sign of progress. It is a measure of how long the problem was deferred.
The working group may yet produce something useful. A unified industry position on sustainable funding. A framework for metered access that the community can accept. A collective approach to the large corporate consumers that individual registries cannot confront alone.
But a working group is not governance. It is a conversation. And the history of this particular conversation suggests that the distance between a working group recommendation and actual implementation is measured not in months but in years — if it is ever closed at all.
The governance vacuum did not appear overnight. It will not be filled overnight either.
If the governance vacuum is the story of what the open source community failed to build, the regulatory blindspot is the story of what governments failed to notice. Or noticed, and chose not to act on. The distinction matters less than the outcome — which is that the infrastructure underpinning global software supply chains has no regulatory designation, no resilience mandate, no oversight framework, and no government anywhere that has formally accepted responsibility for its continuity.
This is not an accident. It is a choice. And in at least one jurisdiction, it appears to have been a deliberate one.
Start with what critical infrastructure designation actually means. In most jurisdictions, infrastructure deemed critical — power grids, water systems, telecommunications networks, financial systems — attracts a specific set of obligations. Operators must meet minimum security standards. They must report incidents. They must maintain resilience plans. Regulators have powers to intervene if standards are not met. Governments have, implicitly or explicitly, accepted that the continuity of this infrastructure is a matter of public interest that cannot be left entirely to market forces.
None of this applies to package registries.
PyPI, npm, Maven Central, RubyGems, Crates — none of them are designated critical infrastructure in any G7 jurisdiction. They are, in regulatory terms, roughly equivalent to a moderately popular website. The organisations that depend on them — banks, hospitals, government departments — have no legal obligation to audit their dependency on this infrastructure. The registries themselves have no legal obligation to maintain minimum service levels, report security incidents to regulators, or demonstrate financial resilience.
The blast radius of a major registry failure would extend, without exaggeration, across the global economy. The regulatory framework treating that possibility as a concern worth managing does not exist.
This is not for want of relevant legislation. The European Union’s Network and Information Security Directive — NIS2 — came into force in 2023 and covers a broad range of digital infrastructure. It was supposed to bring software supply chain security within its scope. In practice, NIS2 focuses on “essential entities” — operators of infrastructure already designated as critical. It covers ICT managed service providers and digital infrastructure operators in general terms.
It does not explicitly cover open source package registries. The question of whether PyPI or npm falls within NIS2’s scope is, as of May 2026, unresolved. It sits in a grey area that regulators have not rushed to clarify, partly because clarifying it would create obligations that nobody has volunteered to fund.
The EU’s Cyber Resilience Act — Regulation 2024/2847, which begins full application in December 2027 — goes further. It introduces the concept of Open Source Software Stewards — foundations and similar entities that manage open source development — and places compliance obligations on them. Security policies. Vulnerability handling. Cooperation with market surveillance authorities.
The penalties for non-compliance are significant. Up to fifteen million euros or 2.5 percent of global turnover.
The funding to meet those obligations? Not provided.
The EU has, in other words, created a liability framework for open source stewards without creating a funding mechanism to support the infrastructure those stewards maintain. It has handed the Python Software Foundation a compliance burden without handing it a budget. It has legislated the problem without solving it — and in doing so may have made the burnout crisis worse before it makes it better.
Across the Atlantic, the picture is different but no more encouraging. For a brief period, it looked as though the United States might take software supply chain security seriously as a matter of federal policy.
In May 2021, following the SolarWinds attack, the Biden administration issued Executive Order 14028 — Improving the Nation’s Cybersecurity. Section 4 of that order mandated Software Bills of Materials for software sold to the US federal government. An SBOM is a formal inventory of a software product’s components — including its open source dependencies. The logic was straightforward: you cannot secure what you cannot see, and most large organisations had no idea what open source packages their software depended on.
It was, in principle, the kind of mandate that could have forced the conversation about registry sustainability into boardrooms that had never considered it. If you have to disclose your dependencies, you start to notice where they come from. If you notice where they come from, you start to think about whether those sources are sustainable.
On 23 January 2026, the Office of Management and Budget issued Memorandum M-26-05. It rescinded the mandate. The secure software development requirements introduced by the Biden administration were swept away. Responsibility for software supply chain security was devolved to individual agencies under a loosely defined “risk-based approach.”
The federal mandate for software supply chain transparency was gone.
This did not happen in isolation.
The Department of Government Efficiency — established by executive order on 20 January 2025 and scheduled to expire, with a certain poetic appropriateness, on 4 July 2026 — has spent its brief existence cutting federal capacity with broad strokes and limited discrimination. CISA, the Cybersecurity and Infrastructure Security Agency, faces a proposed budget reduction of $707 million for FY2027. Approximately 1,300 positions are being eliminated. A 40 percent workforce reduction. Programmes focused on software supply chain security have been among those cut.
The agency that was supposed to be the federal government’s primary instrument for addressing software supply chain risk is being systematically defunded at the same moment the supply chain mandate it was supposed to enforce has been rescinded.
DOGE’s operational methods have attracted judicial scrutiny that goes beyond the budget cuts themselves. On 7 May 2026, US District Judge Colleen McMahon ruled in The Authors Guild et al. v. Department of Government Efficiency et al. (1:25-cv-03823, S.D.N.Y.) that DOGE had exceeded its legal authority by cancelling 1,412 previously appropriated National Endowment for the Humanities grants. The judge found the process a “textbook example of unconstitutional viewpoint discrimination.”
What the ruling revealed about DOGE’s methods is relevant beyond the specific case. DOGE staffers admitted in depositions to feeding grant descriptions into ChatGPT with prompts designed to identify projects related to DEI. The AI’s outputs were then used to determine which grants to cancel. Judge McMahon was direct in her assessment, writing that “ChatGPT was the Government’s chosen instrument for purposes of this project, and DOGE’s use of AI to identify DEI-related material neither excuses presumptively unconstitutional conduct nor gives the Government carte blanche to engage in it.” Citing the comedian Flip Wilson’s character Geraldine Jones, she added: “The devil made me do it… That excuse did not work for Geraldine Jones, and it does not work for the Government.”
The same class of technology that is hammering package registries at machine speed — contributing directly to the sustainability crisis this piece describes — was used by agents of the US federal government to automate the dismantling of the oversight capacity that might have addressed it. You could not write that as fiction.
The governance vacuum, in other words, is not simply the product of regulatory inattention or institutional drift. In the United States, it appears to be the intended output of deliberate policy. The mandates were rescinded. The agency enforcing them was defunded. The methods used to identify what to cut were themselves a demonstration of the problem — automated, opaque, and apparently immune to the kind of human judgement that might have noticed the irony.
Europe is legislating without resourcing. America has dismantled what little oversight existed and is now watching the courts try to pick through the wreckage.
Nobody is minding the store. And in at least one case, the people who were supposed to be minding it used an AI chatbot to decide what to throw away.
On 6 May 2026, Sonatype and the Linux Foundation announced the formation of the Sustaining Package Registries Working Group. Founding members include Alpha-Omega, the Eclipse Foundation, the OpenJS Foundation, the Open Source Security Foundation, Packagist, the Python Software Foundation, Ruby Central, and the Rust Foundation.
The announcement was welcomed by the open source security community. It was the right instinct. It was overdue by approximately a decade. And whether it will produce anything beyond a well-intentioned press release remains, as of the time of writing, an open question.
To understand what the working group can and cannot do, it helps to understand what it is. It is not a regulatory body. It has no enforcement powers. It cannot compel any company to pay for registry access it has always received for free. It cannot designate registries as critical infrastructure. It cannot mandate SBOMs, require dependency audits, or impose financial obligations on the organisations whose pipelines consume the most bandwidth.
What it can do is coordinate. It can bring the registries into alignment on a shared position. It can present that position to the industry — to the large technology companies, the cloud providers, the AI labs — as a unified ask rather than a series of individual appeals. It can make the argument, collectively and with more credibility than any single registry could muster alone, that the current arrangement is unsustainable and that the industry has a shared interest in addressing it.
This matters more than it might appear. The free rider problem that afflicts individual registries is partly a collective action problem. Any single registry that introduces metered access or authentication requirements risks losing traffic to registries that do not. If all the major registries move together, that dynamic changes. There is nowhere else to go.
The working group is, in this sense, the registries attempting to form the cartel that their own situation requires. Not to fix prices or exclude competitors — but to present a unified front to an industry that has, for years, exploited their inability to coordinate.
The question is whether coordination alone is sufficient.
The history of working groups in the open source ecosystem is not encouraging. The community has been having versions of this conversation — about sustainability, about funding, about the free rider problem — for years. Working groups have been formed. Reports have been written. Recommendations have been made. The structural conditions that produce the crisis have not materially changed.
What has changed, this time, is the scale of the crisis and the visibility of the threat. The XZ Utils near-miss brought state-sponsored supply chain attacks into mainstream security consciousness. The DOGE-driven dismantling of CISA’s oversight capacity has removed the federal backstop that some in the industry assumed would eventually address the problem. The AI wave has added a new class of industrial consumer that makes the CI/CD pipeline problem look modest by comparison.
The working group is forming at a moment when the urgency is higher than it has ever been. Whether that urgency translates into action depends on whether the large commercial consumers of registry infrastructure decide that contributing to sustainability is cheaper than the alternative.
The alternative, to be clear, is a registry failure — or a series of them. Not necessarily a dramatic, sudden collapse. More likely a gradual degradation. Maintainers burning out and stepping back. Security response times lengthening. Infrastructure becoming less reliable. The slow hollowing out of the systems that the global software industry depends on, until something breaks badly enough that the cost of having ignored the problem becomes impossible to ignore.
There are things that would actually work. They are not secret. They have been identified, discussed, and in some cases piloted, for years.
Metered access for high-volume automated consumers. A tiered model — free for humans and small teams, paid for the CI/CD pipelines and AI training systems that generate the majority of traffic — would align cost with consumption in a way that donations never can. The registries have resisted this because it requires authentication infrastructure they do not have and risks community backlash they cannot afford. A working group with the backing of all major registries could change that calculus.
Direct corporate funding at scale. Not the hundred-thousand-dollar donations that constitute reputational insurance for hyperscalers. Structural commitments — multi-year, material, tied to consumption levels — from the companies whose production systems depend on registry availability. The working group provides the forum for that conversation. Whether the companies will come to it honestly is another matter.
Regulatory designation. If package registries were formally designated as critical infrastructure in major jurisdictions, the obligations and funding that designation attracts would follow. This requires governments to act — which, as the previous section established, is not currently a safe assumption in the world’s largest technology jurisdiction. But NIS2 implementation in Europe, and the CRA’s stewardship provisions, create at least the architecture for this conversation to happen.
None of these solutions is simple. All of them require someone with power — commercial, regulatory, or both — to accept a cost they have successfully avoided until now. The working group can make the argument. It cannot compel the outcome.
Brian Fox, CTO of Sonatype and one of the architects of the working group, has framed the current situation clearly. Open source registries, he has said, are no longer passive distribution points. They are operational and security-critical systems sitting in the path of nearly every modern software build. The industry still talks about them as though they run on goodwill and spare time.
Spoiler alert, as Fox puts it: they don’t.
The working group is the industry’s attempt to make that reality visible to the people with the power to change it. It is a necessary step. It is not, by itself, a sufficient one.
The piper is still waiting to be paid. A working group is not a cheque.
The working group exists. The conversation is happening. The crisis is visible. So the question that has been building through this entire piece can finally be asked directly.
Who pays the piper?
The honest answer, right now, is nobody adequate.
The Python Software Foundation runs on five million dollars a year, most of which is not cash. The Rust Foundation operates on a budget that would not cover the annual salary costs of a mid-sized technology company’s security team. Ruby Central, which operates RubyGems, is a 501(c)(3) non-profit that publishes its financials and would not embarrass a moderately successful local business. Maven Central is a marketing expense on a private equity firm’s balance sheet.
These are the organisations maintaining the foundations of the global software industry. Their combined budgets are a rounding error on the quarterly earnings of any single hyperscaler that depends on their infrastructure.
The gap between what these organisations receive and what they would need to operate as the critical infrastructure they actually are is not a funding shortfall. It is a category error. It is the result of an entire industry treating infrastructure that cost billions to build — in volunteer hours, donated expertise, and foregone commercial opportunity — as a free resource with no balance sheet entry and no line item in anyone’s risk register.
The most likely scenario for how this gets resolved — if it gets resolved — is that the large technology companies write cheques. Not because they have developed a conscience about the free rider problem. Not because a working group made a compelling moral argument. But because the alternative eventually becomes more expensive than the contribution.
A significant registry failure — or a successful supply chain attack routed through an undermaintained package — would cost the companies that depend on that infrastructure orders of magnitude more than sustainable funding would have cost. The economics of prevention versus remediation are not complicated. They are, in the technology industry, simply not taken seriously until the remediation bill arrives.
When the cheques come — and they will come, eventually, in some form — they will come with strings. The piper doesn’t just want your coin. He wants your playlist.
Consider what it means that Microsoft owns npm.
npm is the package registry for JavaScript and Node.js. It serves more downloads than any other registry in the ecosystem. It is embedded in the development workflow of millions of engineers around the world. Its dependency graph touches virtually every modern web application.
Microsoft acquired GitHub in 2018. GitHub had acquired npm Inc. in 2020. The transaction was described as a commitment to the open source community. Microsoft, to its credit, has not made dramatic changes to npm’s operation. The registry remains accessible. The service has been maintained.
But Microsoft is a corporation with a fiduciary duty to its shareholders, not a charitable trust for the European or Manx digital commons. npm is not a public utility. It is a product feature. Its continuity is a commercial courtesy, subject to the shifting weather of the Redmond boardroom.
Every developer who types npm install is interacting with infrastructure governed by US law, subject to the CLOUD Act and FISA 702. This is not a theoretical concern. It is critical national infrastructure — for every nation that runs software — operating on a private playground where the rules can be rewritten by a foreign jurisdiction.
Business decisions change when interests change. The most widely used package registry in the world is, in governance terms, a product feature of a subsidiary of a US technology corporation. Its continuity is a courtesy, not a guarantee.
npm is not the only chokepoint Microsoft occupies in the developer ecosystem. GitHub hosts more than 100 million repositories — the largest collection of source code in human history. When Microsoft launched GitHub Copilot, that code became training data for a commercial AI product. Developers who had published code on GitHub under open source licences found that their work was being used, without explicit consent beyond the platform’s terms of service, to train a product Microsoft sells.
The currency being extracted here is not just metadata. It is the act of creation itself.
By observing how developers build, how they solve problems, and the patterns of their preferences, these companies are engaged in what can only be described as cognitive strip-mining. The Copilot memory features — the capability for the AI to retain context across sessions, to learn your codebase, your patterns, your preferences — mean that the more you use it, the more of your intellectual process is observed, retained, and commodified. The AI wave hitting registries today is not just a technical load problem. It is a systematic harvesting of the global developer’s cognitive output to fuel a proprietary black box.
This is what Judge McMahon identified, in a different but structurally identical context, when she ruled against DOGE in May 2026. The problem was not merely that ChatGPT was used to cut funding. It was the “delegation of executive discretion to a commercial Large Language Model” — the outsourcing of judgement itself to an entity whose interests are not those of the people affected by its decisions. When we outsource our registry infrastructure to the hyperscalers, we are doing exactly the same thing. Delegating the discretion over our digital foundations to commercial entities whose accountability runs to their shareholders, not to us.
The sovereignty dimension of this extends beyond npm and GitHub. Open source package registries are, for practical purposes, American infrastructure. PyPI — US non-profit. npm — US corporation. Maven Central — US company, US private equity ownership. Crates — Rust Foundation, US non-profit. The governance, the legal jurisdiction, the financial structures, and the commercial relationships that determine whether these systems continue to operate are all located, primarily, in the United States.
Every nation whose software industry depends on these registries — which is every nation with a software industry — is running critical infrastructure that it does not control, cannot regulate, and has no legal standing to protect.
For the Isle of Man, for the United Kingdom, for every European Union member state, this is not a theoretical concern. It is a live dependency that nobody has mapped and nobody is managing. The software running government systems, hospital infrastructure, and financial services in every one of these jurisdictions pulls from registries governed by US law, operated by US entities, and subject to US political and commercial decisions.
This is not paranoia. It is a straightforward description of what critical infrastructure dependency without sovereignty looks like.
This is why sovereignty-conscious operators run their own infrastructure. Forgejo. Gitea. A self-hosted Git instance on hardware you control, in a jurisdiction you understand, with an audit trail that belongs to you. Not because the hyperscalers are necessarily malicious. But because dependency on infrastructure you do not control, operated by an entity whose interests are not identical to yours, is a structural vulnerability — regardless of how convenient the service is and how good the product feels to use.
The free infrastructure is never actually free. Someone is always paying. The question is whether you know what the currency is.
So when the cheques eventually come — when Google or Microsoft or Amazon decides that funding registry sustainability is cheaper than the alternative — the question that the open source community will face is the same question that any dependent faces when a powerful party offers to solve their problem.
What do they want in return?
Influence over governance decisions? A seat at the table when security policies are set? The ability to shape the terms under which competitors access the same infrastructure? The data on what the entire industry is building and deploying, available through the consumption patterns of the registries they now fund?
None of these outcomes requires bad faith. They do not require a conspiracy. They are simply what happens when power concentrates around infrastructure that everyone needs and only some can afford to maintain.
The open source movement was built, in part, to prevent exactly this kind of concentration. The irony is that the philosophy it used to fight that concentration — open by default, free for everyone, no toll booths — has produced the conditions in which concentration is now the most likely resolution to the crisis it created.
The piper gets paid. The piper calls the tune.
If the tune is called by the same companies whose pipelines created the sustainability crisis in the first place, the open source community will have traded one form of dependency for another. The infrastructure will be funded. The question of by whom, and on whose terms, will matter enormously.
That question is not being asked loudly enough. Not yet.
Denis Pushkarev is still at his laptop. In 2026, more than three years after he published his distress signal on GitHub, he is still maintaining core-js. The download counter is still climbing. The corporations whose products depend on his work have still not responded in any meaningful way.
In the intervening period he has done something pragmatic and quietly significant. He incorporated a company — CoreJS Company, core-js.io — around the project. Not as a surrender to the commercial model he spent years being failed by. As an attempt to create a structure that enterprise consumers could actually engage with. A route for the support contracts that personal appeals never produced.
It is, in miniature, the answer the ecosystem needs at scale. Not charity. Not heroism. A sustainable commercial relationship between the people who build critical infrastructure and the organisations that depend on it.
Whether anyone takes him up on it remains to be seen.
The open source ecosystem runs on people like Denis Pushkarev. People who built something useful, watched it become critical, and kept showing up anyway — through burnout, through financial hardship, through harassment, through the quiet indignity of watching their work generate billions for companies that could not name them.
Most of them are not incorporated. Most of them have not published a manifesto. Most of them are simply tired, working evenings on infrastructure that the global software industry depends on, wondering how much longer they can keep going.
The queue behind Pushkarev is long. The people in it are just as exhausted, just as invisible, and just as essential. The banks, the hospitals, the government departments, the AI companies training their models on code those people wrote — none of them know the names. None of them have mapped the dependency. None of them have a plan for what happens when the next person in that queue makes the same calculation Marak Squires made, or the same decision Dominic Tarr made, or simply closes their laptop one evening and does not open it again.
Nobody will notice until something breaks.
The working group is meeting. The regulators are, in some jurisdictions, beginning to ask the right questions. The industry is, slowly and reluctantly, acknowledging that the current arrangement cannot continue indefinitely.
But the queue is still there. And the people in it are not waiting for a working group.
Who’s next?
Sonatype, 7th Annual State of the Software Supply Chain (2021), p.4 — sonatype.com/resources/state-of-the-software-supply-chain
Tidelift, 2024 State of the Open Source Maintainer Report (2024), sample n=437 — tidelift.com/subscription/2024-open-source-maintainer-survey
Andres Freund, Openwall oss-security mailing list, 29 March 2024, “backdoor in upstream xz/liblzma leading to ssh server compromise” — openwall.com/lists/oss-security/2024/03/29/4
Denis Pushkarev (zloirock), GitHub Issue #1179, core-js, “The state of core-js and a personal message”, 14 February 2023 — github.com/zloirock/core-js/issues/1179
MALTA research paper, “Maintenance-Aware Technical Lag, Estimation to Address Software Abandonment”, March 2026 — arxiv.org/html/2603.10265v1
Sonatype and Linux Foundation, Sustaining Package Registries Working Group announcement, 6 May 2026 — sonatype.com/press-releases/sonatype-and-package-registry-leaders-unite
Office of Management and Budget, Memorandum M-26-05, 23 January 2026
EU Cyber Resilience Act, Regulation (EU) 2024/2847 — Official Journal of the European Union
Executive Order 14028, “Improving the Nation’s Cybersecurity”, May 2021 — whitehouse.gov
Executive Order 14158, “Establishing and Implementing the President’s Department of Government Efficiency”, 20 January 2025 — federalregister.gov
The Authors Guild et al. v. Department of Government Efficiency et al., 1:25-cv-03823 (S.D.N.Y.), decision 7 May 2026
Python Software Foundation, 2023 Annual Report — python.org/psf/annual-report/2023
dominictarr, GitHub Issue #116, event-stream, 2018 — github.com/dominictarr/event-stream/issues/116
Marak Squires, faker.js README statement, November 2020
Babel maintainers, public funding statement, May 2021
The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy -- with a particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.
