AI 如何改变开源世界
英文标题：🔶 How AI Is Changing Open Source
AI 正在迅速改变开源软件生态：代码和仓库数量激增，但大量低质量、缺乏维护意愿的项目也让用户更难判断其可靠性。AI 生成代码将开源项目的瓶颈从编写代码转移到审查代码，而经验丰富的维护者本已稀缺，正被海量低质量贡献进一步压垮。文章指出，审查负担、许可证被规避的担忧以及安全报告泛滥，可能促使部分项目从开放开发转向闭源或仅公开源码。对开发者和行业而言，AI 降低了代码生产门槛，却可能削弱开源协作、长期维护和贡献者培养这些更核心的机制。
12.1 KB
8.4 KB
68.7 KB
65.3 KB
72.0 KB
20.6 KB
13.9 KB
5.6 KB
28.9 KB
16.6 KB
4.5 KB
13.0 KB
2.7 KB
10.9 KB
15.5 KB
12.5 KB
69.5 KB
3.4 KB
17.3 KB
26.8 KB
中文
今年，AI 全速进入软件开发领域，也正在显著影响开源项目。本文讨论我近期在开源领域观察到的几项与 AI 相关的趋势，以及这些趋势如何改变开源软件的世界。
本文最初发表于我的捷克语博客。由于反响极其热烈，我决定将其译为英文，并也在这里发布。
项目膨胀
AI 带来的总体趋势之一，是内容的爆炸式增长。搜索结果被生成式网站填满，社交网络也充斥着生成的图片和视频。源代码同样不例外。如今，GitHub 正淹没在数量不断增加的代码仓库之中。
然而，这并不意味着高质量项目的数量也在增长。恰恰相反，其中许多项目让人根本不知道是否值得信赖。过去，当你偶然发现一个拥有数千行代码的较大型项目时，人们通常会有一种基本预期：既然有人愿意花力气做出这样的东西，他应该对问题有所理解，与自己的创作有个人联系，并且愿意在未来持续维护它。
如今，你已经完全不能再依赖这种预期。现在，只需片刻就能生成一个拥有数千行代码的项目。它可能完全是无意义的东西，甚至可能有危险；它也可能是某人为满足自己当下需求而生成、随后发布到 GitHub 的可用工具，但作者并没有兴趣把它发展成一个开源项目。因为，一个包含代码的仓库并不等于一个开源项目。GitHub 上的一段代码与开源项目的区别在于：开源项目解决的是其用户的问题和使用场景，而不只是作者一次性的需求。而大多数这类快速拼凑代码的作者，根本无意去做这些事。
这一点在 MeshCore 之类的项目中非常明显。例如，几乎所有东西都有几十个 fork。官方 MeshCore 固件缺少某项功能？你只需要 fork 一份，用氛围编程（vibe-coding）补上缺失部分，然后以 MeshCore-UltimateEdition 的名字丢到 GitHub 上。问题在于，它的创建成本极低，作者通常与其没有任何联系，一个月后就会失去兴趣；它甚至还没来得及变老，就成了无人维护的软件。
大约十年前，人们开始说 Linux 软件仓库的概念已经走到尽头。2000 年代，它们几乎是 Linux 软件的唯一来源。如果一个项目无法进入发行版仓库，就会面临问题。但后来，开源项目的数量增长速度快到发行版根本跟不上。用户不得不从其他地方获取软件，软件作者也学会了绕开发行版生存。就在几年前，“我需要的一切都能在 Debian 里找到”的方式似乎已经彻底死亡。
不过，经过筛选的软件来源——例如 Linux 发行版仓库——有可能重新流行起来。开源软件世界正在变得如此混乱，以至于用户会再次开始重视那些包含经过筛选的软件、有人替他们审核过、并且六个月后仍可依赖的来源。
审查过载
AI 在开源领域引发的另一项趋势是“审查过载”（review overwhelm）。此前，编写代码本身是一道天然过滤器，因为它需要投入不可忽略的时间和精力。如今，这道过滤器消失了，创建代码变得快速且容易。但在这些代码进入严肃的生产环境之前，仍然需要有人审查。多年来在开源项目中有效运作的审查流程，如今已达到容量上限。
在 GNOME 50 中，由于长期无人维护，Google Drive 支持被移除了。用户自然对此感到不满，最终有一名用户站出来，重新添加了该支持，并将其提交到上游的 gvfs 项目。
一位负责维护该项目的同事感叹，这是一项涉及 4,000 行代码的改动。尽管它在基本层面上似乎可以运行，但显然是使用 AI 生成的。他仍必须逐行检查，以验证它是否真的按预期工作，并符合长期承诺维护该代码所需的代码质量标准。
因此，大部分工作已经从创建代码转移到了审查代码，这正是 AI 的典型特征。不过，开源的问题在于：在 AI 出现之前，拥有足够经验、能够审查和合并代码的开发者就已经是瓶颈。现在，这个问题明显加剧了。而在上面的例子中，我的同事还算幸运，因为该贡献者会回应，并且表现出对这个问题的长期兴趣。
如今，这种情况更像是罕见的例外。更常见的贡献方式是：有人毫无节制地对某个东西进行氛围编程，对主题既没有深入兴趣也没有理解，然后把结果直接扔给维护者。
我最近在 Meshy 中就有过这样的经历。有人提交了一个 pull request，改动了 9,000 行代码，声称要增加对 macOS 的支持。某天晚上，我花了一小时做非常粗略的审查；即使在这么短的时间内，我也发现了大量问题：代码明显由 AI 生成，数千行代码只是毫无意义地把单引号替换成双引号；与问题无关的代码部分被改动；它还覆盖了我过去几周在主分支中做的所有修改。
作者从未回复我的评论，此后我也再没有听到他的消息。我的结论是，即便只是那一个小时，对于这类贡献来说也是过大的时间投入；下一次，我会更快地拒绝它们。
一些项目正通过收紧基本贡献要求来应对这种局面。例如，Flathub 拒绝 AI 生成应用的决定引发了相当大的争议。许多人批评它是在自断前路，但你必须看看他们所面对的现实。
Flathub 目前托管了数千款应用，而且每天仍有更多应用加入。只有三个人负责审查。虽然他们的审查流程高度自动化，但执行得非常彻底，仍然需要大量人工参与。显然，他们的目标不只是找出最糟糕的垃圾内容，而是维持相对较高的代码卫生标准。过去六个月里，我向 Flathub 提交了两款应用，审查流程最终也帮助提升了应用本身的质量。
然而，这种机制如今与另一种现实发生了冲突：人们提交完全靠氛围编程制作、没有投入一丝个人努力的应用。申请收录的工单模板会提出几个问题，其中包括要求上传一段展示应用如何工作的短视频。这其实并不苛刻，任何人都能在 15 分钟内完成。然而，即使是这样一点工作，对于 AI 垃圾内容的制作者而言也嫌太多。
一些人没有满足这些最低要求，反而将其称为对 Linux 自由的攻击，并立刻氛围编程出了一个替代品，作为一个理论上向所有人开放的 Flathub 替代方案。毫不意外，它几乎只维持了一个月。
开源维护者不仅没有足够能力满足这种代码审查需求，也正在失去审查的动力。对他们来说，自己编写某项功能往往会更快；但在历史上，审查流程也是他们培养新的长期贡献者和潜在继任者的方式。当有人向你提交一份没有花任何力气、并且他们很可能连自己都不理解的氛围编程贡献时，你要如何期待把他们培养成能长期帮助项目的贡献者？
开源软件从来不只是结果，也关乎过程——贡献者在其中与项目建立联系，并成长为最终能将这种关系传递给他人的人。这与 AI 世界形成鲜明对比：AI 世界一切只看结果，越快越好，越省力越好。
发布代码的动力正在下降
20 世纪 90 年代，弗朗西斯·福山（Francis Fukuyama）宣称，民主和自由经济将成为世界秩序安排中的最终胜利者。如今，随着民主在全球范围内受到侵蚀、既有经济秩序逐渐瓦解，这一说法至少看起来过早且过于大胆。类似地，就在几年前，一些人还因过去几十年的发展而对开源印象深刻，并将其誉为软件开发模式中的最终赢家。我们是否也即将面对一次类似于福山论点的清醒现实检验？
近来，我一直观察到一种微妙但确实存在的趋势：人们正从开源开发中后退。我听到的一个反对开放式开发的理由，是前文所述的审查过载。对一些项目而言，被 AI 垃圾内容淹没所带来的成本，可能超过有价值社区贡献带来的收益。它们可能仍会为了透明度而发布源代码，但会从开放开发项目转变为开源、闭源开发模式的项目。至于那些不太在意透明度的人，则可能会完全关闭源代码。
另一个反对公开源代码的理由，是对许可证被规避的担忧。如今，LLM 会不顾源代码许可证进行训练，随后就能轻易生成相似的解决方案，而你可以选择以任何许可证发布该方案。
对于宽松许可证而言，这不是问题，因为作者本来就已接受任何人几乎可以对代码做任何事。但 AI 对 GNU GPL 这样的 copyleft 许可证构成了直接威胁。作者通常选择这类许可证，是为了确保其作品永远保持开放，并要求任何使用它的人将改进成果回馈给社区。如果一个 LLM 使用你多年投入的项目进行训练，随后生成非常相似的解决方案，并以专有许可证发布，它实际上就绕过了这一原则。
再次以 MeshCore 为例：协议本身和固件都是开源的，但客户端是闭源的。最近，社区发现，一名核心团队成员秘密申请了 MeshCore 商标，并开始基于现有代码对自己的闭源解决方案进行氛围编程。MeshCore 创始人 Scott Powell 引用此事来说明，这进一步坚定了他将客户端源代码保持私有的决定。他具体写道：
所以，在 AI 时代，我认为开源意味着把你的鲜血、汗水和泪水交出去，任由他人以数不清的方式剽窃。
我们或许不同意 Powell 的观点，但这代表了一种正当立场，而且我在身边越来越频繁地看到这种立场。我看到一些终身的开源倡导者——过去他们会发布每一个辅助脚本，因为他们希望分享——如今却将这些东西留给自己，只在别人提出请求时才提供。他们的理由与 Powell 类似。
开源同样源于分享的需要。写代码很难；维护代码更难。为什么每个人都要独立实现同样的东西？不如在一个开源项目中联合起来，编写一个共享库，让每个人都能从结果中受益。如今支撑互联网的基础设施，正是建立在这一基础之上。但 AI 正在抑制这种需求。
例如，我看到一些观点称 WordPress 已经死了，因为“我可以很容易地生成自己的 CMS”。在我看来，这严重低估了一个开源项目实际提供的东西。它远不只是编写代码，把对开源项目的依赖换成对 LLM 的依赖，这种策略长期来看未必会有回报。
尽管如此，对共享开源组件的依赖确实在一定程度上减少了。AI 可能无法替代一切，但如果你根本不需要一个大型外部库超过 10% 的功能，而 AI 在从原始库中学习后可以迅速为你仿制那 10%，那你为什么还要依赖该库？而一旦你有了自己的实现，又为什么要把改进贡献回一个共享的开源项目？
我最近听到的最后一个反对发布源代码的理由是安全性。诚然，在我参与开源的二十年间，我一直听到这种论点，但它从未像现在这么响亮。多年来，批评者声称开源不安全，因为它允许攻击者研究代码并寻找漏洞。对此，开源倡导者认为，_通过模糊实现安全_并不是真正的安全，开源软件之所以更安全，是因为“只要有足够多的眼睛，所有 bug 都是浅显的”。
但如今，开源项目实际上正被 AI 生成的安全漏洞报告淹没。报告量前所未有，以至于人们确实很容易陷入“闭源代码更安全”的想法。值得注意的是，新闻标题会报道 AI _发现了_多少 bug，却很少提到 AI _修复了_多少安全 bug。修复漏洞仍然需要对代码库有深入理解，仍然由人类程序员完成。而这也和审查 pull request 一样，正在压垮他们的能力。
不过，在这种情况下，我认为这只是一个暂时的趋势。开源项目
English / 原文
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 originallypublished 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.