Ghostty 离开 GitHub：一位 18 年老兵的无奈选择
Ghostty 离开 GitHub：一位 18 年老兵的无奈选择
当 Mitchell Hashimoto — Vagrant 的创建者、GitHub 用户 1299 — 宣布他的项目 Ghostty 将离开 GitHub 时，整个开源社区为之震动。这不仅是一个项目的技术迁移，更是一次对 GitHub 平台现状的深刻反思。
18 年的情感羁绊
Mitchell 在 2008 年 2 月加入 GitHub，用户编号 1299。在过去的 18 年里，他每天都会打开 GitHub，一天多次。即使在生活的重大时刻 — 分手疗伤、大学凌晨 4 点、蜜月旅行 — 他都在 GitHub 上提交代码。
"GitHub 是让我最快乐的地方，" Mitchell 写道，"我总是为它腾出时间。"
他的情感投入如此之深，以至于创建 Vagrant 的部分原因就是希望能被 GitHub 雇佣。在 20 岁时的第一次公开演讲中，他开玩笑说："如果 Vagrant 足够好，也许 GitHub 会雇佣我！"
GitHub 不仅仅是代码托管平台，它是 Mitchell 的梦想工作场所，他的爱好、工作和激情完美融合的地方。
现实的残酷打击
然而，最近一个月， Mitchell 开始记录日记。他在每个因 GitHub 故障而无法工作的日期旁画一个 "X"。
结果是：几乎每天都有 X。
"在我写这篇文章的当天，由于 GitHub Actions 故障，我已经无法进行 PR 审查大约 2 小时，" Mitchell 说，"如果它每天都把你阻挡在外数小时，这就不再是一个适合严肃工作的地方了。"
这不仅仅是个别服务的偶尔故障，而是系统性的可靠性问题。GitHub 的核心基础设施 — Issues、Pull Requests、Actions 等 — 已经无法满足专业开发者的需求。
核心问题：依赖性与脆弱性
有人会说 "Git 是分布式的！" 但 Mitchell 指出，问题不在于 Git 本身，而在于围绕它的基础设施：
- Issues & Discussions：社区交流的核心
- Pull Requests：代码协作的主要方式
- GitHub Actions：CI/CD 的关键环节
- Packages：依赖管理的中心
对开源社区的启示
Ghostty 的离开折射出开源项目面临的一个深层问题：平台依赖性风险。
当开源项目过度依赖单一商业平台时，就面临着多重风险：
1. 服务可靠性：频繁的故障影响开发效率 2. 政策变动：平台规则可能随时改变 3. 商业压力：商业利益可能凌驾于社区利益之上 4. 数据主权：项目数据不在自己的控制之下
可能的替代方案
Mitchell 表示，他们正在与多个提供商讨论，包括商业和开源方案。可能的选项包括：
1. 自托管方案
- Forgejo：Gitea 的社区分支，完全开源
- GitLab Community Edition：功能丰富，资源需求较高
- Codeberg：专注于纯开源项目的非营利平台
2. 商业托管
- GitLab.com：提供免费托管，有 CI/CD
- Bitbucket：Atlassian 生态系统的一部分
- Sourcehut：极简主义设计，强调邮件驱动工作流
3. 混合方案
保留 GitHub 的只读镜像，主开发迁移到其他平台，这样既照顾到用户习惯，又降低了对 GitHub 的依赖。迁移的挑战
离开 GitHub 并非易事，项目需要面对：
- 用户习惯：开发者已经习惯 GitHub 的工作流
- 生态系统：大量第三方工具依赖 GitHub API
- 社区迁移：Issue、PR、Star 等数据的迁移
- CI/CD 重构：GitHub Actions 替代方案的配置
- 发现机制：GitHub 是项目被发现的主要渠道
给开源项目的建议
Ghostty 的案例为其他开源项目提供了宝贵经验：
1. 多样化托管策略
不要把所有鸡蛋放在一个篮子里。考虑：- 主开发平台
- 镜像仓库
- 备份位置
2. 文档化迁移路径
提前规划迁移方案，包括：- 数据导出格式
- CI/CD 配置模板
- 通知渠道
3. 社区参与决策
重大变更应该与社区讨论，了解用户需求。4. 关注平台健康度
定期评估托管平台的：- 服务可靠性
- API 稳定性
- 社区反馈
GitHub 的未来
Ghostty 的离开应该是对 GitHub 的警钟。作为一个拥有数千万开发者的平台，GitHub 有责任：
1. 提升可靠性：核心服务必须达到企业级 SLA 2. 倾听社区：重视长期用户的反馈 3. 透明沟通：及时通报故障和处理进展 4. 改善体验：优化而不是过度复杂化产品
结语
Mitchell 的决定让人感伤，但也令人敬佩。"我想要 GitHub 变得更好，但我同时也想要写代码，" 他写道，"而现在，我无法在 GitHub 上写代码了。"
18 年的情感羁绊无法抵消现实的残酷。对于开源项目来说，平台应该是工具，而不是枷锁。当工具无法完成工作时，是时候寻找新的工具了。
Ghostty 的离开，或许是开源社区重新思考平台依赖性的契机。在未来，我们可能会看到更多项目采取多元化的托管策略，构建更健壮、更自主的开源生态系统。
> "我会保留 GitHub 上的只读镜像，" Mitchell 承诺，"我的个人项目和其他工作暂时仍会保留在 GitHub 上。Ghostty 是我、我们的维护者和我们的开源社区受影响最大的地方，所以这次变更的重点是 Ghostty。让我们看看未来会走向何方。"
这是一个时代的结束，也可能是另一个时代的开始。
---
参考资料：
- Mitchell Hashimoto 的博客：Ghostty Is Leaving GitHub
- Hacker News 讨论：Ghostty is leaving GitHub
- Ghostty 项目：https://github.com/ghostty-org/ghostty