1.6万 Star 的流行容器云平台停止开源

什么是 KubeSphere ?

KubeSphere 是面向云原生应用的容器混合云。

KubeSphere 愿景是打造一个以 Kubernetes 为内核的云原生分布式操作系统,它的架构可以非常方便地使第三方应用与云原生生态组件进行即插即用(plug-and-play)的集成,支持云原生应用在多云与多集群的统一分发和运维管理。

社区情况

KubeSphere 已经拥有超过 16.2k (1.6万) Star 的 GitHub 仓库, 是一个比较受欢迎的开源项目,在国内 KubeSphere 的用户还是很多的。

停止开源通知

观点分析

原因分析

我身边就有不少朋友使用 KubeSphere 来管理他们的容器云集群,有人说它 页面 UI 好看 ,也有人说它 产品交互设计体验好,降低了 Kubernetes 的学习成本 等,当然也有一部分人因为他是国内厂商主导的(青云)开源项目,便于后续信创 而选择。

在项目 Issue 中,KubeSphere 负责人对停止开源的背景做了简要的说明,或许可以分析(猜测)出来一些事情:

  1. KubeSphere 产品已经相对成熟进入稳定期。 KubeSphere 是 Kubernets 的下游项目,经过多年的发展 Kubernetes 也逐渐成熟了,因此 KubeSphere 也会逐渐进入成熟期。

  2. KubeSphere 的商业化营收数字不好,可能是利润低,甚至亏损。 企业是以盈利为目的存在的,可以在创新业务上有一定的投入,比如 OpenAI 早期的 100 亿美元的投入。但是,如果这个业务长期收益不达标(资金、政策扶持、知名度、支撑内部等都算),正常的企业都会选择减少投入,比如停止更新、裁员、卖掉等等。

  3. KubeSphere 项目核心负责人及创始人离职,大概率是被动离职。 技术人员在向上管理的能力总是欠缺的,如果在职期间没能快速升职提升话语权,在公司战略调整中只能被动接受决策,没资格参与到公司重大决策就很难为团队争取利益。由于 KubeSphere 也相对稳定了,降本增效的措施中的降低成本最直接的方式就是裁员,而项目负责人或资深的研发往往成本是比较高的人员。

  4. KubeSphere的商业模式和战略规划不合理。 这本应该是创始人重点的工作内容,而不是全身心的投入到产品完善的细节中,也为最后的离开奠定了基础。作为一个受欢迎的开源项目,而且是云原生中通用基础设施型的项目,具有产品本身定位上的优势,即只要进行云原生相关建设,就少不了容器云平台,而 KubeSphere 刚好是个不错的选择。具体战略规划目前不清楚,但就目前这个停止开源的策略就是一个不合适的战术动作。

社区白嫖导致利益受损?

看通知中的说【过去几年,大量违反开源协议的行为------二次包装、甚至直接用于商业化------对公司的利益造成了实质性影响。】给我一种感觉就是青云的高层对开源的理解不到位。

开源项目被用户拿来白嫖或者商业使用的情况,在开源之初应该就能预料到的,这么多年才意识到这个问题只能说大公司的病也开始发作了,在找借口呢。

如果不开源 KubeSphere 怎么能够被人熟知呢?如果不开源,会有大量的用户反馈问题甚至提交PR优化产品吗?反过来,如果不开源又有几个人会买青云的闭源容器云产品呢?

删除文档和镜像

关于在社区中讨论比较激烈的话题就是,KubeSphere 在停止开源的同时把项目相关的文档和镜像删除了,这点我也很诧异。

这是领导失去理智了吧?这种决策绝对是弊大于利,除非是完全不想要要这块业务了,要破罐子破摔。

不会 是资源成本过高,要释放资源减少成本投入。文档如果不维护内容,只是提供访问本身资源消耗就不多。镜像直接托管在 Dockerhub 或 Github 也不需要费用。

这种骚操作,删除文档和镜像后可能的影响:

  • 普通用户不会将 KubeSphere 作为一种选择。 不开源、没文档、等于放弃了新用户,市场上就会减少相关的技术人才储备。
  • 企业失去信任, 购买企业版本会更加的谨慎。 公司的管理有问题,担心就算买了企业版本,也可能哪天突然就把项目砍了,直接不维护了,这对使用的企业是很糟糕的事情。
  • 已经采用的企业,会考虑替换成其他项目。 由于后续的发展演进不清晰,KubeSphere的用户无论是否购买了企业版本的,都会进行适当的评估和考虑替换掉。
  • 口碑连坐,也会影响对青云评价。 毕竟 KubeSphere 是青云主导的,闭源的决策也是青云公司,那对青云也同样会有影响。甚至影响青云的核心云业务服务市场口碑。

如何看待这个事情

当前的信息技术产业离不开开源技术,离开了就绝对无法进行信息建设。 这个结论很绝对,但作为近10年的技术从业者,我很负责任的说,这是事实。有人说"信创"不就是国内企业完全独立自主研发相关产品吗?我只能呵呵~~,要知道一个应用软件的生命周期过程中,会涉及底层的操作系统、内核、编程语言、依赖库、数据库、网络协议、 框架、工具等等,这些是人类发展积累的基础设施,单一国家或企业不可能重新建设一套出来。

推荐企业使用开源项目来进行 IT 建设,尽量不要使用闭源的产品。 开源项目有很多优点,比如成本极低、没有厂商锁定、市场有人才储备等等;当然也有缺点,比如兼容性、定制化、服务响应等都和企业服务没法比。这就看企业对技术的态度,来进行利弊的均衡。就个人经验而言,如果有好的开源产品,建议优先选择开源的产品。

开源项目也有生命周期,及时关注期生命周期状态,提前规划替换。在进行技术选型时,同种功能的技术实现至少有2种以上的选择;还需要考虑有新技术需要替换某个老的技术,或者某个技术停止开源或者收费等情况;

放平心态,合理应对。

相关推荐
Albert_Lsk28 分钟前
【2025/08/01】GitHub 今日热门项目
人工智能·开源·github·开源协议
蚂蚁数据AntData2 小时前
DB-GPT 0.7.3 版本更新:支持Qwen3 Embedding和Reranker模型、支持知识库自定义检索策略等
大数据·开源·全文检索·数据库架构
东风微鸣3 小时前
职场生存指南:如何优雅应对"双面人"同事
docker·云原生·kubernetes·可观察性
Java侠3 小时前
graylog6.3 docker-compose部署全流程
运维·docker·容器·graylog·docker compose
●VON3 小时前
重生之我在暑假学习微服务第七天《微服务之服务治理篇》
java·学习·微服务·云原生·nacos·架构·springcloud
云和数据.ChenGuang3 小时前
云计算k8s集群部署配置问题总结
云原生·容器·kubernetes·云计算
阿里云云原生4 小时前
Vibecoding 新体验:实测 Qwen3 Coder 代码生成效果
云原生
寅时码4 小时前
从“一键部署”到“可观测、可定制的发布流”:我如何打造一个企业级部署工具
运维·开源·node.js
斯普信专业组4 小时前
k8s云原生rook-ceph pvc快照与恢复(下)
ceph·云原生·kubernetes
爱吃芝麻汤圆5 小时前
k8s之DevicePlugin
云原生·容器·kubernetes