Artificial intelligence is changing the economics and workload of open-source software maintenance. AI coding tools can generate code, suggest patches and uncover security flaws at speed. But the people who decide what enters a project's official release still have to evaluate that output themselves. The result is a new layer of review work on projects that are often volunteer-run, thinly funded and deeply embedded in the world's digital infrastructure.

That burden is not confined to developers. Open-source components sit inside smartphones, automobiles, cloud platforms, industrial systems and AI services. When maintainers fall behind, the effects can reach any organization that depends on that code. A business-school study cited by technology policy researchers estimated that firms would spend 3.5 times more on software without open-source components. The savings are real, but they also create a collective obligation that many users never pay for directly.

Key facts at a glance

• AI coding tools increase the volume of code and security findings that human maintainers must review.
• Open-source code underpins phones, cars, cloud systems and AI platforms, so maintenance gaps can affect nearly every software user.
• Many projects lack reliable revenue, and deferred maintenance can leave security holes in downstream products.
• Attackers are planting malicious packages and code in popular repositories while AI helps defenders find and patch flaws faster.
• Funding is heavily concentrated: one large foundation reported about 292 million dollars in 2024 revenue, while a volunteer-heavy foundation reported about 2.4 million dollars.
• Most open-source applications do not generate or ship a software bill of materials, despite US and EU mandates.
• Ecosystem-wide data on AI effects remains hard to collect because open source is governed project by project.

AI adds volume, not judgment

Most open-source projects accept contributions from outside their core teams. They typically rely on a vetted group of trusted contributors to decide what gets committed into the official codebase. AI has made it easier for anyone to write and submit code, and some of what arrives is poor. Researchers acknowledge that quality may improve as models improve, but a human still has to assess the added volume. That assessment is not a formality. Reviewers must check whether a change is correct, secure, compatible with the project's architecture and consistent with its long-term direction.

The review problem is cumulative. A single AI-assisted patch may look small, but thousands of small patches can overwhelm a project that has only a handful of active maintainers. Each contribution can arrive with tests, documentation, dependency changes and security implications. Maintainers must also consider licensing, provenance and whether the contributor understands the project's conventions. AI can reduce the cost of producing code, but it does not reduce the cost of accepting responsibility for it. The human review step remains the control point where quality and trust are either preserved or lost.

This is especially difficult for projects that already operate close to their limits. Many maintainers work on critical libraries in their spare time, with little or no funding. They may be the only person who understands a particular subsystem. When AI-generated pull requests, bug reports and security alerts arrive faster than they can be triaged, the risk is not simply slower progress. The risk is that important fixes and questionable changes compete for the same limited attention.

The security paradox: faster fixes, faster attacks

AI is not only adding to the review queue. It is also changing the speed at which security work happens. Automated agents can scan large codebases and propose fixes for known classes of vulnerabilities. Between April and October 2025, one major technology company reported that its CodeMender agent contributed 72 security fixes to open-source projects, including some projects as large as 4.5 million lines of code. That kind of output can be valuable, particularly for projects that lack dedicated security staff.

But the same capabilities can be turned toward attack. Models that find and patch flaws can also be used to identify weaknesses and build exploits. The researchers doubt that restricting top security models to trusted users will solve the problem, because general-purpose models keep getting stronger. Capabilities that are restricted today may become widely available tomorrow through open models or commercial services. The defensive advantage is therefore temporary unless projects have the capacity to review, test and deploy fixes quickly.

The scale of open source makes the consequences of a single flaw unusually large. So much of the world runs the same code that a vulnerability in a popular library can affect thousands of products at once. Attackers have noticed. A growing number of incidents involve malicious packages and code planted in popular repositories, sometimes through compromised accounts or social engineering. AI can help attackers generate convincing contributions, identify promising targets and automate parts of the exploitation process. Defenders can use similar tools, but they still need people to make decisions under uncertainty.

Patching is also harder than it looks. When a flaw is found in one open-source component, every application built from that component may need its own update, rebuild and release. Organizations that depend on many components must coordinate patches in sequence. A fix in a low-level library can force changes in middleware, container images and internal applications. AI can shorten the time needed to identify a flaw, but it cannot remove the operational complexity of updating a distributed software supply chain.

The funding gap is lopsided

The money behind open source is unevenly distributed. The Linux Foundation reported 292,217,236 dollars in revenue for 2024. The Apache Software Foundation, which researchers cite as an example of projects that run on volunteer labor and sponsorships, reported 2,379,402 dollars, less than 1 percent of that total. Those figures do not capture every project or every funding model, but they illustrate a broader pattern. A small number of large foundations and corporate-backed projects attract substantial resources, while many critical components rely on donations, grants or unpaid work.

Across open source, most users never pay. This is often described as the free-rider problem. Companies build products on open-source libraries, sell those products and generate revenue, yet the maintainers of the underlying components may receive nothing. The imbalance is not merely unfair. It is a security and resilience problem. When a project cannot fund documentation, testing, release engineering or security response, the entire ecosystem inherits the risk.

Funding also affects the kind of work that gets done. Donors and sponsors often prefer visible features or new capabilities over maintenance. But maintenance is where security patches, compatibility fixes and dependency updates happen. Deferred maintenance can stay invisible for years, until a vulnerability or a breaking change forces attention. By then, the maintainer may be exhausted, the original contributors may have moved on, and the project may lack the institutional knowledge needed to respond quickly.

SBOMs reveal components, not health

A software bill of materials, or SBOM, is a machine-readable list of the components inside an application. It can help organizations understand what libraries and dependencies they are running. Despite US and EU mandates, the vast majority of open-source applications do not generate or ship one. Even when an SBOM exists, it has limits. It would show what is present, not whether each piece is maintained, funded, secure or abandoned.

That distinction matters. An SBOM can tell a security team that a product includes a particular version of a library. It cannot tell them whether the maintainer has time to review a patch, whether the project has a security response process, or whether the last release was tested against current threats. Dependency visibility is a starting point, not a complete risk assessment. Organizations need to combine SBOM data with information about project health, governance and funding.

The lack of SBOM adoption also complicates incident response. When a new vulnerability is announced, affected organizations need to know quickly whether they use the component and where it appears. Without a reliable inventory, teams must search manually across repositories, build systems and production environments. That delay can be costly. It can also lead to over-patching or under-patching, as teams struggle to distinguish critical dependencies from incidental ones.

Governance remains human and project-by-project

Open source is governed project by project. There is no central authority that can collect ecosystem-wide numbers on AI effects or mandate a single response. That makes it difficult to measure how much AI-generated code is entering projects, how often it is reviewed and what proportion of security alerts come from automated tools. The fragmentation is a strength in some ways, because it allows projects to experiment with different models. It is a weakness when the ecosystem needs coordinated action.

The researchers argue that projects should put more resources into documentation, packaging, fundraising and gathering requirements. These areas are less glamorous than writing new features, but they determine whether a project can absorb contributions and respond to security issues. Deciding what a project needs and getting its community to agree still falls to people. AI can draft documentation or summarize issues, but it cannot build consensus or take responsibility for a release.

For institutions, the challenge is even broader. Many organizations do not have a clear picture of the governance, maintenance and security state of the software they depend on. They may know which vendors they pay, but not which open-source projects sit beneath those vendors' products. Learning that state is perhaps the largest challenge they face, because it requires tracing dependencies, assessing project health and identifying critical components before something fails.

Practical pressure points for maintainers and users

Maintainers can reduce some of the review burden by setting clear contribution rules, requiring tests and provenance information, and using automation to screen for obvious problems. But automation cannot replace judgment. Projects still need trusted reviewers who understand the code and can say no. They also need sustainable funding to pay for that review time, especially when AI increases the volume of submissions.

Users of open source can help by treating critical dependencies as infrastructure rather than free resources. That means funding projects that matter, participating in governance, demanding SBOMs from vendors and asking whether the components inside a product are maintained. It also means recognizing that security is not a one-time purchase. It is an ongoing process of review, patching and coordination.

The pressure is likely to grow as AI tools become more capable and more widely available. Faster code generation and faster vulnerability discovery will not automatically produce a healthier ecosystem. They will produce more decisions for humans to make. The projects that can fund, document and govern those decisions will be better positioned to absorb the change. The projects that cannot will remain exposed, and so will everyone who runs their code.

Source:Help Net Security News