• GitHub 之前的世界：声誉驱动，充满摩擦
• Git 本该去中心化，结果反而养出了最大的中心
• GitHub 真正做了什么
• npm 和依赖爆炸
• GitHub 正在衰退
• 分散化的真正代价
• 我们需要什么样的档案馆

Armin 最早的开源项目放在 SourceForge 上，后来他跟 Georg Brandl 一起搞了个叫 Pocoo 的团体，自己搭 Trac、管 Subversion 仓库、维护邮件列表、发布 tarball，自己当系统管理员。在那个时候，你想发布软件，就得同时学会运维。

这不是个别现象。SVN 是中心化的版本控制系统，天然需要一个服务器，所以每个项目都有一个"家"：一个主机名、一个目录、一个 Trac 实例、一个邮件列表归档。项目有地盘，地盘有人管。

这种高摩擦带来了一个副作用：开源的"人际信任网"。你知道哪些项目维护了很久，你知道维护者是谁，你熟悉那些邮件列表，你知道谁在社区里混了多年攒下了信誉。Debian 的人会跑来挑你许可证的毛病、检查版权头是否合规。烦人是烦人，但这也意味着有人在把关。

依赖也不是随便加的。加一个依赖意味着你得搞清楚它从哪来、谁在维护、有没有持续发布。很多依赖干脆直接 vendoring 到自己的 SVN 树里，因为那个年代的自动化抓取脚本太痛苦了，与其依赖别人的服务随时在线，不如把代码拷进来。

GitHub 出现之前的开源世界，摩擦本身就是一种筛选机制。你不付出一定成本，就没资格在开源圈子里刷脸。

当 Mercurial 和 Git 出现时，它们在哲学上是 SVN 的反面。分布式意味着每个人都有完整仓库，每个人都可以有自己的分支、自己的历史。按理说，分布式版本控制系统应该降低对单一中心的依赖。

但现实走向了完全相反的方向。

GitHub 成了那个中心。全世界标准化了一个巨大的中心化服务来托管分布式的 Git。这是 Armin 眼中现代开源最大的反讽：分布式版本控制系统赢了，然后所有人选了一个超级中心来用它。

这不是 Git 的设计缺陷。Git 本身是为"多个家"设计的。是 GitHub 的产品体验太好，好到所有人都愿意把家搬过去。

Armin 列了 GitHub 的一串贡献：降低创建项目的门槛、让项目可被搜索发现、让不熟悉邮件列表的新人也能参与协作、提供 issue tracker、pull request、wiki、CI、API、webhook。这些贡献实实在在，但 Armin 认为 GitHub 最被低估的是另一件事：

它成了一座图书馆。

因为 GitHub 是中心，所有开源代码都放在同一个地方，它自然成了整个软件世界的统一目录。即使是废弃的项目仍然可以被找到，fork 关系清晰可见，旧 issue 和讨论永远在线。这种"可发现的记忆"不是任何去中心化系统天然具备的。Armin 自己的早期项目看起来还在 PyPI 上，但实际包文件早已随着他的旧服务器一起消失了。在 GitHub 之前，这是常态：域名过期、VPS 关停、开发者去世，他们维护的服务也跟着消失。

GitHub 的领导层曾经认真对待这件事：即使在最严厉的美国制裁下，他们也努力让伊朗开发者能继续访问 GitHub。

集中化带来了可发现的记忆。去中心化则意味着每个项目独立维护自己的历史，而历史很容易被遗忘。

微依赖问题不只是因为有人喜欢发 11 行的 npm 包。GitHub 和 npm 的组合降低了发布、发现、安装、依赖每个环节的摩擦感。当一切几乎零成本，包的依赖图就能以超出任何人推理能力的速度膨胀。

在 GitHub 之前，声誉和寿命几乎是被动融入依赖选择过程的。你得认真考虑是否要添加一个依赖，因为自动化程度低，加依赖很麻烦。在npm 生态里，这个功课被跳过了。GitHub 后来试图弥补这一点，措施包括通过 terms of service 澄清 license 问题，通过 trusted publishing 确保包的来源可信，但这些都是在一个已经膨胀起来的系统上修修补补。

更微妙的是，GitHub 慢慢成了信任体系的一部分：你看到一个 npm 包，会去看它的仓库，看维护者还在不在、issue 有没有人回、最近有没有改动、有没有别的项目在用。当 GitHub 本身的可信度在下降，影响的不只是源码托管，而是围绕它形成的整个供应链文化。

Armin 的话说得很直接：GitHub 正在慢慢死去。他认为问题不出在个别产品决策上，而是系统性衰退：产品不稳定、功能瞎折腾、Copilot AI 的噪音盖过一切、领导力缺失。

跟几年前不同，现在离开 GitHub 的不再是边缘项目或激进自由软件信徒。Mitchell Hashimoto 宣布 Ghostty 将离开 GitHub，Strudel 和 Tenacity 搬到了 Codeberg。Armin 说他发现自己最近访问非 GitHub 属地的频率明显比一年前高了。

他的态度很微妙：一方面认为去中心化对开源是健康的，Git 本来就是为多个家设计的；另一方面也清醒地知道，回到多 forge 时代意味着大量信息会再次丢失。

如果项目搬回自建的 forge、自己管的 Mercurial 或 cgit 服务器，代码在理论上仍然是分布式的（因为 Git），但社交上下文不是。Issue、代码审查讨论、设计决策、发布说明、安全公告、旧 tarball 链接，这些东西是脆弱的。邮件列表曾经承载了这些功能，但已经跟不上今天的协作需求，而且对普通用户极度不友好。

回到多中心意味着自主权回来了，不受微软领导层的喜好左右，不同社区可以选不同工作流。但代价是：网络会再次遗忘。

Armin 提出了一个也是他整个论述落点的诉求：需要一个公开的、沉闷的、资金充足的存档机构。它的目标不是去做最好的开发者工具、抢占市场份额，只是确保最重要的东西不会消失。源代码归档、发布制品、元数据，再加上足够的项目上下文让人理解来龙去脉。这些不该绑在一家公司的商业模式或领导层心情上。

GitHub 意外地成了那个档案馆，因为它是开源活动的中心。一旦 GitHub 不再是中心了，别指望会自动蹦出另一个档案馆来接替它。Google Code 和 Bitbucket 的结局就是前车之鉴。

Armin 说他真心希望 GitHub 能恢复过来，毕竟大量历史存在那里，而且依然留在 GitHub 的人继承了一件真正重要的东西。但他不再认为把开源的持续记忆押在 GitHub 一家公司上是个负责任的选择。

读完全文，我印象最深的是"摩擦"这个词的反复出现。在 GitHub 之前，开源世界的摩擦系数很高：建项目有门槛、加依赖有成本、参与协作要懂邮件列表礼仪。这些摩擦让人不爽，但也迫使人在行动前多想想。GitHub 用十年时间把这些摩擦磨平了，然后我们发现自己面对一个新问题：当一切都变得太容易，质量、信任、记忆这些"副产品"该由什么机制来保障？Armin 不想要回到那些断链的 tarball 和废弃的 Trac 实例。他想要的是在前二十年教训上搭建的下一代：把开源的历史留住，但不再把这份记忆押在某一家的服务器上。