Before GitHub

SourceForge 是。在 GitHub 之前，我有自己的 Trac 安装。我有 Subversion 存储库、票据、tarball 和我控制的基础设施的文档。后来我将项目转移到了 Bitbucket，当时 Bitbucket 仍然感觉像是开源项目的一个严肃的替代场所，特别是对于那些还没有完全投入 Git 的人来说。然后，最终，GitHub 成为了这个地方，我把所有的东西都搬到了那里。我很难夸大 GitHub 在我生活中的重要性。我的开源身份的很大一部分就是在那里形成的。我从事的项目在那里找到了用户。人们在那里找到了我，我也在那里找到了其他人。许多职业关系和许多友谊的开始是因为某些存储库、问题、拉取请求或评论线程使两个人相互了解。这就是为什么我觉得 GitHub 今天发生的事情如此悲伤和令人失望。我并不认为这只是微软的员工做出了我不喜欢的产品决策。

核心内容

GitHub 很长一段时间以来都是开源社交基础设施的一部分。对于我们许多人来说，它不仅是代码所在的地方，也是代码所在的地方。这是社区大部分人居住的地方。所以当我思考 GitHub 的衰落时，我也会思考它之前发生的事情以及之后可能发生的事情。多年来我已经写过几次关于依赖关系的文章，特别是关于微依赖关系的问题。在我看来，GitHub 赋予了这种现象以生命。我绝对不完全支持这一点，但它也使开源更具包容性。

GitHub 改变了开源的感觉，后来 npm 和其他系统改变了依赖关系的感觉。把它们放在一起，你就会得到一个发布代码几乎毫无摩擦、消费代码几乎毫无摩擦的世界，而且世界上的项目数量呈爆炸式增长。这有很多好处。但值得记住的是，开源并不总是以这种方式运作。在 GitHub 出现之前，开源世界要小得多。不一定是关心它的人数，而是我们大多数人实际上可以依赖的项目的数量。有一些著名的项目，由相对少数的人长期维护。你知道这些名字。您知道邮件列表。您知道谁已经存在多年以及谁赢得了信任。这种信任并不完美，旧世界有很多把关，但声誉却以非常直接的方式发挥着重要作用。当 Debian 人员来告诉我们我们的许可内容不明确或者版权标题不符合要求时，我们感到自豪（但也感到沮丧），因为他们把东西打包了。依赖项不仅仅是包名称。

这是一个有历史、有网站、有维护者、有发布过程、有很多摩擦的项目，而且通常在更大的社区中占有一席之地。您不会随意添加依赖项，因为依赖某些东西的行为通常意味着您必须了解它来自哪里。并非所有这些都一定是有意为之，但由于这些项目相对较大，他们也需要自带基础设施。小型项目可能在大学服务器上运行，其中许多项目都在 SourceForge 上，但较大的项目则有自己的表现。他们组成了更大的集体以使其发挥作用。我的第一个开源项目依赖于我自己运行的基础设施。我自己的机器或我控制下的服务器提供了 Trac 安装、Subversion 存储库、tarball、文档和发布文件。那是正常的。如果您想发布软件，您通常也会成为一名小型系统管理员。

Georg 和我为我们的开源项目运行了我们自己的集体：Pocoo。我们分担了服务器成本以及维护 Subversion 和 Trac、邮件列表等的负担。

Subversion 尤其让“经营自己的锻造厂”变得自然而然。它是集中式的：你需要一台服务器，并且必须有人操作它。该项目有一个家，并且该家通常非常字面意思：主机名、目录、Trac 实例、邮件列表存档。当 Mercurial 和 Git 出现时，它们在哲学上是相反的。两者均已分发。每个人都可以拥有完整的存储库。每个人都可以拥有自己的副本、自己的分支、自己的历史。原则上，那些分布式版本控制系统应该减少对单一中心的需求。但尽管如此，GitHub 仍然成为了中心。这是现代开源的最大讽刺之一。分布式版本控制系统获胜，然后世界标准化了一个巨大的集中式服务来托管它。现在很容易只谈论 GitHub 的失败，目前这样的失败有很多，但这是不公平的：GitHub 过去是、现在仍然是对开源的巨大礼物。它使创建项目变得容易，也使发现项目变得容易。对于那些一生中从未订阅过开发邮件列表的人来说，贡献变得可以理解。它为项目提供了问题跟踪器、拉取请求、发布页面、wiki、组织页面、API 访问、网络钩子和后来的 CI。它规范了开源是公开发生的、具有可见历史和可见协作的理念。十年来，这是一个出色且合理的默认选择。但也许 GitHub 所做的最被低估的事情就是档案工作：GitHub 成为了一个图书馆。

它成为了很大一部分软件共享的索引，因为即使是废弃的项目仍然可以找到。你可以找到分叉，旧的问题和讨论都留在网上。尽管人们对中心化有种种抱怨，但中心化也创造了可发现的记忆。那里的领导人曾经非常关心如何保持 GitHub 的可用性，即使是在受到美国制裁的国家也是如此。我知道另一种选择是什么样子，因为我就是这样生活的。我最早的一些开源项目从技术上讲仍然在 PyPI 上，但实际的包已经消失了。元数据指向我的旧服务器，而该服务器早已停止提供这些文件。在大型平台出现之前，这很正常。个人域名过期、VPS 关闭、开发人员去世，他们付费的服务也随之消失。网络上曾经充满了小软件之家，其中许多已经消失了 1。微依赖问题不仅仅是人们发布了非常小的软件包。

GitHub 和 npm 的托管基础​​设施让人感觉创建、发布、发现、安装和依赖它们是没有成本的。在 GitHub 出现之前的世界中，声誉和寿命几乎是依赖选择过程的一部分，并且通常需要供应商。默认情况下，我们的大量早期依赖项只是供应到我们自己的 Subversion 树中，部分原因是我们甚至无法依赖其他服务在需要时启动，而且在 API 出现之前维护获取它们的脚本非常痛苦。隐含的摩擦迫使一些反思，并导致了不同的开发人员行为。借助 npm 式的生态系统，包图的增长速度可能超出任何人的推理能力。这种思维方式产生的问题也意味着必须一路寻找解决方案。

GitHub 帮助弥补了责任问题，并在许可方面提供了帮助。在某一时刻，新发现的开发人员涌入和合并的拉取请求留下了许多关于许可证实际状态的悬而未决的问题。

GitHub 甚至试图通过他们的服务条款来纠正这个问题。多年来的想法是，如果我要依赖某个小包，我至少想查看它的存储库。我想看看维护者是否存在，是否存在问题，最近是否有更改，其他项目是否使用它，代码是否是包声称的那样。

GitHub 成为提供信任的系统的一部分，最近它甚至成为少数几个可以通过可信发布将包发布到 npm 和其他注册表的系统之一。这意味着当对 GitHub 的信任受到侵蚀时，问题不仅仅局限于源托管。

它影响着围绕它形成的整个供应链文化。

GitHub 目前正在失去一些让它感觉不可避免的东西。也许这就是大型中心化平台的生与死：它们最终总是令人失望。现在，人们厌倦了不稳定、产品流失、副驾驶人工智能噪音、不明确的领导力，以及平台不再主要为使其有价值的社区设计的感觉。显然，GitHub 也发现自己正处于代理编码革命之中，这给那里的人们带来了巨大的压力。但网站没有领导！事情进展顺利，这真是一个奇迹。有一段时间，离开 GitHub 感觉像是一个象征性的举动，主要是由较小的项目或对软件自由有强烈看法的人做出的。当 Zig 搬到 Codeberg 时，我确实感到畏缩！但我现在看到一些真正有分量、有信号的人在谈论离开 GitHub。最明显的就是米切尔桥本，他宣布Ghostty将搬家。它会走向何方尚不清楚，但这是一个强烈的信号。但也有其他人。

Strudel 搬到了 Codeberg，Tenacity 也搬到了 Codeberg。它们会引起足够的转变吗？可能不会，但与一年前相比，我发现自己再次更频繁地访问非 GitHub 资源。人们可以说这是一件好事：对于开源来说，停止假装一家公司应该成为一切事物的默认家园是健康的。

Git 本身是为一个拥有众多家庭的世界而设计的。回到许多熔炉、许多服务器、许多小家庭和许多独立社区将增加去中心化，并在许多方面迫使系统进行适应。这可以恢复自主权，并减少项目对微软领导层突发奇想的依赖。它还可以允许不同的社区选择不同的工作流程。