AI "Vibe Coding" Threatens Open Source as Maintainers Face Crisis

Open-source maintainers are closing their doors to outside contributors at an alarming rate. Daniel Stenberg shut down cURL's six-year bug bounty program in January. Mitchell Hashimoto banned AI-generated code from Ghostty. Steve Ruiz went further - tldraw now auto-closes all external pull requests. These aren't isolated incidents. They're responses to what RedMonk analyst Kate Holterhoff calls "AI Slopageddon" - a flood of AI-generated contributions so voluminous and low-quality that maintainers can't keep up.

But according to a recent research paper from Central European University and the Kiel Institute for the World Economy, the surface crisis masks a deeper structural threat. The study models "vibe coding" - having AI agents select and assemble open-source packages without developers reading documentation, reporting bugs, or engaging with maintainers. Their economic model shows that when open-source projects depend on user engagement for returns, documentation visits, bug reports, and community recognition, widespread vibe coding creates a negative feedback loop.

As developers delegate package selection to AI, fewer eyes land on documentation, fewer human bugs get filed, and maintainer incentives erode. Despite AI productivity gains, the model predicts declining software availability and quality. Stack Overflow saw 25% less activity within six months of ChatGPT's launch. Tailwind CSS downloads climbed while documentation traffic fell 40% and revenue dropped 80%.

For Stenberg, the breaking point came after $86,000 in payouts: by 2025, 20% of submissions were AI-generated, with overall valid-rate dropping to 5%. The crisis extends beyond bug bounties. Craig McLuckie, co-founder of Stacklok, describes how good first issue labels once attracted engineers who would grow into contributors. He stated: "Now we file something as 'good first issue' and in less than 24 hours get absolutely inundated with low quality vibe-coded slop that takes time away from doing real work."

Holterhoff traces the problem to a broken filter. Writing code historically required time and effort, screening out unserious participants. AI eliminated that barrier. Hashimoto responded with a zero-tolerance policy at Ghostty, banning contributors who submit AI code without approval: "This is not an anti-AI stance. This is an anti-idiot stance. Ghostty is written with plenty of AI assistance and many of our maintainers use AI daily. We just want quality contributions, regardless of how they are made."

Ruiz went even further. After discovering his own AI scripts created poorly written issues that contributors fed to their AI tools generating pull requests based on hallucinations, he shut down external contributions: "If writing the code is the easy part, why would I want someone else to write it?"

Platform incentives compound the problem. GitHub launched Copilot issue generation in May 2025 without giving maintainers tools to filter AI submissions. Stefan Prodan, core maintainer of Flux CD, summarized the mismatch: "AI slop is DDOSing OSS maintainers, and the platforms hosting OSS projects have no incentive to stop it. On the contrary, they're incentivized to inflate AI-generated contributions to show 'value' to their shareholders."

The researchers propose a "Spotify model" where AI platforms redistribute subscription revenue based on package usage, but their calculations show vibe-coded users would need to contribute 84% of what direct users currently generate - an unrealistic threshold. Open-source foundations have issued policies focused on licensing rather than quality. The Linux Foundation addresses license compatibility; Apache recommends "Generated-by:" tags. Neither helps with the flood.

Gentoo Linux and NetBSD banned AI contributions entirely, though as RedMonk's Holterhoff noted, detecting violations will become functionally impossible within a year or two. Koren warns the damage will fall unevenly: "Popular libraries will keep finding sponsors. Smaller, niche projects are more likely to suffer. But many currently successful projects, like Linux, git, TeX, or grep, started out with one person trying to scratch their own itch. If the maintainers of small projects give up, who will produce the next Linux?"

For now, maintainers like Stenberg, Hashimoto, and Ruiz are answering that question by closing their doors one project at a time.