Ghostty 离开 GitHub：一个 18 年老用户用「故障日记」投出的不信任票

2026 年 4 月 28 日，Mitchell Hashimoto——HashiCorp 联合创始人、Vagrant/Terraform/Consul 等知名开源项目作者——发了一篇标题就很重的文章：Ghostty Is Leaving GitHub。Ghostty 是他主理的明星跨平台 GPU 加速终端模拟器，而他本人是 GitHub 注册第 1299 号用户，2008 年 2 月加入。一个把半个职业生涯都长在 GitHub 上的人，公开宣布「我得走了」，这在开源圈是件标志性事件。本文不转述情绪，而是基于他原文与三条脚注，把这次离开的真实理由、口径与行业信号讲清楚。

一、为什么是他走，动静特别大

Hashimoto 在文章里回溯了自己和 GitHub 的关系：加入 18 年、几乎每天多次打开，「超过半生」；他做 Vagrant 的初衷之一，年轻时在公开演讲里开玩笑说「做得好也许 GitHub 会雇我」；蜜月期间趁妻子没醒还在提 commit。他甚至说 GitHub 曾是他「最快乐的地方」——有人刷社交媒体，他刷 GitHub issue。

正因如此，这次离开不是一个云淡风轻的「换个托管」。他自己也承认情绪很重：写这篇东西「让我莫名地难过」，最近对 GitHub 的公开批评「很刻薄、很愤怒、伤了一些人感情」，并为此道歉——但他强调，愤怒的根源是「GitHub 每天都在让我失败」。

二、导火索：一本打满 X 的故障日记

真正的理由写在这一段：过去一个月他坚持写「故障日记」，凡 GitHub 故障影响他工作的日子就打一个 X——结果几乎每天都有 X。就在写这篇文章当天，他因为一次 GitHub Actions 故障，整整约两个小时没法做任何 PR review。

他的结论很直接：如果一个协作平台「每天把你锁在门外几小时」，它就不再是严肃工作的地方。「我想把它改好，但我也得写代码——而我已经没法再用 GitHub 写代码了。」

三、原文脚注：三个容易被误读的口径

这篇文章最有价值的部分，恰恰是他自己加的三条脚注。它们帮我们排除掉几类常见的过度解读：

1. 时间点并非「被大故障气走」：公告恰好赶在 4 月 27 日 GitHub 那次大型故障之后，但他明确说，离开的讨论和计划已经准备了好几个月、这篇博文一周前就写好了，只是这周才最终拍板。也就是说，这不是一时冲动的「故障报复」。
2. 「Git 是分布式的」这套话说不通：他专门回应——问题不在 Git 本身（Git 当然分布式、换远端很容易），而在围绕 Git 的那一圈依赖：Issues、Pull Request、Actions。真正让他每天停工的是这些托管在 GitHub 上的协同与 CI 服务，不是版本控制协议。
3. 当天那次 Actions 故障不是 4 月 27 日那次大事故：他特意澄清，发稿当天影响他 review 的是另一次独立的 Actions 故障。言下之意是：故障是高频、日常的，不必等「上头条的大宕机」才够格成为理由。

迁移方案他也讲得克制：仍在与多家（商业的和开源的）托管方接洽，几个月内公布；会渐进式剥离对 GitHub 的依赖，并在原 URL 保留一个只读镜像；他个人的其他项目暂时仍留在 GitHub，先把受影响最大的 Ghostty 社区迁走。

四、这件事的本质：平台依赖，而非代码托管

把情绪剥掉，事件的内核是一句话：当代开源项目早就不只是把代码 push 到一个 git 远端，而是把 issue 追踪、代码评审、CI/CD、Release、Discussions、甚至社区社交都绑死在同一个平台上。 Git 本身确实可移植，但这一整套工作流一旦深度绑定，「换平台」的迁移成本就接近换操作系统。Hashimoto 被卡住的正是这一层——他能随时 git remote add，却不能在十分钟内迁走 Actions 流水线和 issue 历史。

这也是为什么 Koala 项目库的点评点到要害：AI 编码工具爆发后，GitHub 的负载正以数十倍速度增长，连 GitHub CTO 都发文承认在做技术升级。当平台从「开发者的社交网络」被迫变成「CI/Agent 的高吞吐基础设施」，它的可靠性压力是结构性的——这不是某个团队不努力，而是 workload 性质变了。

五、优势与局限（对这场迁移本身的冷静评估）

它积极的一面：

1. 一个最深度的 GitHub 用户用真实故障记录说话，把「平台可靠性」从吐槽变成了可讨论的工程议题；
2. 他选择保留只读镜像、渐进迁移，给社区留了缓冲，是成熟的治理示范；
3. 客观上给 Gitea/Forgejo/Codeberg 这类更轻、更稳定的 FOSS Git 基础设施，以及商业托管，让出了一次被认真审视的机会。

它的局限与争议：

1. 事件驱动的迁移有情绪化成分——他自己都承认「irrationally personal」，冷静下来后是否真的全量迁走仍未定（个人项目就留下了）；
2. 替代方案并未揭晓：文章没有给出下家，FOSS 平台在 CI、协同体验、社交分发上是否真能「更稳更好用」，仍待验证；
3. 对绝大多数项目，GitHub 仍是事实标准：迁走意味着放弃 star 社交、Issue 分发和生态入口，这个代价个人明星项目扛得起，普通项目未必；
4. 他记录的是自己一台机器、一个团队视角的故障体感，不是 GitHub 全局可用性的统计结论。

六、谁该关注

• 正在把团队 CI/Issue 深度绑在单一平台上的工程负责人：这次事件提醒你，平台锁定的真正成本在 workflow 而非代码，值得现在就做可迁移性预案；
• 关注开源治理与 FOSS 基础设施的人：Gitea/Forgejo 这一波「去社交化、更稳定」的路线，可能因此拿到新的关注；
• 重度依赖 GitHub Actions 的个人与小团队：可以顺手评估一下备用 CI，别把鸡蛋放在一个每天可能让你停摆两小时的篮子里。

Hashimoto 最后说，希望有一天能回去——但「前提是真实的改进，而不是言辞和承诺」。这句话，大概是所有对平台又爱又恨的维护者共同的心声。

参考来源

• Mitchell Hashimoto: Ghostty Is Leaving GitHub（2026-04-28）
• Ghostty 官网
• Koala 项目库条目