Open source software is now carrying a load it was never funded to carry. That is the blunt reading of a new TechBrief from the Association for Computing Machinery’s Technology Policy Council, released to the press on 15 September 2026, which argues that increasingly capable AI systems are simultaneously improving open source software and overwhelming the volunteer structures that keep it alive.
The brief is short, as ACM TechBriefs are, but the tension it describes is not. AI can find vulnerabilities, write patches and accelerate development. The same capability hands attackers a faster route in, and floods maintainers with contributions they are obliged to read. The economic stakes make the imbalance harder to ignore: research cited in the brief estimates firms would spend 3.5 times more on software if open source software did not exist, and puts the demand-side value of open source software to firms worldwide at $8.8 trillion.
This article works through what the TechBrief actually says, what the underlying numbers are, and what has already happened to real projects — curl, Log4j, Kubernetes, tldraw, Ghostty — that ran out of volunteer capacity first. Every figure traces to a named source, and the References section links all of them.
Table of contents
- What the ACM TechBrief Says About Open Source Software
- The $8.8 Trillion Economy Resting on Open Source Software
- Cybersecurity: AI Cuts Both Ways in Open Source Software
- The Maintainer Flood: When Contribution Volume Outruns Review
- curl, Log4j and the Collapse of the Bug Bounty Model
- Why Open Source Software Sustainability Is the Real Bottleneck
- How Open Source Software Projects Are Fighting Back
- What the ACM Recommends and What Businesses Should Do Now
- Frequently Asked Questions About Open Source Software and AI
- References
What the ACM TechBrief Says About Open Source Software
“TechBrief: Artificial Intelligence‘s Effects on Open Source” was published by ACM under DOI 10.1145/3838809 on 7 August 2026 and pushed to the press on 15 September. Its authors are Arunachalam Balasubramanian Shrinivass, Simson Garfinkel, Josiah Dykstra, Andy Oram, Nina Shamsi and Jonathan M. Smith — a mix of industry and academic contributors working through ACM’s Technology Policy Council.
Garfinkel, Chief Scientist at BasisTech and Chair of the ACM TechBriefs Committee, framed the central point in a way worth quoting in full:
“Open source has always depended on more than the ability to write code. Successful projects require people to set priorities, evaluate contributions, make governance decisions, and build consensus around the needs of their communities. AI can dramatically accelerate technical work, but those decisions still require human judgment — at least for now.”
The four challenges the brief identifies
The TechBrief does not treat AI as a single threat to open source software. It separates the pressure into four distinct problems, each with a different cost owner.
| Challenge | What AI changes | Who absorbs the cost |
|---|---|---|
| Cybersecurity | Both vulnerability discovery and attack capability accelerate together | Every downstream user of the package |
| Software maintenance | Contribution volume rises; evaluation stays manual | Unpaid project maintainers |
| Long-term sustainability | Workload grows without a matching revenue stream | The project, until it stops |
| Knowledge gap | Dependency trees deepen faster than anyone maps them | Organisations that do not know what they ship |
The pattern across all four rows is the same. AI raises throughput on the side of the ledger that machines are good at, and leaves the human side — judgement, triage, governance, consensus — exactly where it was. Open source software has always run on a thin layer of human attention, and that layer is not elastic.
Why open source software is the load-bearing case
The brief notes that vulnerabilities in open source software carry disproportionate impact because adoption is so wide. A flaw in a proprietary product affects that product’s customers. A flaw in a widely used open source software library propagates into every application, device and cloud service that imported it, often several layers deep, and often without the downstream owner knowing the dependency exists at all.
The $8.8 Trillion Economy Resting on Open Source Software
The economic figures in the TechBrief come from “The Value of Open Source Software”, a Harvard Business School working paper by Manuel Hoffmann, Frank Nagle and Yanuo Zhou, first published on 16 January 2024. It remains the most widely cited attempt to price open source software, and its numbers are worth separating carefully, because the two headline figures measure different things.
Supply side versus demand side
The supply-side value is the cost to write the software once: what it would take to recreate the most widely used open source software from scratch, one time. The demand-side value is the replacement cost carried by every firm that uses it. The gap between them is the entire argument.
| Measure | Figure | What it counts |
|---|---|---|
| Supply-side value | $4.15 billion | Cost to create the widely used code once |
| Demand-side value | $8.8 trillion | Replacement cost across every firm using it |
| Spending multiplier | 3.5x | What firms would spend without open source software |
| Value concentration | 96% from 5% of developers | Share of demand-side value by contributor |
| Language concentration | 84% from six languages | Share of demand-side value by language |
Divide the demand-side figure by the supply-side figure and the ratio is roughly 2,120 to 1. Every dollar of effort spent creating widely used open source software produces about $2,120 of value for the firms that consume it. That is not a criticism of anyone; it is simply what non-rival goods do. But it does explain why a maintainer’s inbox and a maintainer’s bank balance have never been proportional.
The concentration problem
The 96%-from-5% finding is the one that should worry anyone modelling risk in open source software. The value is not spread evenly across a broad community. It sits with a small group of highly active contributors, which means the ecosystem’s resilience is a function of whether a few thousand people stay interested, stay healthy and stay unburned. AI has just handed every one of them a substantially larger inbox.
Cybersecurity: AI Cuts Both Ways in Open Source Software
The TechBrief’s first challenge is cybersecurity, and it is the one where the symmetry is most uncomfortable. The same model that reads a codebase and spots an off-by-one error can be pointed at that codebase by someone who does not intend to file a report.
Defensive gains are real
Automated vulnerability discovery genuinely works, and it works at a scale no human review process matches. Fuzzing harnesses guided by language models, static analysis with semantic understanding of intent, and automated patch generation have all moved from research demos to production tooling. For a well-resourced open source software project with paid security staff, this is a straight improvement.
The triage cost lands on volunteers
The problem is that the output of automated discovery arrives as a report, and a report has to be read by a person before anyone knows whether it is real. The cost of generating a plausible-looking vulnerability report has collapsed. The cost of disproving one has not moved at all. That asymmetry is the whole story of what happened to open source software bug bounty programmes in 2026, and it is covered in detail below.
Disproportionate blast radius
Because open source software sits underneath so much else, a single unpatched flaw has leverage that a proprietary bug does not. The TechBrief is explicit that this is why cybersecurity in open source software deserves separate policy attention rather than being folded into general software security guidance.
The Maintainer Flood: When Contribution Volume Outruns Review
The second challenge is maintenance, and this is where the strain on open source software is most measurable. GitHub’s Octoverse 2025 report gives the scale.
What the platform numbers show
Developers merged a record 518.7 million pull requests over the year, up 29% year on year, averaging 43.2 million merged pull requests a month, up 23%. More than 36 million new developers joined GitHub, taking the platform past 180 million — more than one new developer per second. Between May and September 2025, a five-month window, coding agents opened more than one million pull requests on their own.
Run the arithmetic on the 29% growth figure and the prior year lands at roughly 402 million merged pull requests. The chart below shows the two years side by side, scaled against the 2025 total.
Volume is not the same as value
An extra 116 million merged pull requests in one year would be unambiguously good news if each carried the same amount of considered human intent as the ones before it. The evidence from maintainers is that it does not. Reviewing a change requires understanding what it does, why it was made and whether the author can defend it — and that review cost does not fall when the authoring cost does.
This is the mechanism the TechBrief describes, stated plainly: AI coding tools increase contribution volume and burden maintainers with evaluation responsibilities. Open source software has no mechanism for charging the submitter for the reviewer’s time, and that missing price signal is what agentic tooling has now exposed.
The backpressure that disappeared
Ghostty’s maintainers put the structural point better than most policy documents have. The rise of agentic programming, they argued, removed the natural effort-based backpressure that used to limit low-effort contributions: producing a large volume of bad content once required a large volume of work. Open source software governance was implicitly designed around that constraint, and the constraint is gone.
curl, Log4j and the Collapse of the Bug Bounty Model
The clearest evidence that AI is straining open source software is not a survey. It is curl, a library shipped in billions of devices, shutting down a programme that had run for nearly seven years.
What Daniel Stenberg actually reported
curl launched its bug bounty in April 2019 through HackerOne. Over its life it confirmed 87 vulnerabilities and paid out more than $100,000. Stenberg announced in January 2026 that the programme would accept submissions until 31 January 2026 and then close, with reports already in progress still processed.
The number that drove the decision is the confirmation rate. Historically, more than 15% of submissions turned out to be real vulnerabilities. In 2025 that fell below 5%. Stenberg dated the shift to late 2024 and said it “accelerated badly in 2025”.
A drop from 15% to 5% means the volunteer security team now reads roughly three times as many reports to find the same single real bug. Stenberg gave three reasons: an explosion in AI slop reports, bad-faith submissions from people exaggerating findings without contributing fixes, and the mental toll of managing an unending stream of low-quality work. He also noted that the Apache Log4j project faced the same problem and planned to close its own programme by late February 2026 if adjustments failed.
Removing the incentive, not the reporting
curl did not stop accepting vulnerability reports. It stopped paying for them, routing disclosure through GitHub’s private vulnerability reporting and a security email address instead. The stated goal was to remove the incentive to submit poorly researched reports. That is a rational response, and it is also a quiet loss for open source software: a funded channel that brought genuine researchers in has been closed because the channel could no longer be defended.
Why Open Source Software Sustainability Is the Real Bottleneck
The TechBrief’s third challenge is long-term sustainability, and the maintainer survey data explains why the first two challenges bite as hard as they do.
The funding picture has not moved
Tidelift’s maintainer research found 60% of maintainers are unpaid for their work — the same figure it recorded in 2021 and 2023. Of the 400 respondents, 16% identified as unpaid hobbyists who would not want to be paid, while 44% of unpaid maintainers said they would appreciate being paid. Nearly 60% reported having quit or considered quitting maintaining a project. About half said they feel underappreciated, and 43% said maintaining adds stress to their lives.
| Factor | Paid maintainers | Unpaid maintainers |
|---|---|---|
| Share of surveyed maintainers | 40% | 60% |
| Working alone on the project | Under half; most have 2+ co-maintainers | 61% maintain alone |
| Critical security practices | Baseline | 55% less likely to implement them |
| Capacity to absorb a review surge | Limited but real | Effectively none |
Solo maintainers and surge capacity
The 61% figure is the one that connects sustainability to the contribution flood. A solo unpaid maintainer of a widely depended-upon open source software package has no queue, no rota and no colleague to hand triage to. When submissions triple, the options are to work more unpaid hours, to close the gate, or to stop. All three have now been observed in production.
Paid maintenance is a security control
Tidelift’s finding that paid maintainers are 55% more likely to implement critical security and maintenance practices reframes funding as a security question rather than a fairness question. An organisation with a cybersecurity budget and an unfunded dependency tree is, on this evidence, buying the vulnerability and declining the mitigation.
How Open Source Software Projects Are Fighting Back
Projects did not wait for a policy brief. Between January and August 2026 several major open source software communities changed their contribution rules, and the range of responses is instructive.
Four different answers to the same problem
| Project | Action | Date | Approach |
|---|---|---|---|
| curl | Closed its HackerOne bug bounty | 31 January 2026 | Remove the incentive |
| tldraw | Auto-closed all external pull requests | 15 January 2026 | Close the gate |
| Ghostty | AI contributions limited to accepted issues and maintainers | January 2026 | Zero tolerance, with bans |
| Kubernetes | Disclosure plus personal accountability policy | June 2026 | Regulate, do not ban |
| Apache Log4j | Planned bounty closure if adjustments failed | Late February 2026 | Remove the incentive |
The Kubernetes model is the one to watch
Kubernetes took the most carefully constructed position, published on the project’s contributor blog in June 2026. Generative AI use must be disclosed in the pull request description — a line such as “This PR was written in part with the assistance of generative AI” is enough. AI tooling may not be listed as a co-author, may not co-sign commits, and may not appear in assisted-by or co-developed trailers. AI-generated commit messages and large AI-generated pull requests are not allowed.
The core rule is about accountability rather than provenance: if you cannot personally explain changes that AI helped generate, the pull request is closed. Contributors are also expected to respond to review comments themselves, without routing replies through a model, because reviewers want to engage with a person.
That distinction matters for anyone writing policy for open source software. Kubernetes did not ban the tool. It insisted that a human remain answerable for the output, which is precisely the human-judgement layer Garfinkel’s quote identifies as irreplaceable.
tldraw and the platform gap
tldraw’s founder Steve Ruiz framed the January decision as a temporary policy pending better tooling from GitHub, citing incomplete or misleading context, a lack of understanding of the codebase, and a lack of follow-up from authors. The framing is worth noting: several of these projects are not rejecting AI contributions on principle. They are rejecting them because the platform gives maintainers no proportionate way to filter, and closing the gate entirely was the only lever available.
What the ACM Recommends and What Businesses Should Do Now
The TechBrief closes with four recommendations. They are aimed at policymakers and large organisations, but they translate directly into actions any company consuming open source software can take this quarter.
The four recommendations
| ACM recommendation | Practical action for a business |
|---|---|
| Expand adoption of software bills of materials | Generate an SBOM per build and store it with the artefact, not in a wiki |
| Map and actively govern organisational OSS use | Name an owner for every critical dependency and review the list quarterly |
| Resource project management beyond coding | Fund or second staff into triage, review and release management |
| Address long-term financial sustainability | Budget direct support for the handful of packages you cannot ship without |
Start with the knowledge gap
The TechBrief’s fourth challenge — organisations lacking awareness of the governance, maintenance and cybersecurity properties of their dependencies — is the cheapest to close and the most commonly ignored. Most teams can list their direct dependencies. Very few can say who maintains them, whether that person is paid, or what the project’s disclosure policy is. If you build software on top of open source software, those three facts belong in your risk register alongside supplier credit ratings.
Progressive Robot’s DevOps services and software development work both start from that dependency map, because an SBOM you cannot act on is documentation rather than control. The same logic applies to managed IT services: patch cadence is only meaningful if someone knows which upstream projects still have a maintainer able to ship a patch.
Treat contribution policy as a supplier requirement
If your engineers contribute to open source software on company time — and if they use AI assistants, which most now do — your organisation is one of the sources of the volume described above. Adopting something close to the Kubernetes rule internally costs nothing and removes your team from the problem: disclose AI assistance, and never open a pull request against an upstream project that the author cannot personally defend in review.
Frequently Asked Questions About Open Source Software and AI
Is AI bad for open source software?
No, and the TechBrief does not argue that. It argues the benefits and the costs land on different people. AI improves vulnerability discovery, patch generation and development speed, which benefits consumers of open source software. The review, triage and governance burden lands on maintainers, 60% of whom are unpaid. The problem is distributional, not technological.
Why did curl close its bug bounty rather than filter submissions?
Filtering requires reading. The confirmation rate falling from above 15% to below 5% means the security team’s reading load roughly tripled per genuine finding, and curl’s team is small and largely volunteer. Closing the bounty removed the financial incentive to submit speculative reports while keeping private disclosure open through GitHub and email.
Does banning AI contributions solve the problem?
Partially, and at a cost. tldraw and Ghostty closed or restricted external contribution and bought their maintainers relief, but open source software depends on the outside contributor pipeline for its next generation of maintainers. Kubernetes bet that disclosure plus personal accountability preserves that pipeline while filtering the unaccountable submissions, which is why its policy is being widely copied.
How much of the world’s software actually depends on open source software?
The Harvard Business School estimate is that firms would spend 3.5 times more on software without it, with a demand-side value of $8.8 trillion against a supply-side creation cost of $4.15 billion. Roughly 96% of that demand-side value traces to 5% of contributors, and 84% to six programming languages.
What should a business do first?
Produce an accurate dependency map with owners, then identify the handful of open source software packages your product genuinely cannot ship without, and check whether each has a funded maintainer. That single exercise turns an abstract sustainability debate into a short, costed list.
References
ACM TechBrief: Artificial Intelligence’s Effects on Open Source
AI Is Reshaping Open Source Software and Straining the Systems That Sustain It
Tech Xplore: AI is reshaping open source software and straining the systems that sustain it
The Value of Open Source Software
The end of the curl bug-bounty
Curl shutters bug bounty program to stop AI slop
Open source maintainership in the age of AI
Octoverse: A new developer joins GitHub every second
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.