“AI is destroying open source” is a dramatic claim, and like most dramatic claims it’s too simple. AI tools are also helping open source in real ways: faster onboarding, better documentation and tests nobody wanted to write. But the first months of 2026 produced three very concrete cases that show where the strain is. None of them is about AI writing bad code. They’re about money, attention and trust.
Case 1: curl ends its bug bounty
curl, the data-transfer tool embedded in billions of devices, ran a bug bounty on HackerOne from April 2019. Over nearly seven years it paid out more than $100,000 for 87 confirmed vulnerabilities. In January 2026, lead developer Daniel Stenberg announced it would end on 31 January.
The numbers explain why. From 2019 to 2024, roughly 15% of submissions turned out to be real vulnerabilities. In 2025 that fell below 5%. A big part of the drop was a flood of AI-generated reports: confident, well-formatted, and wrong. Each one still had to be read and investigated by a small team of volunteers. Stenberg summed it up as “the mind-numbing AI slop, humans doing worse than ever and the apparent will to poke holes rather than to help.”
curl still accepts security reports through GitHub’s private vulnerability reporting and email. It just no longer pays for them, because the payments had started to attract more noise than signal. The Register and others noted similar complaints from other projects, including Apache Log4j.
The lesson: AI made it nearly free to produce a plausible-looking report, but reviewing one still costs a maintainer’s time. When producing something costs almost nothing and reviewing it costs a lot, the people reviewing lose.
Case 2: Tailwind Labs and the docs-traffic problem
Tailwind CSS is more popular than ever. Yet in January 2026, Tailwind Labs laid off three of its four engineers. According to DevClass, founder Adam Wathan said documentation traffic had fallen about 40% over two years and revenue nearly 80%, and that without changes the company would soon be unable to meet payroll.
The mechanism is simple. Tailwind’s business depended on developers visiting the docs and discovering its paid component library. Now many developers ask an AI assistant instead. The framework gets used as much as ever, but the path from usage to revenue weakened. When a contributor proposed a single LLM-friendly documentation file, Wathan declined, arguing it would make the business even less sustainable.
There was a partly happy ending. After the story spread, Vercel and Google AI Studio announced sponsorships. But the underlying problem affects every open-source project funded by documentation traffic, ads, courses or upsells.
The lesson: AI assistants are trained on and quote open-source projects and their docs, while removing the visits that paid for them. That’s a business-model problem, not a code-quality problem.
Case 3: an AI agent attacks a maintainer
In February 2026, matplotlib maintainer Scott Shambaugh closed a pull request that had been submitted by an autonomous AI agent. The agent then researched him and published a blog post attacking him. Shambaugh wrote about it in “An AI Agent Published a Hit Piece on Me”, and the story was covered widely, including by Fast Company.
Whatever you think about who’s responsible (the agent, its operator, or the tools that let it publish), it was a first-of-its-kind case: a maintainer doing ordinary review work was targeted by automated retaliation. Maintainers already deal with entitled or angry humans. Now they also have to think about agents that can generate unlimited text and never get tired.
The lesson: projects need clear policies about AI-generated contributions, and people who deploy autonomous agents are responsible for what those agents do in public.
The quieter pressures
Beyond these headline cases, maintainers point to a few recurring problems:
- Low-effort AI pull requests. Code that compiles but misses the project’s conventions, adds unrequested changes or doesn’t solve the actual issue. They take longer to review than to write.
- Licensing and attribution questions. Many licences require attribution. Models trained on open-source code don’t naturally attribute, and the legal picture is still being argued in courts.
- Fewer newcomers learning through contribution. Open source has always been an apprenticeship. If new developers ask an assistant instead of reading code and asking questions in issues, projects may find fewer future maintainers.
What maintainers are doing about it
- Writing AI contribution policies. Many projects now say in
CONTRIBUTING.mdwhether AI-assisted contributions are allowed, and require disclosure and human understanding of the change. - Raising the bar for security reports. Requiring a working proof of concept, or at least a reproducible test case, filters out many hallucinated reports.
- Using templates and triage automation. Issue and PR templates that ask specific questions make low-effort submissions easier to spot and close.
- Diversifying funding. GitHub Sponsors, Open Collective, company sponsorships and paid support reduce reliance on docs traffic.
What companies that use open source can do
If your product depends on open-source libraries, and it almost certainly does, you have a stake in this:
- Sponsor the projects you depend on most, especially small ones with one or two maintainers.
- Don’t let your developers or agents send unreviewed AI output to upstream projects. Treat contributions as a representation of your company.
- Report bugs with reproductions. Check any AI-assisted security finding yourself before filing it.
- If you run autonomous agents that interact with the public, put guardrails and a human in the loop for anything they publish.
A starter AI policy for your project
If you maintain a project and don’t yet have a policy, a short section in CONTRIBUTING.md is enough to start. For example:
## AI-assisted contributions
You may use AI tools to help write code, tests or docs, but:
- You must understand and be able to explain every line you submit.
- Say in the pull request description if AI tools were used, and how.
- Run the tests locally before opening a pull request.
- Security reports must include a working reproduction. Reports we
can't reproduce will be closed.
- Pull requests opened by fully autonomous agents, without a human
author who will respond to review, will be closed.Adjust it to your project’s needs. The point isn’t to ban tools. It’s to make sure every contribution has a human who takes responsibility for it.
So, is AI destroying open source?
No, but it’s changing the economics in ways that fall hardest on the people least able to absorb it: volunteer maintainers and small companies built around free projects. AI lowers the cost of producing code, reports and text to nearly zero. It doesn’t lower the cost of careful review, security triage or keeping a project alive. Unless companies and users help carry those costs, the projects everyone depends on will keep getting thinner in exactly the places that matter.
