Artificial intelligence coding tools are changing the economics and security of open-source software, but not in the way their most optimistic marketing suggests. The tools can write code, generate tests and identify security flaws at speed. Yet the maintainers who decide what enters a project’s official release still have to judge that output themselves. A group of researchers writing for the Association for Computing Machinery’s Technology Policy Council argues that this review burden is becoming one of the most important constraints on open-source health.
The issue reaches far beyond the projects themselves. Open-source code sits inside phones, cars, cloud systems and AI platforms. A Harvard Business School paper cited by the researchers estimates that firms would spend 3.5 times more on software without open source. That saving depends on maintainers who review contributions, issue releases and respond to vulnerabilities. Many of those projects have no reliable revenue, and deferred maintenance can leave security holes in the software built on top of them.
AI Expands the Review Queue
Most open-source projects accept outside contributions. They usually rely on a vetted group of trusted contributors to decide what gets committed, meaning accepted into the official codebase. That model works when contributions arrive at a manageable pace and reviewers can understand the code, the context and the intent behind a change. AI has made writing and submitting code cheap. It has also made it easier to produce plausible-looking patches that are incomplete, insecure or irrelevant.
The researchers allow that the quality of AI-generated code may improve as models improve. Better models could reduce some types of errors and help maintainers spot problems earlier. But quality is only one part of the problem. Volume is another. A maintainer who once received a handful of patches in a week may now face a stream of submissions that each need triage, testing, discussion and follow-up. Even a low rejection rate adds up when the number of incoming changes rises sharply. Human reviewers still have to assess licensing, compatibility, maintainability, performance and security implications that an AI model may not understand in the context of a specific project.
Review is not a passive task. It requires reading code, reproducing bugs, checking documentation, considering edge cases and deciding whether a change fits the project’s long-term direction. AI can assist with some of that work, but it also creates new work: reviewers must determine whether a patch was generated responsibly, whether it contains hidden assumptions, whether it duplicates existing efforts and whether it introduces dependencies that no one is prepared to maintain. The result is a strange contradiction. Tools that lower the cost of producing code can raise the cost of accepting it.
Why Open-Source Security Is a Shared Surface
So much of the world runs the same code that a flaw found in a widely used component can have outsized impact. A single vulnerable library can affect thousands of applications, including systems that never directly chose that library. The same property that makes open source efficient, namely reuse, also concentrates risk. A growing number of attackers plant malicious packages and code in popular repositories, hoping that developers will install them through automated dependency resolution or copy them from examples.
AI makes this landscape more complicated. The same models that help defenders find flaws can help attackers build exploits. The researchers doubt that restricting top security models to trusted users will solve the problem, because general-purpose models keep getting stronger. Capability spreads. A technique that is limited to a small group today may become widely available through open models, commercial services or simple experimentation. Security therefore cannot depend only on controlling who has access to the most advanced tools. It must also depend on making projects easier to review, patch and govern.
Faster Fixes, Faster Attacks
AI is already producing measurable security work. Between April and October 2025, Google’s CodeMender agent contributed 72 security fixes to open-source projects, including some projects as large as 4.5 million lines of code, according to Google. That is a useful signal. Automated systems can find and patch certain classes of flaws at a scale that human teams cannot match. But it does not remove the need for maintainers. A patch still has to be reviewed, tested and released. Someone has to decide whether the fix is correct, whether it breaks compatibility and whether the project can support the change over time.
AI-found flaws also push organizations to patch sooner. That sounds like an unambiguous good, but it is difficult for applications built from many open-source components. Every component needs its own patch and re-release, often in sequence. One dependency may be updated quickly, while another lags for weeks. Integration testing has to be repeated. Organizations that do not know what they run cannot easily prioritize. The speed of discovery can therefore expose the slowness of remediation. The bottleneck moves from finding vulnerabilities to coordinating fixes across a fragmented supply chain.
The Funding Gap Behind the Code
The money in open source is lopsided. The Linux Foundation brought in $292,217,236 in 2024. The Apache Software Foundation, which the researchers cite as an example of projects that run on volunteer labor and sponsorships, brought in $2,379,402. That is less than 1 percent of the Linux Foundation figure. The comparison is not a judgment about the value of either organization. It illustrates how unevenly support is distributed across the ecosystem and how many critical projects operate with tiny budgets relative to their importance.
Across open source, most users never pay. This is the free-rider problem. Companies build products on open-source components, save on development costs and sometimes contribute code or sponsorship. But many do not contribute money, maintainers or review time. The projects that are most depended upon may be the least visible to the organizations that rely on them. A library can be embedded in a product for years without anyone tracking its maintainer count, release cadence or funding status. When a maintainer burns out or a vulnerability appears, the dependency suddenly becomes visible.
Thin funding does not only affect code writing. It affects the unglamorous work that makes code usable and secure. Documentation, packaging, fundraising, issue triage and requirements gathering all require human attention. The researchers argue that projects need more resources in these areas because deciding what a project needs and getting its community to agree still falls to people. An AI model can draft documentation or suggest a release process, but it cannot resolve competing priorities among users, sponsors and contributors. It cannot take responsibility for a security decision or build trust with a community.
Visibility Does Not Equal Safety
A software bill of materials, or SBOM, is a machine-readable list of the components inside an application. The idea is straightforward: if organizations know what is in their software, they can respond faster when a component is compromised. Despite US and EU mandates, the vast majority of open-source applications do not generate or ship one. Even when an SBOM exists, it shows what is present. It does not show whether each piece is maintained, funded, secure or abandoned.
That distinction matters. An SBOM can tell an organization that it uses a particular library at a particular version. It cannot tell whether the library’s maintainer has stopped responding, whether the project has one volunteer reviewer or whether security fixes are released promptly. Those are governance and maintenance questions. Answering them requires more than a list of components. It requires relationships, data collection and a way to assess the health of dependencies over time. Without that context, an SBOM can create a false sense of control.
The same problem applies to ecosystem-wide measurement. Open source is governed project by project, so numbers on AI’s effects are hard to collect. There is no central authority that tracks how many AI-generated contributions arrive, how many are rejected, how much review time they consume or how often they introduce vulnerabilities. Projects have different policies, different tooling and different levels of transparency. Researchers can study samples, but the full picture remains fragmented.
The Human Governance Bottleneck
The researchers want projects to put more resources into documentation, packaging, fundraising and gathering requirements. These are not peripheral activities. They determine whether a project can attract contributors, retain maintainers and respond to security issues. They also determine whether users can understand what the project promises and what it does not. AI can help produce artifacts, but it cannot replace the human work of setting priorities and reaching agreement.
Most institutions face perhaps their largest challenge in learning the governance, maintenance and security state of their software. They need to spot critical dependencies before something fails. That means going beyond inventories and asking harder questions. Who maintains this component. How is it funded. How quickly are vulnerabilities addressed. What happens if the lead maintainer leaves. Is the project used in a way that its maintainers do not know about. The answers are often incomplete, and the gaps are where risk accumulates.
The review load created by AI is therefore not just a productivity problem. It is a governance problem. Tools can generate more code, more patches and more vulnerability reports, but they do not create more trusted reviewers, more funding or more community consensus. Those resources remain scarce. Projects that can afford staff and tooling may absorb the new volume. Projects that depend on volunteers may struggle. The disparity can widen the security gap between well-supported components and the thinly funded ones that quietly hold up critical systems.
For organizations that rely on open source, the practical implication is that dependency management has to include maintainer capacity. A component is not safe simply because it is popular or because it has an SBOM. It is safer when someone is reviewing changes, releasing fixes and planning for the future. AI can assist with those tasks, but it also adds to the queue that those people must process. The work is less about writing more code than knowing which code matters, who is responsible for it, and whether it can be repaired before a failure becomes systemic.
Source: Help Net Security News