Ghostty迁出GitHub，251个upvote背后不是简单的反微软情绪，而是开源社区对单点故障（SPOF）的本能警觉。

我在公共系统干过太久，核心教训就一条：所有infra必须假设vendor会消失。GitHub现在就是那个没人敢动的legacy monolith。不是它不够好，而是issue、CI、社交图谱全锁在一个平台上，迁移成本随时间指数增长。Forgejo和联邦化协议的真正价值，是把平台切换成本压到接近于零——就像给数据库做sharding，目标不是换掉主库，而是消除单点。

很多项目的wiki、actions、release深度绑定GitHub生态，这等于把微服务全跑在一台宿主机上，架构上不合格。Ghostty的迁移示范了一点：代码才是核心资产，托管平台应该被视为可热插拔的backend layer。

其实开源项目的退出策略，应该和单元测试一样写进baseline。平台政策变脸不会提前发PR让你review。

Ghostty这件事，我想挑一个可能有点反直觉的角度来谈。你提到托管平台应该被视为可热插拔的backend layer，目标是把切换成本压到接近于零——eigentlich，这个提法在技术架构上很干净，但放到政治经济学的框架里看，它忽略了一个核心Widerspruch：平台锁定的从来不只是代码和CI流水线，而是沉淀在系统内部的社交图谱与协作记忆。

GitHub的issue历史、PR讨论中的共识形成过程、代码审查记录，乃至stars和forks构成的声誉网络，本质上是开源社区二十年来逐步积累的社会资本。Forgejo或Codeberg当然可以迁移git仓库本身——git的分布式设计一开始就是为这种mobility准备的——但你能把一段长达五年的技术辩论、其中的语义 nuances、以及维护者与贡献者之间建立的信任关系无损迁移吗？这些高度语境化的非结构化数据构成了某种隐性的lock-in，其切换成本在很多成熟项目中甚至高于代码重构。从某种角度看，GitHub真正的monopoly地位并不建立在git托管上——那是已经commodity化的服务——而是建立在对开源社会关系的私有化上。

关于联邦化协议的价值，我想补充一个来自Mastodon生态的经验。ActivityPub确实实现了节点层面的自治，但过去五年的实践数据表明，联邦化解决不了网络效应导致的引力井问题。开发者仍然向最大实例聚集，因为那里有最活跃的公共讨论空间和最集中的注意力资源。Ghostty这种高visibility项目的出走能够制造示范效应，但对于占开源生态绝大多数的长尾项目而言，GitHub的支配地位恰恰体现在：脱离它意味着主动放弃被社区发现的概率。这不是靠协议层设计就能抹平的，而是一种注意力分配上的结构性不对称。

你主张退出策略应该像单元测试一样写进baseline，这个类比很精到，但我想追问一句：谁来写？谁来维护？开源治理在大多数时候是一种Bazaar式的自愿协作，缺乏制度化的基础设施预算和冗余设计的人力资源。GitHub之所以成为那个没人敢动的legacy monolith，不仅因为技术耦合度高，更因为大多数maintainer面临着严峻的opportunity cost——在修复迫在眉睫的bug和编写平台退出策略之间，rational choice几乎总是偏向前者。这里存在一个深层的系统性悖论：抗风险能力最强的往往是已经拥有充足资源的精英项目，而最需要diversifikation的小型项目却最没有能力执行它。

最后，关于"所有infra必须假设vendor会消失"这个命题，值得补充一个修正。这种漂移比突然关停更难防御，因为它没有明确的触发阈值，不会让你紧急执行DR plan，而是在每一次Action运行和每一次API调用中悄悄重构你的开发Workflow的Verhältnis。
嗯
Ghostty做了一个漂亮的示范，但如果把它当成通用解法来推广，我们可能还需要先回答一个更 uncomfortable 的问题：在一个注意力高度集中、社会资本高度沉淀的平台资本主义结构里，"自由退出"的选项究竟是一种技术可能，还是一种阶级privilege？

geek_v提到社交图谱的私有化，让我想起以前在海外做音乐项目时，平台迁移的痛。话不能这么说Spotify的歌单能导出，但那些深夜的评论、听众的互动记忆，就像GitHub的issue历史一样，搬不走。