AI entered software development at full speed this year, and it is significantly impacting open-source projects as well. In this article, I discuss several trends I have recently observed in open source in connection with AI, and how these trends are changing the world of open-source software.

This article was originally published on my Czech blog, but it received such an overhelming response that I decided to translate it into English and publish it here as well.

Project Inflation

One of the trends that AI brings in general is an explosion of content. Search results are filled with generated websites, and social networks are inundated with generated images and videos. Source code is no exception. Today, GitHub is drowning in an ever-increasing number of repositories.

However, it is not as if a larger number of high-quality projects are being created. On the contrary, these are projects where you have no idea whether you can rely on them or not. In the past, if you stumbled upon a more extensive project with thousands of lines of code, there was a certain assumption that if someone went to the trouble of creating something like that, they would have some knowledge of the problem, a personal connection to their creation, and some willingness to maintain it going forward.

You can no longer rely on this at all. Today, you can generate a project with several thousand lines of code in a matter of moments. It could be complete nonsense or even something dangerous; it could be something functional that someone generated for their own immediate needs and posted to GitHub, but with no interest in turning it into an open-source project. Because a repository with code doesn’t make an open-source project. The difference between a piece of code on GitHub and an open-source project is that an open-source project solves problems and use cases for its users, not just the author’s one-off need. And most authors of such quick-and-dirty code simply aren’t interested in doing that.

This is clearly visible in projects like MeshCore, for instance. There are dozens of forks of everything imaginable. Missing a feature in the official MeshCore firmware? You just fork it, vibe-code the missing piece, and dump it on GitHub as MeshCore-UltimateEdition. The problem is that it was created with minimal effort, the author usually has no relationship to it, gets bored after a month, and it becomes abandonware before it even has a chance to age.

About ten years ago, people started saying that the concept of Linux repositories had run its course. In the 2000s, they were practically the only source of Linux software. If a project didn’t make it into distribution repositories, it had a problem. But then the number of open-source projects grew at such a rate that distributions couldn’t keep up. Users had to start getting their software elsewhere, and software authors learned to do without distributions. Just a few years ago, the “everything I need, I find in Debian” approach seemed definitively dead.

However, it is possible that curated software sources – like Linux distribution repositories – will make a comeback. The open-source software world is becoming so chaotic that users will once again start appreciating sources containing curated software that someone has vetted for them and that they can rely on six months down the road.

Review Overwhelm

Another trend that AI has triggered in open source is ‘review overwhelm’. Previously, writing code acted as a natural filter because it required a non-trivial amount of effort and time investment. That is now gone, making code creation fast and easy. But someone still has to review this code before it goes into serious production. The review processes that worked in open-source projects for years are now at their capacity limits.

In GNOME 50, support for Google Drive was removed because nobody had been maintaining it for a long time. Users were naturally unhappy about it, and eventually, one user stepped up, re-added the support, and submitted it upstream to the gvfs project.

A colleague responsible for maintaining that project lamented that it was a change involving 4,000 lines of code. Even though it seems to work at a basic level, it was clearly generated using AI. He will still have to go through it line by line to verify that it actually works as intended and meets the code quality standards required to commit to maintaining it long-term.

Most of the effort has thus shifted from code creation to code review, which is typical for AI. The problem in open source, however, is that developers experienced enough to review and merge code were already a bottleneck before AI. Now, the problem has deepened significantly. And in the example above, my colleague can count himself lucky that the contributor is responsive and has shown long-term interest in the issue.

Today, that is more of a rare exception. Common contributions consist of someone wildly vibe-coding something without any deeper interest or understanding of the subject, and throwing it over the wall to the maintainers.

I have a fairly recent experience with this in Meshy. Someone submitted a pull request with 9,000 lines of changed code, which was supposed to add support for macOS. I spent an hour one evening doing a very quick review, and even during that short time, I ran into numerous issues: the code was blatantly AI-generated, several thousand lines were just completely useless replacements of single quotes with double quotes, parts of the code unrelated to the problem were modified, and it overwrote all the changes I had made in the main branch over the last few weeks.

The author never responded to my comments and I never heard from him again. My takeaway was that even that one hour was too big of a time investment for contributions like that, and next time I will reject them much faster.

Some projects are responding to this situation by tightening basic contribution requirements. For example, Flathub’s decision to reject AI-generated apps caused quite a stir. Many people criticized it as shooting themselves in the foot, but you have to look at their reality.

Flathub currently hosts several thousand apps, with more added every day. Only three people handle the reviews. Although their review process is highly automated, they do it very thoroughly, and a lot of manual input is still required. It’s clear their goal isn’t just to spot the worst slop, but to maintain a relatively high standard of code hygiene. In the last six months, I submitted two apps to Flathub, and the review process ultimately contributed to improving the quality of the apps themselves.

However, this has now clashed with the reality of people submitting completely vibe-coded apps without a shred of personal effort. The ticket template for requesting inclusion asks a few questions, including a requirement to upload a short video showing how the app works. It really isn’t demanding, and anyone can put it together in 15 minutes. Yet even that is too much effort for creators of AI slop.

Instead of fulfilling these minimal requirements, some labeled it an attack on Linux’s freedom and immediately vibe-coded an alternative to Flathub that was supposed to be open to everyone. Unsurprisingly, it barely lasted a month.

Not only do open-source maintainers lack the capacity to satisfy this demand for code review, but they are also losing the motivation to do it. Often, it would be faster for them to write the feature themselves, but the review process was historically how they cultivated new long-term contributors and potential successors. When someone sends you a vibe-coded contribution that cost them zero effort and which they likely don’t even understand, how do you expect to mentor them into a contributor who will help the project in the long run?

Open-source software was never just about the end result; it was also about the process – where contributors build a relationship with the project and grow into someone who will eventually pass that on to others. This stands in sharp contrast to the world of AI, where it’s all about the result. As fast as possible, with as little effort as possible.

Declining Motivation to Publish Code

In the 1990s, Francis Fukuyama declared democracy and liberal economics to be the ultimate victors in the arrangement of the world order. Today, as democracy erodes globally and the existing economic order crumbles, that looks like a prematurely bold statement to say the least. Similarly, just a few years ago, impressed by the developments of the last few decades, some hailed open source as the ultimate winner among software development models. Are we about to face a sobering reality check similar to Fukuyama’s thesis?

Lately, I’ve been observing a subtle, yet present trend of stepping back from open-source development. One argument against open development I hear concerns the aforementioned review overload. For some projects, the costs associated with being overwhelmed by AI slop can outweigh the benefits of useful community contributions. They might still publish the source code for transparency’s sake, but they transform from an open-development project into an open-source, closed-development project. And those who don’t care as much about transparency may close off the source code entirely.

Another argument against making source code public is the fear of license circumvention. Today’s LLMs train on source code regardless of its license and can then easily generate a similar solution that you can publish under whatever license you choose.

This isn’t an issue for permissive licenses, as the author has already accepted that anyone can do practically whatever they want with the code. However, AI poses a direct threat to copyleft licenses like the GNU GPL. Authors usually choose these to ensure their work remains open forever and that anyone who uses it shares their improvements back with the community. If an LLM trains on a project you’ve worked on for years and then generates a very similar solution published under a proprietary license, it effectively bypasses this principle.

Take MeshCore again as an example: the protocol itself and the firmware are open-source, but the clients are closed. Recently, it came to light in the community that a core team member secretly applied for the MeshCore trademark and started vibe-coding his own closed-source solutions based on the available code. MeshCore founder Scott Powell cited this as something that reaffirmed his decision to keep the client source code private. Specifically, he wrote:

So, I see open source, in the age of AI, as offering up your blood, sweat and tears for others to rip-off, but in innumerable ways.

We may disagree with Powell’s perspective, but it represents a legitimate stance that I see more and more often around me. I see lifelong open-source advocates – people who used to publish every last helper script because they wanted to share – who now keep those things to themselves, offering them to others only upon request. They have reasons similar to Powell’s.

Open source also grew out of the need to share. Writing code was hard; maintaining it was even harder. Why should everyone implement the same thing independently? Let’s join forces in an open-source project, write a shared library, and everyone can benefit from the results. The infrastructure powering the Internet today was built on this foundation. But AI is suppressing this need.

For instance, I encounter opinions that WordPress is dead because “I can just easily generate my own CMS.” In my view, that severely underestimates what an open-source project actually provides. It is so much more than just writing code, and this strategy of swapping a dependency on an open-source project for a dependency on an LLM might not pay off in the long run.

Nevertheless, the reliance on shared open-source components has indeed decreased to some extent. AI might not replace everything, but why depend on a large external library when you don’t even need 10% of its functionality, if AI can quickly rip off that 10% for you after learning from the original library? And once you have your own implementation, why would you contribute improvements back to a shared open-source project?

The final argument against publishing source code that I’ve been hearing lately is security. Granted, I’ve heard this argument throughout the two decades I’ve been involved in open source, but it has never been this loud. For years, critics have claimed that open source is insecure because it allows attackers to study the code and hunt for vulnerabilities. In response, open-source advocates argue that security through obscurity is not real security and that open-source software is safer because “given enough eyeballs, all bugs are shallow.”

Today, however, open-source projects are literally flooded with security vulnerability reports generated by AI. The volume is so unprecedented that it is genuinely easy to fall into the trap of believing closed code is safer. It’s interesting to note that while news headlines cover how many bugs AI has found, they rarely mention how many security bugs AI has fixed. Fixing them still requires a deep understanding of the codebase and is still done by human programmers. And just like reviewing pull requests, it is overwhelming their capacity.

In this case, though, I believe it’s just a temporary trend. Open-source projects will eventually wade through these security reports, the general security of maintained open-source software will improve, and the ecosystem will benefit in the end. As for the other trends mentioned in this article, it’s hard to say. I’m not quite as unconditionally optimistic there.