Tangled 这篇文章的钩子很直接：git 早就是去中心化的，但开源协作不是。
这事反常，也现实。代码仓库可以 clone、mirror、迁移。可一个开源项目真正跑起来，靠的不只是代码。issue、pull request、review、star、关注关系、贡献者身份、SSH 公钥、项目动态流，这些才是日常协作层。
而这一层，过去十几年高度收口到 GitHub。
Tangled 的方案并不激进。它不重写 git。代码仍然用 git 传输，协作事件交给 AT Protocol，让不同 git 服务器之间也能协作、fork、提 PR。
这篇文章该看的，不是“Tangled 能不能马上取代 GitHub”。答案大概率是否定的。更该看的问题是：开源把协作入口继续押给单一平台，风险是不是已经太大了。
git 没坏，被锁住的是协作层
原文把代码协作拆成两层。这个拆法很关键。
| 路线 | 代码传输 | 协作沟通 |
|---|---|---|
| 早期开源 | git | |
| GitHub 时代 | git | GitHub 网站 |
| ForgeFed 路线 | git | ActivityPub |
| Tangled 路线 | git | AT Protocol |
所以问题不在 git。
git 仍然负责代码本体。它分布式、耐用、粗粝，但够稳。真正被平台化的是 git 之外那套工作流：issue 怎么开，PR 怎么提，review 怎么留痕，贡献者怎么被识别，项目声誉怎么积累。
Tangled 把联邦化的 git 服务器叫作 knots。它想做几件事：
- 在不同服务器上的仓库之间协作。
- 跨服务器 fork。
- 把代码 push 到自己的服务器后，向另一台服务器上的 repo 发 pull request。
AT Protocol 在这里承载协作事件。包括 issue、PR、邀请、SSH 公钥、动态流、关注、star，以及未来可能出现的 vouch 等社交信号。
代码本体还是 git。变的是协作层的流转方式。
这不是成熟的 GitHub 杀手。它更像一个正在搭建的联邦化 forge 方案。可它提出的问题很硬：如果开源代码可以分散，为什么开源协作必须集中在一个网站？
影响最大的是维护者，不是围观者
原文说 GitHub 近期表现不稳，还用了 crumbling 这样的词。这个说法我会打折。
目前材料不足以支撑“GitHub 正在崩盘”这种叙事。不能把它写成财务恶化、组织失控或确定性衰退。更稳的说法是：GitHub 太关键了，所以它的任何不稳定、规则调整、接口变化，都会被放大成基础设施风险。
受影响的人很具体。
| 对象 | 真正被卡住的地方 | 现实动作 |
|---|---|---|
| OSS 维护者 | issue、PR、review、贡献者关系、项目声誉都在平台里 | 暂时不必迁移，但应保留镜像、备份议题数据，避免只剩一个入口 |
| 开源基础设施提供者 | 很难和 GitHub 工作流平等互通 | 重点观察跨服务器 PR、身份同步、垃圾治理能否跑通 |
| 依赖 GitHub 工作流的开发者 | 迁移成本不在代码，而在身份、通知、review 习惯 | 先观望，不要为理念更换主工作流 |
对维护者来说，最现实的风险不是“代码拿不回来”。代码通常拿得回来。
麻烦在协作资产。
多年积累的 issue、讨论上下文、贡献记录、review 关系、star 带来的可见度，很难像 git 仓库一样完整搬家。代码可以 clone，关系很难 clone。
这也是 Tangled 这类方案有意义的地方。它不是在重造一个代码仓库，而是在试图把协作事件从平台页面里拆出来。
“天下熙熙，皆为利来。”这句话放到平台经济里一点也不陈旧。GitHub 提供了极好的体验，也自然获得了控制权。问题不在它赚钱，也不在它强。问题在默认入口和控制权合在一起后，生态会变脆。
联邦化方向对，但难点都在脏活里
我赞成 Tangled 指出的方向：开源需要反单一平台。
不是因为 GitHub 做得差。恰恰相反，是因为 GitHub 做得太好，大家才把太多东西交给了它。
但我不买账一种轻松叙事：协议开放了，用户自然会迁移。
不会。
开发者工具的迁移从来不是理念投票。维护者最怕多维护一套流程。贡献者最怕点开以后不会提 PR。项目最怕新人少一半。基础设施提供者最怕标准正确，但没人用。
Tangled 要过的关，至少有三道。
| 变量 | 要解决什么 | 如果解决不好 |
|---|---|---|
| 体验 | 跨服务器 PR 要接近 GitHub 的顺手程度 | 只会留在小圈子里 |
| 网络效应 | star、关注、贡献记录要能跟着人走 | 项目曝光和信任会断裂 |
| 治理 | 垃圾 issue、冒充身份、恶意 fork、信任背书要有机制 | 联邦网络会被滥用拖垮 |
email 和 git 能活很久，是因为它们简单、粗粝、耐用。GitHub 赢，是因为它把粗粝的协作包装成网页上的顺手动作。
Tangled 如果只复兴前者的精神，却拿不出后者的顺滑，就会停在少数人的正确玩具里。
这里也要把对比说清。ForgeFed 走的是 ActivityPub 路线，Tangled 走 AT Protocol。它们都在处理同一个老问题：代码本体早就能分散，协作事件却被网站吞了。
差别不该被简化成“哪个协议更先进”。真正要看的是执行：跨服务器 PR 是否自然，身份是否可携带，通知是否可靠，维护者是否少受折腾。
接下来最该观察的不是口号，而是两个硬指标。
一是 Tangled 能不能让一个普通维护者在不牺牲太多体验的情况下，接受外站贡献。二是它能不能处理真实开源项目里的脏流量：垃圾 issue、低质量 PR、身份冒充、项目声誉劫持。
这两个跑不通，联邦化就只是架构图好看。
跑通了，哪怕规模还小，它也会给开源世界多留一条路。
开源不只等于代码开放。协作入口、身份系统、项目声誉、贡献路径，也都是基础设施。过去我们太习惯把这些东西放在一个平台里，方便到忘了它们其实不是 git 的一部分。
Tangled 的价值，正在于把这层遮布掀开。
GitHub 未必会倒。可一个健康的开源世界，不该只有一扇门。