1. An Open-Source-Centric Business Model
One of the charms of open source is its inclusiveness. It accepts people with all kinds of intentions — the engineer obsessed with technology, the merchant with ulterior motives, the volunteer passionate about public welfare, even the casual bystander — all of them can collide and mingle here, forming a force.
Building a business around open source should be allowed and accepted. Open source and business succeed through each other. The latest open source report shows that on GitHub, developers are noticeably more active on weekdays than on weekends. This suggests that full-time open source developers are increasing, and that open source is bringing developers income. This income may come from a foundation, a commercial company, or sponsors, supporting developers to devote themselves fully to open source.
An open-source-based business model requires thinking through several questions.
What can open source bring to a product? Open source is not just hosting source code on GitHub; it requires managing and operating a community, and leveraging the power of the community to build popularity and expand influence.
Why should users use this product? Open source does not mean lowering the bar for the product; a product’s edge is one of the key factors in open source success. Polishing a good product is not an easy task. You need a deep understanding of the domain and a grasp of user habits to fill the gaps through the product and transmit value.
What services can be provided for this product? Open source is free, but services are paid. Without continuous revenue, a business cannot sustainably invest in open source. Such revenue usually does not come directly from open source, but is derived on top of it. Open source software can be used for free, but if you need training, enhanced security, scenario adaptation, problem fixes, solution consulting, custom development, application distribution, and so on, there are business opportunities.
2. KubeSphere’s Open Source Path
KubeSphere was formally established as a project in April 2018; it released 1.0 in July of the same year, 2.0 in April 2019, and 3.0 in August 2020.
For three consecutive years, with R&D investment at the tens-of-millions level each year, QingCloud has high expectations for KubeSphere, calling it QingCloud 2.0, a new generation built for cloud native. Providing HC (headcount) and adding manpower are the most direct ways for upper management to support the ranks below. In recent years, many people have come and gone on the KubeSphere team, but the overall headcount has kept growing. Notably, KubeSphere has begun to spread into QingCloud’s other teams, and the surrounding teams are using KubeSphere as a template to accelerate their integration into cloud native.
And the report card KubeSphere has delivered is:
- The main repository kubesphere/kubesphere has over 5.1K stars
- The installation tool ks-installer has reached 1M+ downloads
- The Chinese forum / Slack / WeChat group each reached 1–2K members
Judging from the data, KubeSphere has completed its primitive accumulation and obtained a ticket to cloud native. Below we discuss it from several different angles.
2.1 Product R&D
The product R&D strategy is to first pile up features to attract users, then split things out into a pluggable architecture.
For a purely ToB company, the hardest thing is finding users willing to try something new. Without users continuously using and giving feedback, you cannot build a good product. Therefore, from the very beginning KubeSphere chased features, continuously integrating components to attract more users. 1.0 managed native Kubernetes basic objects, DevOps, Prometheus monitoring, and an app store; 2.0 added Istio and logging; 3.0 added multi-cluster and network management.
But merely integrating components to build popularity is not enough. It cannot bring in revenue; facing upward, the pressure from the boss is high, and downward, the returns are low with a high turnover rate. Fortunately, QingCloud is an IaaS vendor, and it has many components that can be connected to the cloud native ecosystem, such as storage, load balancers, cloud hosts, and so on. By providing a fully independent Kubernetes + KubeSphere service, it not only drove sales of QingCloud IaaS and surrounding products, but also made it possible for KubeSphere to enter users’ minds.
At the same time, R&D gets the chance to be exposed to users’ real usage scenarios, feeding back into product design.
In the future 4.0 architecture, the expectation is to use KubeSphere as the core architecture and the app store as the distribution channel, building an ecosystem similar to iOS. Paired with it is a service sales system, kubesphere.cloud, providing ticketing, custom development, and other services.
At this point, it is a very common architectural pattern. A project I participated in before had the same idea. I have also written some thoughts about platforms; see Domain Knowledge Is the Core Competitiveness of a PaaS.
Below is a figure I cited:
KubeSphere’s platform goals correspond to the PaaS layer. But when KubeSphere was first designed, it was developed more with a SaaS positioning, and it did not provide a common runtime, nor abstract a common SDK library. This in fact corresponds to the two parts, aPaaS and iPaaS.
First, foundational capabilities need to be pushed down, such as a unified error code, logging output, authentication control, frontend scaffolding, and so on — this is essentially a development framework. KubeSphere provides core functions like users, permissions, and the app store in the form of microservices.
Then, based on the development framework, components like DevOps, microservices, logging, and network management are refactored and released to the app store. But this will not be a short process, for two main reasons.
- Architectural decoupling is difficult
If you have read the KubeSphere source code, you will find that these components are all controlled by feature toggles and have dependencies among one another. KubeSphere is learning from Kubernetes in architectural evolution and collaboration patterns, but it has neglected its application-oriented positioning, which is not friendly to developers.
- Style inertia is strong
Below is the KubeSphere 1.0 UI:
It looks very similar to 3.0. Once a style is formed, it is very hard to change — that is the product’s DNA. Splitting SaaS into PaaS/SaaS will also face great challenges.
Code splitting may be only a very small part of it; converting a Monorepo to Polyrepo would not take long. The risk lies in the fact that the earlier accumulation — user habits, documentation, FAQ, blog posts, etc. — would all become invalid, and the experience of previous participants would all need updating. Look at SkyWalking’s development path: it also went through several refactors, from prototype validation and productization to community-building and feature enrichment, and finally performance optimization. But the fact that it is talked about with such relish is precisely what makes it rare — KubeSphere has a long and arduous road ahead.
2.2 Development Stages
Here I would like to cite the chasm theory, as shown below:
The three stages of CNCF incubation projects correspond to three groups in the chasm theory:
- Sandbox, innovators
- Incubating, early adopters
- Graduated, early majority
KubeSphere has completed the journey from 0 to 1, proving that there is room for it in the market, and at the same time it has cultivated a group of fans. I believe KubeSphere has now entered the view of early adopters and is climbing upward.
Different stages require different emphases. In the long term there should be strategy, so that when things happen there is direction; in the short term there should be tactics, so that practice has method. Only this way do small wins accumulate into big ones.
In the early days of a project, R&D is more important — lay a solid foundation early, develop the product with care, and prove its value.
At present KubeSphere’s features are basically complete, and it is in the stage of volume-based promotion, emphasizing operations, user acquisition, retention, and incremental markets. The main goal is to scale out, respond actively to feedback, and maintain a healthy user base.
In later large-scale adoption, many problems will be exposed. Users become more demanding of the product, and it is necessary to return to R&D again, folding the feedback from the previous stage into the product — and thereby the product moves from early adopters into the view of the early majority.
2.3 Service Models
There are three service models in total: public cloud, private cloud, and pure services.
Leveraging QingCloud’s public cloud IaaS, KubeSphere provides a fully independent Kubernetes service, QingCloud KubeSphere Engine (QKE for short). Users simply select QKE in the QingCloud console to get a Kubernetes cluster based on QingCloud IaaS, cloud disks, and load balancers. It also provides a free cluster ticketing service. Beyond that, the industry’s other two service models — semi-managed and fully managed Kubernetes cluster services — are technically more challenging and are not currently suitable for KubeSphere.
In the private cloud market, combining QingCloud’s consistent technical architecture across public and private cloud, KubeSphere can provide a full solution from IaaS to containers. The revenue share after winning a private cloud bid is KubeSphere’s main source of income.
Pure services are a bigger dream, and this is also what I find interesting. From OpenPitrix to kubesphere.cloud, QingCloud always seems to find good ideas. OpenPitrix aims to unify the runtime and achieve full lifecycle management of applications, whether they are deployed on Alibaba Cloud, Amazon Cloud, VMware, or Kubernetes. And kubesphere.cloud separates services from the vendor and sells them independently, while allowing other participants in the open source community to join as sellers.
The current service model relies on ticket duty staff, pre-sales, post-sales, and R&D, mostly manual labor, and customers often punch through the intermediate layers and reach R&D directly. This is not a scalable way of doing things — the more services are sold, the harder the team is to coordinate, and I think this is one of the problems that urgently needs solving.
3. Some Thoughts on Organization and Business Strategy
3.1 Innovation Is Crucial
Entrepreneurship is not about grabbing someone else’s cake into your own bowl; it is about making the cake bigger.
When starting a business, do not choose a stock market; choose an incremental market. “Cloud Native is eating the world,” and Kubernetes is an incremental market. Cloud native will take over operations infrastructure and R&D processes, and there is a huge market opportunity and room for growth.
KubeSphere chose a good track. Kubernetes, cloud native, and Istio can catch the eye of users and capital. KubeSphere chose a Dashboard — something everyone dismisses as not technical enough — as its entry point, sidestepping competition while grasping users’ pain points and offering a lot of room for imagination.
Do not walk the road others have walked, or you will forever be only a follower.
3.2 Emphasize Internal Knowledge Flow
The talent gradient at a startup has a very large gap, and the flow of internal knowledge is very important.
The returns at a startup may be very different from those at a big company; a startup concentrates its cost on a very small number of people. While this ensures those few do not leave, a high turnover rate brings many potential problems and noticeably reduces the team’s overall efficiency.
Money can solve part of the problem, but the opportunity for rapid growth, a happy working environment, and the industry’s growth prospects can also retain people.
Emphasizing the flow of internal knowledge can avoid single points of failure in personnel, improve people’s capabilities, and reduce attrition. Startups usually do not have the resources to build their own academy; more often they need to form an internal mechanism and atmosphere.
“Internal” does not only mean the same team; it actually also includes pre-sales, post-sales, and other collaborators. This requires institutional innovation to bring stakeholders together.
3.3 Rely on Mechanisms, Not on People
Human service is not conducive to scaling; human decisions carry greater risk, and the loss of a person also means risk to the business. We need to convert experience and thinking into something visible.
When handling business problems, learn to record, form a solution, then write it into documentation, encode it as scripts and other automation tools, output it as a product, and turn it into self-service.
What we need is a workflow that can replace people. Anyone can start it, run it, and get a consistent result.
On the other hand, training employees also needs to form a system, so that interns can also become key players, and then there is no need to worry about attrition.
3.4 Willingness Beats Skill
It does not matter if the direction is wrong, as long as someone is willing to keep correcting it — getting started is actually the hardest part.
Thinking through everything is not necessarily a good thing — it takes twice the effort for half the result. Such thinking is limited by existing experience and the current environment; once experience grows and the environment changes, previous conclusions will be overturned.
kubekey is a good example: an operations person was willing to learn Go and do R&D, so they just let him do it. Now kubekey is one of KubeSphere’s core product matrix.
If there is the willingness to do it, then do it in small, quick steps without hesitation. Many times, taking one step back leads to a steady retreat; conversely, if you hold the line, a new sky opens up.
3.5 Distributed Offices Should Be Divided by Responsibility
Distributed offices mean a team is physically separated across different locations. A team split across different cities — Beijing, Shanghai, Wuhan, Chengdu, and some even at home — seems very nice, very global, but if it is not structured well, the attrition rate will be high.
A team constitutes a system architecture. A team is divided into many small groups, each group has a specific goal, and the whole group works together toward that goal.
A group should be assigned to one region — for example, microservices in Wuhan, multi-cluster in Chengdu, DevOps in Beijing. You cannot have a group of three people spread across three regions; that would create extremely high communication costs. Even though remote work from home is gradually being accepted now, the members of such a group, having built no emotional bonds, are very likely to leave, and they will not think much on behalf of the project — they leave at the drop of a hat.
Dividing regions by responsibility is a more appropriate approach. Members of a single region can communicate fully, and different regions collaborate with one another, forming a complete team.
