Ghostty is leaving GitHub

{"category":"编程开发","title_cn":"告别 GitHub：Ghostty 创始人 18 年后的理性出走与开源基础设施之痛","content":"> 一个深度依赖 GitHub 18 年的开源开发者，因频繁故障影响开发效率，宣布其终端项目 Ghostty 离开 GitHub。

引子：这不是一次冲动的决定

2026年4月28日，Mitchell Hashimoto（HashiCorp 联合创始人、Vagrant 作者、Ghostty 终端模拟器作者）发布了一篇标题朴素却情感复杂的博客文章：《Ghostty Is Leaving GitHub》。

文章开篇的第一句话是："写这段话让我感到一种不理性的悲伤，但 Ghostty 确实要离开 GitHub 了。"

这是一篇写给 18 年数字家园的告别信，也是开源社区关于平台依赖、基础设施韧性的一次深刻反思。它不是又一次"GitHub 很烂我要搬走"的情绪化宣言，而是一个从 2008 年（GitHub 创立仅一年后）就开始每天登录、痴迷于其生态的忠实用户，在持续数月记录服务故障后做出的理性结论。

18 年：从 Vagrant 到 Ghostty

Mitchell 在文章中透露了自己的 GitHub 用户 ID：1299，注册于 2008 年 2 月。在接下来的 18 年里，他几乎每天打开 GitHub 多次，这种频率持续了超过半个世纪的人生——他估算，除每年不超过一周的例外，他从未间断过。

这段叙述充满了私密情感：\n- 在痛苦的分手期间，他在 GitHub 上投身开源来麻痹自己；\n- 大学凌晨 4 点，当室友都在沉睡时，他会提交一个 commit；\n- 度蜜月时，在妻子醒来之前，他也在刷 GitHub。

他坦白地说："有些人在社交媒体上无休止地滚动，而我在 GitHub 上无休止地刷 issues，早在'doom scrolling'这个词出现之前就开始了。"他甚至会在度假时收藏不同的 GitHub 项目，不仅研究源代码，还会研究其他维护者如何应对困难局面、开源社区的运作方式。

更令人唏嘘的是，他创办 Vagrant——他的第一个成功的开源项目——很大程度上是希望借此获得 GitHub 的工作机会。在 20 岁第一次公开演讲 Vagrant 时，他甚至开玩笑说："如果这个项目做得好，也许 GitHub 会雇用我！"

GitHub 是他梦想的工作场所，尽管他从未在那里工作过。他说："GitHub 是让我最开心的地方。"

转折：从热爱到愤怒

然而，近年来 Mitchell 对 GitHub 的公开批评越来越尖锐。他承认自己"一直很刻薄、很愤怒、伤人感情、暴躁易怒"，并将这种情绪归因于一种深刻的个人感受：

"GitHub 每天都在让我失望，这完全是私人化的。我对 GitHub 的爱超过了一个人对某件事物应有的爱，而我对它感到愤怒。"

这种愤怒并非无源之水。文章揭示了过去一个月里，他坚持在日历上标记 GitHub 故障负面影响到他工作的每一天——几乎所有日期都打了"X"。就在文章写作当天，由于 GitHub Actions 的一个持续约 2 小时的故障（他特别注明这不是 2026 年 4 月 27 日那次大规模 Elasticsearch 故障，而是另一次独立事件），他完全无法进行 PR 审查。

他直接反驳了那些说"Git 是分布式的，问题不大"的人："问题不在于 Git，而在于它周围的基础设施：issues、PRs、Actions 等。"

核心论点：服务韧性已不适合严肃工作

Mitchell 的核心观点非常清晰：GitHub 已经不能承载严肃工作。

他描述了自己每天面临的现实：每天被阻断数小时，日复一日。这不是一次偶发事件，而是常态化的基础设施失效。

"这不再是一个适合严肃工作的地方，如果它每天只是让你卡住几个小时的话。"他说。

"我想在那里，但它不再想要我在那里；我想完成工作，但它不让我完成；我想发布软件，但它不允许我发布。我想要它变得更好，但我同时想继续写代码。而我已经无法继续和 GitHub 一起写代码了。"

这种表述不是技术上的抱怨，而是一种存在性的矛盾：一个把 GitHub 当作精神家园的人，发现这个家园的基础设施已经无法支撑他日常的生产力需求。

宣布与后续：Ghostty 的迁移计划

Mitchell 明确说明了当前状态和未来计划：

1. 时间节点：博客写于 2026 年 4 月 28 日，但文章和迁移计划已经讨论了一个多月（与 4 月 27 日的大规模故障时间上只是巧合）。迁移的最终决定是在这一周才做出的。

2. 迁移范围：目前只将 Ghostty（一个用 Zig 写的终端模拟器，在 GitHub 上拥有相当高的星标数和活跃社区）迁移出 GitHub。他的个人项目和其他工作暂时留在 GitHub。

3. 迁移方式：团队已经有计划，正在与多个商业和 FOSS 提供商讨论。迁移将"尽可能以增量方式"进行，并且会在原有 GitHub URL 上保留一个只读镜像。

4. 后续决策：他表示，如果 GitHub 未来有真正的改进和实质性的结果（而不是空洞的承诺），他愿意回归。

深度解读：一个数字原住民的平台困境

Mitchell 的离别信虽然充满个人情感，但它实际上揭示了一个更深层的生态问题——开源项目对单一平台的基础设施依赖。

GitHub 已经不仅仅是一个 Git 托管服务，而是构成了一个完整的开发操作系统：issue 跟踪、PR 审查流程、CI/CD（Actions）、包分发（Packages）、社区讨论（Discussions）、安全通告（Advisories）等。一旦这套系统中的关键环节出现故障，整个开发流程就会被阻断。

尤其对于像 Ghostty 这样的高活跃度开源项目，其维护者和社区每天依赖 GitHub Actions 来做自动测试、交叉编译和发布。如果 Actions 不稳定，项目的发布节奏和代码质量保障都会受到直接影响。

值得注意的是，Mitchell 并不是在倡导"Git 去中心化"——他明确承认这套基础设施的问题在于那些周边服务，而非 Git 本身。这实际上指向了一个更现实的矛盾：版本控制是分散的，但开发协作的基础设施已经高度垄断化。

这种垄断带来的风险是：当唯一的平台变得不稳定，数以百万计的项目会同时感受到冲击——而绝大多数项目没有资源和动力去迁移。

结语：是告别，也是提醒

这篇文章写于 2026 年（内容中日期为 April 28, 2026），是一份时效性极强的档案记录。它也是开源社区心态变化的一个样本：当"热爱"变成"依赖"，当"依赖"建立在一个不稳定的公共服务之上时，即使是 GitHub 最忠诚的用户也会开始考虑备选方案。

尽管如此，Mitchell 的告别并非没有温度。他承认这种悲伤是"不理性的"，他为自己伤到 GitHub 员工的情感道歉，并表示"如果有一天能回来，我会很高兴"。

这不是一个关于"GitHub 很糟糕"的帖子，而是一个关于"我累了，我想要稳定，我想回到写代码的自由中"的帖子。

作为一个开发者，他想要的是重构：构建、测试、审查、合并、发布。当这个流程不再顺畅时，一切热爱都会逐渐变为挫折。

GitHub 失去的不只是一个用户，而是一个曾经以它为家的精神布道者。对一个平台而言，最危险的信号不是用户离开，而是最忠实的用户开始记录你的每一次宕机，并最终画上句号。

原文链接：https://mitchellh.com/writing/ghostty-leaving-github
"}