Why open-source maintainers are closing the door on outside pull requests
TechScripts Nepal · Kathmandu · October 7, 2026 · 3 min read
On October 1, Sindre Sorhus, one of the most prolific open-source maintainers, turned off external pull requests across all his repositories. In his words, open source "as we have known it" was fun while it lasted, after 15 years. He'll still maintain the projects and handle issues, but he won't take code from outsiders.
It's easy to read that as one burned-out maintainer. The pattern across the ecosystem says otherwise.
What he actually said
Sorhus was explicit that this wasn't an attack on AI itself. He noted that the quality of open-source contributions had been declining long before AI, but that AI accelerated the problem and made pull-request spam dramatically worse. His practical argument is hard to dispute: it makes no sense to spend time reviewing and going back and forth on a low-quality pull request when he can generate, verify, and ship the fix himself many times faster.
He's one of several
Other well-known projects have moved in the same direction in 2026:
- curl closed its six-year bug bounty on HackerOne in January after AI-generated submissions flooded the security queue. Reports described vulnerabilities that sounded technical but didn't exist in the code.
- Ghostty introduced a standalone AI policy in January. Drive-by AI-generated pull requests not tied to an accepted issue are closed, and contributors who submit unverified AI output can be permanently blocked. The maintainers' reasoning was that agentic coding removed the natural friction of effort that used to filter out low-quality contributions.
- Godot announced on July 1 that it was rewriting its contributor guidelines to sharply restrict generative AI in code submissions. Narrow, low-stakes uses such as code completion or find-and-replace are still allowed if disclosed in the pull request.
The underlying shift
For decades, the effort required to write a patch acted as an unofficial quality filter. If someone took the time to understand a codebase and submit a fix, that investment was a signal. Generating a plausible-looking patch now costs almost nothing, but reviewing it still costs a maintainer real time and attention. The cost moved from the contributor to the reviewer.
What this means if you build on open source
- Expect slower or narrower community input on some projects you depend on. A project that no longer takes outside pull requests will still ship fixes, but through fewer hands. Check how active a dependency's maintainers are, not just its star count.
- If you contribute, lead with an issue and disclose how you used AI. Several projects now require a discussed issue first and a note about AI assistance. Following that process is the fastest way to get a change reviewed.
- The same dynamic applies inside your own repositories. If you run coding agents that open pull requests against your codebase, review capacity becomes the bottleneck. The agent's speed is only useful if someone can verify its work, which is why we flagged supervision in our look at OpenAI's DevDay announcements.
Open source isn't going away, but the unwritten social contract around contributions is being rewritten in public, one policy file at a time.