被 Microsoft "Fork" 了：关于开源项目 Spegel 的故事
Philip Laine
关于软件开发的随想
Philip Laine
被 Microsoft "Fork" 了
2025年4月21日 阅读时长5分钟
三年前，我所在的团队负责为终端用户客户开发和维护 Kubernetes 集群。客户环境中停机的主要原因之一是镜像仓库出现故障。传统的解决方案是建立有状态的镜像，但由于客户的预算和时间限制，我们无法这样做。在一次黑色星期五，当 GitHub 容器注册表宕机时，我们开始受到大量流量的冲击。这限制了我们扩展集群的能力，因为我们依赖于该注册表中的关键镜像。在这次事件之后，我开始思考一种更好的方法来避免这些可伸缩性问题。这个解决方案不需要有状态组件，并且只需要最少的运营监督。这就是 Spegel 的由来。
作为开源项目的唯一维护者，当 Microsoft 联系我安排会议讨论 Spegel 时，我感到非常兴奋。会议进行得很顺利，我感觉未来充满合作的机会，并希望能够招募新的维护者。我继续与一位 Microsoft 工程师进行讨论，帮助他们运行 Spegel 并回答他们提出的任何架构问题。当时我很乐观，因为我认为 Microsoft 有可能根据他们的学习贡献代码。随着时间的推移，一切归于平静，我以为是工作重点发生了变化。
直到在 KubeCon Paris 参加了一个引起我兴趣的演讲。该演讲是关于加速镜像分发的策略，其中讨论的一个策略是 P2P 共享。摘要中的主题听起来与 Spegel 相似，所以我很高兴听到其他人对这个问题的想法。在演讲中，我很高兴看到 Spegel，我自己的项目，被讨论为 P2P 镜像共享解决方案。当 Microsoft 创建的 Kubernetes 集群中的容器内容 P2P 分发器 Peerd 被提及时，我迅速对其进行了研究。在 README 的底部，有一段感谢我和 Spegel 的文字。这种致谢让我觉得他们从我的项目中获得了一些灵感，并开发了自己的版本。
在研究 Peerd 时，我对理解该问题领域中不同方法的兴致迅速消退。我看到了非常熟悉的函数签名和注释，就像我自己写的一样。深入挖掘后，我发现了一些引用 Spegel 和我以前雇主的测试用例，这些测试用例直接来自我的项目。这些引用至今仍然存在。该项目是 Spegel 的一个 "fork" 版本，由 Microsoft 维护，但使用 Microsoft 的 MIT 许可证。
Spegel 是在 MIT 许可证下发布的。在 MIT 许可证下发布的软件允许 "fork" 和修改，而无需贡献这些更改。我默认使用 MIT 许可证，因为它简单且宽松。该许可证不允许删除原始许可证并声称代码是由其他人创建的。看起来该项目的大部分代码直接从 Spegel 复制，而没有提及原始来源。我包含了一小段代码片段，比较了添加镜像配置的代码，甚至函数注释都是相同的。
Peerd 的创建产生了一个负面影响，即它给新用户带来了困惑。我经常被问及 Spegel 和 Peerd 之间的区别。作为一名维护者，我有义务尽可能地保持公正和实事求是，但这段动荡的历史让这变得充满挑战。Microsoft 拥有很高的品牌知名度，因此 Spegel 很难在这样一个庞然大物旁边占据一席之地。
作为一名开源维护者，我投入了大量时间来处理社区请求、修复 bug 和安全漏洞。在与 Microsoft 的对话中，我愿意合作，继续构建一个工具来造福开源社区。多年来，我为许多开源项目做出了贡献，并创建了自己的一些项目。Spegel 是我从头开始创建的第一个获得一些关注的项目，并且似乎受到了社区的赞赏。看到我的项目被 Microsoft "fork" 让我觉得自己不再有用。有一段时间，我怀疑是否还有必要继续开发 Spegel。
幸运的是，我坚持了下来。Spegel 仍然保持强劲的发展势头，自两年多前首次发布以来，已获得超过 1.7k 个 star 和 1440 万次 pull。然而，我不是第一个，不幸的是也不会是最后一个遇到这种 "大卫与歌利亚" 般经历的人。单独的维护者如何与数十亿美元的公司合作，而不被利用？随着 Hashicorp 许可的改变在开源社区中产生连锁反应，以及对整个开源领域的投资大幅下降，社区如何才能获胜？为了资助 Spegel 的工作，我启用了 GitHub赞助。这次经历也让我考虑更改 Spegel 的许可证，因为这似乎是我唯一能扔的石头。