# When open-sourcing your code goes wrong... - Channel: [Fireship](https://www.youtube.com/channel/UCsBjURrPoezykLs9EqgamOA) - Published: 2026-02-26 - Source video: [Watch on YouTube](https://youtube.com/watch?v=wzzh7Not8XE) - Read on ReadTube: https://www.read.tube/p/videos/wzzh7Not8XE - Language: Simplified Chinese ## Summary **开源翻车史** 这段视频讲述了几个开源项目在爆红后又因资金、管理、技术路线或平台竞争而迅速衰落的故事，核心观点是开源并不自动带来成功，甚至可能在商业上反噬创作者。视频依次提到 Faker.js、Pars、Meteor、OpenSolaris 和火狐浏览器，说明有些项目因作者倦怠、有些因被收购后关停、有些因时代和架构不合适，还有些虽技术更好却输给了平台控制与分发优势。 这期视频总结了几个“开源后走红、却最终失控或衰落”的案例，核心结论是：开源能带来巨大传播和技术影响，但并不等于商业成功，尤其当项目依赖个人热情、公司收购、平台分发或时代窗口时，成功很容易反噬成失败。 - 有的项目因创始人倦怠而自然消亡，说明个人驱动型开源很脆弱。 - 有的项目在爆红后因维护者抗议无偿劳动而引发危机，甚至导致源码被删除。 - 有的项目被大公司收购后直接停更，证明控制权比代码开放更关键。 - 有的项目技术上先进，却因架构复杂、扩展性差或时机过早而被市场抛弃。 - 最典型的教训是：开源可以赢技术口碑，但无法战胜平台分发和商业权力；即使最终失败，也可能间接推动行业进步。 ## Article ### 前所未有的开源崛起：一个失败项目如何冲到二十万以上星标 程序世界最近见证了某种前所未有的事情：一个开源项目在宇宙历史上最快的崛起。一个从失败的副业项目，在短短几周内冲到 **超过 200,000 个 GitHub 星标** 的项目。一个已经被 OpenAI 收购、据说金额大到离谱的项目。 这个项目当然就是 **OpenClaw**，一个其实也没比基础的 JavaScript AI 说唱工具强多少的东西。但大多数人没有意识到的是：你今天使用的每一款软件，都是建立在巨人的肩膀上。可悲的是，其中很多巨人早就在很久以前的战斗中倒下了。 几乎每一款有意义的软件，都是由极具创造力和才华的程序员用**血、汗与泪**打造出来的。令人沮丧的是，几乎所有这些程序员都没能从自己的创造中收获荣耀和金钱。 今天我们要看五个开源项目的故事：它们先是经历了流星般的崛起，然后又在自己成功的重压下崩塌。 现在是 **2026 年 2 月 26 日**，你正在收看《代码报告》。 --- ### 从乐器到商业产品：背后消失的创造者 昨天我还在用 **Arteria Microreak** 摆弄一些很带感的节拍。但我没有意识到，这个商业产品其实建立在 **Mutable Instruments** 背后那位开发者 **Emily Glay** 的惊人工作之上。 这是一个非常厉害的工具，能够让声波做你能想象的一切。它是用 **C++** 手工编写的，但后台始终有一个问题：**倦怠**。 这个项目由一位独立经营者管理，她只是想要生活中别的东西。当她决定转向一个新事业时，这个项目就简单地淡出了。 但老话说得好：**与其逐渐消退，不如轰然燃尽。** 而这正是一个名叫 **Faker.js** 的热门项目所发生的事——它以一种极其壮观的方式“燃尽”了。 #### Faker.js：把删除源代码当作抗议 Faker 是一个 JavaScript 库，每周下载量达到数百万，作用是生成假数据。这东西对自动化测试很有用，也很适合给你的社交媒体应用“刷”出数百万个假用户，好从风投那里拉到钱。 但在 2022 年某个决定命运的日子里，开发者 **Marak Squires** 做了一件大胆的事。他删除了源代码，把内容替换成 **endgame**，然后在 npm 上发布了 **6.6.6** 版本。 这一下直接让成千上万的 JavaScript 应用在更新依赖时当场炸裂。 依赖他工作成果的公司们，愤怒得完全合情合理。但他自己也很愤怒，因为自己一直在做没有报酬的免费工作，于是把这次更新当作抗议。 不幸的是，他后来被赶出了自己的项目，这个项目则被新开发者接手，并且今天仍然活着。 --- ### 即便有资金和大团队，项目也可能死掉：Pars 的结局 但有时候，即使是资金充足、团队很大的项目，也依然会失败，比如 **Pars**。 在 **Superbase 1** 之前，甚至在 **Firebase 1** 之前，早在 **2011 年** 就已经有一个叫 Pars 的 **后端即服务** 项目，为移动应用提供数据库和认证功能。 开发者们非常喜欢它，以至于 **Facebook** 在 **2013 年以 8500 万美元**收购了它——放在当时，这已经算很多钱了。这也让项目获得了业内最有才华的开发者。 但仅仅几年后，在 **2016 年**，它被 Facebook 关闭并终止。任何使用它的开发者都被迫迁移到新平台。 扎克决定，托管移动应用基础设施是在浪费时间。 不过这个故事还有一个半圆满的结局：**pars server** 背后的代码被开源了，这让开发者可以自行托管并独立维护它。 --- ### Meteor：比时代早一步，也因此走得太早 如果你是那个年代的老开发者，你可能还记得另一个项目：**Meteor**。 它是最早的一批在“全栈 JavaScript”还没流行之前就这么做的框架之一。 在 **2013 年**，**Ruby on Rails** 正火得一塌糊涂，但 Meteor 看起来像是下一个大热门，因为它能做同样的事情，只不过完全依赖 **JavaScript**，而不是那种优美但有点深奥的 Ruby 语言。 它的设计还使用了 **websocket 连接** 和 **有状态服务器** 来执行即时 UI 更新，在早期演示里那种感觉非常神奇，但这也正是问题的一部分。 当应用进入生产环境后，它们很难维护，而且在云中也不容易水平扩展。 几年后，当 **React** 和 **Angular** 登场时，开发者们决定最好还是把客户端和服务器重新分开。于是它的受欢迎程度慢慢沉入深渊。 讽刺的是，未来像 **Next** 这样的框架又会重新引入这些相同的概念。 所以，时机在软件世界里很重要，而 Meteor 只是生得比时代早了一点。 不过，实际上也许时机并不是一切。 --- ### OpenSolaris：技术上更强，但输在所有权变化 比如 **2005 年的 OpenSolaris**。 那时候，**Linux** 已经是服务器上占主导地位的开源操作系统。但这匹更强的“新马”是基于 **Sun Microsystems** 的 Solaris Unix 进入赛道的。 它拥有 **ZFS 文件系统**、**DTrace 可观测性**，甚至在 Docker 诞生之前就已经有了 **容器**。 从纸面上看，它显然是更好的操作系统。 但后来，在 **2010 年**，一件非常糟糕的事情发生了：**Oracle 收购了 Sun Microsystems**。几乎在一夜之间，这个项目的未来蒸发了。 开放开发停止了。源代码发布悄悄消失，社区意识到这场实验结束了。 Oracle 把 Solaris 重新关回了闭门状态，以保护自己强迫开发者 fork 最后可用代码的企业业务。 所以即便它时机不错，而且在技术上非常出色，它还是失败了，因为**所有权变了**。 --- ### 火狐的诞生：开源成功了，但商业上已经输了 也许有史以来最壮观的开源失败，就是你绝对想不到的那个：**Mozilla Firefox**，它就是“开源代码搞砸了会怎样”的典型例子。 你看，在 **1990 年代**，**Netscape** 主导着浏览器市场份额，但微软也想分一杯羹。 于是微软做了什么？它把 **Internet Explorer** 直接捆绑进 Windows，把浏览器变成默认免费工具，而不是你必须主动选择购买的产品。 当 Netscape 开始失去市场份额时，他们的回应极端得很：把浏览器开源，并号召全网站到自己这边。 互联网为此欢呼，但问题是代码一团糟。最终，这些代码变成了 **Mosilla** 项目，而这场过渡简直是一场噩梦，需要几乎彻底重写所有遗留代码。 与此同时，Internet Explorer 仅靠分发优势迅速获取新用户。 但等到 Mosilla 最终做出 **Firefox** 时——它更快、更安全，也更好——Netscape 本身已经死了。 这家公司输掉了浏览器战争，证明了开源可以造出更好的软件，但它**打不过平台控制和分发**。 不过很讽刺的是，那场失败反而复活了浏览器竞争，并为现代网络奠定了基础。也就是说，Firefox 在商业上先输掉，才在技术上成功。 --- ### 2026 年还想开源翻车？先看看 Code Rabbit 但如果你梦想在 **2026 年** 自己打造一个失败的开源项目，你需要知道今天视频的赞助商：**Code Rabbit**。 他们刚刚推出了一个新功能，可以让你自定义他们的 AI 代码审查工具如何撰写拉取请求摘要。 所以你不必再浪费时间去解读团队的 PR，你和你的团队可以告诉 Code Rabbit：你们希望在每个摘要里看到什么信息。 比如在这里，我们写了一个文档，让它在摘要中包含**改了什么**以及**为什么改**，并且对任何**分支变更**或**新依赖**做特殊标注。 Code Rabbit 会按照这些指令运行，确保每个 PR 都有一个清晰的摘要，让每个人都能快速扫一眼。 它已经为开发团队节省了数百小时，而且你可以通过下面的链接免费试用。 --- ### 结尾 这里是《代码报告》。感谢观看，我们下一期再见。