首页信息技术 AI 动态

5.5万 Star 开源项目 Ghostty 被迫出走，GitHub 正在终结一代技术人的乌托邦

小新正四品 (知府) 2026-05-03 15:55 2 0 返回 AI 动态

小

小新正四品 (知府) 楼主

2026-05-03 15:55

第1楼

摘要：Mitchell Hashimoto 出生于 1990 年，是一位典型的“从开源社区成长起来”的工程师。在商业层面，HashiCorp 也一路成长为一家上市公司，成为少数从纯开源社区成功走向企业级商业化的软件公司之一。大学凌晨四点，所有人都睡着的时候，我再提交一次 commit。

结束18年热爱，Ghostty 逃离 GitHub

“有些告别，并不是因为不再热爱，而是因为再也无法继续留下。”

这是 Ghostty 项目创始人 Mitchell Hashimoto 在宣布项目即将逃离 GitHub 时写下的开头。整篇长文没有技术细节的铺陈，反而像一封写给过去18年的“告别信”，甚至，他在写这封“告别信”时是哭着写完的！

Mitchell Hashimoto 出生于 1990 年，是一位典型的“从开源社区成长起来”的工程师。

20 岁出头时，他就因创建 Vagrant 而在开发者圈子中崭露头角。Vagrant 解决的是开发环境一致性的问题——在容器和云原生尚未普及的年代，它几乎是团队协作开发的“标配工具”。

这一项目不仅让他一举成名，也成为后来一整套基础设施工具体系的起点。

2012 年，他与联合创始人一起创立了 HashiCorp。这家公司后来成为 DevOps 工具链中不可忽视的一极，推出了一系列广泛使用的基础设施软件，包括：

Terraform：定义并管理云资源的事实标准之一Consul：服务发现与服务网格基础组件Vault：安全密钥与凭证管理Nomad：轻量级调度与编排系统

这些工具的共同特点是：将复杂的基础设施操作抽象为可编程、可复用的工作流，本质上推动了“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 加速的世界里，曾经那种缓慢、稳定、以人为中心的开发体验，还能否被保留下来。