内容
GitHub 并非我开源软件的第一个家。SourceForge 才是。
在 GitHub 之前，我有自己的 Trac 实例。我在自己掌控的基础设施上运行着 Subversion 仓库、工单系统、源码包和文档。后来我把项目搬到了 Bitbucket，那时候 Bitbucket 还像是开源项目的一个正经替代选择，尤其是对那些还没有全面拥抱 Git 的人而言。
再后来，GitHub 成了那个"唯一的地方"，我把所有东西都搬了过去。GitHub 在我生命中的重要程度怎么形容都不为过。我的开源身份有一大部分是在那里塑造的。我做的项目在那里找到了用户，人们在那里找到了我，我也在那里找到了其他人。很多职业关系和友谊都始于某个仓库、issue、拉取请求或评论串让两个人注意到了彼此。
正因如此，我对今天发生在 GitHub 身上的事感到如此悲伤和失望。我不只是将其视为微软的人做了我不喜欢的产品决策。长期以来，GitHub 是开源社会基础设施的一部分。对我们很多人来说，它不仅仅是代码存放的地方，也是很大一部分社区生活的地方。
所以当我思考 GitHub 的衰落时，我也会想到它之前的世界，以及之后可能会是什么样子。这些年来我写过几次关于依赖的文章，特别是关于微依赖的问题。在我看来，GitHub 催生了这一现象。这并非我完全赞同的事情，但它确实让开源变得更具包容性。GitHub 改变了开源的"感觉"，后来 npm 和其他系统改变了依赖的"感觉"。两者叠加的结果就是：发布代码几乎零摩擦，消费代码几乎零摩擦，全世界的项目数量呈爆炸式增长。
这有很多好处。但值得记住的是，开源并非一直都是这样运作的。
一个更小的世界
在 GitHub 之前，开源是一个小得多的世界。不一定是关心它的人更少，而是我们大多数人能够实际依赖的项目数量更少。
有一些知名的项目，由相对较少的人长期维护。你知道那些名字。你知道邮件列表。你知道谁是多年的老面孔，谁赢得了信任。那种信任并不完美，旧世界也有大量的守门行为，但声誉以一种非常直接的方式起作用。当 Debian 的人过来告诉我们说我们的授权协议含糊不清或版权头不够规范时，我们会感到自豪（也会感到沮丧），因为他们要把东西打包发布。
一个依赖不仅仅是一个包名。它是一个有历史的项目，有网站、有维护者、有发布流程、有很多摩擦，往往还在更大的社区中占有一席之地。你不会随意添加依赖，因为依赖某样东西的行为通常意味着你必须了解它来自哪里。
这一切并非全是有意为之，但由于这些项目相对较大，它们也需要自带基础设施。小型项目可能跑在大学服务器上，很多在 SourceForge 上，但大型项目则自己运营。它们聚集成更大的集体来维持运转。
我们运营自己的基础设施
我最早的开源项目运行在我自己管理的基础设施上。有 Trac 实例、Subversion 仓库、源码包、文档，以及从我自己的机器或我控制的服务器上提供的发布文件。这很正常。如果你想发布软件，你往往也就成了一个业余的系统管理员。Georg 和我为我们的开源项目运营着自己的集体：Pocoo。我们分摊服务器成本，共同维护 Subversion 和 Trac、邮件列表等等。
Subversion 尤其让这种"运营自己的代码托管平台"变得自然而然。它是集中式的：你需要一台服务器，得有人来运营。项目有一个"家"，而且这个家通常非常字面化：一个主机名、一个目录、一个 Trac 实例、一个邮件列表归档。
当 Mercurial 和 Git 出现时，它们在理念上是完全对立的。两者都是分布式的。每个人都可以拥有完整的仓库。每个人都可以有自己的副本、自己的分支、自己的历史。原则上，这些分布式版本控制系统应该减少对单一中心的需求。但尽管如此，GitHub 还是成了中心。
这是现代开源最大的讽刺之一：分布式版本控制系统赢了，然后全世界却标准化在了一个巨大的集中式托管服务上。
GitHub 给了我们什么
现在很容易只谈论 GitHub 的失败——目前确实有很多——但这不公平：GitHub 过去是、现在也依然是开源的巨大馈赠。
它让创建项目变得容易，让发现项目变得容易。它让那些从未订阅过开发邮件列表的人也能理解如何为项目做贡献。它为项目提供了 issue 追踪器、拉取请求、发布页面、Wiki、组织页面、API 接入、webhook，后来又加上了 CI。它让"开源在开放中进行、有可见的历史和可见的协作"这一理念成为常态。在整整十年里，它是一个出色而合理的默认选择。
但也许 GitHub 最被低估的贡献是存档工作：GitHub 成为了一座图书馆。它成为了软件公共领域很大一部分的索引，因为即使是废弃的项目仍然可以被找到。你可以找到 fork，旧的 issue 和讨论都留在线上。尽管人们对中心化有诸多抱怨，但这种中心化也创造了可发现的记忆。
那里的领导者曾经非常关心让 GitHub 即使在美国制裁的国家也能使用。
我知道替代方案是什么样子，因为我经历过。我最早的一些开源项目在技术上仍然存在于 PyPI 上，但实际的包已经不见了。元数据指向我的旧服务器，而那台服务器早就停止提供这些文件了。
在大型平台出现之前，这是常态。个人域名过期了，VPS 被关停了，开发者离世了，他们付费维护的服务也随之消失。互联网上曾经遍布小小的软件之家，其中很多已经不复存在了1。
npm 与依赖爆炸
微依赖问题不仅仅在于人们发布了非常小的包。GitHub 和 npm 的托管基础设施让人觉得创建、发布、发现、安装和依赖这些包似乎没有任何成本。
在 GitHub 之前的世界里，声誉和持久性几乎是依赖选择过程中不可避免的一部分，而且通常需要 vendoring（将依赖源码直接纳入项目）。我们早期的依赖默认就是 vendoring 到自己的 Subversion 树中，部分原因是我们甚至无法保证在我们需要时其他服务还在线，而且在还没有 API 的年代，维护获取依赖的脚本是一件痛苦的事。这种隐性的摩擦迫使人们有所反思，也塑造了不同的开发者行为。而在 npm 风格的生态系统中，包依赖图的增长速度会超过任何人理解它的能力。
这种思维方式产生的问题也意味着必须沿途找到解决方案。GitHub 帮助弥补了问责问题，也在授权协议方面提供了帮助。曾经有一段时间，大量涌入的开发者和合并的拉取请求留下了很多关于授权协议实际状态的悬而未决的问题。GitHub 甚至试图通过其服务条款来纠正这一点。
多年来的思路是：如果我打算依赖某个微小的包，我至少想看到它的仓库。我想看看维护者是否存在，有没有 issue，最近有没有变更，其他项目是否在使用它，代码是否与包声称的一致。GitHub 成为了提供信任体系的一部分，而最近它甚至成为了少数几个可以通过可信发布向 npm 和其他注册表发布包的系统之一。
这意味着当对 GitHub 的信任被侵蚀时，问题不仅限于源码托管。它会影响围绕它形成的整个供应链文化。
GitHub 正在缓慢地衰亡
GitHub 正在失去一些让它看起来不可替代的东西。也许这就是大型集中式平台的生与死：它们最终总是让人失望。现在人们厌倦了不稳定、产品的频繁更迭、Copilot AI 的噪音、领导层的不清晰，以及这个平台似乎不再主要为让它有价值的社区而设计的感受。
显然，GitHub 也正处于智能编码革命的浪潮中，这给那里的人带来了巨大的压力。但网站已经没有领导层了！事情能运转得这么好简直是个奇迹。
有一段时间，离开 GitHub 感觉更像是一种象征性举动，主要由小型项目或对软件自由有强烈主张的人做出。当 Zig 搬到 Codeberg 时我确实感到有些不自在！但我现在看到有真正分量和影响力的人在谈论离开 GitHub。最明显的是 Mitchell Hashimoto，他宣布 Ghostty 将迁移。迁往何处尚不清楚，但这是一个强烈的信号。不过也有其他例子。Strudel 搬到了 Codeberg，Tenacity 也是。它们会引发足够的转变吗？大概不会，但与仅仅一年前相比，我发现自己更频繁地出现在非 GitHub 的平台上了。
有人可能会说这是好事：开源不再假装一家公司应该是所有东西的默认之家，这是健康的。Git 本身就是为了一个拥有许多"家"的世界而设计的。
分散化有代价
回归到许多托管平台、许多服务器、许多小家园和许多独立社区，这将增加去中心化，在很多方面也会迫使系统做出调整。这可以恢复自主性，使项目不那么受制于微软领导层的奇想。它也可以让不同的社区选择不同的工作流。Pi 的 issue 追踪器目前正在发生的事情，很大程度上是 GitHub 的产品选择不再适应当今开源世界的结果。它是为参与度而构建的，不是为维护者的理智而构建的。
它也可能让互联网再次遗忘。我非常欣赏会"遗忘"的软件，因为它有一种净化的力量。也许真正的丧失风险会让我们更多地反思如何真正利用分布式版本控制系统。
但如果项目转向类似自托管的托管平台——它们自己的自托管 Mercurial 或 cgit 服务器——我们就有可能失去不想失去的东西。代码在理论上是分布式的，但社交背景往往不是。issue、代码审查、设计讨论、发布说明、安全公告和旧的源码包都是脆弱的。它们消失得比我们愿意承认的要容易得多。邮件列表承载了早年大量的这些内容，但已经跟不上当今的需求，而且在很大程度上是一场用户体验的灾难。
我们需要一个存档
尽管我喜欢事物消逝的理念，但我们绝对需要图书馆和存档。
无论 GitHub 是否继续存在，或者项目找到新的家园，我希望看到的是某种公开的、无聊的、资金充裕的开源软件存档。某种拥有捐赠基金或公共资金力量来维持运转的东西。它的使命不是赢得开发者生产力市场，而只是确保我们创造的最重要的东西不会消失。
花哨的功能可以是别人的问题，但源码存档、发布产物、元数据以及足够的项目上下文——让人能够理解发生了什么——应该保存在某个不依赖于单一公司商业模式或领导层心情的地方。
GitHub 意外地成为了那个存档，因为它成为了开源活动的中心。一旦这一点不再成立，我们就不应该假设某种神奇的存档功能会自动出现，或者 GitHub 会继续充当这一角色。
我们已经看到了当项目之家只是个人服务器和良好意图时会发生什么，也看到了 Google Code 和 Bitbucket 的下场。
我希望 GitHub 能恢复，真的，部分原因是因为大量的历史存在于那里，也因为仍在那里工作的人继承了真正重要的东西。但我不再认为让开源的持续记忆依赖于 GitHub 保持健康的产品状态是负责任的做法。
GitHub 之前的世界有更多的自主性，也有更多的丧失，在某种程度上，我们可能会回到那里，至少暂时如此。无论人们接下来想尝试构建什么，都应该努力保留记忆、摆脱依赖。
应该让迁移项目变得更容易，让镜像其社交背景变得更容易，让保存发布版本变得更容易，让一家公司的漂移变成所有人的文化危机变得更难。
我不想回到满是损坏的源码包链接和废弃的 Trac 实例的旧网络。我也不想开源假装过去二十年是正常的或永久的。GitHub 书写了开源史上非凡的一章，如果这一章正在结束，下一章应该从它身上学习，也应该从它之前的世界学习。
这也是一个很好的提醒：我们非常依赖互联网档案馆来保存那个时代的许多项目。↩