In January 2026, Daniel Stenberg, the creator of curl, closed the curl bug bounty on HackerOne. The same month, Mitchell Hashimoto declared that drive-by AI-generated PRs to the terminal emulator Ghostty would be closed without question. Steve Ruiz of tldraw flipped his repository to auto-close all external pull requests. And Jazzband, the collaborative maintenance organization behind 84 Python projects, announced it was shutting down entirely.

The catalyst across all of these was “AI slop”: plausible-looking but unverified PRs, issues, and vulnerability reports produced by generative AI tools. Coding agents have inverted the review economy (generation now takes seconds while debunking takes hours), and the “open contribution” model that sustained OSS for decades is straining at the seams.

This post walks through the primary sources from late 2024 through mid-2026 (maintainer blogs, repository commits, AI-policy documents, mailing-list debates), and then groups the responses into three policy families: outright bans, human-in-the-loop, and structural closure. The goal is a working catalogue any team running an OSS project can use to find the right precedent.

AI Slop and the Asymmetry of Maintenance Cost

The term “AI slop” was popularized by Simon Willison and others starting in 2024, to describe low-quality content produced by generative AI. In the OSS context it covers PRs the submitter never validated, bug reports citing hallucinated APIs, and vulnerability reports dressed up with tests and documentation that make plausible nonsense look authoritative.

The first systematic write-up of the problem came from Seth Larson, the Python Software Foundation Security Developer-in-Residence, in his December 2024 blog post “New era of slop security reports for open source”, based on his triage work for CPython, pip, urllib3, and Requests.

The core problem is the asymmetry between the cost of producing a contribution and the cost of reviewing it.

Metric	Old model	AI-driven model	Governance impact
Generation cost	Hours to days	Seconds, one prompt	Loss of natural quality filter
Review cost	Moderate (context-dependent)	Very high (adversarial verification needed)	Maintainer burnout
Surface correctness	Correlated with value	Decoupled from value	Distrust of “clean-looking” code
Intent	Tied to a concrete need	Opaque (rep-farming, automation)	Surge in unwanted feature requests

LangChain’s contributing guide frames the dynamic directly: “Mass automated contributions represent a denial-of-service attack on our human effort.”

As Stenberg framed it in “Death by a thousand slops”, maintainers need to “reduce the amount of sand in the machine,” and whether the noise originates from a human or an AI, “the net effect is the same.”

Three Policy Families

The policies published from late 2024 through mid-2026 fall into three broad families.

flowchart LR
    A[AI Slop response]
    A --> B[Outright ban]
    A --> C[Human-in-the-loop]
    A --> D[Structural closure]

    B --> B1[NetBSD]
    B --> B2[Gentoo]
    B --> B3[QEMU]
    B --> B4[Zig / GIMP]
    B --> B5[Cloud Hypervisor]

    C --> C1[Linux Kernel]
    C --> C2[LLVM]
    C --> C3[Fedora]
    C --> C4[WordPress]
    C --> C5[Django security.txt]
    C --> C6[MicroPython]
    C --> C7[Mastodon]
    C --> C8[EFF]

    D --> D1[curl — bounty shutdown]
    D --> D2[Ghostty — vouch system]
    D --> D3[tldraw — external PR auto-close]
    D --> D4[Jazzband — sunset]
    D --> D5[GitHub — PR controls]

• Outright ban. Declares that AI-generated content cannot be committed at all, typically grounded in DCO (Developer Certificate of Origin) or licensing arguments. NetBSD, Gentoo, QEMU, Zig, and GIMP sit here.
• Human-in-the-loop. Allows AI assistance but requires disclosure, human accountability, and limits on where AI may be used (e.g. not on Good First Issues). The Linux kernel, LLVM, Fedora, WordPress, Mastodon, and the EFF follow this pattern.
• Structural closure. Closes inbound channels themselves rather than writing more policy. curl’s bounty shutdown, Ghostty’s vouch system, tldraw’s external-PR auto-close, and Jazzband’s sunset all fall into this category.

The rest of the post walks the representative cases.

curl — Closing the Bug Bounty as a Signal-to-Noise Problem

curl ships on tens of billions of installations and ran its HackerOne bug bounty from 2019. In Stenberg’s January 26, 2026 post “The end of the curl bug-bounty”, he reports 87 confirmed vulnerabilities and over $100,000 paid out over six years.

The economics collapsed in 2025. Stenberg’s October 2024 stats post showed roughly 1-in-6 reports clearing as a valid CVE (~15%). Through 2025, AI-fabricated reports flooded the queue and the valid rate dropped below 5%. The signal-to-noise ratio continued to deteriorate into 2026: the early-month intake was almost entirely AI-derived, with virtually no submissions that could be confidently classified as human-authored.

The submissions look professional: a “Buffer Overflow Vulnerability in WebSocket Handling” against a function curl deleted a decade ago, a “format string vulnerability” in a function named curl_mfprintf that does not exist, an HTTP/3 “stream dependency cycle exploit” referencing fictional internals. Each one demands hours of expert time to read, reproduce-or-not, and rebut.

On February 1, 2026, at the FOSDEM 2026 closing keynote “Open Source Security in spite of AI”, Stenberg laid out the new policy to a full Janson auditorium. The updated BUG-BOUNTY.md states: “The curl project does not offer any rewards for reported bugs or vulnerabilities.” The accompanying .well-known/security.txt goes further: “We will ban you and ridicule you in public if you waste our time on crap reports.” All reports now go through GitHub Private Vulnerability Reporting.

Stenberg’s April 2026 follow-up “High-Quality Chaos” reports that after the bounty shutdown and a return to HackerOne on a reputation-based footing, the slop situation settled visibly. Separately, Stenberg has often pointed to a counterpoint that disambiguates AI itself from the slop problem: Joshua Rogers’ collaboration with ZeroPath, summarized in Stenberg’s October 2025 post “A new breed of analyzers”, surfaced over 100 real curl bugs that fuzzers and static analyzers had missed. The problem is not AI itself; it is the unverified output of humans hoping to game a bounty.

Ghostty — Vouching and the Public Denouncement List

Ghostty is HashiCorp co-founder Mitchell Hashimoto’s Zig-based terminal emulator. Hashimoto uses AI heavily in his own work, which makes Ghostty’s stance against AI slop all the more striking.

The policy hardened in three steps.

1. August 19, 2025: PR #8289 introduced a disclosure requirement: every AI-assisted PR must declare it. Hashimoto’s stated reasoning was that AI tends to produce slop, that inexperienced contributors increasingly ship code they have not reviewed, and that disclosure helps maintainers calibrate review effort.
2. January 22, 2026: A standalone AI_POLICY.md replaced the simple disclosure rule. The commit message noted that agentic programming had eliminated the natural friction of effort that used to filter contributions, and that the bad-PR count had risen roughly 10x or more. The new policy bans drive-by AI PRs that aren’t tied to an accepted issue, prohibits AI-generated media, and reserves the right to permanently block contributors who submit unverified AI output.
3. February 15, 2026: CONTRIBUTING.md and the discussion templates added a Vouch Request system. First-time contributors must open a Vouch Request discussion “in your own words, not written by AI” before they can submit a PR. Unvouched PRs are closed automatically. Repeat offenders land on the Public Denouncement List, a public register that other projects can reference, with bot-driven closures of any future submission.

Hashimoto’s framing in AI_POLICY.md explicitly rejects an anti-AI position. The line Ghostty draws is around contributors who outsource their thinking to a model and then make maintainers do the verification.

In April 2026 Hashimoto followed up with “Ghostty Is Leaving GitHub”, pulling the project off GitHub entirely. The stated reason was infrastructure instability (repeated GitHub Actions outages and platform downtime), and the post itself does not call out AI moderation controls, though the timing follows on from his earlier writing about how little GitHub gives maintainers to filter AI noise. He is separately experimenting with Vouch, a web-of-trust tool that requires existing maintainers to vouch for new contributors before they can interact.

tldraw — “Stay Away From My Trash”

tldraw is a React-based whiteboard SDK. On January 15, 2026, founder Steve Ruiz filed Issue #7695 announcing that external pull requests would be auto-closed by default. Two days later, on January 17, he elaborated in the blog post “Stay away from my trash!”.

Ruiz’s observation cut to the heart of the loop. He noticed that the rough draft issues his own Claude Code /issue command had been auto-generating and posting to GitHub (his own “trash”) were being fed back into AI tools by external contributors, who then submitted plausible-looking but misdirected PRs in response (his trash returned as “poison”). He called the cycle “AI slop all the way down.”

The question Ruiz puts directly is the one every maintainer is asking quietly: “If writing code is now the easiest part of the process, why should I have someone else do it for me?” Issue #7695 drew hundreds of positive reactions, and community support was, on balance, with him.

tldraw’s pattern is structurally simpler than Ghostty’s. There is no detailed policy. Issues, bug reports, and Discussions remain open; the PR funnel is narrowed. The point of the narrowing is to protect the meaning of “an open PR queue” so that the queue can still be reviewed seriously.

Linux Kernel — Only Humans Sign the DCO

After months of LKML debate, the Linux kernel adopted a formal “Coding assistants and Linux kernel development” policy in 2026. The background was a series of incidents where undisclosed LLM-generated patches landed and shipped regressions, combined with an ongoing mailing-list push to make AI involvement visible through explicit trailers such as Co-developed-by: and Generated-by:.

The final policy:

• AI assistance is allowed.
• AI agents must not add Signed-off-by:. The DCO is reserved for humans.
• Any AI involvement is declared via an Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] trailer.
• The human submitter owns the license, correctness, and review obligations end-to-end.

Linus Torvalds’ position, expressed repeatedly on LKML in January 2026 (covered by The Register), was that AI should be treated as “just another tool” and that the documentation “is for good actors”—AI slop submitters don’t read the policy anyway. The kernel bets instead on human accountability. This has become the de facto template for human-in-the-loop policies elsewhere.

LLVM — No AI on Good First Issues

LLVM shipped its “AI Tool Policy” in early 2026 (commit 18695b27d565). The stated rationale: “Over the course of 2025, we observed an increase in the volume of LLM-assisted nuisance contributions to the project.”

Two parts of the policy stand out. The first prohibits AI agents that publish PRs without human approval (the explicit target is GitHub’s @claude and similar autonomous-PR bots). The second is the ban on AI use for Good First Issues. The reasoning is that Good First Issues are educational assets for the next generation of human contributors, and letting AI clear them strips out the apprentice path that keeps the project culturally sustainable. Drupal makes a parallel argument in its “Proposed guidelines for AI contribution”.

Fedora and WordPress — Disclosure-First Regimes

The Fedora Council ratified its “Policy on AI-Assisted Contributions” in October 2025. Three pillars:

1. Accountability: you can use AI, but you own the output.
2. Transparency: when substantial AI-generated content is taken unchanged, declare it via an Assisted-by: trailer.
3. Limited Review: AI may assist reviewers, but cannot be the final arbiter.

The policy explicitly forbids AI for human-judgment tasks: Code of Conduct evaluations, funding-request scoring, conference-talk selection.

WordPress followed in 2026 with its “AI Guidelines”. Five principles (human responsibility, disclosure of meaningful AI use, GPL-compatible ToS for AI tools, coverage of non-code assets, and “quality over volume”), plus an explicit clause that maintainers may close work that “appears to be AI slop.”

Django shipped a tighter, security-focused version. After a wave of LLM-fabricated CVE submissions citing nonexistent Django APIs, security lead Natalia Bidart updated docs/internals/security.txt in late 2025. Reporters must disclose AI use and verify reproducibility; unverified AI output “will be closed without response.” Bidart noted on Mastodon: “Never thought I’d be writing official docs for a major open source project begging LLMs to stop fabricating surreal vulnerabilities” (covered by Socket).

NetBSD, Gentoo, QEMU, Zig — The Ban Camp

Several projects took the licensing argument to its logical end and disallowed AI-generated content outright.

• NetBSD (May 2024): Updated commit guidelines declare LLM-generated code “presumed to be tainted code” that must not be committed without prior written core approval. The license compatibility of BSD code and LLMs trained on GPL or Stack Overflow content is the central concern.
• Gentoo (April 2024): Council motion forbidding “any content that has been created with the assistance of Natural Language Processing artificial intelligence tools,” including code, docs, bug reports, and forum posts.
• QEMU (June 2025): docs/devel/code-provenance.rst (commit 3d40db0 by Daniel P. Berrangé) declares: “Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content.” The argument is that DCO clauses (b) and (c) cannot be honored for AI output.
• Zig: Hard ban on LLM use in issues and PRs in the contributor guide. The most aggressive position among modern languages.
• Cloud Hypervisor (September 2025, v48): A Linux Foundation–hosted project that formally restricts AI-generated submissions on license-compliance grounds.

The honest read on these bans is that they are cultural signals more than technical enforcement. No one has a reliable way to prove AI authorship after the fact. What the policies do is raise the social and reputational cost of submitting AI slop, and force a public conversation about training-data licensing that platforms like the Linux Foundation have otherwise sidestepped.

Mid-Sized Projects — NewPipe, typescript-eslint, and llama.cpp

Below the headline cases, a quieter pattern is emerging across mid-sized projects: short policy notes, AI checkboxes in templates, and frequent iteration as gaps surface.

NewPipe — An AI Checkbox in Every Template

NewPipe (about 38K stars) updated CONTRIBUTING.md, issue, feature-request, and PR templates in a single commit on December 16, 2025 (097c643). The commit message is blunt: “The amount of AI generated PRs is increasing while their quality often remains poor.”

Rather than a blanket ban, the policy draws lines per workflow stage. Significant AI involvement in new features or large refactors is prohibited; small bug fixes are conditionally allowed if the author understands the root cause; documentation generation is permitted but must clear human review; filling out issue or PR templates with AI text is explicitly forbidden. Bug reports and feature requests added an “I did not generate this content with AI” checkbox.

typescript-eslint — Protecting Maintainer Bandwidth

typescript-eslint (about 16K stars) added a standalone AI_Contribution_Policy.mdx on January 20, 2026. The opening framing is direct: AI-assisted coding tools make it easy to generate a flood of low-quality contributions, and reading, reviewing, and corresponding about them in good faith consumes far more maintainer bandwidth than traditional contributions.

The policy is explicit that it “cannot and will not attempt to ban contributions which make use of AI.” Instead it requires that:

• AI-generated code is reviewed rigorously by the author.
• AI is used only within what the author can understand, fix, and defend on their own.
• Issue and PR templates are filled out properly.
• Non-code prose (PR descriptions, issue bodies, comments) avoids AI-generated text.

The note on PR descriptions is particularly sharp: AI-written PR descriptions tend to paraphrase the diff and “add no value to maintainers”; if a description needs to be auto-generated, “it’d be a better use of our time to prompt the LLM ourselves.”

llama.cpp — Six Tightenings in Four Months

llama.cpp (about 109K stars) is a textbook case of policy-by-iteration. The CONTRIBUTING.md history reads:

• 2025-11-30: update guidelines for AI-generated code
• 2025-12-29: tighten AI usage policy
• 2026-01-13: ban AI-generated PR descriptions
• 2026-02-11: ban AI for issues and discussions
• 2026-03-09: limit open PRs for new contributors to 1
• 2026-03-21: explicit about banning accounts that violates policy

The current policy states “This project does not accept pull requests that are fully or predominantly AI-generated,” requires reviewers to be able to explain every line, and bans AI-generated text in PR descriptions, issues, discussions, bug reports, feature requests, and inter-personal replies. Maintainers reserve the right to close violating PRs without explanation.

The lesson: AI slop policies are not “write once, ship.” llama.cpp tightened theirs roughly once a month, each time closing a specific gap that surfaced in operations.

Jazzband — When the Collaborative Model Stops Working

Jazzband maintained 84 Python projects for over a decade, including django-debug-toolbar, pip-tools, prettytable, and sorl-thumbnail. Monthly downloads ran around 150 million, with 3,135 members across 56 countries and over 93,000 GitHub stars.

On March 14, 2026, founder and PSF Chair Jannis Leidel published “Sunsetting Jazzband”. The named trigger was GitHub’s “slopocalypse.” Jazzband had been designed for a world where the worst case was “someone accidentally merging the wrong PR.” In a world where AI-generated spam floods the inbox, shared push access across thousands of members is no longer tenable.

New signups stopped immediately, project leads will be contacted before PyCon US 2026, and the GitHub organization will be retired by end of 2026. Simon Willison amplified the announcement to a wider audience.

GitHub — Maintainer Controls, Finally

Faced with maintainer departures and explicit public pressure, GitHub acknowledged the problem in February 2026. OSPO director Ashley Wolf published “Welcome to the Eternal September of open source”, framing the platform’s shift from “open by default” toward “defensive governance.”

The features that have shipped or are in progress:

• Per-repo option to disable PRs entirely.
• “Collaborators only” PR creation as a setting.
• Pinned issue-comment for contribution guidelines.
• Temporary interaction limits.
• Archiving closed PRs to hide them from public view; UI-driven PR deletion (GitHub Community discussion #185387 and #187038).
• In progress: criteria-based gating (linked issues, vouching) and AI-triage workflows on GitHub Models via gh-aw.

The Register and devclass.com have both pointed out the awkward angle: Microsoft is the largest beneficiary of Copilot adoption, and GitHub has avoided naming AI as the cause of the maintainer crisis its own tools have helped accelerate.

Standards and Community Catalogues

In parallel with individual projects, the standards work is also moving.

• OpenSSF Vulnerability Disclosures WG, Issue #178 (“AI-SLOP: Develop best current practises for Open Source maintainers”) coordinates best-practice documents and policy templates.
• chaoss/wg-ai-alignment and melissawm/open-source-ai-contribution-policies catalogue 63+ formal AI contribution policies, with roughly 14 hard bans, about a third disclosure-required, and a dozen undecided as of early 2026.
• The Linux Foundation’s generative AI guidance focuses on license compatibility.

The Apache Software Foundation has maintained a permissive 2023-vintage policy requiring copyright verification and a Generated-by: tag; Apache Airflow is layering project-specific anti-slop tooling on top after PMC member Jarek Potiuk traced an issue-volume doubling to coordinated submissions from Scale AI’s Outlier platform (covered by The New Stack). Yusuke Wada, creator of Hono, captured the equivalent conversation inside the Japanese ecosystem in his Zenn post “OSSにおけるAI Slop問題の何が問題なのか？”.

Choosing a Pattern for Your Own Project

The cases above map onto a few decision dimensions that are worth running through when deciding what to put in your own CONTRIBUTING.md.

Concern	Pattern	When it fits
License integrity	Outright ban (NetBSD / QEMU style)	GPL-family codebases where training-data licensing is a real exposure
Bounty-hunting pressure	Bounty shutdown, PVR only (curl style)	Security reporting pipelines where monetary incentives attract slop
Mid-sized maintainer team	Human-in-the-loop with disclosure (Linux / LLVM / Fedora style)	Keep the AI productivity gains; lay the responsibility on the human submitter
Solo or tiny maintainer team	Channel closure (Ghostty / tldraw style)	Review bandwidth is the limiting resource and burnout is real
Preventive template setup	NewPipe / typescript-eslint / llama.cpp style	Slop hasn’t hit critical mass yet, but you want guardrails in place

A pragmatic roll-out usually looks like this.

1. Add a short AI policy to CONTRIBUTING.md. Following typescript-eslint, “AI is allowed but you must be able to explain it without AI, follow the templates, and write the prose yourself” is enough to recover a surprising amount of bandwidth.
2. Add self-declaration checkboxes to issue and PR templates. NewPipe’s “I did not generate this with AI” line is weak enforcement on paper but a strong triage signal in practice.
3. Cover non-code prose explicitly. Maintainers are losing more time to AI-generated PR descriptions, issue bodies, and Discussions threads than to AI-generated code itself. llama.cpp’s February tightening filled exactly this gap.
4. Close inbound channels when the volume crosses the line. Ghostty’s vouch system and tldraw’s external-PR auto-close are aggressive moves, but they are reachable choices before maintainers lose the will to keep going.
5. Pair each policy with concrete enforcement. Ghostty’s denouncement list, llama.cpp’s account-ban clause, tldraw’s auto-close, and NewPipe’s template checkbox all share the property that they convert a request into operational protection.

At the level above tactics, Stenberg’s framing is the one to keep close. AI is neither the threat nor the savior; the question is whether a project’s governance can distinguish “an expert wielding a powerful tool” (Joshua Rogers’s ZeroPath collaboration on curl found over 100 real bugs) from “submitters who paste model output and let maintainers do the verification.” Open source contribution is not dead. It is being redefined: the value of a contribution is shifting from “lines written” to understanding of the design intent, commitment to long-term maintenance, and contribution of context that AI can’t generate. Rewriting your contribution policy is the most concrete way to face that shift as an organization.

So that’s how OSS contribution policies are being reshaped under AI slop pressure, sent from the field.