Artificial intelligence is changing the economics and security of open-source software, but not in the way that headlines about automated coding often suggest. AI tools can write code and uncover vulnerabilities at a pace that human teams cannot match. The bottleneck is not creation. It is review. Every patch, dependency, feature, and security fix still has to be judged by maintainers who decide what enters a project’s official release. As AI increases the volume of contributions, those maintainers face a growing burden, and many open-source projects operate with thin or unreliable funding.

The issue reaches far beyond the developers who manage repositories. Open-source code sits inside phones, cars, cloud systems, and AI platforms. A Harvard Business School paper cited in a recent policy analysis estimated that firms would spend 3.5 times more on software without open-source components. That figure captures the value of shared code, but it also captures the risk. When a widely used project lacks resources, deferred maintenance can leave security holes in every product built on top of it.

Key Facts

• AI coding tools are adding to the review load on open-source projects.
• Human maintainers still must decide what enters an official codebase.
• Open-source components are embedded in phones, cars, cloud systems, and AI platforms.
• Firms would spend an estimated 3.5 times more on software without open source, according to a cited Harvard Business School paper.
• Most open-source projects lack reliable revenue, and deferred maintenance can create security gaps.
• AI makes code submission easier, including poor-quality contributions that require human assessment.
• Shared code means a single flaw can affect a huge number of users and systems.
• Attackers increasingly plant malicious packages and code in popular repositories.
• Google’s CodeMender agent contributed 72 security fixes to open-source projects between April and October 2025, including changes to codebases as large as 4.5 million lines.
• AI models that find and patch flaws can also be used to build attacks.
• Restricting top security models to trusted users is unlikely to help because general-purpose models keep improving.
• AI-found flaws push organizations to patch sooner, but applications built from many components require sequential patches and re-releases.
• The Linux Foundation brought in $292,217,236 in 2024; the Apache Software Foundation brought in $2,379,402, less than 1 percent of that.
• Most open-source users never pay, a pattern known as the free-rider problem.
• A software bill of materials, or SBOM, is a machine-readable list of components inside an application.
• Despite US and EU mandates, the vast majority of open-source applications do not generate or ship an SBOM.
• An SBOM shows what is present, not whether each component is maintained, funded, secure, or abandoned.
• Open source is governed project by project, making ecosystem-wide numbers on AI’s effects hard to collect.
• Policy authors want more resources for documentation, packaging, fundraising, and requirements gathering.
• Institutions face a major challenge in learning the governance, maintenance, and security state of their software so they can spot critical dependencies before failure.

The Human Bottleneck in an AI-Accelerated Workflow

Most open-source projects accept outside contributions. They typically rely on a vetted group of trusted contributors to decide what gets committed, meaning accepted into the official codebase. AI has made writing and submitting code easy. Some of what arrives is poor. The authors of a policy analysis allow that quality may improve as models do, but a human still has to assess the added volume. That is the core problem: automation can generate more candidate code, but it cannot absorb the accountability for what ships.

Reviewing code is not a passive task. It requires understanding a project’s design, its compatibility promises, its security posture, and its long-term maintenance plan. A maintainer must ask whether a contribution solves a real problem, whether it introduces new dependencies, whether it follows project conventions, and whether it can be maintained after the original contributor moves on. AI can help draft tests or suggest fixes, but it does not remove the need for judgment. In many projects, the same small group of volunteers handles those decisions after their day jobs.

Why Shared Code Creates Outsized Risk

So much of the world runs the same code that a flaw found in it can have an outsized impact. A single vulnerable library can affect thousands of applications, from banking systems to medical devices to consumer gadgets. A growing number of attackers plant malicious packages and code in popular repositories. These attacks exploit the trust that developers place in package managers and open-source communities. When a project is underfunded, its maintainers may not have the time or tools to detect every malicious contribution.

The review burden therefore has a security dimension. AI can help find flaws, but it also lowers the cost of producing attacks. Models that find and patch vulnerabilities can be repurposed to build exploits. The policy authors doubt that restricting top security models to trusted users will help, since general-purpose models keep getting stronger. Even if the most capable security-focused systems were limited, attackers could use widely available models to probe code, generate malicious packages, or automate social engineering against maintainers.

Faster Fixes, Faster Attacks

Between April and October 2025, Google’s CodeMender agent contributed 72 security fixes to open-source projects, including some as large as 4.5 million lines of code, according to Google. That example shows the potential of AI to reduce the time between discovery and repair. It also shows the scale of the review problem. A fix for a 4.5-million-line codebase is not a simple patch. It must be evaluated for correctness, regressions, and compatibility. If the fix arrives faster than maintainers can review it, the benefit may be delayed or lost.

AI-found flaws push organizations to patch sooner. That is hard for applications built from many open-source components, because every one of those components needs its own patch and re-release, in sequence. A modern application may include hundreds of direct and transitive dependencies. Each dependency has its own maintainers, release cadence, and compatibility constraints. Patching one component can require updating another, and the process can cascade across an entire software supply chain. For institutions with legacy systems or limited engineering staff, that sequence can be daunting.

The Economics of Maintenance: A Widening Funding Gap

The money in open source is lopsided. The Linux Foundation brought in $292,217,236 in 2024. The Apache Software Foundation, which the policy authors cite as an example of projects that run on volunteer labor and sponsorships, brought in $2,379,402, less than 1 percent of that. Across open source, most users never pay, a pattern known as the free-rider problem. Companies build products on free components, but they often do not contribute back in proportion to the value they capture.

That imbalance matters more as AI increases the volume of code and the speed of vulnerability discovery. A project with one or two part-time maintainers cannot easily absorb a flood of AI-generated pull requests, security reports, and dependency updates. Even well-funded foundations struggle to coordinate across hundreds of projects. The result is a maintenance backlog that can persist for years, leaving known flaws unpatched and new contributions unreviewed.

Visibility Gaps: SBOMs and the Limits of Mandates

A software bill of materials, or SBOM, is a machine-readable list of the components inside an application. Despite US and EU mandates, the vast majority of open-source applications do not generate or ship one. That leaves organizations without a clear inventory of what they run. An SBOM would show what is present, not whether each piece is maintained, funded, secure, or abandoned. It is a starting point for visibility, not a complete risk assessment.

Without that visibility, institutions cannot easily answer basic questions. Which projects are critical to their operations? Which are maintained by a single person? Which have no recent security releases? Which rely on dependencies that have been abandoned? AI can help analyze code and dependencies, but it cannot replace governance. Someone still has to decide what levels of risk are acceptable, what resources to invest, and how to respond when a critical dependency fails.

Governance, Documentation, and the Long Road Ahead

Open source is governed project by project, so ecosystem-wide numbers on AI’s effects are hard to collect. The policy authors want projects to put more resources into documentation, packaging, fundraising, and gathering requirements. Deciding what a project needs and getting its community to agree still falls to people. Those activities are not glamorous, but they determine whether a project can survive an influx of AI-generated contributions and AI-discovered vulnerabilities.

Documentation helps new contributors understand how to participate without adding to maintainer overload. Packaging reduces the friction of distributing secure releases. Fundraising creates the capacity to pay for review, testing, and security response. Requirements gathering aligns contributors around a shared roadmap rather than a scatter of individual interests. None of these tasks are solved by better models alone. They require sustained human coordination and, in many cases, money.

Most institutions, the authors write, face perhaps their largest challenge in learning the governance, maintenance, and security state of their software, so they can spot critical dependencies before something fails. That challenge is both technical and organizational. It involves asking vendors for SBOMs, tracking the health of upstream projects, funding maintainers, and building internal processes for rapid patching. AI may accelerate parts of that work, but it also raises the stakes. The more code that is generated, the more review, maintenance, and governance capacity is needed to keep the software that the world depends on from becoming a liability. The task is to spot critical dependencies before something fails.

Source:Help Net Security News