Honestly, seeing Qingyun announce the suspension of KubeSphere’s open-source version download and support (see Announcement on the Adjustment of the KubeSphere Open Source Project #6550), I felt quite emotional.
This reminded me of Docker’s 2023 incident of cleaning up unpaid “open source accounts”. At that time, many projects’ CI/CD pipelines collapsed overnight. You realize this isn’t purely a technical problem, but a “trust crisis” - when you thought you could rely on an open source project’s long-term availability, suddenly you become an outsider.
KubeSphere has been active since 2018 and is one of the domestic open source projects I’ve witnessed grow. Starting from early container platform visualization, to later supporting DevOps, microservice governance, multi-tenancy, and other features, it has accumulated many real users in China’s cloud-native community and attracted many evangelists and contributors. Now, choosing to suspend the release of the open-source version may be officially taking the COSS (Commercial Open Source Software) path: commercializing past core capabilities to support team development.
This itself isn’t hard to understand. After all, open source is never charity. We all know that truly maintaining a project continuously is extremely costly, especially under the GenAI wave where infrastructure companies’ survival pressure is indeed increasing. Pivoting to commercialization is understandable, but the problem is - lack of prior communication and transition arrangements.
The Community Can Understand Commercialization, But Can’t Accept “Sudden Cut-Offs”
Before the GitHub announcement, there was no warning; the image registry was taken offline, installation links cleared, users reported inability to pull images, nodes unable to update, production environments affected - this is a “cut-off,” not a “transition.”
What’s even more disheartening is that under Issue #6550, community users raised various concerns, requested extended support, sought image backups - some rational, some emotional - and the official response was to close the comment section within 24 hours, as if closing the door could shut down all discussion. This isn’t community governance, but enterprise product control.
How to View This Change More Maturely?
As an open source community participant, I prefer to view this event from a constructive perspective.
1. Don’t Panic, First Understand the Motivation
From the announcement content, KubeSphere’s core code remains on GitHub and continues to be released under Apache License 2.0 + additional terms. This means the project hasn’t been closed-sourced but has suspended “release” publication and free support.
This is somewhat like Kubernetes switching from Docker runtime to containerd back in the day. Although it caused considerable controversy, the ecosystem could evolve, and users could migrate. The problem isn’t change, but communication style.
2. Embrace Alternatives, Maintain Technical Diversity
The spirit of cloud-native is “componentization” and “replaceability.” Whether Rancher or OpenShift, both have the capability to replace KubeSphere’s functionality, just with different deployment and operations methods.
Not binding all infrastructure to one project is the true cloud-native mindset.
3. Instead of Complaining, Participate in Co-Building
If you still want to use KubeSphere, you can completely organize community maintenance forks, build your own image registry, and construct CI/CD pipelines. This event might foster a more truly meaningful “decentralized community governance.”
You use it, you’re also responsible - this is the essence of open source.
In Conclusion
I don’t want to blame Qingyun’s decision. As an infrastructure company, they may have discovered during long-term business exploration that providing complex systems completely for free is unsustainable, and exploring stable commercial paths is reasonable. But as a far-reaching open source project, KubeSphere could have had a smoother exit.
It could have announced three months in advance, left old version images, built a documentation archive site, and established a community handover mechanism. It could have told everyone who ever PR’d, opened issues, or shared deployment experiences: “Thank you for joining this journey, we’re changing how we move forward.”
Unfortunately, it didn’t.
Open source isn’t a free lunch, but a long-term partnership. Trust is harder to establish than technology, and easier to collapse. But I’m still willing to believe that China’s open source ecosystem will learn to build the future more maturely from every setback.
I look forward to the next truly community-driven cloud-native platform, and also hope that users leaving today will find new belonging rather than silently giving up in disappointment.
