Beneath the surface of every phone, car, and cloud platform runs a vast architecture of open source code—maintained largely by volunteers who now face an accelerating paradox: AI tools generate and audit code faster than human judgment can follow. The authors of a new ACM Technology Policy Council paper, including Simson Garfinkel and Josiah Dykstra, argue that this imbalance—between the speed of machine contribution and the limits of human review—is quietly straining the infrastructure the modern world depends on. Funding remains deeply unequal, visibility into what software actually runs whe
AI Coding Tools Strain Open Source Maintainers as Funding Gaps Widen
A human still has to read every line, judge its quality, and decide whether it belongs
Mark
So the problem is that AI writes code faster than humans can review it. Is that the whole story?
Mimi
It's part of it. The real issue is that review work is piling up on people who are already stretched thin and mostly unpaid. AI didn't create the funding gap—it just made the gap more visible.
Luke
But we should be careful here. The source says AI-generated code quality may improve as models improve. We don't actually know yet if this is a permanent burden or a transition problem.
Mark
Fair. But what about the security side? If AI can find flaws faster, isn't that good?
Mimi
It is good. Google's CodeMender fixed 72 vulnerabilities in six months. But the same capability can be used to find and exploit flaws. And when a flaw is found, patching is complicated because applications depend on multiple components.
Luke
The source doesn't say attackers are actually using AI to find flaws yet—it says the authors doubt that restricting access will help. That's a prediction, not a fact on the ground.
Mark
What about the money? The funding numbers seem stark.
Mimi
They are. Linux Foundation got $292 million in 2024. Apache got $2.4 million. Most open source users never pay. It's called the free-rider problem.
Luke
But we should note that Linux Foundation and Apache do different things at different scales. The comparison is real, but it's not quite apples to apples.
Mark
So what's the actual risk here?
Mimi
Deferred maintenance. If projects can't afford to keep up with review work, security holes stay open. And since open source is everywhere—in your phone, your car, the cloud—those holes matter.
Luke
The source does say that, but it doesn't give us examples of specific projects that have had to shut down or go unmaintained because of this. That would be the real test.
Mark
What about the SBOM thing?
Mimi
Most applications don't have one, even though the US and EU mandate them. So you don't actually know what's inside the software you're running.
Luke
Right. But the source doesn't tell us how many applications are non-compliant or what the enforcement looks like. It's a gap, but we don't know how big.
Le Pouls
- AI coding tools are flooding open source projects with submissions faster than volunteer maintainers—most of them unpaid—can possibly review them.
- The funding gap is severe: the Linux Foundation received $292 million in 2024 while the Apache Software Foundation, a bellwether for volunteer-run projects, received just $2.4 million.
- Google's CodeMender agent patched 72 security flaws across millions of lines of code in six months—but the same AI capability is available to attackers building exploits.
- When a vulnerability is found in a shared component, patching cascades through every dependent layer, each requiring its own fix and release in sequence, all at human speed.
- Software bills of materials—mandated by the US and EU to map what components live inside applications—are still absent from the vast majority of open source projects, leaving operators blind to what they are actually running.
Beneath the surface of every phone, car, and cloud platform runs a vast architecture of open source code—maintained largely by volunteers who now face an accelerating paradox: AI tools generate and audit code faster than human judgment can follow. The authors of a new ACM Technology Policy Council paper, including Simson Garfinkel and Josiah Dykstra, argue that this imbalance—between the speed of machine contribution and the limits of human review—is quietly straining the infrastructure the modern world depends on. Funding remains deeply unequal, visibility into what software actually runs where remains poor, and the same tools that repair vulnerabilities can be turned to exploit them.
Open source maintainers—volunteers and small teams who decide what code reaches the world—are being outpaced by the very tools meant to help them. AI writes code and finds its flaws at machine speed, but a human still has to read every submission, judge its quality, and decide whether it belongs. Six authors writing for the ACM Technology Policy Council, including Simson Garfinkel and Josiah Dykstra, have named this growing imbalance as a crisis.
The stakes are enormous. A Harvard Business School estimate cited in the paper suggests companies would spend 3.5 times more on software if open source did not exist. Yet the money flowing back to these projects is wildly uneven. The Linux Foundation brought in $292 million in 2024; the Apache Software Foundation, representative of projects running on volunteer labor and modest sponsorships, received $2.4 million—less than one percent of that. Most users never pay. The problem has a name: free-rider.
The speed of AI cuts in both directions. Between April and October 2025, Google's CodeMender agent contributed 72 security fixes to open source projects, some spanning 4.5 million lines of code—repair work that might otherwise have taken months. But the same models that find and patch flaws can be turned toward building attacks. The authors are skeptical that restricting powerful security models to trusted users will contain the risk, as general-purpose models keep improving and knowledge spreads.
When a flaw surfaces in widely used code, the damage is outsized—and patching becomes a cascade. Most applications stack many open source components on top of each other; each needs its own fix, its own re-release, in sequence. The pressure to move fast runs into machinery that still moves at human speed.
Visibility compounds the problem. Software bills of materials—machine-readable inventories of what components live inside an application—have been mandated by both the United States and the European Union. Yet most open source applications still do not generate or ship one. Even where an SBOM exists, it shows what is present, not whether each piece is maintained, funded, or quietly abandoned. Operators may not know what they are running. In many cases, neither do the maintainers.
The code arrives faster than ever. Open source maintainers—the volunteers and small teams who decide what software gets released to the world—are drowning in submissions. AI coding tools write it. AI finds the flaws in it. But humans still have to read every line, judge its quality, and decide whether it belongs in projects that power phones, cars, cloud systems, and the AI platforms themselves.
This is the bind that six authors writing for the Association for Computing Machinery's Technology Policy Council have flagged as a growing crisis. Among them are Simson Garfinkel and Josiah Dykstra. The tools are fast. The maintainers are not. And most of them are not paid.
The scale of what open source carries is staggering. A Harvard Business School paper cited by the authors estimates that companies would spend 3.5 times more on software if open source did not exist. Yet the funding that flows to these projects is wildly uneven. The Linux Foundation brought in $292 million in 2024. The Apache Software Foundation, which the authors point to as representative of projects running on volunteer labor and sponsorships, took in $2.4 million—less than 1 percent of that. Across the open source ecosystem, most users never pay. The problem has a name: free-rider.
AI has made writing code trivial. Submitting it is now easier than ever. Some of what arrives is poor. The authors acknowledge that quality may improve as the models improve, but the volume keeps climbing, and a human still has to assess each contribution. This is not abstract work. It is reading code, understanding intent, spotting mistakes, and deciding yes or no. When you multiply that across thousands of projects, most understaffed and underfunded, the math breaks down.
The speed cuts both ways. Between April and October 2025, Google's CodeMender agent contributed 72 security fixes to open source projects, including some spanning 4.5 million lines of code. That is repair work that might have taken months. But the same models that find and patch flaws can be weaponized to build attacks. The authors are skeptical that restricting top security models to trusted users will help—general-purpose models keep getting stronger, and the knowledge spreads. When a flaw is found in widely used code, the impact is outsized. A growing number of attackers now plant malicious packages directly into popular repositories.
Patching becomes a cascade problem. When AI finds a vulnerability in a component, organizations want to patch it fast. But most applications are built from many open source components stacked on top of each other. Each one needs its own patch. Each one needs its own re-release. They have to happen in sequence. The pressure accelerates, but the machinery moves at human speed.
There is another gap that the authors highlight: visibility. A software bill of materials, or SBOM, is a machine-readable list of what components sit inside an application. The United States and European Union have mandated them. Yet the vast majority of open source applications do not generate or ship one. An SBOM would show what is present—but not whether each piece is maintained, funded, secure, or abandoned. You may not know what you are running. The maintainers may not know either.
Citations marquantes
AI coding tools write code and find security flaws quickly, but maintainers who decide what enters a project's official release still have to judge that output themselves— Association for Computing Machinery Technology Policy Council authors, including Simson Garfinkel and Josiah Dykstra
Envie de l'histoire complète ?
Lire l'original sur Help Net Security ↗
Technology