The Open Source Software (OSS) Sustainability Crisis

The AI impact to Open Source projects

Jan 2026 pushback

In the first three weeks of January 2026, three critical open-source projects took unprecedented defensive measures because of AI. curl runs on up to 50 billion devices worldwide, and has recently shut down its six-year bug bounty program in PR #20312. Ghostty has now implemented a zero-tolerance policy to ban low-quality AI-generated contributions, and tldraw went one step further, taking the decision to auto-close all external pull requests.

AI “Slop”

The trigger for this action is what maintainers are calling “AI slop”. Across Open Source projects, maintainers are seeing a flood of plausible looking PR’s which are fundamentally broken contributions, consuming valuable review time without adding any value to the project. curl saw twenty security reports in 21 days, none of which were valid. There were PRs that claimed to fix bugs that didn’t exist, while others flagged curl behaviours that could only be dangerous if deliberately misused. Lastly, code that looked right, upon digging, revealed a complete misunderstanding of the project. While only 5 of the reported twenty were immediately dismissed by the maintainers as obvious hallucinated AI-generated junk, perhaps more insidious are the remaining reports that weren’t immediately dismissed but still consumed valuable review time treading the line between plausible and useful.

Why is this happening?

IT professionals seem desperate to take shortcuts and “stat pad” their CV with how many projects they have contributed to, taking little time to understand the project, letting AI produce the Pull Request and putting all the onus on the maintainer to do all the heavy lifting in the review.

The purpose of the blog is not to hammer people who want to be contributors. We all want sustainable infrastructure. The purpose of this blog is to highlight the problem, and promote the correct guidelines of how we achieve the ongoing goal on sustainable infrastructure in this AI dominated world.

The CNCF Annual Report 2025

The 2025 CNCF Annual Survey published in January 2026 gave a clear indication that AI was dominating the industry. With 98% of organisations now using cloud native technologies and 66% running AI workloads on Kubernetes, the report identified a critical concern that “machine-driven automated usage puts a strain on the open source systems we all depend on.”

The numbers behind the statement paint a compelling story that sustainability should be on all of our radars:

• 234 CNCF projects maintained by 270,000+ contributors globally.
• 82% of container users deploy Kubernetes in production (up from 66% in 2023).
• 52% of organisations consume AI models and the infrastructure they are built on because they are not training their own AI models.

As a result, Infrastructure sustainability now ranks alongside technical complexity as a top concern amongst IT professionals, and it represents the fact that actual humans are maintaining the code running your infrastructure, and those humans are burning out.

How Open Source projects are responding

curl shuts down bug bounty program

On January 22, curl creator Daniel Stenberg ended the project’s bug bounty program. Over six years, the program had paid $86,000 for 78 valid vulnerabilities. The shutdown came after receiving 20 AI generated security reports in the first 21 days of 2026, however none of the 20 reported issues identified any actual vulnerabilities.

Stenberg wrote in his commit message that “We have concluded the hard way that a bug bounty gives people too strong incentives to find and make up “problems” in bad faith that cause overload and abuse.”

Stenberg’s updated security policy now includes a blunt warning that anyone who submits fake and madeup security problems.

“As we take security reports seriously, we investigate each report with priority. This work is both time and energy consuming and pulls us away from doing other meaningful work. Fake and otherwise made up security problems effectively prevent us from doing real project work and make us waste time and resources. We ban users immediately who submit made up fake reports to the project.”

Ghostty claims it is a war zone

Mitchell Hashimoto, HashiCorp co-founder and creator of the Ghostty terminal emulator, has been extremely open about the use of AI to build Ghostty, but extremely frustrated with open source contributions that are produced by AI which he calls “slop”. Ghostty has now implemented a zero-tolerance policy, that AI-generated pull requests are only allowed for accepted issues. Any drive by contributions get closed immediately, and repeat offenders will be permanently banned and publicly ridiculed. This is his final step in his battle against AI slop, building on his August 2025 enforcement requiring any contributions to disclose any use of AI tooling.

If you don’t follow Hashimoto on Socials, we recommend you do. He has used it recently to highlight the real severity of the sustainability issue, and the impact on the maintainers. We won’t do his tweet justice, so we will just include it below for you to read directly.

But using AI is not all doom and gloom. What is important to note is the issue is not with using AI, the issue is people are using AI wrong. Ghostty itself is built with AI assistance, and many maintainers use AI tools daily. The new Ghostty policy explicitly states:

“This is not an anti-AI stance. This is an anti-idiot stance. It’s the people, not the tools, that are the problem.”

Again, referring back to Hashimoto’s socials, he shared one brilliant success story that illustrates the difference between using AI correctly and using it to create slop.

tldraw implements auto close of PR’s

Steve Ruiz, founder of tldraw, was also in a position to make a tough decision. On January 15, tldraw began auto-closing all external pull requests, implementing a “temporary policy until GitHub provides better tools for managing contributions.” His blog post from 17th January titled: “Stay Away From My Trash”, is well worth a read.

He later asked a fundamental question, “In a world of AI coding assistants, is code from external contributors actually valuable at all? If writing the code is the easy part, why would I want someone else to write it?” He later signs off the blog, stating that if the value of external contribution is less than zero, then it’s better to limit community contribution to the places it still matters: reporting, discussion, perspective, and care, because it is easy for an internal contributor with context to click a button and vibe code themselves.

Engineering principles for contributing in the AI Era

It is fairly easy to list the things your engineering teams should not be doing. These include everything from drive-by PRs without understanding project context, not following-up when maintainers ask questions, making claims to fix bugs that don’t exist, and general “vibe coding” just to increase your GitHub activity. However, as part of this blog we wanted to provide actual guidance of what can be done, and how to effectively use AI. It is a tool that is not going away, and it is a tool that can be of great influence in fixing our sustainability issue we mentioned earlier.

1. Issues before implementation

Never submit code as the first interaction with a project. Open an issue, describe the problem, and discuss potential approaches. Let maintainers validate that the problem is real and a solution is required. This single step can eliminate up to 90% of the current wasted review time.

2. Disclose AI usage upfront

State which tools you used (Claude Code, Copilot, etc.) and the extent of AI assistance. This isn’t about shaming the gap in your knowledge. Everyone has gaps somewhere, but disclosing your use of AI sets expectations with the reviewer.

Note: Many projects now require this in their contribution guidelines as a must have.

3. Verify everything yourself

AI hallucinates, it can invent APIs that don’t exist, it suggests patterns that don’t fit the codebase, and it makes very confident assertions about requirements it doesn’t understand. If you can’t explain why every line of AI-generated code is correct, then please don’t submit it for someone else to figure out why.

4. Test before submission

Never submit code for platforms or environments you can’t personally test. If you’re using AI to write macOS-specific code but you’re on Linux, you have no way to verify that your code works correctly. Once again, this is putting the onus on someone else to do the work which you haven’t done. Please don’t use maintainers as a QA team.

5. Show your thinking

Building on number (2), include the prompts you used, the decisions you made, and any corrections you applied. This “show your working out” principle provides reviewers and maintainers with the context to understand your intent and approach. The logic you disclose will provide the human reasoning, which is more valuable than the final code.

6. Commit & proceed until Closed

If maintainers ask questions or request changes, respond within 48 hours. If you don’t have time to iterate on feedback, then you don’t really have time to submit the PR. Abandoned pull requests are worse than no pull requests as it promotes a “throw it over the fence” mentality.

7. Respect the “No”

If maintainers close your PR or reject your approach, accept it gracefully. They understand the project better than you do. This is particularly important when AI has convinced you that your solution is correct. We hope this list provides a safe list for engineering teams to get utilise. The common thread within all of them is about ownership. Mitchell Hashimoto put it clearly: “As a reviewer, I do not care what the AI said. The AI output is noise. I want to see the contributor’s thinking.”

The Corporate Responsibility Gap

There is an uncomfortable truth behind the pattern we have seen with Open Source projects thus far in 2026 crisis. Organisations consuming open source tools and infrastructure are often not contributing to their sustainability. Your Kubernetes deployment depends on 234 other CNCF projects, and your cloud native architecture relies on volunteers to review PR’s, triage issues, and maintain code. All of this while doing their actual job.

Big tech and enterprise organisations have built trillion-dollar businesses on open source foundations. They’ve often hired hundreds, if not thousands, of engineers who use these tools daily. Yet maintainer burnout is at an all-time high because contribution remains optional, sponsorship remains modest, and the burden of sustainability still falls on volunteers.

Our LiveWyer recommendations for IT leaders

Infrastructure sustainability is everyone’s responsibility, so we’ve put together a series of steps for IT Leaders to do their part when it comes to Corporate Responsibility and IT Stewardship.

Short term wins

Understand & scrutinise dependencies: Track which projects you depend on. You can use SBOM tools to map your dependencies, and identify single points of failure in your infrastructure. In addition, you can analyse how many maintainers they have, when was the last meaningful commit, and what does the contribution ratio looks like.

Create contribution quotas: Make open source contribution a performance expectation. If your codebase depends on open source libraries, dedicate a percentage of engineering time to contributing back. We encourage you to track it, reward it and even make it part of promotion criteria. While this will not create an immediate ROI, this is about reducing technical debt, increasing resilience and mitigating the associated financial and reputation risks.

Longer term stewardship goals

Hire full-time maintainers: Sponsoring projects is somewhat helpful, but putting engineers on your payroll whose job is to maintain the open source projects you depend on is a much more pro-active solution. Let them spend 100% of their time on upstream contribution, and mark it down as infrastructure investment.

Support maintainer succession: Many critical projects have a single maintainer. Encouraging junior maintainers or even creating apprenticeship programs will help future sustainability. There is a knowledge transfer problem which is critical to address.

Need help with your infrastructure modernisation?

At LiveWyer, we have guided numerous organisations through complex Kubernetes infrastructure transitions, helping them evaluate options, plan migration strategies, and execute changes without service disruption.

Contact us to learn how we can help you modernise your infrastructure whilst strengthening your Business’ foundations for future growth.