跪拜 Guibai
← Back to the summary

Open Source Says No: 22 Projects Publicly Ban AI-Generated Contributions

💡 One-line summary: A directory site called Open Source Says No lists 22 open-source projects that publicly reject AI-generated contributions (yt-dlp, Godot, QEMU, immich...), hitting the Hacker News front page on November 11. This isn't a new policy release; it puts open source's ongoing "AI slop counterattack" of the past year on a visible stage. If you submit PRs to open-source projects with AI, this list is worth checking before you act.

Let's start with a question that might hit you: have you ever wondered what happens when you casually let Claude Code or Copilot generate a PR and submit it to an open-source project?

The standard answer used to be "wait in line for review." Today, it might be: closed immediately, and repeat offenders get banned, without even a chance to explain. yt-dlp's contribution guide says "NO AI / NO LLM" in capital letters, covering code, documentation, issues, translations, and art—none are accepted.

On November 11, a directory site called Open Source Says No (osssaysno.com) reached the Hacker News front page (61 points, 106 comments). It does one simple thing: lists open-source projects that publicly declare they reject AI-generated contributions, with policy quotes, scope, and verification dates. As of that day, the list had 22 verified projects.

Why does a "list page" go viral? Because it turns something scattered across hundreds of CONTRIBUTING.md files into a single ecological signal: open source's attitude toward AI-generated content has shifted from tacit acceptance to systematic backlash.

Want to check it out yourself?

How did we get here?

Laying out the timeline, this backlash isn't a collective freak-out one day; it's the result of a year of being pushed by AI slop (AI garbage—low-quality, AI-generated content that no one truly understands).

In February, GitHub itself got concerned: an official product manager started a discussion on whether to add a "kill switch" for PRs—letting maintainers one-click disable PR intake that might be flooded with slop. Even a platform that lives on Copilot is pondering this, which shows the problem is substantial.

In March, Redox (an OS written in Rust) got blunt: "This policy is not up for discussion," with all AI-generated content closed immediately and attempts to bypass leading to bans. Around the same time, researchers' statistics emerged: of 112 surveyed open-source projects, 71 had commits explicitly marked with AI assistant involvement.

At the end of June, the landmark hammer fell: the Godot Foundation (the open-source game engine) officially announced changes to its contribution policy. The rules are quite detailed—

Godot's reasoning is blunt: "AI cannot take responsibility, and we can't expect developers who rely heavily on AI to truly understand their code well enough to fix it." This quote was later repeatedly cited by The Register, IT之家, and other media.

In August, Oracle set a temporary rule for OpenJDK: no content generated by large models or diffusion models may be submitted, with a formal policy still on the way. In early October, System76 updated the PR template for COSMIC desktop in Pop!_OS—contributors must check a box declaring "no AI-generated code, comments, or descriptions included."

Interestingly, System76's reasoning is notable. Chief engineer Jeremy Soller's logic isn't ideological; it's arithmetic: AI brings the cost of submitting a PR near zero, the number of PRs surges, while the people available to review stays the same—the math doesn't balance, so rejection is the only option.

In late October, a Linux Foundation survey gave a magnitude: respondents estimated that about a quarter of incoming PRs are low-quality AI slop. The Register's headline was blunt: "AI saves developers time, but also fills open source's inbox with crap."

Then on November 11, ossaysno.com hit the HN front page—marking the shift of "banning AI contributions" from scattered self-protection by individual projects to a visible ecosystem with a directory, original texts, and a community workflow (you can paste a repo link to automatically check policies and generate a pre-filled issue reminding maintainers to take a stand).

Policies actually fall into three camps

Spreading out this year's policies, RedMonk analyst kate holterhoff mapped 86 open-source organizations into three stances, each with weighty representatives:

Sounds like a three-way split? The actual proportions are far from balanced. In that survey of 112 projects, only 4 had whole-project bans as of March (Zig, NetBSD, GIMP, QEMU), while most sat at "allow but require responsibility." A clarification: the directory's 22 and the survey's 4 have different scopes—the former is a November, item-by-item verified collection of explicit bans, while the latter is a snapshot from an earlier date. The numerical difference comes from time and criteria, not from anyone being wrong.

But the direction of the trend is clear: policies are moving from allow to disclose, and from disclose to ban, with Godot and System76 acting in the second half of 2026. pypa's (pip official) new policy is a typical middle state—AI assistance isn't blanket-banned, but LLMs can't appear in Co-authored-by: attribution, repeated slop submissions get closed without review, and unsupervised agents like OpenClaw are explicitly prohibited.

HN comments: The biggest joke and the most genuine concern

The top-voted quip in the HN thread is sharp: "A website built via vibe coding, dedicated to cataloguing projects that oppose vibe coding—and everyone noticed." Yes, this irony exists, and no one intends to deny it.

The serious discussion is equally solid. The mainstream opinion supports the ban camp: slop PRs are cheap to produce but expensive to review—this asymmetry is the root of the problem, and bans protect overburdened maintainers. A minority worries about two things: first, detection is unreliable; declarative policies rely on self-disclosure plus human identification, so the risk of hurting real contributors is real (Godot's automatic bans were specifically called out). Second, a blanket ban might discourage compliant new contributors—after all, most people who write serious code also use autocomplete.

Interestingly, both sides end up nearly converging: "The real problem is disclosure, and taking responsibility for one's submissions." This sentence, upvoted from the comments, is almost word-for-word the official wording in allow-camp policies—the community argues, yet the bottom-line consensus is clear.

Academia joined in too. An ACM paper (Peking University team) systematically studied how open-source projects govern GenAI contributions, and the conclusion matches practitioners' intuition: generation becoming cheaper does not mean review becomes cheaper—this asymmetry is the origin of all policies.

What does this mean for you?

If you use AI to write code daily, there are several practical things worth doing now:

Looking at the bigger picture, the signal is larger than the 22 projects themselves. AI coding tools sell 'everyone becomes a 10x engineer,' while the open-source hosting side responds with 'prove you understand what you submit.' The more aggressive the tools, the more concrete the policy backlash from gatekeepers—this tug-of-war has only just begun.

References

(Note: The specific timing of cURL shutting down its bug bounty project was not independently verified, only seen in RedMonk's inventory, marked uncertain; the directory site's creator identity and launch date were not determined.)

Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

圆头耗子锄大地

What's even more interesting is that this article of yours was also written with AI—using an AI-written article to discuss a vibe-coded website that catalogs projects opposing vibe coding.