三年前，我曾是一名负责为客户开发和维护Kubernetes集群的团队成员。当时，我们面临的主要问题是当镜像仓库宕机时，客户的生产环境会受到影响。解决这一问题的传统方法是设置一个状态化的镜像，但客户的预算和时间限制不允许我们这样做。在一次黑色星期五期间，我们的系统突然收到了大量流量，而GitHub的容器镜像仓库却宕机了。由于我们集群依赖的关键镜像来自于这个仓库，这大大限制了我们扩展集群的能力。这一事件促使我思考一个更好的解决方案，以避免类似的问题再次发生。最终，我开发了一个名为Spegel的项目，它可以通过去中心化的方式解决镜像分发的问题，而无需依赖状态化组件或太多的运维工作。 微软对Spegel表现出兴趣时，我感到非常兴奋。他们提出希望与我见面，讨论Spegel的合作可能性。最初的会议进行得很顺利，我看到了微软可能会贡献反向修改的前景。随后，我和微软的一名工程师进行了多次交流，帮助他们运行和理解Spegel的架构。然而，随着时间的推移，我却没有再听到他们的消息，以为是工作优先级的变化所致。 直到在巴黎举行的KubeCon会议上，我参加了一场关于加速镜像分发策略的演讲。演讲中提到的一个策略是P2P共享，这让我不由想起了Spegel。当主讲人提到微软开发的Peerd项目时，我迅速查阅了相关信息。Peerd是一款用于Kubernetes集群中容器内容的P2P分发工具。令我惊讶的是，该项目的README文件底部感谢了我及Spegel，表明微软受到了我们项目的启发。经过 deeper research，我发现Peerd中有许多函数签名和注释与Spegel非常相似，甚至是直接复制了Spegel的测试用例。令人不安的是，Peerd不仅 fork 了Spegel，而且使用了微软的MIT许可证，而未明确提到原始项目。 这种做法对 Spegel 产生了一些负面影响，特别是在新用户中造成了混淆。我经常被问及 Spegel 和 Peerd 之间的区别，这让我在解释时感到相当困难，因为这两者的历史纠葛。此外，微软的品牌影响力使得 Spegel 在市场上难以匹敌。尽管如此，我决定继续坚持下去。Spegel 仍然强大，自发布以来获得了超过 1.7k 的星标和 14.4 万次的拉取。不过，我开始考虑是否需要对 Spegel 的许可协议进行修改，以防止类似的事件再次发生。 对开放源代码维护者来说，与多亿级别的公司合作而不被利用，是一个难以解决的问题。特别是随着 Hashicorp 许可协议的变化和对开放源代码投资的整体下降，这个问题显得更加紧迫。为了继续支持 Spegel 的开发，我启用了 GitHub Sponsors。这一系列的经历也让我深刻反思，希望找到更好的方式来保护开放源代码的成果。 业内专家认为，这一事件反映了大公司在开放源代码领域的伦理问题。虽然MIT许可证允许 fork 和修改，但明确标注原始来源是基本的尊重。微软作为行业巨头，在处理这些合作时应更加谨慎，确保维护者的权益得到保护。Spegel 项目背后的开发者在社区中享有一定的声誉，而这一事件对他的信心打击很大，但他的坚持也为其他开放源代码维护者树立了榜样。