GitHub之前

# 在 GitHub 之前 来源：https://lucumr.pocoo.org/2026/4/28/before-github/ 写作于 2026 年 4 月 28 日 GitHub 并不是我的开源软件的第一个家。SourceForge 才是（https://sourceforge.net/projects/pocoo/）。 在 GitHub 之前，我有自己的 Trac 安装。我有 Subversion 仓库、工单、tar 包，以及托管在我控制的基础设施上的文档。后来我把项目搬到了 Bitbucket，那时 Bitbucket 仍然感觉像一个严肃的开源项目替代平台，尤其是对于那些还没有完全转向 Git 的人来说。 然后，最终，GitHub 成了那个地方，我把所有东西都搬了过去。 我无论如何强调 GitHub 在我的生活中变得多么重要都不为过。我的开源身份有很大一部分是在那里形成的。我参与的项目在那里找到了用户。人们在那里找到了我，我也在那里找到了其他人。许多职业关系和友谊，都因为某个仓库、工单、拉取请求或评论线程而让两个人注意到彼此。 正因如此，我看到今天 GitHub 发生的事情感到如此悲伤和失望。我不只是将其视为微软的人在做出我不喜欢的产品决策。GitHub 在很长一段时间里是开源的社会基础设施。对我们许多人来说，它不仅承载代码，还承载着社区的大部分生活。 所以，当我想到 GitHub 的衰落时，我也会想到它之前是什么，以及它之后可能会是什么。这些年我写过几次关于依赖的问题，特别是关于微依赖的问题（https://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/）。在我看来，GitHub 赋予了这种现象生命力。虽然我并非完全支持它，但它也让开源变得更加包容。GitHub 改变了开源的感觉，后来 npm 和其他系统改变了依赖的感觉。把两者结合起来，你就得到了一个发布代码几乎零摩擦、消费代码几乎零摩擦的世界，项目数量呈爆炸式增长。 这有很多好处。但值得记住的是，开源并不总是这样运作的。 ## 一个更小的世界 在 GitHub 之前，开源是一个小得多的世界。不一定是在乎它的人数少，而是我们大多数人实际能依赖的项目数量少。 有那些众所周知的、由相对少数人长期维护的项目。你知道那些名字（https://lucumr.pocoo.org/2024/3/31/skin-in-the-game/）。你知道那些邮件列表。你知道谁已经活跃多年，谁赢得了信任。这种信任并不完美，旧世界也充满了把关，但声誉以一种非常直接的方式起作用。当 Debian 的人来告诉我们我们的许可条款不清晰或版权头不符合标准时，我们感到自豪（也感到沮丧），因为他们会打包这些东西。 一个依赖不仅仅是一个包名。它是一个有历史、有网站、有维护者、有发布流程、有很多摩擦、并且往往在更大社区中有一定地位的项目。你不会随意添加依赖，因为依赖某物通常意味着你必须了解它来自哪里。 这些并非全部有意为之，但由于这些项目相对较大，它们也需要自带基础设施。小项目可能运行在大学服务器上，许多项目都在 SourceForge 上，但较大的项目则自己运营。它们组成更大的集体来使其运作。 ## 我们运行自己的基础设施 我的第一个开源项目生活在我自己运行的基础设施上。有一个 Trac 安装、Subversion 仓库、tar 包、文档和发布文件，这些都来自我自己的机器或我控制的服务器。那是正常的。如果你想发布软件，你通常也会成为一名兼职系统管理员。 Georg（https://github.com/birkenfeld） 和我运营着我们自己的开源项目集体：Pocoo（http://www.pocoo.org/）。我们分担服务器成本以及维护 Subversion、Trac、邮件列表等的工作。 特别是 Subversion，使得这种“自建平台”变得自然。它是中心化的：你需要一台服务器，并且需要有人来操作它。项目有一个家，这个家通常很字面化：一个主机名、一个目录、一个 Trac 实例、一个邮件列表存档。 当 Mercurial 和 Git 到来时，它们在哲学上恰恰相反。两者都是分布式的。每个人都可以拥有完整的仓库。每个人都可以有自己的副本、自己的分支、自己的历史。原则上，这些分布式版本控制系统应该减少对单一中心的需求。但尽管如此，GitHub 成为了中心。 这就是现代开源的一个巨大讽刺。分布式版本控制系统赢了，然后世界在一个庞大的集中式托管服务上标准化了。 ## GitHub 给了我们什么 现在很容易只谈论 GitHub 的失败——目前确实很多——但那将是不公平的：GitHub 曾经并依然是对开源的巨大馈赠。 它让创建项目变得容易，让发现项目变得容易。它让那些从未订阅过开发邮件列表的人也能理解如何贡献。它给项目提供了工单追踪器、拉取请求、发布页面、Wiki、组织页面、API 访问、Webhooks，后来还有 CI。它使“开源在公开场合发生，具有可见的历史和可见的协作”这一理念变得正常。而且在十年间，它一直是一个出色且合理的默认选择。 但也许 GitHub 最被低估的事情是归档工作：GitHub 变成了一座图书馆。它成为了软件公共资源巨大一部分的索引，因为即使是废弃的项目也仍然可被发现。你可以找到分叉，旧的工单和讨论也都在线。尽管你可以对集中化做出各种抱怨，但这种集中化也创造了可发现的记忆。那里的领导者曾经非常关心（https://github.blog/news-insights/policy-news-and-insights/advancing-developer-freedom-github-is-fully-available-in-iran/）即使在受美国制裁的国家也让 GitHub 可用。 我知道替代方案是什么样子的，因为我就经历过。我最早的一些开源项目技术上仍在 PyPI 上（https://pypi.org/project/Colubrid/0.9/），但实际的包已经消失了。元数据指向我的旧服务器，而那个服务器早已停止提供那些文件。 在大平台出现之前，这是正常的。个人域名过期，VPS 被关闭，开发者去世，他们付费的服务也随之消失。网络曾经充满了小小的软件之家，其中许多已经消失了[¹](#fn-1)。 ## npm 与依赖爆炸 微依赖问题不仅仅是人们发布了非常小的包。GitHub 和 npm 的托管基础设施让人觉得创建、发布、发现、安装和依赖它们是没有成本的。 在 GitHub 之前的世界里，声誉和寿命几乎是依赖选择过程中必不可少的一部分，而且通常需要内嵌供应商。我们早期的许多依赖默认就被内嵌到我们自己的 Subversion 树中，部分原因是即使在需要时我们也无法依赖其他服务保持在线，并且因为在 API 出现之前，维护获取它们的脚本非常痛苦。这种隐含的摩擦迫使人们进行反思，并导致了不同的开发者行为。在 npm 式的生态系统中，依赖图增长的速度超过了任何人理解它的能力。 这种思维方式创造的问题也意味着必须沿途找到解决方案。GitHub 帮助弥补了问责问题，并帮助解决了许可问题。在某个时候，新涌入的开发者以及合并的拉取请求留下了很多关于许可状态实际上是什么的未解问题。GitHub 甚至尝试通过其服务条款来纠正这一点（https://github.blog/news-insights/new-github-terms-of-service/）。 多年来，人们的想法是：如果我要依赖某个小小的包，我至少想看看它的仓库。我想看看维护者是否存在，是否有问题，是否有最近的更改，是否有其他项目在使用它，代码是否如包所声称的那样。GitHub 成为了提供信任的系统的一部分，最近它甚至成为了少数几个可以使用信任发布将包发布到 npm 和其他注册表的系统之一。 这意味着当对 GitHub 的信任削弱时，问题并不仅限于源代码托管。它影响了围绕它形成的整个供应链文化。 ## GitHub 正在慢慢消亡 GitHub 目前正在失去一些让它显得不可避免的东西。也许这就是大型集中式平台的生与死：它们最终总会令人失望。现在人们厌倦了不稳定性、产品的折腾、Copilot AI 的噪音、不清晰的领导力，以及感觉这个平台不再主要是为了那些让它变得有价值的社区而设计。 显然，GitHub 也发现自己正处于代理编码革命之中，这给那里的人们带来了巨大的压力。但这个网站没有领导力！事情能像现在这样进展，已经是个奇迹了。 有一段时间，离开 GitHub 感觉像是一种象征性的行动，主要是由较小的项目或对软件自由有强烈看法的人进行的。当 Zig 搬到 Codeberg 时，我确实感到有些尴尬！但现在我看到一些真正有分量、有信号的人也在谈论离开 GitHub。最明显的是 Mitchell Hashimoto，他宣布 Ghostty 将搬离（https://mitchellh.com/writing/ghostty-leaving-github）。搬到哪里还不清楚，但这是一个强烈的信号。还有其他人，比如 Strudel 搬到了 Codeberg（https://codeberg.org/uzu/strudel），Tenacity 也搬到了 Codeberg（https://codeberg.org/tenacityteam/tenacity）。它们会造成足够的转变吗？可能不会，但我发现自己比一年前更频繁地出现在非 GitHub 的平台上。 有人可能会说这是好事：开源不再假装一家公司应该成为一切默认的家园，这对健康有好处。Git 本身就是为了一个多家园的世界而设计的。 ## 分散是有代价的 回到多个平台、多个服务器、多个小家园和多个独立社区将会增加去中心化，并且在很多方面会迫使系统适应。这可以恢复自主权，使项目更少依赖微软领导层的突发奇想。它还可以让不同的社区选择不同的工作流程。Pi（https://pi.dev/）的工单追踪器中目前发生的事情，很大程度上是 GitHub 的产品选择在当今开源世界中不再有效的结果。它是为参与度而设计的，而不是为维护者的理智设计的。 这也会让网络再次遗忘。我相当喜欢会“遗忘”的软件（https://lucumr.pocoo.org/2024/10/30/make-it-ephemeral/），因为它有净化作用。也许真正的丢失风险会促使我们更多地反思如何实际利用分布式版本控制系统。 但是如果项目迁移到更像自托管平台、自己的自托管 Mercurial 或 cgit 服务器，我们就有失去我们不想失去的东西的风险。代码理论上分布了，但社会背景往往没有。工单、审查、设计讨论、发布说明、安全公告和旧的 tar 包都很脆弱。它们消失得比我们愿意承认的容易得多。邮件列表在过去承载了很多这些内容，但已跟不上当今的需求，而且在用户体验上基本是一场灾难。 ## 我们需要一个档案 尽管我很喜欢事物逐渐消失的想法，但我们绝对需要图书馆和档案。 无论 GitHub 是否继续存在，或者项目找到新家，我希望看到的是某种公共的、乏味的、资金充足的开源软件档案。一些拥有捐赠基金或公共资金来维持其运转的东西。其职责不是赢得开发者生产力市场，而只是确保我们创造的最重要的东西不会消失。 那些花哨的功能可以是别人的问题，但源代码档案、发布制品、元数据以及足够理解项目背景的信息，应该保存在某个不受单一公司商业模式或领导层情绪影响的地方。 GitHub 偶然成为了那个档案，因为它成了开源活动的中心。一旦这不再成立，我们不应该假设某种神奇的归档功能会自然出现，或者 GitHub 会继续充当这个角色。我们已经看到当项目家园只是个人服务器和良好意愿时会发生什么，也看到了 Google Code 和 Bitbucket 的结局。 我希望 GitHub 能恢复，我真的希望，部分原因是那里存有大量历史，也因为仍在为之工作的人们继承了一些真正重要的东西。但我现在认为，让开源的持续记忆依赖于 GitHub 保持一个健康的产品是不负责任的。 在 GitHub 之前的世界有更多的自主权和更多的损失，在某些方面，我们可能会回到那种状态，至少在一段时间内。无论人们接下来想开始构建什么，都应该尝试保留记忆，同时失去依赖。应该更容易迁移项目、更容易镜像它们的社会背景、更容易保留发布版本，并且更难让一家公司的偏离成为其他人的文化危机。 我不想回到那个充满失效 tar 包链接和废弃 Trac 实例的旧网络。我也不希望开源假装过去的二十年是正常或永久的。GitHub 谱写了开源中非凡的一章，如果那一章正在结束，下一章应该从中学习，也应该从它之前的东西中学习。 这篇文章标记了：github（https://lucumr.pocoo.org/tags/github/）、open-source（https://lucumr.pocoo.org/tags/open-source/） 和 thoughts（https://lucumr.pocoo.org/tags/thoughts/） 复制为（https://lucumr.pocoo.org/2026/4/28/before-github.md）/查看（https://lucumr.pocoo.org/2026/4/28/before-github.md）markdown