Open source has never been the sprawling community of contributors that many imagine. In reality, most critical software depends on a tiny core of unpaid maintainers, often just one or two people. This imbalance worked when contributing had friction — developers had to care enough to reproduce a bug, understand the codebase, and risk looking foolish in public. But artificial intelligence, particularly large language models (LLMs) and coding agents, is obliterating that friction. As a result, the very nature of open source contribution is being redefined, and not necessarily for the better.
Mitchell Hashimoto, founder of HashiCorp and a prominent figure in open source, recently considered closing external pull requests to his projects entirely. His reason: he is drowning in “slop PRs” generated by AI agents. These submissions look plausible but lack deep understanding of the codebase. They are statistically generated approximations of a fix, not thoughtful contributions. This phenomenon, which Flask creator Armin Ronacher calls “agent psychosis,” describes developers addicted to the dopamine hit of agentic coding, spinning up agents that run wild through projects. The result is a massive degradation of quality — code that feels right but misses context, trade-offs, and historical perspective.
The problem is only going to worsen. As SemiAnalysis noted, we have moved past simple chat interfaces into agentic tools that live in the terminal. Claude Code can research a codebase, execute commands, and submit pull requests autonomously. While this is a productivity boon for a developer working on their own project, it is a nightmare for maintainers of popular repositories. The barrier to producing a plausible patch has collapsed, but the barrier to responsibly merging it has not.
This leads to a provocative question: Will the best open source projects become those that are hardest to contribute to?
The cost of contribution
The economics driving this shift are brutally asymmetric. It takes a developer 60 seconds to prompt an agent to fix typos and optimize loops across a dozen files. But it takes a maintainer an hour to carefully review those changes, verify they don’t break obscure edge cases, and ensure alignment with the project’s long-term vision. Multiply that by a hundred contributors using personal LLM assistants, and you don’t get a better project — you get a maintainer who walks away.
In the past, a developer might find a bug, fix it, and submit a pull request as a gesture of gratitude. It was a human transaction. Now automation has replaced that thank you with a mountain of digital noise. The OCaml community experienced this firsthand when maintainers rejected an AI-generated pull request containing over 13,000 lines of code. Copyright concerns, lack of review resources, and long-term maintenance burden were cited. One maintainer warned that such low-effort submissions could bring the pull request system to a halt.
Even GitHub, the host of the world’s largest code forge, is feeling the pressure. As reported by InfoWorld, GitHub is exploring tighter pull request controls and UI-level deletion options because maintainers are overwhelmed by AI-generated submissions. When the platform itself contemplates a kill switch for pull requests, this is no longer a niche annoyance — it is a structural shift in how open source gets made.
Small open source projects are hit hardest. Nolan Lawson, author of blob-util — a JavaScript library with millions of downloads — recently explored this in “The Fate of ‘Small’ Open Source.” For a decade, blob-util was a staple because it was easier to install the library than to write the utility functions yourself. Now developers simply ask their AI to generate a utility function, and it produces a serviceable snippet in milliseconds. The era of the small, low-value utility library is over. AI has made them obsolete. If an LLM can generate the code on command, the incentive to maintain a dedicated library vanishes.
But something deeper is lost. These libraries were educational tools where developers learned by reading others’ work. Replacing them with ephemeral, AI-generated snippets trades understanding for instant answers. This is the teaching mentality that Lawson sees as the heart of open source — gone.
Build it, don’t borrow it
Ronacher proposed a different path: build it yourself. If pulling in a dependency means dealing with constant churn, the logical response is to retreat. Use AI to help you, but keep the code inside your own walls. The irony is that AI may reduce demand for small libraries while simultaneously increasing the volume of low-quality contributions into the libraries that remain.
All of this prompts a fundamental question: If open source is not primarily powered by mass contribution, what does it mean when the contribution channel becomes hostile to maintainers?
The likely outcome is bifurcation. On one side are massive, enterprise-backed projects like Linux or Kubernetes. These cathedrals are guarded by sophisticated gates, with resources to build AI-filtering tools and organizational weight to ignore noise. On the other side are provincial open source projects — run by individuals or small cores — that simply stop accepting contributions from the outside. The proletariat becomes isolated.
The irony is that AI was supposed to make open source more accessible. It has — sort of. But in lowering the barrier, it has also lowered the value. When everyone can contribute, nobody’s contribution is special. When code becomes a commodity produced by a machine, the only scarce resource is human judgment to say no.
The future of open source is not dying, but the “open” part is being redefined. We are moving from radical transparency and “anyone can contribute” to an era of radical curation. The future belongs to the few, not the many. Open source’s “community” was always partly a myth, but AI has made the myth unsustainable. We are returning to a world where only those who actually write the code matter, not those who prompt a machine to do it for them. The era of the drive-by contributor is being replaced by the era of the verified human.
In this new world, the most successful open source projects will be those that are hardest to contribute to. They will demand high levels of human effort, context, and relationship. They will reject slop loops and agentic psychosis in favor of slow, deliberate, deeply personal development. The bazaar was a fun idea while it lasted, but it could not survive the arrival of the robots. The future of open source is smaller, quieter, and much more exclusive. That might be the only way it survives.
We don’t need more code; we need more care. Care for the humans who shepherd communities and create code that will endure beyond a simple prompt. The challenge isn’t technological — it’s about preserving the human core of software development in an age of autonomous machines.
Source: InfoWorld News