2025 年 8 月 1 日，青云科技在 KubeSphere 社区发布消息，宣布暂停 KubeSphere 的开源版本支持（https://github.com/kubesphere/kubesphere/issues/6550）。这一消息如同投下一颗重磅炸弹，引发了全球开源社区的强烈反响。 作为前青云科技的高级社区经理、KubeSphere 项目的前核心维护者，我曾参与这个项目从零到一的过程。在这篇文章中，我站在一个长期开源从业者的角度，尝试用辩证的视角去还原事件背后更深层的逻辑，并回答一些几个普遍关注的问题。
2025 年 8 月 1 日，青云科技在 KubeSphere 社区发布消息，宣布暂停 KubeSphere 的开源版本支持（https://github.com/kubesphere/kubesphere/issues/6550）。这一消息如同投下一颗重磅炸弹，引发了全球开源社区的强烈反响。
作为前青云科技的高级社区经理、KubeSphere 项目的前核心维护者，我曾参与这个项目从零到一的过程。在这篇文章中，我站在一个长期开源从业者的角度，尝试用辩证的视角去还原事件背后更深层的逻辑，并回答一些几个普遍关注的问题。
KubeSphere 自 2018 年 4 月份开始在 GItHub 写下第一行代码并开源，至今七年多的时间，曾被全球数以万计的大小企业所使用，与众多知名开源项目集成，被全球各大云厂商认可和合作，不可否认的事实是，KubeSphere 是一个非常优秀的开源项目和云原生产品，项目创始人 Ray 也是一个很有开源情怀的人。
我曾在 2018-2022 年担任青云科技的高级社区经理，在全球不遗余力地推广 KubeSphere，从零到一构建了活跃多元化的开源社区，创作了官网、用户文档、博客、视频教程，在全国各大城市办过几十场活动，并将 KubeSphere 孵化的 3 个子项目捐给 CNCF 基金会。
2020-2022年几乎是 KubeSphere 在全球飞速发展的三年，我记得曾经几乎每天都能看到新的用户增长和使用反馈，以及来自全球不同公司的贡献者参与。说实话，那曾是我最有工作成就感和成长飞快的时光，在开源社区认识了很多优秀的开发者，也给公司带来过一些商业机会。
令人遗憾的是，这次青云的决定来了个 180 度急转弯，不仅将前端代码闭源，还删除所有已发布的文档和安装镜像，彻底将 KubeSphere 推向了深渊，在全球开源社区引发了巨大的舆论和开源信任危机。巧合的是，消息发布当天正是项目创始人 Ray 宣布离职的时间点。我不知道这是否是有意为之，但属实是不讲“情面”的一个选择，也引发了国内外很多开发者对“中国式开源”的发问和深层焦虑。
事实上，我刚开始看到消息时也有些情绪化，因为 “KubeSphere 闭源删库”后，互联网舆论呈现了墙倒众人推的趋势，很多博主的文章以及吃瓜群众的评论，站在制高点一味地批判和指责商业公司“闭源”的行为，诋毁该开源项目的价值，甚至还有很多人直接全盘否定 “中国开源” 的努力和价值。这些带有偏见的观点，很容易误导大众的认知和情绪，并且不会让这个行业变得更好。
我也看到了很多曾经的用户、贡献者、前同事们表示唏嘘和惋惜，感叹自己曾经参与过的开源明星项目的陨落。我没有选择在第一时间发布这篇文章，在阅读了国内外很多博主的文章、讨论和用户在 GitHub 上的回复后，带着辩证的角度来分享自己的一些观点。
截止目前，我看到的可能有价值的一个讨论是，有一些用户在 GitHub 上希望通过投票和众筹的方式重新组建纯社区自发驱动的 KubeSphere 开源贡献者团队，Issue 下也有众多用户和贡献者表示支持，这让我感受到了些许欣慰，因为它展现了开源社区开发者的集体力量，但这个目标要实现的难度不亚于去经营一家公司。
这是一个值得每位开源参与者深思的问题。开源项目由商业公司主导，并不意味着它对社区有“义务”无限维护。
显然 “KubeSphere 闭源删库” 是一个唐突而又糟糕的决策，但我想说，选择“闭源”或核心团队撤离开源项目这件事情本身从来不是某一家商业公司的过错，任何一家商业公司主导的开源项目都存在这样的“闭源”风险，这在开源界也已有多个案例。客观来说，在当前的经济下行的市场环境下，几乎所有商业公司都在收缩投资或调整战略，对于营收增长慢的项目和人力都有被优化的可能。维护开源项目并不是一家商业公司应有的社会责任或义务。
但是，开源项目背后的主导公司如果希望撤资开源投入，需要遵循开源项目客观存在的生命周期，而不是把开源社区一刀切，用开源断供来“绑架”用户，转到自家商业产品，这并不是一项精明的生意决策。实际上，如果青云选择将 KubeSphere 项目归档 （Archive）并选择提前一段时间在社区发布项目 Retire 的公告，同时致谢所有参与贡献的开发者和用户，那就不会出现今天的危机局面。
“得开发者得天下” 是一个很通俗的道理，很多大小企业选择走开源的策略，也正是因为开源是一个能够低成本地快速地获取全球开发者用户的机会和建立跨企业的社区合作模式，比传统的闭源软件开发和 Marketing 传播更快，通过开源社区协作开发也更容易建立规模与行业标准。
但很多商业公司错误地把开源作为低成本“获客”的渠道，把开源作为一项“免费广告”的福利，利用开发者对开源技术的关注来获取销售商机，这样的做法是对开源社区最大的伤害，也是对商业公司口碑的破坏。
实际上，很多开源项目的开发者用户是一些企业的运维开发负责人或内部决策影响者，他们虽然可能不能直接决定公司的软件采购，但他们提供的观点和意见会直接或间接地影响企业管理层的决策。很可惜，很多开源商业化公司的 CXO 们并不懂开发者的重要性，忽视了开源社区的规模影响力。
答案是能。
青云作为一家上市公司，公司层面一定还是会关注自己在业内的口碑以及客户的信任。这里我不适合作为局外人指点江山，但提供思路作为参考，毕竟在社区里还有很多用户在关注 KubeSphere 后续是否会有好的转机。
让我们来看一个正面的例子，CNCF 毕业项目 Flux 背后的核心维护公司 WeaveWorks 在去年 2 月份虽然宣布了公司关闭停止运营，但 CEO 第一时间在联系一些大公司的用户和贡献者参与 Flux 项目的维护，并积极寻求 CNCF 的帮助，确保该项目在即使没有了 WeaveWorks 公司的支持，还能继续在社区维护和迭代。
青云是否会考虑做一个 “git revert” 的回滚操作，来响应社区目前呼声最高的提议：恢复闭源的仓库、下线的文档、历史镜像，并将开源项目交由给中立的社区自发去维护？青云作为商业公司继续去做自己的商业产品，或许还有重建信任的机会。如果公司层面担心开源项目抢了自己的商业产品的蛋糕，那必然是商业产品与服务做得还不够好。
KubeSphere 有两个子项目的开源协议值得探讨，第一个是此次被闭源的前端 Console 项目开源协议是 AGPL-3.0，这个协议除了要求二次分发必须开源没有其它问题，一些知名项目如 Grafana 也采用该协议。还记得 KubeSphere 曾多次被国内和海外的一些大公司换 Logo 后改个名字后就拿去卖钱，AGPL-3.0 的协议某种程度上也有一定的品牌保护作用。
但值得注意的是，后端开源是在 Apache 2.0 基础上加入了“附加条款”的开源协议，例如：
禁止用于商业化 SaaS 服务；
禁止移除或修改 KubeSphere 品牌和 logo；
要求贡献者接受维护者可以在未来改变授权方式的条款；
对 fork 或商用做出限制。
虽然它的目的是出于保护青云的商业产品利益和 KubeSphere 品牌，但这个修改后的协议是不符合 OSI（Open Source Initiative）定义的开源标准的，破坏了 Apache 2.0 的开放性和自由性。所以青云回复 KubeSphere 将继续保持核心代码开源的声明，是需要推敲的。
开源协议的选择，以及所选开源协议的开放程度和商业友好程度，会从本质上影响和决定这个项目最终是否会有众多企业级贡献者来参与。
圈子里有开源从业者提出了一个问题：KubeSphere 作为 K8s 发行版，秉着 “Upstream First” 的原则， KubeSphere 项目维护者在上游 K8s 社区的贡献有多少？
实际上，研究这个问题对于分析这个事件的的意义并不大，因为 KubeSphere 不算严格意义上 K8s 发行版，因为它没有改 K8s 一行代码，没有对 K8s 进行二次分发，它是一个构建于 Kubernetes 之上的平台型项目，用户可以使用自己已有的 K8s 对接 KubeSphere，所以从产品定义层面这个说法不是非常准确；
其次，KubeSphere 团队对 K8s 项目的贡献多少，并不会直接影响到 KubeSphere 开源项目本身的可持续性发展，上游贡献的指标仅对下游企业在 K8s 上游社区的话语权和影响力能产生影响，或对企业内部基于 K8s 做了扩展或二次修改的厂商，或是直接提供托管 K8s 云服务的云厂商，能体现技术实力。
“一个人可以走得很快，但一群人可以走得更远。”
很多用户评估开源项目是否值得在企业内部特别是生产环境采用，习惯先去看这个项目的 GitHub Star 数量来评估这个项目的流行度，从而判断该项目的可持续性。实际上，这样的方式太过于片面和业余。
我如果作为用户，我认为最可靠的方式是去关注这些指标：
有多少家公司参与了开源项目的贡献与维护？贡献比例分别是多少？（单一厂商控制的开源项目属于高风险）
开源社区治理和开发流程是否公开和透明？
有多少大的企业已经采用了该开源项目？（这通常在官网或 README 中能找到）
该开源项目对商业化是否友好？业内是否已有多家商业公司集成和提供商业支持？
…
我的观点是，真正强大的开源项目，往往拥有更丰富的“社区股东”和更清晰的合作模型。一个开源项目的贡献者和商业生态越多元化，拥抱它的企业越多，它的可持续性将会越强大。如果只有单一厂商在维护，并且只有用户生态，缺乏不同组织的贡献者，并且用户市场还局限在国内，这样的开源项目大概率是走不远的。
对于希望构建开源商业化的公司：开源的核心价值并不仅仅是代码和技术，而是围绕这些能力构建起来的社区生态与信任体系。如果把开源仅仅视为一种“获客渠道”，通过免费开放源码吸引用户，再通过商用版本进行转化，却忽略了社区治理、合作机制、开发者关系和中立性建设，最终可能得到短期流量，但失去长期信任。
对开源项目使用者的启示： 如何选型一个更有可持续性的项目是非常关键的，上面提到的一些指标可以作为参考。作为用户在有余力的情况下，可以思考自己作为用户如何参与到开源社区中，毕竟 “众人拾柴火焰高”。
我在西雅图的周日晚午夜时分写完这篇文章，虽然我已经离开了前司青云三年多时间，但依然对曾经一起参与 KubeSphere 维护的前同事、社区贡献者和用户们合作的时光非常怀念，当时 KubeSphere 项目也确实在四海大地聚集了很有有热情和信仰的开源爱好者。如今的局面，个人还是衷心希望能有一些好的转机！
评论删除后，数据将无法恢复
辩证看待 KubeSphere 闭源删库，前核心团队成员的解读
KubeSphere 自 2018 年 4 月份开始在 GItHub 写下第一行代码并开源，至今七年多的时间，曾被全球数以万计的大小企业所使用，与众多知名开源项目集成，被全球各大云厂商认可和合作，不可否认的事实是，KubeSphere 是一个非常优秀的开源项目和云原生产品，项目创始人 Ray 也是一个很有开源情怀的人。
我曾在 2018-2022 年担任青云科技的高级社区经理，在全球不遗余力地推广 KubeSphere，从零到一构建了活跃多元化的开源社区，创作了官网、用户文档、博客、视频教程，在全国各大城市办过几十场活动，并将 KubeSphere 孵化的 3 个子项目捐给 CNCF 基金会。
2020-2022年几乎是 KubeSphere 在全球飞速发展的三年，我记得曾经几乎每天都能看到新的用户增长和使用反馈，以及来自全球不同公司的贡献者参与。说实话，那曾是我最有工作成就感和成长飞快的时光，在开源社区认识了很多优秀的开发者，也给公司带来过一些商业机会。
一次不留余地的急转弯
令人遗憾的是，这次青云的决定来了个 180 度急转弯，不仅将前端代码闭源，还删除所有已发布的文档和安装镜像，彻底将 KubeSphere 推向了深渊，在全球开源社区引发了巨大的舆论和开源信任危机。巧合的是，消息发布当天正是项目创始人 Ray 宣布离职的时间点。我不知道这是否是有意为之，但属实是不讲“情面”的一个选择，也引发了国内外很多开发者对“中国式开源”的发问和深层焦虑。
墙倒众人推，并不能让中国开源更好
事实上，我刚开始看到消息时也有些情绪化，因为 “KubeSphere 闭源删库”后，互联网舆论呈现了墙倒众人推的趋势，很多博主的文章以及吃瓜群众的评论，站在制高点一味地批判和指责商业公司“闭源”的行为，诋毁该开源项目的价值，甚至还有很多人直接全盘否定 “中国开源” 的努力和价值。这些带有偏见的观点，很容易误导大众的认知和情绪，并且不会让这个行业变得更好。
我也看到了很多曾经的用户、贡献者、前同事们表示唏嘘和惋惜，感叹自己曾经参与过的开源明星项目的陨落。我没有选择在第一时间发布这篇文章，在阅读了国内外很多博主的文章、讨论和用户在 GitHub 上的回复后，带着辩证的角度来分享自己的一些观点。
截止目前，我看到的可能有价值的一个讨论是，有一些用户在 GitHub 上希望通过投票和众筹的方式重新组建纯社区自发驱动的 KubeSphere 开源贡献者团队，Issue 下也有众多用户和贡献者表示支持，这让我感受到了些许欣慰，因为它展现了开源社区开发者的集体力量，但这个目标要实现的难度不亚于去经营一家公司。
维护开源是商业公司应有的社会责任吗？
这是一个值得每位开源参与者深思的问题。开源项目由商业公司主导，并不意味着它对社区有“义务”无限维护。
显然 “KubeSphere 闭源删库” 是一个唐突而又糟糕的决策，但我想说，选择“闭源”或核心团队撤离开源项目这件事情本身从来不是某一家商业公司的过错，任何一家商业公司主导的开源项目都存在这样的“闭源”风险，这在开源界也已有多个案例。客观来说，在当前的经济下行的市场环境下，几乎所有商业公司都在收缩投资或调整战略，对于营收增长慢的项目和人力都有被优化的可能。维护开源项目并不是一家商业公司应有的社会责任或义务。
但是，开源项目背后的主导公司如果希望撤资开源投入，需要遵循开源项目客观存在的生命周期，而不是把开源社区一刀切，用开源断供来“绑架”用户，转到自家商业产品，这并不是一项精明的生意决策。实际上，如果青云选择将 KubeSphere 项目归档 （Archive）并选择提前一段时间在社区发布项目 Retire 的公告，同时致谢所有参与贡献的开发者和用户，那就不会出现今天的危机局面。
失去开发者=失去企业服务信任
“得开发者得天下” 是一个很通俗的道理，很多大小企业选择走开源的策略，也正是因为开源是一个能够低成本地快速地获取全球开发者用户的机会和建立跨企业的社区合作模式，比传统的闭源软件开发和 Marketing 传播更快，通过开源社区协作开发也更容易建立规模与行业标准。
但很多商业公司错误地把开源作为低成本“获客”的渠道，把开源作为一项“免费广告”的福利，利用开发者对开源技术的关注来获取销售商机，这样的做法是对开源社区最大的伤害，也是对商业公司口碑的破坏。
实际上，很多开源项目的开发者用户是一些企业的运维开发负责人或内部决策影响者，他们虽然可能不能直接决定公司的软件采购，但他们提供的观点和意见会直接或间接地影响企业管理层的决策。很可惜，很多开源商业化公司的 CXO 们并不懂开发者的重要性，忽视了开源社区的规模影响力。
青云做些什么能补救？
答案是能。
青云作为一家上市公司，公司层面一定还是会关注自己在业内的口碑以及客户的信任。这里我不适合作为局外人指点江山，但提供思路作为参考，毕竟在社区里还有很多用户在关注 KubeSphere 后续是否会有好的转机。
让我们来看一个正面的例子，CNCF 毕业项目 Flux 背后的核心维护公司 WeaveWorks 在去年 2 月份虽然宣布了公司关闭停止运营，但 CEO 第一时间在联系一些大公司的用户和贡献者参与 Flux 项目的维护，并积极寻求 CNCF 的帮助，确保该项目在即使没有了 WeaveWorks 公司的支持，还能继续在社区维护和迭代。
青云是否会考虑做一个 “git revert” 的回滚操作，来响应社区目前呼声最高的提议：恢复闭源的仓库、下线的文档、历史镜像，并将开源项目交由给中立的社区自发去维护？青云作为商业公司继续去做自己的商业产品，或许还有重建信任的机会。如果公司层面担心开源项目抢了自己的商业产品的蛋糕，那必然是商业产品与服务做得还不够好。
对 KubeSphere 开源协议的疑问？
KubeSphere 有两个子项目的开源协议值得探讨，第一个是此次被闭源的前端 Console 项目开源协议是 AGPL-3.0，这个协议除了要求二次分发必须开源没有其它问题，一些知名项目如 Grafana 也采用该协议。还记得 KubeSphere 曾多次被国内和海外的一些大公司换 Logo 后改个名字后就拿去卖钱，AGPL-3.0 的协议某种程度上也有一定的品牌保护作用。
但值得注意的是，后端开源是在 Apache 2.0 基础上加入了“附加条款”的开源协议，例如：
禁止用于商业化 SaaS 服务；
禁止移除或修改 KubeSphere 品牌和 logo；
要求贡献者接受维护者可以在未来改变授权方式的条款；
对 fork 或商用做出限制。
虽然它的目的是出于保护青云的商业产品利益和 KubeSphere 品牌，但这个修改后的协议是不符合 OSI（Open Source Initiative）定义的开源标准的，破坏了 Apache 2.0 的开放性和自由性。所以青云回复 KubeSphere 将继续保持核心代码开源的声明，是需要推敲的。
开源协议的选择，以及所选开源协议的开放程度和商业友好程度，会从本质上影响和决定这个项目最终是否会有众多企业级贡献者来参与。
关于“K8s上游贡献”的误解
圈子里有开源从业者提出了一个问题：KubeSphere 作为 K8s 发行版，秉着 “Upstream First” 的原则， KubeSphere 项目维护者在上游 K8s 社区的贡献有多少？
实际上，研究这个问题对于分析这个事件的的意义并不大，因为 KubeSphere 不算严格意义上 K8s 发行版，因为它没有改 K8s 一行代码，没有对 K8s 进行二次分发，它是一个构建于 Kubernetes 之上的平台型项目，用户可以使用自己已有的 K8s 对接 KubeSphere，所以从产品定义层面这个说法不是非常准确；
其次，KubeSphere 团队对 K8s 项目的贡献多少，并不会直接影响到 KubeSphere 开源项目本身的可持续性发展，上游贡献的指标仅对下游企业在 K8s 上游社区的话语权和影响力能产生影响，或对企业内部基于 K8s 做了扩展或二次修改的厂商，或是直接提供托管 K8s 云服务的云厂商，能体现技术实力。
可持续的开源项目，有哪些共同特征？
很多用户评估开源项目是否值得在企业内部特别是生产环境采用，习惯先去看这个项目的 GitHub Star 数量来评估这个项目的流行度，从而判断该项目的可持续性。实际上，这样的方式太过于片面和业余。
我如果作为用户，我认为最可靠的方式是去关注这些指标：
有多少家公司参与了开源项目的贡献与维护？贡献比例分别是多少？（单一厂商控制的开源项目属于高风险）
开源社区治理和开发流程是否公开和透明？
有多少大的企业已经采用了该开源项目？（这通常在官网或 README 中能找到）
该开源项目对商业化是否友好？业内是否已有多家商业公司集成和提供商业支持？
…
我的观点是，真正强大的开源项目，往往拥有更丰富的“社区股东”和更清晰的合作模型。一个开源项目的贡献者和商业生态越多元化，拥抱它的企业越多，它的可持续性将会越强大。如果只有单一厂商在维护，并且只有用户生态，缺乏不同组织的贡献者，并且用户市场还局限在国内，这样的开源项目大概率是走不远的。
我们从该事件能学到什么？
对于希望构建开源商业化的公司：开源的核心价值并不仅仅是代码和技术，而是围绕这些能力构建起来的社区生态与信任体系。如果把开源仅仅视为一种“获客渠道”，通过免费开放源码吸引用户，再通过商用版本进行转化，却忽略了社区治理、合作机制、开发者关系和中立性建设，最终可能得到短期流量，但失去长期信任。
对开源项目使用者的启示： 如何选型一个更有可持续性的项目是非常关键的，上面提到的一些指标可以作为参考。作为用户在有余力的情况下，可以思考自己作为用户如何参与到开源社区中，毕竟 “众人拾柴火焰高”。
写在最后
我在西雅图的周日晚午夜时分写完这篇文章，虽然我已经离开了前司青云三年多时间，但依然对曾经一起参与 KubeSphere 维护的前同事、社区贡献者和用户们合作的时光非常怀念，当时 KubeSphere 项目也确实在四海大地聚集了很有有热情和信仰的开源爱好者。如今的局面，个人还是衷心希望能有一些好的转机！