一个从2008年就开始用GitHub的开发者，最近开始在本子上画"X"——每遇到一次影响工作的故障，就记一笔。一个月下来，几乎天天都有。
「几乎每天都有一个X」
Mitchell Hashimoto在博客中写道，过去一个月他养成了记日记的习惯：日期旁边画叉，代表当天GitHub故障影响了工作。结果是"几乎每天都有一个X"。
发文当天，GitHub Actions（持续集成/持续部署服务）又挂了约2小时，他完全没法做代码审查（Pull Request review）。Hashimoto的原话是："这不再是能承载严肃工作的地方，如果它每天都能把你挡在外面好几个小时的话。"
Hashimoto的身份有点特殊。他是GitHub第1299位注册用户，2008年入站，用了18年。"每天多次打开GitHub，连续18年多"，"早在'doom scrolling'这个词出现之前，我就已经在GitHub issues里 doom scrolling 了"。
他开发的终端软件Ghostty，正是托管在GitHub上。这款工具在开发者圈子里口碑不错，但Hashimoto决定：重要项目要搬走。
哪些走、哪些留
Hashimoto的迁移策略很明确：
个人项目继续留在GitHub。但关键的大型项目——包括Ghostty——要换地方。
至于搬去哪，他自己也不知道。"我还没决定Ghostty会托管在哪里"，Hashimoto写道。但他说会关注这件事的进展，暗示选择还在评估中。
值得注意的是，Hashimoto留了退路：如果GitHub把稳定性问题解决，他愿意回来。但目前，"不会把关键工作放在那里"。
GitHub的麻烦不止这一家
Hashimoto不是唯一一个被折腾的人。原文提到，从小型爱好者到大型企业，最近都受到了GitHub可靠性问题的影响。规模大到什么程度？OpenAI reportedly 考虑过自建代码托管平台，只为确保随时能访问自己的代码。
GitHub的故障频率已经影响到日常开发流程。对Ghostty这种活跃的开源项目来说，持续集成服务（GitHub Actions）宕机意味着自动化测试、构建、发布全卡死。Hashimoto提到的"2小时无法做PR review"，在协作密集的项目里会直接阻塞整个团队的进度。
一个用了18年的平台，用户忠诚度本该极高。但当可靠性跌到"几乎每天故障"的程度，迁移成本反而显得可以接受了。
迁移本身也是成本
Hashimoto的犹豫——"还没决定去哪"——道出了开源生态的现实困境。
GitHub的护城河从来不只是代码托管。18年积累的问题讨论、PR历史、协作关系、自动化工作流，迁移意味着重建这一切。替代品如GitLab、SourceHut、Codeberg各有优劣，但没有一个能无缝承接GitHub的生态位。
Hashimoto选择拆分策略：个人项目留守，降低迁移摩擦；核心项目出走，规避业务风险。这种"骑墙"姿态，恰恰说明他对GitHub仍有感情，只是不再信任其可靠性。
更深层的问题是：当平台规模大到成为行业基础设施，它的每一次故障都是对整个开发者的征税。Hashimoto的日记本，记录的是个体开发者的耐心消耗曲线——从"每天多次打开"的依赖，到"几乎每天画叉"的疲惫。
GitHub需要面对的，不只是一个老用户的离开，而是"可靠性"这个品牌核心资产正在贬值的信号。Hashimoto说"愿意回来"，但前提是"GitHub gets its act together"——把状态调整好。这句话的潜台词是：用户还在给机会，但窗口期正在收窄。
Ghostty的最终去向，会成为开源社区的一个风向标。如果Hashimoto这样的标杆开发者能在新平台重建完整的协作体验，更多项目可能会跟进。反之，如果迁移后的 friction（摩擦成本）过高，也会印证GitHub生态锁定的深度。
无论结果如何，这个案例都说明了一件事：在开发者工具领域，"用习惯了"是最脆弱的护城河，"每天能用"才是硬通货。
热门跟贴