2026 年 4 月 28 日，HashiCorp 联合创始人 Mitchell Hashimoto 发文宣布，开源终端模拟器项目 Ghostty 将离开 GitHub。
他在文章中写道，自己是 GitHub 第 1299 位用户，2008 年 2 月就加入了这个平台。过去 18 年多，他几乎每天都会打开 GitHub，甚至一天多次。对他而言，GitHub 不只是一个代码托管网站，而是开源、工作和个人热情长期交汇的地方。
Mitchell Hashimoto 的语气并不轻松。
他称，写下这篇文章让他“莫名地难过”。他回忆，自己曾把 GitHub 视为最快乐、最想待的地方：失恋时沉浸在开源项目里，大学凌晨 4 点提交代码，甚至蜜月期间也会在妻子睡着后继续浏览 GitHub。Vagrant 这个让他成名的开源项目，当年也部分源于一个愿望：希望有一天能因此获得 GitHub 的工作机会。
但这份长期感情最终被稳定性问题消耗掉了。
Mitchell Hashimoto 表示，过去一个月，他开始在日记里记录每一次 GitHub 宕机影响工作的日期，结果几乎每天都要打上一个 “X”。
在写下文章当天，他因为 GitHub Actions 中断，大约 2 小时无法进行 PR 审核。他的判断很直接：如果一个平台每天都让开发者损失数小时工作时间，那这里就“不再适合严肃工作”。
这并不是孤立抱怨。
GitHub 官方状态页显示，4 月 27 日，GitHub 搜索相关服务出现降级，影响 Actions、Issues、Packages 和 Pull Requests 等多个关键功能；当天用户曾遇到 issue、PR、project 和 Actions workflow run 间歇性加载失败。4 月 28 日，GitHub 又出现 Pull Requests 性能降级，部分仓库的 PR 页面无法完整显示结果，同时 Actions 托管 Ubuntu 作业也出现延迟或失败。
GitHub 解释称，4 月 27 日的事故影响了 Elasticsearch 子系统。该子系统支撑 GitHub 上多个依赖搜索的体验，包括部分 Pull Requests、Issues 和 Projects。GitHub 表示，集群过载，初步判断可能与 botnet 攻击有关；事故没有造成数据丢失，Git 操作和 API 没受影响，但依赖搜索的部分界面无法返回结果，造成了明显中断。
现代开源项目依赖的早已不只是 Git 仓库本身。
Issues、Pull Requests、Actions、Packages、Release、搜索、项目管理和社区协作，已经共同构成开发者的日常工作流。核心代码可以正常拉取，并不意味着开发没有被打断。一旦 PR 审核、CI 流水线、搜索和项目管理频繁出问题，平台就会从基础设施变成风险源。
Ghostty 是 Mitchell Hashimoto 近年来投入大量精力的开源终端模拟器项目。Ghostty 是一个快速、功能丰富、跨平台的终端模拟器，采用平台原生 UI 和 GPU 加速。Mitchell Hashimoto 也在个人主页中表示，自己目前主要时间都投入在 Ghostty 上。
按照 Mitchell Hashimoto 的说法，Ghostty 不会立刻“一刀切”迁走。
未来几个月，团队会公布更多迁移细节，目前已与多个商业供应商和 FOSS 方案进行深入讨论。迁移 GitHub 依赖需要时间，项目计划逐步完成，并保留当前 GitHub 地址作为只读镜像。他的个人项目和其他工作暂时仍会留在 GitHub 上，此次变更主要集中在 Ghostty。
这次事件对 GitHub 的冲击，不在于一个项目仓库本身有多大，而在于离开者的身份和语境。
Mitchell Hashimoto 是 HashiCorp 联合创始人，也是 Vagrant、Terraform、Vault、Nomad 等基础设施工具背后的重要人物之一。
一个使用 GitHub 超过 18 年、把它视作职业和开源生活中心的开发者公开离场，比普通用户抱怨更具象征意义。
对 GitHub 来说，这更像一次信任警报。
开发者不是不能接受偶发故障，但无法接受关键工作流反复中断，更无法接受平台从“每天都想打开的地方”变成“每天都阻碍工作的地方”。
他希望 GitHub 能变好，也希望有一天能回来。但前提不是承诺，而是实际成果和改进。对于 GitHub 而言，真正要挽回的，可能不是 Ghostty 这一个项目，而是开源维护者对这个平台长期稳定性的信心。
Mitchell Hashimoto 全文。
Ghostty 即将离开 GitHub
写下这些文字，让人有些不理性地难过，但 Ghostty 即将离开 GitHub。
我是 GitHub 第 1299 位用户，2008 年 2 月加入。
从那以后，我每天都会打开 GitHub。每天，一天好几次，持续了 18 年多。这已经超过了人生的一半时间。中间当然有少数例外，我也很想看看具体数据，但很难想象，一年里不使用 GitHub 的时间会超过一周。
GitHub 是最让我快乐的地方。总会愿意为它腾出时间。经历艰难分手时，会让自己沉浸在 GitHub 上的开源世界里。大学时，凌晨 4 点，大家都睡着了，还会想着再提交一段代码。蜜月期间，妻子还在睡觉，也会打开 GitHub。很长一段时间里，GitHub 就是最让人开心、最想待着的地方。
甚至连那些烦人的事情也是如此。有人会刷社交媒体刷到停不下来，而在这个词出现之前，我就已经在 GitHub issues 里“末日式滑动”了。度假时，也会收藏一些想研究的 GitHub 项目。不只是看源代码，也会看开源软件的协作流程，看其他维护者如何处理棘手问题。信不信由你，我就是喜欢这些。
有人可能会觉得这有点病态。但我的爱好、工作和热情刚好重合，而在我大部分人生里，它们又刚好汇聚在互联网上同一个地方：GitHub。
你知道吗？我之所以开始做 Vagrant，也就是第一个真正成功的开源项目，很大程度上是因为希望它能帮我获得一份 GitHub 的工作。这并不是什么秘密，我已经说过很多次。第一次公开讲 Vagrant 时，我才 20 岁。当时我还开玩笑说：“如果 Vagrant 做得不错，也许 GitHub 会雇我！”
GitHub 曾经是我梦想中的工作。我最后没有在那里工作过，这不是他们的错。但那是我最想去的完美地方。那里的工程师很出色，产品也令人惊艳，而我每天都沉浸其中。直到现在也是如此，过去 18 年一直如此。18 年，已经足够让一个人在 GitHub 上从少年长成成年人。
最近，我一直在公开批评 GitHub。我说过一些很重的话，也很愤怒，可能伤害了一些人的感情。我确实是在发泄。因为 GitHub 每天都在让我失望，而这件事对我来说很私人，也不理性地私人。我对 GitHub 的喜欢，已经超过一个人对一件东西应有的喜欢，所以我才会对它生气。如果伤害了 GitHub 团队成员的感受，我很抱歉。
这种感受已经持续很久了。但过去一个月，我开始记日记：每当 GitHub 宕机影响我工作，就在那一天旁边打一个 “X”。几乎每天都有一个 “X”。就在写这篇文章的当天，因为 GitHub Actions 中断，我大约 2 个小时无法进行任何 PR 审查。如果一个平台每天都让人被挡在工作之外好几个小时，那它已经不再适合严肃工作。
这里对我来说，已经不再是一个愉快的地方。我想待在那里，但它好像并不想让我待在那里。我想完成工作，但它不让我完成工作。我想发布软件，但它不让我发布软件。
我希望它变得更好，但我也想写代码。而现在，我已经没法再依靠 GitHub 写代码了。很抱歉。18 年之后，必须离开了。希望有一天还能回来，但这必须建立在真正的结果和改进之上，而不是空话和承诺。
未来几个月，会分享更多关于 Ghostty 项目将迁往何处的细节。我们已经有了计划，但仍在与多家服务商深入沟通，包括商业服务商，也包括 FOSS 方案。
移除所有 GitHub 依赖需要时间，我们已经制定了计划，会尽可能渐进地完成迁移。我们计划在当前 URL 保留一个 GitHub 只读镜像。
我的个人项目和其他工作，目前仍会留在 GitHub。Ghostty 是我、维护者以及开源社区受影响最大的项目，因此这次变化的重点会先放在 Ghostty 上。之后会如何发展，再继续观察。
脚注补充：
这次宣布的时间，恰好和 2026 年 4 月 27 日 GitHub 大规模宕机接近，但只是巧合。我们已经讨论并制定离开 GitHub 的计划好几个月了，这篇文章也是一周多前写好的，只是本周才做出最终决定。
对那些会说“Git 是分布式的”的人：问题不是 Git 本身，而是围绕 Git 所依赖的基础设施，比如 issues、PR、Actions 等。
这也不是 2026 年 4 月 27 日那次大规模 Elasticsearch 宕机。这篇文章是一周前写的，所以这里说的是另一次故障。
热门跟贴