开源项目被收购之后，社区为何集体「出走」
一个被广泛使用的小工具被商业公司接手，几周后主要维护者集体另起分支。这是一次典型的分叉事件复盘。
事件概览
那个项目很小：一段不到两千行的实用工具，作者维护了三年，在相关圈子里几乎人手一个。它的知名度不高，但依赖它的人很稳定。
变化始于作者宣布以个人名义将项目转让给一家商业公司。几周后，项目的主要贡献者发起了一个独立分支。这个过程被外界简单概括为「社区叛逃」，但实际的分歧点要具体得多。
时间线还原
以下节点均来自公开可查证的信息，按事件发生顺序排列。排序本身就是一种信息。
第 1 周
作者宣布转让项目
作者称因维护精力有限，决定将项目交由一家商业公司继续维护，承诺保持开源。
第 2 周
治理结构发生变化
新维护方调整了贡献者权限与合并流程，部分原有维护者权限被收回。
第 3 周
路线图出现分歧
新维护方公布的路线图中包含闭源的云端功能，引发关于边界的讨论。
第 4 周
主要贡献者发起分支
多名核心贡献者另起仓库，保留原有许可证与贡献流程，并邀请原社区迁移。
第 6 周
两个版本并行
原项目与分支同时维护，使用者在依赖选择上开始出现分化。
关键角色
我们关注的是每个角色在节点上「做了什么」，而不是他们「说了什么立场」。
原作者
转让决策方
出发点是维护精力有限，但在转让时对治理结构的交接考虑不足。
接手公司团队
新维护方
希望把项目与商业产品打通，其路线图与社区的开放预期出现了张力。
核心贡献者群体
社区代表
对「开源边界」较为敏感，权限与路线图的叠加变化成为他们离开的直接原因。
还没解释清楚的疑点
比结论更重要的是问题本身。以下几条是公开信息里仍然存在缺口的地方。
如果作者有权转让，社区为什么反对？
法律上的所有权与情感上的归属常常并不重合。项目虽然由作者发起，但它的价值很大程度上来自社区持续的贡献，转让忽略了这一层。
争议的核心是闭源吗？
路线图中的闭源部分是导火索，但更根本的是权限调整。治理结构的变化，让贡献者感到自己不再是项目的参与者，而只是使用者。
分支之后，哪个版本会胜出？
取决于使用者更在意什么。看重商业支持的一方会留下，看重开放治理的一方会迁移。这类结果通常由生态而非技术本身决定。
逻辑复盘
开源的核心资产，是治理而不是代码
代码可以被复制，治理却很难。一次成功的转让，真正要交接的不是仓库，而是社区对决策流程的信任。权限与路线图同时变动，等于在一次动作里挑战了这份信任。
分叉不是失败，而是开源的一种常态
分叉意味着使用者有了选择，从生态角度看未必是坏事。真正需要反思的，是转让过程中能不能把治理规则一起写清楚，让分歧在更早的阶段被讨论。
一句话结论
这次分叉留下的经验很朴素：开源项目可以换主人，但不能轻易换规则。一旦规则变化快于沟通，社区就会用脚投票，而分叉，正是它投票的方式。