Open source projects face an unprecedented crisis: AI-generated "slop" is overwhelming maintainers with low-quality contributions that require hours to review but seconds to generate. Research shows 20% of security reports to curl in 2025 were AI hallucinations, Apache Airflow saw fake issues nearly double, and maintainers across ecosystems report unsustainable review burdens. However, 84% of disclosed AI-assisted PRs are successfully merged when contributors understand their code, test thoroughly, and engage authentically. The solution isn't banning AI tools—which aids learning and productivity—but requiring contributors to use them responsibly: full understanding, proper testing, genuine engagement, and transparency about AI assistance.
This research synthesizes policies from 20+ major FOSS projects (Apache, Linux Kernel, Fedora, QEMU, NetBSD, Gentoo), analyzes real spam campaigns and maintainer experiences, and identifies proven patterns for distinguishing helpful AI-assisted work from mindless automation. The recommended policy welcomes AI as a productivity tool while protecting maintainer time through clear expectations, behavioral red flags, and efficient response templates.
The open source community stands divided on AI-generated contributions, with approaches ranging from outright bans (QEMU, NetBSD, Gentoo, GNOME Loupe) to conditional acceptance with disclosure (Apache, Fedora, Linux Foundation) to ongoing debates (Linux Kernel, Debian). This division reflects a fundamental tension: AI tools genuinely help developers, but thoughtless use creates spam that threatens project sustainability.
Major projects have responded rapidly since ChatGPT's emergence. NetBSD banned AI-generated code in May 2024, calling it "presumed to be tainted." Apache Software Foundation published permissive guidelines in June 2023 requiring copyright verification and disclosure. The Servo browser engine's April 2025 proposal to allow "small snippets" with AI assistance was overwhelmingly rejected by the community after 54 comments, multiple sponsors threatening to withdraw funding, and contributors declaring they'd halt contributions if AI was permitted.
The core problem isn't AI capability—it's the effort-exchange ratio. SymPy maintainer Oscar Benjamin compared it to Ukraine's drone war: "Million dollar interceptor missiles are just too expensive to be used against any large number of incoming thousand dollar drones." Generating AI slop takes seconds; reviewing and debunking it takes 30 minutes to 3 hours per submission, often engaging 3-4 maintainers. Curl maintainer Daniel Stenberg reported his team was "effectively being DDoSed" by AI-generated security reports, with 20% of 2025 submissions being hallucinated vulnerabilities—down from higher percentages of genuine reports in previous years.
Real-world examples show consistent patterns of low-quality AI contributions across ecosystems. Daniel Stenberg documented curl's "AI Slop List" of fake vulnerability reports: "Buffer Overflow Vulnerability in strcpy() Leading to Remote Code Execution," "Use-After-Free in OpenSSL Keylog Callback"—all hallucinations referencing non-existent code or already-fixed CVEs. In a single week in July 2025, curl received 8 AI slop reports. Each engaged 3-4 security team members for up to three hours each.
Apache Airflow experienced a coordinated spam campaign where issue volume spiked from 20-25 to 50 per day, traced back to AI training company Scale AI's Outlier platform. Contributors from new accounts submitted generic feature requests showing zero understanding of the project. The SymPy project saw contributors opening PRs with database schemas from completely different projects, code that clearly hadn't been run, and descriptions containing leaked AI instructions like "You can run the tests with pytest sympy/foo/bar"—literally the LLM telling the user how to test code they didn't test.
One particularly instructive case: A contributor (anonymized as "X") posted AI-generated "solutions" as comments on multiple open issues, opened several PRs with non-functional code, consistently pinged maintainers for review without addressing feedback, used AI to generate responses to reviewer questions, and had a GitHub profile full of closed PRs from other projects experiencing the same spam pattern. When confronted, the pattern continued. Maintainers eventually reported the account to GitHub.
Textual and formatting indicators are surprisingly consistent. ChatGPT leaves distinctive markers: em dashes (—) used excessively, multiple levels of nested bullet points with bold headers, words like "delve," "robust," "leverage," and "comprehensive," unnecessarily verbose explanations with redundant summarization, and an overly formal academic tone. Hacker News discussions noted: "When you see the telltale signs (em dash, bullet points, bold font, words like 'delve'), just close the ticket and stop reading."
Code-level red flags include: imports or API calls to non-existent functions, database schemas from different projects, code that looks right but doesn't execute, missing error handling, solutions that ignore existing code style and conventions, and boilerplate that doesn't fit project patterns. SymPy's Oscar Benjamin observed: "Copilot can frequently be tricky in complex code, in ways that aren't clear... it frequently output incorrect code, in ways I didn't necessarily understand." The danger is "almost-correct" code that's harder to catch than obviously wrong code.
Behavioral indicators prove most reliable: inability to answer specific questions about the code, responses that sound like more LLM output, avoiding technical details when pressed, using AI to generate follow-up responses, multiple low-quality PRs in short timeframes, the same pattern across different projects, profiles full of closed/rejected contributions, and most critically—no evidence of actually running the code. Seth Larson of the Python Software Foundation stated bluntly: "Don't use AI, because 'these systems today cannot understand code.' Only submit reports that have been verified by a human."
QEMU implemented the strictest policy in 2025. Their maintainers concluded they "don't consider it credible (today) for a contributor to assert compliance with the DCO [Developer Certificate of Origin] terms... when a patch includes AI generated code" due to legal uncertainty around AI-generated code copyright. The policy explicitly bans all AI/LLM-generated contributions and declines any contribution "if use of 'AI' is known or suspected." Tools specifically mentioned include GitHub Copilot, ChatGPT, and similar systems. The policy acknowledges it may be revisited "as AI tools mature," but for now treats the elevated legal risk as unacceptable.
Gentoo Linux took an equally firm stance: "It is expressly forbidden to contribute to Gentoo any content that has been created with the assistance of Natural Language Processing artificial intelligence tools." Their rationale cites three concerns—copyright, ethical issues, and quality—with a note that the policy "can be revisited, should a case been made over such a tool that does not pose copyright, ethical and quality concerns." NetBSD similarly classifies AI-generated code as "presumed to be tainted code" that "must not be committed without prior written approval by core."
GNOME's Loupe project maintainer wrote: "This project does not allow contributions generated by large languages models (LLMs) and chatbots... due to the potential negative influence of AI generated content on quality, as well as likely copyright violations." The ban extends to code, documentation, issues, and artworks, with an exception for translating texts to English for issues/comments. The maintainer's reasoning included environmental costs, ethical concerns about "capitalizing on FOSS work without permission," and the view that AI "cements structures of oppression against marginalized people."
Apache Software Foundation's June 2023 guidance represents the most detailed permissive policy. Code generated with AI can be contributed if the contributor ensures: (1) tool terms are compatible with the Open Source Definition, (2) the output is either not copyrightable, contains no third-party materials, or any third-party materials are properly licensed, and (3) reasonable certainty is obtained through tool disclosure features or code scanning. The policy recommends using a "Generated-by: [tool name]" tag in commit messages and explicitly states contributors remain responsible for disclosing copyrighted materials—just as with non-AI code.
Critically, Apache acknowledges this is "a rapidly evolving area" and commits to re-evaluation as "law, technology, and community tolerance changes." The guidance applies across all 300+ ASF projects to code, documentation, and images. Roman Shaposhnik of Apache noted the fundamental challenge: "While the criteria for what constitutes 'your original creation' is pretty easy to understand if you literally just typed a page of code... the line becomes quickly blurred with AI-generated code."
Fedora Project's 2025 policy emphasizes accountability over restriction. Their core principle: "The contributor is always the author and is fully accountable for the entire contribution, whether a human wrote it or an AI assisted it." Contributors MUST disclose when they "take a significant part of the contribution from a tool without changes" and SHOULD disclose other AI uses "when this information might be helpful." The disclosure mechanism uses an "Assisted-by: [tool description]" tag in commit messages. Fedora's pragmatic reasoning: many contributors already use AI tools like Copilot, AI helps with "boring tests" or boilerplate, and transparency helps the community evaluate AI impact.
Linux Foundation guidance (referenced in kernel discussions) provides a framework individual projects can adapt, focusing on ensuring tool terms don't restrict output use inconsistent with project licenses, contributors verify copyright compliance, and ideally using tools that suppress responses similar to copyrighted training data or flag similarity to training materials.
Linux Kernel discussions reveal the complexity of policy development. Linus Torvalds advocates "treating AI tools no differently than traditional coding aids" with no need for special copyright treatment. However, maintainer David Hildenbrand counters: "We cannot keep complaining about maintainer overload and, at the same time, encourage people to bombard us with even more of that stuff." Kernel developer Kees Cook argues a ban would be "not useful, realistic, nor enforceable," suggesting disclosure-based policies are more pragmatic.
The proposed guidelines (v3 as of November 2025) would require disclosure via "Co-developed-by:" tags (AI cannot use "Signed-off-by" as this represents legal certification), contributor accountability for understanding and maintaining code, and potentially standardized .aisettings configuration files. The policy discussion continues, with plans for the Maintainers Summit in December 2025. Notably, the kernel already uses AI through Sasha Levin's AUTOSEL system for backporting patches—describing it as using LLMs "like any other novice engineer intern" for "drudgery no one else has time to do."
Debian explicitly decided against a policy in May 2024 after community discussion showed they were "far from consensus." The view: "Not painful or widespread enough to motivate policy." Interestingly, Debian is exploring OpenAI sponsorship for project-wide LLM access to help developers use AI tools in their workflows, following a scientific journal approach where contributors attest they followed responsible practices. Python/CPython, Rust, Mozilla, Node.js, and KDE have no specific AI contribution policies discovered through research.
The fundamental economics are unsustainable. Generating an AI-written PR takes seconds to minutes. Reviewing it takes 30 minutes to 3 hours of expert maintainer time. Daniel Stenberg: "Every report thus engages 3-4 persons. Perhaps for 30 minutes, sometimes up to an hour or three. Each. I personally spend an insane amount of time on curl already... My fellows however are not full time on curl. They might only have three hours per week for curl." Twenty percent of those weekly hours consumed by hallucinated reports means real security work gets deferred.
Oscar Benjamin articulated the cost-exchange problem precisely: "The effort PR reviewers put in to help with PRs is not reasonable if the author of the PR is not putting in a lot more effort themselves because there are many times more people trying to author PRs than review them. I don't think that it can be sustainable in the face of this spam to review PRs in the same way as if they had been written by humans who are at least trying to understand what they are doing (and therefore learning from feedback)."
This mirrors the first platform to ban AI: Stack Overflow prohibited ChatGPT-generated answers because it was "just too easy to generate superficially reasonable text that was low quality spam and then too much effort for real humans to filter that spam out manually." Benjamin noted: "Bad/incorrect answers were nothing new but large numbers of inexperienced people using ChatGPT had ruined the cost-exchange ratio of filtering them out."
Maintainer burnout studies identify key factors: lack of positive feedback (users only reach out with complaints), not saying 'no' (taking on too many responsibilities), working alone, and insufficient time or resources. AI slop exacerbates every single factor. Daniel Stenberg described the "emotional toll it takes to deal with these mind-numbing stupidities" and said his team is "effectively being DDoSed." Seth Larson warned that "wasting precious volunteer time doing something you don't love and in the end for nothing is the surest way to burn out maintainers or drive them away from security work."
The cultural damage extends beyond individual burnout. Brian Coords observed: "Open source thrives when we collaborate, when we publish our code, when we take the extra few minutes and make whatever we just built a bit more universal so that it can hopefully solve other people's problems... The pathway for new contributors is not just understanding code, but also understanding the culture of collaboration... There's nothing wrong with AI-generated code, I'm using it all the time, too. But I would encourage developers not to lose sight of the actual value of open source software—it's not just the code you get, but the code you give away."
The onramp for genuine contributors is disappearing. Coords continued: "I don't think we're going to see large open source projects suffering any time soon, but I do think that the onramp for new contributors (much like the onramp for junior developers) is disappearing... What open source projects need are more knowledgeable contributors who can lead projects, make decisions, have good taste, have a sense of ownership over features, and who can onboard new contributors." Reading AI-generated summaries won't lead to the deep understanding needed for these roles.
GitHub's May 2025 introduction of Copilot features for generating bug reports and PRs for any public project—without maintainer opt-out—represents a systemic threat. The Copilot bot user is exempted from being blockable, and bug reports don't mention they were AI-generated. Maintainer Andi McClure filed an issue: "Allow us to block Copilot-generated issues (and PRs) from our own repositories." McClure warned: "If we are not granted these tools, and 'AI' junk submissions become a problem, I may be forced to take drastic actions such as closing issues and PRs on my repos entirely, and moving issue hosting to sites such as Codeberg."
A Reddit thread documented this with the title "My new hobby: watching AI slowly drive Microsoft employees insane"—Microsoft's own developers struggling with their company's Copilot bot. The situation illustrates a profound asymmetry: platforms enabling one-click AI generation at scale without giving maintainers equivalent tools to manage the resulting flood.
Academic research reveals AI-assisted contributions can succeed when done responsibly. A study analyzing 18,256 GitHub Copilot-assisted PRs found an 84% merge rate versus 71% for non-AI PRs, with 19.3 hours less average review time. Critically, developers actively edited AI content in 1,437 documented revisions: 22.9% deleted portions, 20.8% refined phrasing, 14.7% replaced with their own content, and 12.3% rearranged structure. The pattern shows AI as a starting point requiring significant human refinement.
What developers added to AI-generated PR descriptions: associated links/issue references (22.7%), PR intent/motivation (12.8%), testing information (9.2%), visual representations/screenshots (7.3%), and custom changelogs (7.7%). This demonstrates that while AI can draft content, human context and project-specific information remain essential. The 55% of developers who manually added testing details to AI-generated descriptions highlight that AI doesn't naturally include the verification evidence maintainers need.
Microsoft's internal AI code review platform processing 600K+ PRs monthly shows what works at scale: interactive Q&A where reviewers can ask AI questions about code changes, configurable standards enforcing team-specific guidelines, AI acting as mentor explaining improvements, and critically—human-in-the-loop where AI suggests but humans decide. Results include faster PR completion, improved code quality, enhanced developer onboarding, and consistent best practices enforcement.
Community consensus identifies acceptable AI uses: Translation and communication aid for non-native English speakers (using LLMs "like Google Translate"), writing PR descriptions after making real code changes yourself (provided descriptions don't generate false information), generating boilerplate code for personal use and well-understood tasks, understanding code patterns and getting unstuck on specific problems (with verification and testing of all outputs), code review assistance identifying potential issues, generating test cases as a starting point, and proofreading for clarity improvements.
What separates helpful from harmful: Berkeley D-Lab's guidelines capture it perfectly: "Don't let AI speak for you" (comments, PRs, and issues should be in the contributor's own voice) and "Don't let AI think for you" (contributions should only be submitted after full understanding). Miguel Grinberg of the Flask project explained: "The truth that may be shocking to some is that open source contributions submitted by users do not really save me time either, because I also feel I have to do a rigorous review of them. But I enjoy working with users who have an interest in my projects and take time to report bugs, request features or submit code changes. These interactions are a source of new ideas more than anything, so they directly help me do better work."
The distinction is clear: AI as a tool that enhances personal productivity is valuable. AI as a shortcut to submit code you don't understand is spam. Oscar Benjamin: "It is very unfortunate that right now AI is being used in all the wrong places. It can do a student's homework because it knows the answers to all the standard homework problems but it can't do the more complicated more realistic things and then students haven't learned anything from doing their homework."
Welcome AI tools as productivity enhancers while requiring genuine human contribution. The policy must balance three goals: (1) don't discourage legitimate developers using AI to write better code faster, (2) protect maintainer time from spam and low-quality submissions, and (3) preserve the collaborative learning culture that makes open source sustainable. The approach treats AI like any other tool—compilers, IDEs, Stack Overflow—where what matters is whether the contributor understands and can maintain their submission.
Transparency through disclosure, accountability through engagement. Following Fedora and Apache's approach, require disclosure of significant AI assistance but focus enforcement on whether contributors demonstrate understanding, respond meaningfully to feedback, and submit tested, working code. The policy acknowledges detection is imperfect and relies on contributor honesty, but deterrent effect through clear standards and efficient response to violations protects maintainers.
AI-Assisted Contributions
We welcome the use of AI tools (like GitHub Copilot, ChatGPT, Claude, or similar) as productivity aids and learning tools. Many maintainers and contributors use these tools ourselves. However, you remain fully responsible for understanding, testing, and maintaining all code you submit.
Requirements for all contributions:
✓ Full Understanding: You must be able to explain every technical decision and implementation detail in your contribution. If asked "why did you implement it this way?" you should have a substantive answer beyond "the AI suggested it."
✓ Thorough Testing: You must verify your code works in your local environment, handles edge cases appropriately, and doesn't break existing functionality. Include information about your testing process in PR descriptions.
✓ Authentic Communication: Write PR descriptions, commit messages, and comments in your own words based on your understanding. Avoid verbose AI-generated boilerplate that makes reviews harder.
✓ Responsive Engagement: Be prepared to meaningfully discuss your implementation, answer technical questions, and make changes based on feedback.
✓ Disclosure: If you used AI assistance for a significant portion of your contribution, mention this in your PR description (e.g., "Used GitHub Copilot for boilerplate generation"). This helps maintainers understand your process and provide better guidance.
What we're looking for:
What causes problems:
Remember: Our review process assumes contributors understand their submissions. If you use AI tools, use them to enhance your productivity, not to replace your understanding. Quality matters far more than quantity.
Before opening a PR, verify:
Initial response (constructive, for borderline cases):
Thank you for your interest in contributing! To help us review effectively, could you please:
1. Explain the motivation for this specific approach
2. Describe how you tested this change locally
3. Clarify [specific technical concern]
If you used AI assistance for this PR, please confirm you've reviewed the generated code and understand how it works. We're happy to help you improve this contribution.Escalation (for persistent issues or clear red flags):
Thank you for your contribution attempt. However, this PR shows signs of being generated without adequate review or understanding:
- [Specific issues: untested code / cannot answer technical questions / doesn't follow guidelines / etc.]
Our project requires contributors to:
- Fully understand all submitted code
- Test changes in a local environment
- Respond meaningfully to technical questions
- Follow project-specific guidelines
Please review our Contributing Guidelines and feel free to resubmit when you can demonstrate understanding of your changes. We're here to help you learn!Closure (for clear spam or bad faith):
We're closing this PR because it doesn't meet our contribution standards:
- [Specific reasons: no evidence of testing / unable to explain implementation / pattern of low-quality submissions / etc.]
Contributing to open source is about learning and collaboration, not just having code merged. If you'd like to contribute in the future:
1. Start with smaller issues you fully understand
2. Engage with the community to learn our practices
3. Ensure you can explain and maintain your submissions
4. Focus on quality over quantity
Thank you for understanding.Quick assessment indicators (30-second check):
If suspicious, ask qualifying questions:
Red flags requiring immediate attention:
For clearly problematic submissions:
For borderline cases (good faith but AI-dependent):
Protecting maintainer time:
Jeff Geerling's principle applies: "Be liberal with your 'no', be judicious with your 'yes'." The cost of merging low-quality code (ongoing maintenance burden, technical debt, setting precedent) exceeds the benefit of being maximally welcoming to submissions that create work without adding value. Maintainer sustainability requires saying no efficiently.
Add the AI-Assisted Contributions section to your CONTRIBUTING.md file. Update issue and PR templates to include the pre-submission checklist. Create saved replies in GitHub with the three response templates for efficient reuse. Add a brief note to your README acknowledging that AI tool usage is common and pointing to contribution guidelines.
Announce the new guidelines through your preferred channels (mailing list, Discord, GitHub Discussions). Pin an announcement issue explaining the policy rationale and welcoming community feedback. Train co-maintainers on red flags and efficient response procedures. Document 2-3 examples of good AI-assisted contributions (if available) to show what success looks like. Create a private maintainer channel for discussing borderline cases.
Track basic metrics: percentage of PRs requiring questioning about AI use, time spent on problematic vs. quality contributions, contributor response patterns to feedback. Gather maintainer feedback quarterly on whether the policy is working. Update guidelines based on community experience and evolving AI capabilities. Share learnings with other projects in your ecosystems (PyPA, Trio, aio-libs, CherryPy, Jazzband).
Consider AI-assisted code review tools like CodeRabbit or Qodo Merge for large projects where automated first-pass review could help. These tools have shown 50% reductions in review time while maintaining quality, but require setup and configuration. For security-critical projects, implement additional static analysis and dependency scanning to catch issues AI might introduce. For very high-traffic projects, consider a "trusted contributor" system where those with merged contributions can bypass more stringent AI-related checks.
From curl's Daniel Stenberg: "We must do something to drastically reduce the temptation for users to submit low quality reports." The solution isn't just policy but changing incentives—he's considering removing monetary bug bounties because the income temptation drives AI-generated spam. For most projects, the incentive is GitHub contributions for resumes; the counter-incentive is efficient rejection of low-quality submissions.
From SymPy's Oscar Benjamin: "The hype that is spun by AI companies probably has many novice programmers believing that it actually is reasonable to behave like this but it really is not and that needs to be clearly stated somewhere." Clear communication sets expectations and educates contributors about what open source collaboration actually requires. Many submitting AI slop genuinely don't realize they're doing something wrong.
From Python's Seth Larson: "Low-quality reports should be treated as if they're malicious... Wasting precious volunteer time doing something you don't love and in the end for nothing is the surest way to burn out maintainers." This doesn't mean treating people harshly, but recognizing that regardless of intent, the effect is the same: maintainer time consumed for zero value. Efficient rejection is an act of self-preservation.
From Flask's Miguel Grinberg: "I enjoy working with users who have an interest in my projects and take time to report bugs, request features or submit code changes. These interactions are a source of new ideas more than anything." The human relationship and exchange of ideas is what makes open source maintenance rewarding. AI-generated contributions without genuine engagement eliminate this benefit while preserving all the work.
From Brian Coords: "There's nothing wrong with AI-generated code, I'm using it all the time, too. But I would encourage developers not to lose sight of the actual value of open source software—it's not just the code you get, but the code you give away." The policy should preserve this cultural value while accepting that AI tools are now part of developers' workflows.
The evidence is clear: AI-assisted contributions can enhance open source when used responsibly, but mindless automation threatens project sustainability. The recommended policy welcomes AI as a productivity tool—just as maintainers use it themselves—while requiring contributors to use it thoughtfully: understanding their code, testing thoroughly, engaging authentically, and being transparent about assistance.
This approach achieves multiple goals. It doesn't discourage skilled developers using AI to contribute better code faster. It provides clear standards for efficiently rejecting spam without prolonged discussion. It educates new contributors about open source collaboration norms. It protects maintainer time and emotional energy for productive work. And it preserves the learning culture and human relationships that make open source meaningful.
The policy must evolve with technology, but the core principle remains constant: contributors are responsible for understanding and maintaining their submissions, regardless of what tools they use to create them. AI doesn't change this fundamental requirement of open source collaboration—it just makes enforcing it more urgent.
For your Python FOSS projects across PyPA, Trio, aio-libs, CherryPy, and Jazzband ecosystems, this policy provides a practical framework grounded in real-world experience from dozens of major projects. It's designed to be clear enough to deter spam, flexible enough to welcome legitimate AI-assisted contributions, and efficient enough to implement without overwhelming maintainers who are already juggling multiple projects.
The future of open source depends on maintaining the human elements—understanding, learning, collaboration, and community—while adapting to new tools that can enhance productivity. This policy framework helps achieve that balance.