开发者 Armin Ronacher 在 4 月 28 日发布的文章《Before GitHub》中，借自己的开源经历重新审视 GitHub 的位置：它曾把分散的开源项目带到一个默认中心，也正在失去一部分社区信任。
这不是一篇“GitHub 已死”的檄文。更准确的判断是：GitHub 仍然重要，但开源世界应在它不再天然居中之前，建立一层公共、长期资助、非商业目标的归档机制。
GitHub 从托管工具变成开源社会基础设施
Ronacher 的路径很有代表性。他最早把项目放在 SourceForge，后来运行自己的 Trac、Subversion、tarball 和文档服务器；他与 Georg Brandl 共同维护 Pocoo，承担服务器、邮件列表和版本库成本；之后迁到 Bitbucket，最终把项目搬到 GitHub。
这条路说明，GitHub 的胜利不只是 Git 比 Subversion 流行。它把创建项目、发现项目、提交补丁和讨论问题做成了低门槛流程。2018 年 Microsoft 以 75 亿美元收购 GitHub 后，这个平台仍继续承载大量开源协作；2020 年 GitHub 又收购 npm，进一步嵌入软件供应链。
| 阶段 | 项目形态 | 好处 | 代价 |
|---|---|---|---|
| SourceForge / 自建 Trac | 项目有独立主页、邮件列表、发布包 | 自主性强，信任更依赖维护者声誉 | 服务器关停、域名过期，历史容易丢 |
| Bitbucket 等替代平台 | Mercurial、Git 项目有更多选择 | 不必押注单一平台 | 平台策略变化会造成迁移成本 |
| GitHub 默认中心 | 仓库、issue、PR、release、讨论集中保存 | 贡献门槛低，项目更容易被发现 | 社区记忆依赖一家公司的产品方向 |
GitHub 最被低估的贡献，是它意外成了开源图书馆。许多没人维护的仓库仍能被搜索到，旧 issue、fork、release 和讨论串还在。这些上下文经常比代码本身更能解释一个项目为什么这样设计、哪些漏洞被修过、哪些路线被否掉。
中心化带来便利，也放大微依赖和信任压力
Ronacher 早年批评过 micro dependencies。GitHub 与 npm 式生态结合后，发布、安装、依赖一个小包几乎没有摩擦，项目数量迅速膨胀。便利是真的，风险也是真的：维护者身份、许可状态、仓库与包是否一致、构建发布是否可信，都变成供应链问题。
这里有一个原文没有展开的限制：Git 是分布式的，但开源协作的社会信息并不天然分布式。你可以 clone 代码，却很难完整带走十年的 issue 讨论、PR review、release 说明、安全公告和用户反馈。Google Code 在 2016 年关闭，Bitbucket 在 2020 年结束 Mercurial 支持并删除相关仓库，就是历史参照。
受影响最直接的是维护者和供应链团队。维护者如果迁往 Codeberg、自建 Forgejo/Gitea 或其他平台，需要重新处理贡献流程、CI、包发布和用户入口；企业安全团队则要判断依赖包背后的仓库、发布者和构建链是否仍可追溯。迁移不是换一个远程地址那么简单。
真问题不是反 Microsoft，而是开源记忆不能只靠商业平台保管
Ronacher 对 GitHub 的不满集中在平台稳定性、产品频繁变化、Copilot 与 AI 噪声、领导方向不清、社区感下降。他也承认，GitHub 面临 agentic coding 浪潮压力，不能简单写成“Microsoft 毁了 GitHub”。目前能看到的是社区信号变多：Mitchell Hashimoto 宣布 Ghostty 将离开 GitHub，Strudel、Tenacity 等项目迁往 Codeberg。
这些案例还不足以证明大规模出走。真正该观察的不是迁移声量，而是三件事：GitHub 能否恢复维护者信任；非 GitHub 平台能否承接 issue、PR、release 等上下文；是否会出现公共资助的开源归档层，专门保存源码、发布物、元数据和关键项目历史。
开源不必永远只有一个中心。问题在于，如果重新分散，却没有归档制度，旧 web 上那些断掉的 tarball 链接、消失的个人服务器和废弃 Trac 实例会再来一次。对维护者来说，现在最现实的动作不是马上搬家，而是开始为仓库、发布物、讨论和安全记录做可迁移、可镜像、可验证的备份。