摘要：故事的主角叫 Philip Laine。他最近在 Hacker News 上发布了一个帖子，标题如同一声惊雷：“微软 Fork 了我的项目，然后发布了一个几乎一样的闭源竞品”
想象一下：你是一位充满激情的独立开发者，在特定技术领域深耕，发现了一个棘手的痛点。
你投入无数个日夜，创造了一个优雅的开源解决方案。
你将它分享给世界，遵循着开放、协作的理念。
你的项目开始获得认可，甚至引起了业界巨头内部工程师的注意和互动。
你以为这是技术改变世界的正向循环？然而，现实有时会给你一记响亮的耳光。
故事的主角叫 Philip Laine。他最近在 Hacker News 上发布了一个帖子，标题如同一声惊雷：“微软 Fork 了我的项目，然后发布了一个几乎一样的闭源竞品”
HN上这个帖子已经爆了，回帖人特别多，看来国外老哥们对微软怨念不小，我浏览器打开这个帖子都卡住了，评论文字太多了！
更重磅的是，他在个人博客上发布了一篇长达万字的控诉檄文——《被微软 Fork 了》(Getting Forked by Microsoft)。
这篇文章，细节详实，情绪饱满，矛头直指 微软 Azure Kubernetes Service (AKS) 团队。
截止目前，微软官方员工终于在原贴下的道歉，但是被评论区的开发者批评的体无完肤！
Philip 指控该团队开发的名为 Peerd 的新项目，是对他多年心血、开源项目 Spegel 的一次近乎“掏心式”的复刻和“洗白”。
这究竟是一场误会？是英雄所见略同的“平行宇宙”创新？还是科技巨头利用其资源优势，对小型开源项目进行的一次不道德的“围猎”？让我们跟随 Philip 的叙述，深入 Hacker News 上数千条评论的风暴中心，一探究竟。
Spegel：边缘 K8s 集群的“甘霖”与开发者的心血
原项目地址
Spegel (瑞典语“镜子”的意思) 是一个为 Kubernetes (K8s) 集群设计的无状态、集群范围的 OCI 镜像分发镜像。听起来有点绕？简单说，它的核心目标是解决在特定环境下（尤其是边缘计算、网络受限或大规模集群中）拉取容器镜像速度慢、消耗带宽大的痛点。
想象一下，在一个有数百个节点的 K8s 集群里，每个节点都要去远端仓库拉取同一个镜像，这是巨大的浪费。Spegel 的巧妙之处在于，它让集群内的节点互相成为“镜像源”。当一个节点需要某个镜像层 (layer) 时，它可以先问问“邻居”有没有，如果有就直接从邻居那里拉取，速度快得多，也极大节省了对外的带宽。这对于网络条件不佳的边缘设备或需要快速扩容的场景来说，简直是“救命稻草”。
Spegel 的关键特性包括：
P2P 分发： 节点间直接共享镜像层。无状态设计： 易于部署和管理。自动对等发现： 节点能自动找到集群内的其他“镜像伙伴”。资源友好： 设计上考虑了边缘环境的资源限制。MIT 协议开源： 源代码开放，允许自由使用和修改，只需保留版权和许可声明。Philip Laine 为 Spegel 倾注了大量心血，从最初的概念验证到不断迭代优化，积极在 GitHub 上与社区互动。项目逐渐积累了一批用户，解决了不少实际问题。
故事的“不对劲”之处，始于微软 Azure 团队的工程师开始关注并参与到 Spegel 的 GitHub 项目中。Philip 在博文中明确提到：
微软工程师的参与： 来自微软（特别是 AKS 团队）的工程师在 Spegel 的 GitHub 仓库中提交了 Issues (问题报告)、参与了 Discussions (讨论)，甚至对项目表达了兴趣和认可。核心人员的重叠： Philip 指出，一些当初与他在 Spegel 项目上互动过的微软工程师，后来赫然出现在了微软新项目 Peerd 的作者或贡献者名单中。正当 Philip 以为 Spegel 的价值得到业界认可，甚至可能迎来与巨头合作的契机时，微软方面却悄然推出了 Peerd。
当 Philip Laine 看到 Peerd 的介绍和代码库时，他惊呆了。用他的话来说，Peerd 在核心概念、架构设计甚至一些关键技术选择上，都与 Spegel 如出一辙。
连测试用例都是抄的
函数注释都抄
他在博文中列出的“相似”或“可疑”之处包括：
核心功能与目标一致： Peerd 的自我描述几乎就是 Spegel 的翻版——一个用于在 K8s 集群（特别是 AKS）内进行容器镜像 P2P 分发的工具，旨在加速镜像拉取，减少对外部仓库的依赖。解决的是同一个核心问题。架构设计上的雷同： Philip 认为 Peerd 的整体架构思路，与 Spegel 非常相似，都是利用节点间的 P2P 网络来共享数据。关键技术选择的“巧合”： 最让他感到不安的是 Peerd 在一些具体技术选择上的“默契”。例如，Spegel 在早期探索过使用 mDNS/DNS-SD 进行节点发现，但后来转向了基于 K8s API 和 Pkarr (一个用于 DHT Pebel 数据签名的库) 的方案。而 Peerd，也采用了 Pkarr 进行节点身份验证和发现。人员重叠与时间线： 参与过 Spegel 讨论的微软工程师出现在 Peerd 项目中，加上 Peerd 的发布时间点，都让 Philip 强烈怀疑 Peerd 并非“独立发明”，而是受到了 Spegel 的深度“启发”，甚至可能是直接的“成果挪用”。最初的归属与署名问题： Philip 指出，Peerd 最初发布时，其 README 文件和宣传口径似乎将其描述为一个全新的、由微软独立开发的项目，并未提及 Spegel 的任何影响或给予应有的署名 (Attribution)。Philip 的感受从震惊转为愤怒，再到深深的无力感。
他感觉自己的开源贡献和创新成果，在与巨头的互动中，被对方轻易地“学习、吸收、然后包装”成了自己的产品。
尽管 Peerd 本身也是开源的（使用 Apache 2.0 协议），但这并不能减轻他的被“掏空”感。问题的核心在于：我的想法和努力，是否被承认？基本的署名和尊重在哪里？
Philip 的万字长文被转到 Hacker News 后，评论区瞬间成为了开发者情绪的宣泄口和理性分析的战场。数千条评论交织着愤怒、同情、技术探讨和对行业未来的忧思。
愤怒与同情是主旋律： 绝大多数评论者站在了 Philip Laine 一边。他们谴责微软 Azure 团队的行为是“不道德的”、“掠夺性的”、“对开源精神的践踏”。许多独立开发者分享了类似的恐惧：“如果我的项目被大厂看上了，会不会也是这个下场？”技术层面的深度挖掘： 社区成员开始仔细比对 Spegel 和 Peerd 的公开信息。有人深入研究了两者在节点发现、数据传输、状态管理等方面的异同。对 Pkarr 的选择成为了讨论焦点，一些人认为这确实是强有力的“借鉴”证据。也有人尝试分析两者代码（因为都是开源的），寻找直接复制代码的痕迹。开源协议再讨论 (MIT vs. Apache 2.0)： 这次事件的核心争议点之一在于署名和衍生作品的处理。Spegel 是 MIT 协议，要求使用者在分发时保留版权和许可声明。Peerd 使用了 Apache 2.0 协议，这也是一个流行的开源协议。质疑微软内部流程： “微软这么大，是不是左手不知道右手在干什么？” 评论区猜测，也许是 AKS 团队内部某个小组看到了 Spegel 觉得不错，没有充分沟通或评估风险就“快速跟进”了？或者是 KPI 压力下的“歪招”？“重复发明”还是“刻意模仿”？ 少数声音认为，P2P 镜像分发并非全新概念，解决 K8s 镜像拉取痛点也是行业热点，不同团队独立研究后得出相似方案的可能性不能完全排除。但支持者反驳，考虑到人员重叠、关键技术选择的巧合以及时间线，将此完全归咎于“巧合”过于牵强。️ 给开发者的启示： 这再次引发了关于如何在开源世界保护自己的讨论。MIT 协议的宽松性是否足够？面对可能“借鉴”创意的大公司，是否需要更强的法律武器（如专利）或更严格的协议？但这是否又会阻碍开源的分享精神？呼吁透明与担责： 社区强烈要求微软 Azure 团队对此事给出公开、透明的解释。承认错误？澄清误会？拿出证据？无论如何，逃避不是选项。目前，这起事件仍在发酵中。微软官方员工终于在原贴下的道歉，并可能在 Peerd 的文档中补充了对 Spegel 的引用。但社区开发者们并不买账！
官方回应
网友评论
Spegel vs. Peerd 事件，远不止于两个项目之间的纠纷。它折射出当今开源生态系统中的结构性矛盾和挑战：
巨头与社区的共生与博弈： 大型科技公司是开源的最大受益者之一，也是重要的贡献者。但它们与草根社区、独立开发者之间的关系始终是微妙的。✨ 创意的价值与保护的困境： 在软件领域，一个巧妙的架构设计、一个解决痛点的核心思路，其价值可能远超具体的代码行。但这些“软”的创新成果，往往最难受到现有知识产权体系的有效保护，极易被“借鉴”。开源协议的精神与现实： 开源协议不仅是法律文本，更承载着分享、协作、透明、尊重的社区精神。宽松协议如 MIT 依赖于参与者的自觉和善意。当有“玩家”只利用其自由度，却无视其精神内核（如署名、致谢）时，就会破坏社区的信任基础。⚖️ 权力的不对等： 个体开发者在与巨头对话时，往往处于绝对的弱势地位。信息不对称、资源悬殊，使得沟通、谈判乃至维权都异常艰难。社区成为第四权力？ Hacker News 这类平台的舆论力量不容小觑。它为弱势方提供了一个发声的渠道，能够形成强大的舆论压力，在一定程度上制衡大公司的行为。来源：对线面试官一点号
