从今天起，Ladybird浏览器项目将不再接受外部Pull Request（代码合并请求）。
一个浏览器项目宣布关闭所有外部代码贡献通道，只让内部维护者提交代码。这不是倒退，而是面对AI浪潮，一次关于“信任”的紧急撤退。
大教堂归来：一个浏览器项目为何“闭关锁国”？
Ladybird，这个备受关注的开源浏览器项目，刚刚扔下一枚重磅炸弹。项目方宣布，即日起不再接受任何来自社区公众的Pull Request，所有代码变更将仅由项目维护者内部引入。
他们给出的理由很直接：项目即将进入首个Alpha测试阶段，需要更紧凑的开发流程、更清晰的安全模型，以及一个更小、责任更明确的代码提交者圈子。
简单说，Ladybird决定从人声鼎沸的“市集”模式，回归到秩序森严的“大教堂”模式。
“善意”失效：AI如何碾碎开源世界的信任基石
这背后的导火索，是AI。
Ladybird团队在公告中写了一句被高频引用的关键话：“一个庞大的补丁曾意味着大量的努力，而这种努力曾是善意的合理代理。这一假设如今不再成立。”
在过去几十年的开源世界里，贡献代码是建立信任的核心路径。你来，提交补丁，负责，留下来。信任，是在一次次具体的贡献中自然生长的。
但AI改变了这一切。生成一个看起来“像模像样”的复杂补丁，成本变得极低。对一个浏览器项目而言，这致命的风险在于：它运行来自整个互联网的不可信代码。一个伪装良好的漏洞，就足以攻陷整个系统。
“我们已经看到过在开源项目中耐心、资源充足的渗透活动，目的是骗取维护者的信任并滥用它。”Ladybird团队透露。而AI的出现，只是让生产这种“看似认真的贡献”的速度变得快了无数倍。
社区的撕裂：这是进步，还是背叛？
消息一出，社区反应激烈。
支持者认为这是必要且明智的：“我理解他们的出发点。如果大多数PR都是AI生成的，那维护者们自己也能通过提示词让Claude Code去完成。”
但反对的声音同样震耳欲聋。
一条评论尖锐地指出：“这留下了一种怪味。因为作者本人经常提交超过1000行代码的PR，并且当天合并，完全没有评审。”这暗示了项目内部可能存在双重标准。
更让一些贡献者感到愤怒的，是一种被“背叛”的体验。有用户在热门评论中写道：“我发现了一个Bug，我修复了它，但我不被允许告诉他们我是如何具体修复的。相反，他们必须重新弄清楚。团队一定很乐意反复去做别人已经完成的工作吧？”
这种挫败感很真实。一位观察者感慨道：“当AI刚出现时，我害怕失业。现在，我看到社区正在受到影响。当你砍掉PR，你杀死的不仅是代码贡献，更是那些无形的、建立在贡献之上的社区纽带。”
行业的镜子：谁更“开放”？
Ladybird的决定，在浏览器引擎的江湖里，意外地照出了一面有趣的镜子。
有评论一针见血：“看到Chromium、Gecko、WebKit现在在‘是否接受外部代码’这一点上，比Ladybird更‘开放’，这真是有趣。”
的确，谷歌、Mozilla、苹果管理的巨型浏览器项目，依然维持着庞大的外部贡献体系。Ladybird作为资金和人力相对紧张的创业项目，选择收缩防线以节省审查成本，这可以理解。但它也让人们意识到，维持开源的“开放”，原来是一件如此昂贵的事情，需要巨大的经济资源来支撑。
这或许也是开源理想在现实中的一次务实妥协。当“信任”的验证机制被技术颠覆时，小项目为了自保，只能选择关闭那扇曾经象征着理想主义的大门。
留下的疑问：开源的未来在哪里？
Ladybird强调，项目依然是开源的。代码仍然在开源协议下公开，外部的Bug报告、测试、讨论依然被欢迎。
但“只读开源”和“可读写开源”，终究是两种温度。
一个深刻的悖论浮出水面：开源运动原本旨在通过开放协作来建立信任和改进软件。而如今，在AI时代，一个开源项目为了自身安全和可控，必须首先选择“不信任”和“封闭”。
这不仅是Ladybird一家的困境。正如另一条评论所问：“这次我好奇的是，作为一直站在场边欢呼的人，是否还有任何方式能让大家在未来参与进来，还是说这实际上是一个永久性的封闭项目？”
开源精神的火种，究竟该如何在一个代码可以自动生成、信任成本急剧升高的世界里，继续传递下去？
【锐评】：当开源项目需要靠“闭源”来捍卫安全和初心时，这可能是对“AI生产力”最辛辣的讽刺，也是给整个开源社区一记清醒的耳光。
参考链接：
https://ladybird.org/posts/changing-how-we-develop-ladybird/