The Maintainers Are Leaving: What the AI Slop Flood Means for the 93% of Your Codebase You Didn't Write

The Week the Bug Bounty Died

On 21 January 2026, Daniel Stenberg shut down curl's bug bounty programme after six years and roughly $86,000 in payouts. The trigger was seven submissions arriving inside a sixteen-hour window. Some described real bugs. None described an actual vulnerability. Each one still had to be read, reproduced, reasoned about and refuted by a human being who understands curl's threat model, which is a very short list of human beings. Stenberg's stated goal was blunt: to 'remove the incentive for people to submit crap and non-well researched reports to us. AI generated or not.'

This was not a sudden decision. Stenberg had been documenting the trend since 2024, and in July 2025 published 'Death by a thousand slops', reporting that roughly 20% of all 2025 submissions were AI slop and that only about 5% of submissions that year turned out to be genuine vulnerabilities, a valid-rate that had fallen sharply from previous years. The title is the argument: no single report is fatal, but the aggregate consumes the maintainer until there is nothing left to consume.

curl was not an outlier, it was the loudest case in a pattern. RedMonk's Kate Holterhoff catalogued the wave under the name 'AI Slopageddon'. In late January 2026 Mitchell Hashimoto merged a new contribution policy for Ghostty: AI-assisted pull requests are permitted only against pre-approved issues, drive-by AI PRs are closed without discussion, and repeat offenders are banned from all future contributions. His reasoning names the mechanism precisely, that agentic programming 'has eliminated the natural effort-based backpressure that previously limited low-effort contributions.' He was careful to add that this is 'not an anti-AI stance. This is an anti-idiot stance... We just want quality contributions, regardless of how they are made.' Ghostty itself is written with substantial AI assistance.

Steve Ruiz of tldraw went further and now auto-closes all external pull requests, after receiving seven nonsensical security advisories in a single day in January 2026. Gentoo Linux banned AI-generated contributions outright back in April 2024. NetBSD classifies LLM-generated code as 'tainted' and requires core team approval to accept it. Flathub extended a blanket AI submission ban across Flatpak repositories in May 2026. Craig McLuckie, co-founder of Stacklok, described the newest failure mode: a 'good first issue' label now attracts low-quality vibe-coded submissions within twenty-four hours, which is to say the on-ramp built specifically to grow new maintainers has become a channel for consuming the existing ones.

If you run an engineering organisation, the instinct is to file this under community drama. It is not. It is a supplier notice.

Why Slop Arrives Faster Than It Can Be Rejected

The economics here are worth stating plainly, because they explain why this will not self-correct. Generating a plausible-looking patch or vulnerability report is now close to free. Refuting one is not, and cannot be made so.

A reviewer evaluating an AI-generated contribution has to do the harder half of the work. The code is idiomatic, consistently named and stylistically indistinguishable from the surrounding codebase, because that is precisely what language models are good at. The failures, when they exist, are structural and semantic: a plausible fix to a bug that does not exist, a security advisory describing a code path that was removed in 2019, a refactor that quietly changes behaviour under concurrency. Catching that requires reconstructing the intent, which takes longer than scanning for obvious errors and cannot be delegated to whoever has spare time.

An academic study published in 2026, 'An Endless Stream of AI Slop', coded 1,154 Reddit and Hacker News posts about the phenomenon and found the largest thematic cluster was structural drivers, at 26.2% of coded posts, followed by AI limitations and mitigation strategies. The developers in that corpus describe workload asymmetry in almost identical language: 'development time has been shortened but the team now needs to spend more time to review.' One team in the dataset reported thirty pull requests arriving daily across six reviewers.

Stenberg's own numbers make the curve visible. He received 2 AI-generated submissions in 2023 and 37 in 2025. That is not a doubling, it is a regime change, and it happened while the number of people qualified to triage curl security reports stayed at roughly the same very small integer.

The uncomfortable part is that most of this volume is not malicious. It comes from people who genuinely want to contribute, who ran an agent against an issue tracker, who did not read the output carefully because reading it carefully was the expensive part they were trying to avoid, and who are individually reasonable actors producing a collectively unsurvivable load. There is no bad guy to ban. That is what makes the defensive measures so drastic.

The 93 Percent of Your Codebase You Did Not Write

Here is where this stops being someone else's community problem. Black Duck's 2026 Open Source Security and Risk Analysis, based on audits of 947 commercial codebases across 17 industries, reports that the mean number of open source vulnerabilities per codebase rose 107% year over year to 581. Not 107% more codebases affected, 107% more vulnerabilities in each one, on average, in a single year.

The composition data explains how. Mean files per codebase grew 74% year over year and average open source component count grew 30%, which is what happens when generation capacity increases and nothing downstream does. 87% of audited codebases contained at least one vulnerability, 78% contained high-risk vulnerabilities and 44% contained critical-risk issues. Separately, 17% of open source components enter codebases outside standard package managers, meaning they are invisible to the dependency scanner you believe is covering you.

Then the maintenance picture. 93% of codebases contained components with no development activity for at least two years. 92% contained components four or more years out of date. Only 7% of components across all audited codebases were running the latest version, and 41% were at least ten versions behind. License conflicts appeared in 68% of codebases, up from 56% the year before, with one codebase carrying 2,675 distinct conflicts, a problem that compounds with everything we have written about license contamination in AI-generated code.

Put the two stories side by side. The volume of code entering your product is rising steeply. The proportion of it that comes from projects with an active maintainer is falling. And the people who maintain the still-active projects are, right now, publicly explaining why they are reducing their exposure to inbound contributions. Every one of those defensive policies is rational for the maintainer and slightly worse for you, because your future upstream fix now has to travel through a narrower door.

LeadDev's analysis of what it calls AI-generated abandonware adds the supply-side half: GitHub added 36 million new developers in a year, with roughly 230 repositories created every minute and 80% of new GitHub developers using Copilot within their first week. The barrier to shipping a package collapsed. The barrier to maintaining one for five years did not move at all. The predictable result is a dependency graph that keeps getting wider and shallower.

The Doors Are Closing, and That Is Your Problem Too

Most enterprise dependency strategies contain an unwritten assumption: if we hit a blocking bug or a CVE in a dependency, we can either wait for the maintainer or send a patch upstream. Both halves of that assumption are now weaker than they were eighteen months ago.

Waiting for the maintainer assumes there is one, and that they have capacity that is not being consumed by triage. Sending a patch upstream assumes the project still accepts external patches. tldraw does not. Ghostty accepts them only against pre-approved issues, which means your engineer must first win an issue conversation before writing code. NetBSD requires core team sign-off for anything LLM-assisted, and if your engineers use AI tooling daily, as roughly 85% of organisations now do according to the same OSSRA data, then declaring provenance honestly puts your patch in the slow lane by default.

There is a second-order effect that is easy to miss. When maintainers cannot distinguish good contributions from generated ones at a glance, they apply the filter they can afford, which is reputation. Contributions from known names get read. Contributions from an unfamiliar corporate email attached to a 400-line diff get closed. Your organisation's ability to influence its own dependencies is becoming a function of standing relationships that most companies never invested in building, because open source felt like a vending machine rather than a community.

The Open Source Security Foundation's vulnerability disclosures working group has an open effort to define best current practices for maintainers facing AI slop, and several foundations have adopted provenance labelling, the Apache Software Foundation with 'Generated-by:' commit tags, the Eclipse Foundation with heightened scrutiny requirements, OpenInfra with 'Generated-By:' and 'Assisted-By:' trailers. These are useful. None of them adds review capacity, which is the actual scarce resource.

The timing is uncomfortable for European product companies specifically. The EU Cyber Resilience Act reporting obligations arrive in September 2026, and they require manufacturers to know and manage the security posture of the components in their products, including third-party open source. An SBOM listing a package whose last commit was in 2023 and whose maintainer publicly stopped accepting contributions in 2026 is not a compliance artefact, it is a documented liability with a date stamp on it.

The Money Loop Is Breaking at the Same Time

If the review load were the only problem, funding would fix it. The harder issue is that the same technology shift is quietly cutting off the revenue and attention that kept maintainers going in the first place.

Tailwind CSS is the cleanest documented case. Its creator Adam Wathan reported documentation traffic down roughly 40% and revenue down almost 80% since early 2023. Nothing about the library got worse. What changed is that developers now ask a model instead of reading the docs, and the model does not click through to the paid components product that funded the free library. Stack Overflow activity fell 25% within six months of ChatGPT's release, by the same mechanism operating at ecosystem scale.

This is the part that deserves attention from anyone doing vendor risk. The interaction surfaces where open source projects convert usage into money, documentation pageviews, sponsorship banners, course sales, support contracts, consulting leads, are exactly the surfaces AI assistants route around. Usage of the underlying software keeps rising. The economic signal it generates falls. Maintainers experience this as more users, more issues, more security expectations and less money, simultaneously.

Tidelift's maintainer research has been documenting the baseline for years: 60% of maintainers are unpaid volunteers, 60% have quit or considered quitting their projects, half say they are not paid enough and 48% report feeling unappreciated. The same research found paid maintainers are 55% more likely to implement critical security and maintenance practices such as those in the OpenSSF Scorecard and the NIST SSDF. That last finding is the one to take to a budget conversation: maintainer funding is not charity, it is a measurable input to the security posture of software you ship.

Deb Nicholson and Loren Crary's framing, echoed by the Python Software Foundation's Seth Larson, is the summary most engineering leaders should internalise: wasting volunteer time on work they do not love is the most reliable way to burn out a maintainer. The projects at risk are rarely the famous ones with foundations behind them. They are the single-maintainer utility packages sitting four levels deep in your dependency tree that nobody at your company can name.

You Are Running the Same Experiment Inside Your Own Repo

It is tempting to read all of this as a story about volunteers, which conveniently makes it someone else's operating problem. It is not. Your internal pull request queue is the same system with a payroll attached, and the payroll only changes how long you can absorb the load before the symptoms appear.

Faros AI's 2026 report, drawn from telemetry across 22,000 developers and around 4,000 teams, found median time in code review up 441.5% and median time to first review up 156.6%. Task completion rose 34% and epics completed per developer rose 66%, so the output gains are real. So are the countervailing numbers: bugs per developer up 54%, incidents per pull request up 242.7%, code churn up 861%. The single most revealing figure in the set is that 31.3% more pull requests merged with no review at all. That is what a saturated review system looks like from the inside. It does not announce itself. It quietly stops reviewing.

The internal version of Ghostty's policy question therefore arrives whether you plan for it or not. Who is allowed to open a large AI-assisted pull request, against what kind of pre-agreed issue, with what obligation to explain the change in their own words? Teams that answered that question early tend to have a lightweight, unglamorous rule: the author must be able to defend the diff in review without referring to the tool, and PRs above a size threshold need a linked design note. Teams that have not answered it are discovering the same asymmetry the maintainers hit, just with better funding and worse visibility.

This connects directly to two failure modes we have written about before. The first is comprehension debt, the growing volume of merged code that nobody on the team can explain. The second is the verification capacity gap, where change volume roughly doubled while the function responsible for checking it was restructured downward. AI slop in open source is the same equation playing out in a system with no payroll to cushion it, which is why it broke first and in public. It is a preview, not a parable.

A Dependency Policy That Survives 2026

The practical response is not to reduce open source usage, which is neither possible nor desirable, and it is not to buy another scanner, which tells you about known CVEs in components you already knew you had. It is to start treating maintainer health as a first-class attribute of a dependency, alongside licence and version.

Start with a maintainer health inventory over your top dependencies by blast radius, not by count. For each one, record four things you can pull from public data: bus factor, meaning how many people merged a commit in the last twelve months; release cadence over the past two years; whether the project has any funding mechanism at all; and whether it has changed its contribution policy recently. That last field is new and it is the leading indicator. A project that just closed external PRs or ended a disclosure programme has told you, in public, that its capacity to respond to your future problem has fallen.

Second, decide in advance what you do about the components with a bus factor of one. There are only four honest options: fund the maintainer, adopt co-maintenance and put an engineer's name on it, vendor the dependency and accept that you now own it, or replace it. Doing nothing is a fifth option that many organisations select by default and describe afterwards as an unforeseeable incident. The XZ Utils backdoor demonstrated what the tail of that distribution looks like when a burnt-out solo maintainer is offered help by a patient stranger.

Third, fund selectively and deliberately. Given the finding that paid maintainers are 55% more likely to implement critical security practices, a five-figure annual allocation across the twenty projects that actually carry your product is one of the better-priced risk reductions available to an engineering organisation, and it converts your company from an anonymous consumer into a known counterparty whose patches get read.

Fourth, make provenance and SBOM work continuous rather than annual. With 17% of components arriving outside package managers and CRA reporting obligations landing in September 2026, a build-time generated SBOM with a component-age and maintainer-activity check in CI is worth more than a spreadsheet refreshed before an audit. The same pipeline should flag components that have gone quiet since the last release, which is the check almost nobody runs.

Fifth, set the internal contribution rules before you need them: disclosure of AI assistance in PR descriptions, a size threshold above which a design note is required, an author-must-explain-it standard in review, and a stated upstream-first policy with actual budgeted hours. That last one matters more than it sounds. An upstream-first policy with no allocated time is a preference, not a policy, and it collapses the first time a sprint is tight.

Who Actually Does This Work

Every item on that list is real engineering work, none of it ships a feature, and all of it loses the prioritisation argument in any given sprint. That is not a failure of will. It is a structural property of work that is continuous, context-heavy and invisible until the quarter it becomes an incident.

It also has a specific shape that determines who can do it well. It is continuous rather than project-bounded, because dependency graphs drift the moment nobody watches them and a maintainer can go quiet in any month. It requires deep context on your particular stack and history, so it decomposes badly into a fixed-scope engagement handed to people who have never seen your build. And it demands seniority, because deciding whether to fund, fork or replace an unmaintained component is a judgment about how your system fails under a specific class of pressure, and no checklist answers that.

Continuous, context-heavy and senior is precisely the profile a dedicated development team handles well and a project-based vendor handles badly. Stepto has run senior-led engineering teams out of Serbia since 2014, and this category of work, supply chain and platform hygiene that runs alongside product delivery rather than competing with it, is one of the more common reasons clients extend a team rather than close an engagement. A standing team can own the dependency inventory, absorb the CRA evidence work as it lands, maintain the internal fork you took two years ago, and carry the upstream relationships that determine whether your patch gets read, none of which survives being re-scoped every quarter.

Timezone overlap matters here for a reason specific to this domain: dependency decisions are usually made under time pressure during a disclosure window. When a CVE lands in a component you rely on and the upstream project is not going to fix it quickly, the useful conversation happens within hours, not on the next handover. For European and UK clients a nearshore team participates in that window; an offshore team receives its conclusions afterwards. We have written before about how that gap gets priced into quotes without ever being named, and incident-driven supply chain work is one of the clearest cases of it.

There is also a due diligence dimension worth flagging for anyone raising or selling. Acquirers have started looking at dependency maintenance status alongside code provenance, and 'we depend on nine unmaintained packages, one of which is a fork we made and never upstreamed' is a finding that moves price. It belongs in the same conversation as technical due diligence on AI-generated code, and it is far cheaper to fix eighteen months before a data room than during one.

The Next Ninety Days

If this describes your situation, sequencing matters more than any individual tactic, because the first step produces the evidence that funds the rest.

Week one to two: generate a real dependency inventory ranked by blast radius rather than alphabetically, and annotate the top fifty with last-commit date, contributor count over twelve months, and whether the project has changed its contribution policy in the last year. Most teams find between five and fifteen components that fail all three checks. Writing that number down is what unlocks the budget for everything after it.

Week three to six: pick the bus-factor-one components on the critical path and make an explicit call on each, fund, co-maintain, vendor or replace. Ship the CI checks at the same time, component age, maintainer activity, and SBOM generation at build time rather than on request. This is also the point to publish the internal AI contribution policy, because it costs nothing and it stops the internal version of the problem from compounding while you fix the external one.

Week seven to twelve: do the CRA evidence work against the inventory you now trust, upstream any long-lived internal forks that can be upstreamed, and set the funding allocation for the following year. Then put a recurring quarterly review on the calendar with a named owner, because the entire failure mode described in this article is what happens to work that has no owner between crises.

What not to do first: do not start by replacing dependencies. It is the most expensive move, it consumes a quarter, and teams that swap components before understanding their maintenance profile routinely trade a quiet unmaintained package for a fashionable one that gets abandoned eighteen months later. The problem is almost never which library you picked. It is that nobody was watching what happened to it afterwards.