分叉一个开源项目从来不是首选，它往往意味着分裂与风险。然而，当项目的主导公司改变核心规则时，这有时会成为保护开源精神的唯一出路。Valkey项目负责人Roberto Luna Rojas和Madelyn Olson在最近的日本开源峰会上分享了他们的故事：面对Redis公司的许可证变更与封闭式治理，他们为何以及如何领导了这场成功的分叉。
2024年初，广泛使用的内存键值NoSQL数据库 Redis宣布放弃宽松的BSD许可证，转而采用限制性更强的RSALv2和SSPLv1许可证。这一决定直接导致了核心开发团队的不满与出走，他们迅速将代码分叉，创建了由Linux基金会托管的Valkey项目。这一分叉获得了AWS、谷歌、微软、甲骨文等科技巨头的支持，并取得了显著成功，甚至促使Redis在数月后决定重新以AGPL许可证开放其代码库。
在分叉发生之前，长期贡献者们已经观察到了一系列危险的信号。
预警信号：从开放走向封闭
时任AWS首席工程师的Olson指出，问题的核心在于治理。权力逐渐集中到了Redis公司内部。她总结了三个主要警示：
- 封闭式治理：公司任命的维护者在项目内部拥有特殊权限，而外部维护者（如Olson本人）则被边缘化为“普通成员”，核心决策权留给了公司员工。
- 公司拥有绝对否决权：Redis公司能够否决社区的任何提议，并强行引入自己希望的功能，即使社区维护者反对。Olson以Redis Functions功能为例，说明这是公司“强制引入项目”的结果。同时，一些备受社区（包括AWS、谷歌等）期待的功能，如集群槽统计，仅因公司不感兴趣而遭拒绝。
- 不透明的项目基础设施：构建流程、性能测试甚至开源制品的发布都托管在私有或专有系统上。“只有Redis的人才能进行实际发布，”Olson强调，这在后来分叉时构成了巨大障碍。
当2024年3月Redis宣布变更许可证时，维护者们知道，采取行动的时刻到了。
构建Valkey：拥抱开放与透明
分叉团队立即明确了优先事项：保持用户体验的连续性、建立强大中立的治理结构、维持社区团结，并坚持最大程度的开放。
他们采用了与之前模式相似的Linux基金会技术指导委员会模式，但承诺所有决策公开、透明、负责。最早的改变之一是取消所有私人会议。“所有会议都是公开的，”Olson说，“如果有人试图举行私人会议，我们会强制取消并公开。” 她将“默认一切公开”定为项目的核心原则。
由于Redis的基础设施不透明，Valkey团队在分叉初期遇到了巨大挑战：他们不知道二进制文件如何构建，也不清楚下游发行版从何处获取软件包。Olson回忆，他们很幸运地在一次活动上遇到了一位Fedora打包员，才得以重建下游支持体系。
为避免重蹈覆辙，新团队将文档和自动化列为重中之重。通过建立公开的自动化流程（如GitHub Actions CI/CD），任何人都能查看构建代码并参与发布。Olson自豪地指出：“前两次发布都是由社区成员完成的，而不是AWS。” 此外，团队还确立了六个月的固定发布周期，为用户和贡献者提供了宝贵的可预测性。
成长中的烦恼
开放治理也带来了新的挑战。由于任何人都能触发发布流程，错误也随之发生。例如，有工程师在忘记提交后“重新标记”了一个发布版本，导致Homebrew等下游系统混乱。Olson笑着建议：“别让你的社区这么做。” 正确的做法是创建并标记一个新版本。
分支保护同样关键。几位贡献者曾不小心将提交直接推送到生产分支。“不是因为我们不信任人，”Olson解释，“每个人都会犯错”，保护措施是为了防止意外。
沟通工具的选择也经历了一番波折。社区最初使用Slack，但尝试迁移到Matrix和Discord均告失败。“最终我们都慢慢回到了Slack，”Olson坦言，因为大多数贡献者已经在那里。
分叉清单：为可能到来的风暴做好准备
Olson和Luna Rojas建议，如果企业在开源项目中表现出不透明管理、忽视开发者与客户请求等预警信号，社区就应该开始为可能的分叉做准备。
Luna Rojas用比喻总结：“当分叉的怪物从你的代码库中跳出来时，你不想独自面对它。” 他分享了任何考虑分叉的项目都应遵循的清单：
- 立即起草章程。
- 规范源代码控制，在确保安全的同时保护分支和标签。
- 凝聚你的社区，无论他们在哪里。
- 记录一切。
- 始终支持下游维护者——这些使软件在全球发行版中可用的“无名英雄”。
分叉虽是最后的手段，但Valkey的案例表明，当原有治理模式失效、社区利益受到威胁时，一个开放、透明、由社区驱动的分叉，可以成为项目最健康、最可持续的新生之路。 | 
发表于 前天 07:14
|
查看: 5|
回复: 0
