结束 18 年热爱，Ghostty 逃离 GitHub
“有些告别，并不是因为不再热爱，而是因为再也无法继续留下。”
这是 Ghostty 项目创始人 Mitchell Hashimoto 在宣布项目即将逃离 GitHub 时写下的开头。整篇长文没有技术细节的铺陈，反而像一封写给过去 18 年的“告别信”，甚至，他在写这封“告别信”时是哭着写完的！
Mitchell Hashimoto 出生于 1990 年，是一位典型的“从开源社区成长起来”的工程师。
20 岁出头时，他就因创建 Vagrant 而在开发者圈子中崭露头角。Vagrant 解决的是开发环境一致性的问题——在容器和云原生尚未普及的年代，它几乎是团队协作开发的“标配工具”。
这一项目不仅让他一举成名，也成为后来一整套基础设施工具体系的起点。
2012 年，他与联合创始人一起创立了 HashiCorp。这家公司后来成为 DevOps 工具链中不可忽视的一极，推出了一系列广泛使用的基础设施软件，包括：
这些工具的共同特点是：将复杂的基础设施操作抽象为可编程、可复用的工作流，本质上推动了“Infrastructure as Code（基础设施即代码）”这一范式的普及。
在商业层面，HashiCorp 也一路成长为一家上市公司，成为少数从纯开源社区成功走向企业级商业化的软件公司之一。
但相比“企业家”身份，Mitchell Hashimoto 更被开发者社区认可的，仍然是“工程师”和“开源作者”。
他长期活跃在开源一线，亲自维护项目、参与社区讨论，并保持极高的技术输出频率。在很多人眼中，他代表的是一类典型的技术人路径：通过开源项目建立声誉，通过工具改变行业，再通过公司将其规模化。
也正因为这种背景，他对 GitHub 的情感才显得格外特殊——他不是简单的“平台用户”，而是那一代真正在 GitHub 上完成自我实现的人：从发布项目、积累影响力，到建立公司、影响行业路径，几乎全部发生在这个平台之上。
Mitchell 在这封与 Github 的告别信中写道：
写下这些让我感到一种不理性的悲伤，但 Ghostty 将逃离 GitHub。
我是 GitHub 用户 1299，注册于 2008 年 2 月。
从那以后，我几乎每天都会打开 GitHub。每天，多次，持续了超过 18 年。这占据了我人生的一半以上。中间或许有极少数例外（我甚至很想看看数据），但我很难想象一年中有哪一周完全没有打开过它。”
GitHub 是让我最快乐的地方。我总会为它留出时间。经历糟糕的分手时，我把自己丢进开源世界……在 GitHub。大学凌晨四点，所有人都睡着的时候，我再提交一次 commit。甚至在蜜月期间，当妻子还在睡觉时，我都在逛 GitHub。这是我一直以来最快乐、也最想待的地方。
有些人会无意义地刷新社交媒体，而我在这个“刷屏”出现之前，就已经在 GitHub 的 issue 里“刷屏”了。度假时，我会收藏一堆 GitHub 项目，去研究它们。不只是代码，还有开源社区的运作方式、维护者如何处理棘手问题……说真的，我喜欢这些。
也许有人会觉得这不太正常，但我的爱好、工作和热情恰好完全重合，而在我人生的大部分时间里，它们都存在于互联网的同一个地方：GitHub。
我创建 Vagrant（我第一个成功的开源项目），很大程度上是因为我希望它能帮我拿到 GitHub 的工作机会。这个我从不避讳——我在 20 岁第一次公开演讲时就开玩笑说：‘如果这个项目做得够好，也许 GitHub 会雇我。’
GitHub 曾是我的梦中工作。我最终没能在那里工作（这不是他们的错）。但那是我最想去的地方。那里的工程师令人惊叹，产品令人惊叹，而它也是我每天呼吸、生活的一部分。18 年，一整个人从出生到成年所需的时间，我都在 GitHub 上度过。
但这封“告别信”，在后半段急转直下。
最近，我一直在公开批评 GitHub。我说了很多难听的话，我很愤怒，也伤害了一些人。我在发泄。因为 GitHub 每一天都在让我失望，这对我来说是件非常私人的事情。也许这种情绪不理性，但我确实把 GitHub 爱得太深了，所以我对它生气。我为伤害到那些仍在努力工作的人感到抱歉。
这种感觉已经持续很久了。过去一个月，我甚至开始做一件事：每天记录一次——如果 GitHub 的故障影响了我的工作，我就在那一天画一个 ‘X’。几乎每天都有 ‘X’。
就在我写这篇文章的今天，我已经有大约两个小时无法进行 PR 审查，因为 GitHub Actions 出现了故障。这已经不再是一个可以认真工作的地方了——如果它每天都要让你停摆几个小时。
这里不再让我感到快乐。我想留下，但它似乎不再需要我。我想完成工作，但它不让我完成。我想发布软件，但它不让我发布。
我希望它变得更好。但我也想写代码。而现在，我无法在 GitHub 上写代码了。抱歉。18 年之后，我必须离开。
也许有一天我会回来。但前提必须是真正的改变与结果，而不是承诺。
至于 Ghostty 项目最终会迁移去哪里，Mitchell 没有明确的回应，但他在一则 X 评论中提及，正在努力寻找一个统一的解决方案，但现在还来得及调整方向。
Mitchell 的其他独立项目将继续托管于 GitHub 平台。本次转移仅涉及 Ghostty 项目，该项目是近期服务中断事件中受影响最严重的，不仅对 Mitchell 本人造成困扰，也给项目维护者及社区用户带来了不便。
创始人的哭诉，引发社区共鸣
然而，这些都还不是这场情绪的全部。
在 Hacker News 上，这位创始人随后补充的一段评论，让这次“逃离”显得更加真实，也更加让人动容：
我知道这听起来很夸张，但这是事实：我写这篇博客文章的时候，真的哭了。（眼泪都滴到键盘上了，说出来确实挺丢人的。）
他补充说道：“没有人应该为一个 SaaS 产品而哭。但 GitHub 对我来说远不止如此（这些我在文章里都写了）。我对它有一种不太健康的情感依附。它给了我太多，我对此心怀感激。但它已经不再是从前的样子了……我也说不清。
我们断断续续讨论了几个月，几周前开始认真讨论，几天前才真正做出决定。当我把这些写下来，按下‘发布’按钮的时候，一切都变得真实了。我知道大家会觉得这很可笑。这确实很蠢。但我真的很喜欢 GitHub，也真心希望它能找到出路。”
Mitchell 这段“带着眼泪的控诉”，迅速点燃了评论区。
一位同样早期加入 GitHub、并且自称现在仍然是 GitHub 员工的用户这样回应：
“我也是老用户——22723 号。某种意义上，我们是同一代人（毕竟现在 GitHub 已经有将近 1.8 亿用户了）。但我对这件事的理解有点不同：只有那些真正关心 GitHub、愿意留下来把它变好的人留下，GitHub 才会变好。”
但他对 GitHub 的态度却截然不同，他表示自己不会离开：
“正因为它对我来说太重要了，我反而无法离开。而且，我不是唯一有这种感觉的人。”
该用户还表示这种转变不能完全归罪于 AI 或者微软，而是技术基础正在发生变化。
“过去几年，GitHub 经历了一次根本性的范式转变（智能体编码）以及爆发式增长。问题并不只是 AI，也不只是微软。用奥卡姆剃刀来看，更简单的解释是：规模，以及我们脚下整个技术基础正在发生变化。我希望我们还能做点什么，让你有一天愿意回来。我希望还能重新点燃你曾经的那种快乐。对开发者来说，这些情绪一点都不愚蠢。”
还有很多 Hacker News 用户表达了与 这位 GitHub 内部员工不同的观点。
这部分开发者群体对 GitHub 现状有一种幻灭感：当一个平台变得“大而不能倒”时，用户的热爱与反馈往往会撞上一堵冰冷的制度高墙。
有用户指出，“那句‘只有真正关心 GitHub 的人留下来，它才会变好’，其实是个极具误导性的陷阱。这话对微软内部的开发者可能成立，但对普通用户来说完全是谎言。作为一个用户，如果你只是像往常一样继续使用它，根本没有任何途径能让它变得更好。”
另一位用户同意上述观点。他写道：
“我深有同感。时间已经给出了答案：即使用户们满怀热忱地留下来，试图‘改进’这个平台，结果看到的却是 GitHub 体验的一路劣化。这种劣化并没有因为用户的坚持而停止。”
更有用户反馈，用户的耐心换来的是长达数年的反馈石沉大海。
“确实如此。早在 2018 年，我就投入了大量精力向官方报告‘压缩合并（squash 'n' merge）’中的元数据重写错误，并持续推动修复。期间虽然有一两个内部员工表现出兴趣，但随后便杳无音信。多年过去了，这个 Bug 依然在那。现在，我对 GitHub 修复基本功能的任何期望都已彻底崩塌，只剩下满心的讽刺与失望。”
面对开发者群体对 Github 的失望情绪，这位 GitHub 员工在评论区继续输出，他认为：GitHub 不会被替代，GitHub 最有可能拥有光明的未来，而实现它的最佳途径，是从内部改进它。他写道：
就像 Mastodon 未能取代崩溃后的 Twitter 一样，我并不认为 GitHub 的替代平台会成为主流。尽管未来可能会出现更多类似 Codeberg 这样的 GitHub 类平台，或者部分项目会转向 Tangled 和 Forgejo 这样的新型代码托管工具，但要说服数百万 GitHub 用户迁移到更为复杂的平台，仍然令人难以置信——这就像‘20XX 年会是 Linux 桌面元年’一样不现实。
我认为，GitHub 最有可能拥有光明的未来，而实现它的最佳途径，恰恰是从内部改进它。我选择加入这里，正是因为我希望从内部推动 GitHub 变得更好。因此，我才提到‘我希望我们的努力，能让你们有一天愿意回来’。我深信这个可能，所以我选择留下，为此付出努力。就像 Mitchell 曾坚守 GitHub 的理想那样，我也珍视那份愿景。他已经决定离开，而我还没有——这无关对错，只是个人选择的不同。
Mitchell 的文字在 Reddit 上同样引发了强烈共鸣。
尤其是在 Reddit 等社区中，围绕“Ghostty 是否应该逃离 GitHub”的讨论迅速发酵，评论区几乎变成了一场集体回忆录：有人谈起自己第一次提交 pull request 的紧张，有人回忆当年追着 issue 学习编程的日子，也有人开始质疑——那个曾经承载开源精神的 GitHub，是否正在变成一个“基础设施优先”的商业平台。
某种程度上，这并不只是一个项目迁移的决定。
对一代技术人而言，GitHub 曾经不仅是工具，更像是一种精神空间：代码、协作、声誉、学习路径，甚至职业命运，都在这里交汇。
它既是“代码托管平台”，也是“技术乌托邦”的象征——一个你只需要写好代码，就能被世界看见的地方。
而如今，当一个从 2008 年就扎根其中的老用户，用“18 年”“每天多次打开”“人生一半时间”来描述自己的关系，并最终选择离开时，这种情绪很难被简单归类为“产品体验不佳”。
它更像是一种时代错位。
当平台规模不断扩大、功能不断叠加、商业逻辑持续强化时，那种最初的、近乎纯粹的开源体验正在被稀释。稳定性问题只是导火索，真正被触动的，是开发者对“归属感”的失落。
有人在评论里扎心地写道：“我们不是在讨论 GitHub 好不好用，而是在讨论，我们曾经相信的那个地方，还在不在。”
以人为中心的开发体验，还能被保留下来吗？
2018 年，Microsoft 以 75 亿美元收购了 GitHub。
当时给出的承诺很简单：让 GitHub 更好地服务开发者，而不是改变它。
在最初几年，这个承诺基本兑现了。
2019 年，GitHub 正式推出了 GitHub Actions，将 CI/CD 能力直接嵌入代码仓库，开发者无需再依赖外部工具链。这一发布被普遍视为 GitHub 平台能力的重要跃迁。
从产品演进来看，那是一个“工程效率优先”的阶段：围绕代码托管本身不断增强基础设施能力，让开发流程更顺滑、更自动化。
但此后情况发生了改变。
2021 年，在以 ChatGPT 为代表的大语言模型爆发后，GitHub 与 OpenAI 合作推出了 GitHub Copilot。逐渐地，Copilot 从辅助工具发展到了微软战略核心位置上。
最初，Copilot 被定义为“AI 结对编程助手”，用于代码补全与建议。但很快，它的定位发生了变化。
Copilot 不再只是一个功能，而成为微软 AI 战略的重要入口之一。围绕它的商业模式也迅速成型：个人版每月 10 美元，团队版 19 美元，企业版 39 美元——这是 GitHub 历史上最清晰、最直接的订阅收入来源之一。
随后几年，围绕 Copilot 的产品演进明显加速，并呈现出一个清晰方向：从“辅助写代码”走向“替你完成开发流程”。
2024 年，GitHub 发布了 Copilot Workspace，允许 AI 从 issue 出发，理解需求、生成代码并直接创建 Pull Request。
到 2025 年，GitHub 进一步推出 Agent 模式（Copilot Agents），将这一能力推进到“端到端自动化开发”的阶段：AI 可以从需求理解、代码生成到提交 PR 完整执行一条链路。
从产品路径来看，这是一条非常一致的技术路线：从代码补全 → 任务理解 → 自动生成 → 自主执行，GitHub 正在从“代码托管平台”，转向“AI 驱动的软件生产系统”。
但与此同时，另一条曲线开始浮现。
开发者社区的反馈逐渐出现分化，尤其集中在基础设施层面——最典型的，就是 GitHub Actions。
用户开始对 GitHub Actions 的稳定性表示失望，失望的原因有很多，包括构建排队时间显著增加、Runner 随机失败、缓存命中率不稳定、日志丢失或加载缓慢等等。
GitHub 官方状态页面也在一定程度上反映了这种压力：
尽管这些问题并不意味着系统“不可用”，但对于依赖 CI/CD 的团队而言，稳定性波动本身就是生产力损耗。
而在 Ghostty 创始人的那篇长文中，这种“体感”第一次被具象化——通过“每天打一个 X”的方式，记录 GitHub 故障对工作的实际影响。
如果把这两条曲线叠加在一起，一个更值得讨论的问题就出现了：GitHub 是否真的“变差了”？还是说，它只是把重心转移了？
从企业资源配置的逻辑来看，答案倾向于后者。
Copilot 作为明确的收入来源，契合微软以 AI 为核心的战略，开发者工具正是其关键落地场景。相比之下，Actions 等基础设施更偏向“成本中心”，其目标往往是“稳定可用”而非“追求突破”。当一个平台将最优秀的工程资源和战略优先级倾注于 AI 产品时，原有基础设施滑向“足够好”的状态，几乎是一种必然。这不是 GitHub 独有的问题，而是许多平台在战略转型期都会面临的结构性张力。
更深层的变化在于，AI 正在重塑 GitHub 的底层负载模型。过去，平台的系统负载是基于“人类开发节奏”设计的：人工写代码、提交 PR、触发 CI 构建，这是一个相对稳定、可预测的流程。
但随着 GitHub Copilot、Claude Code、Cursor 等 AI 编程工具的普及，开发行为发生了根本变化：单个开发者的代码产出量和提交频率大幅提升，自动化测试的触发次数呈倍数增长。尤其在 AI Agent 模式下，一个简单需求就可能引发多轮自动迭代，这使得 CI 负载不再与“开发者数量”线性相关，而是与“AI 迭代次数”挂钩，形成了一种指数级增长的压力模型。
而 GitHub 的基础设施，最初并非为此类模式设计。
这导致了一种颇具“黑色幽默”的现实：GitHub 正全力推动 AI 编程，鼓励开发者更高效地产出代码，但 AI 生成代码所带来的海量工作流，却在反向对平台自身的基础设施构成持续的压力放大。
真正的问题或许不在于这种变化是对是错，而在于：在这个被 AI 加速的世界里，曾经那种缓慢、稳定、以人为中心的开发体验，还能否被保留下来。
GitHub 之外，开源只剩更差选择
即便 GitHub 广受争议，但是当人们开始审视 GitHub 之外的选项时，很快会发现，每一种路径都对应着一种妥协。
从产品能力看，GitLab 是最接近 GitHub 的平台：完整 DevOps 生命周期、CI/CD、权限管理、企业级能力一应俱全。
但问题在于，它的两种路径都不理想：
SaaS：价格直接劝退：GitLab Premium 定价约 $29/用户/月，明显高于 GitHub Team。对于一个 10 人团队，每月成本可达 $145–290，美式企业软件定价逻辑非常明显。
自托管：隐藏成本远高于预期。理论上，GitLab CE（开源版）可以自托管，听起来是“自由”的解决方案。但现实是：算上基础设施、运维成本后，一个 20～50 人的团队，总成本差不多要在 2000 美元/月，总结起来就一个字：贵。
因此有 Reddit 用户吐槽说 GitLab 托管费高得离谱。
如果说 GitLab 是“企业级替代”，那么 Codeberg 更像是“理念驱动型替代”。
它的优势明确：非营利组织运营、不做数据收集、不做 AI 训练并且完全免费（靠捐赠）， 这也是为什么一些项目开始迁移。例如：Zig 语言已经从 GitHub 迁移到 Codeberg，理由包括性能问题和 CI 不稳定。
但 Codeberg 的问题同样明显：定位只服务开源。它重点强调 FOSS（自由开源软件），商业闭源项目并不适配 。
Reddit 用户总结得很直白：它的灵活性太低了。
此外，Codeberg 能力与生态不足：CI/CD 依赖外部工具（如 Woodpecker）、插件生态几乎不存在、社区规模远小于 GitHub。
另一类替代方案是：Gitea 和 Forgejo。特点很简单：可以拥有完全控制权，但是必须承担全部复杂度。包括：CI/CD 自建、权限系统维护、备份与灾备以及安全更新等，这些工具本质不是平台，而是“基础组件”。
可以这样说，开源世界并非没有选择，而是所有替代路径都伴随着清晰且不可回避的代价。
参考链接：
https://news.ycombinator.com/item?id=47939579
https://mitchellh.com/writing/ghostty-leaving-github
https://www.xda-developers.com/ghostty-ditching-github-over-chronic-reliability-failures/
https://www.reddit.com/r/programming/comments/1sye8fc/ghostty_is_leaving_github/
https://www.mymcpshelf.com/blog/best-github-alternatives/?utm_source=chatgpt.com
https://www.reddit.com/r/opensource/comments/1qmiv56/for_those_who_use_github_to_host_their_projects/?utm_source=chatgpt.com
