ToB 创业公司的开源之路 - KubeSphere

1. 以开源为核心的商业模式

开源的魅力之一在于其包容性。它能接受怀揣各种意图的人，无论是执着技术的的工程师，还是心怀鬼胎的商人，亦或是热心公益的志愿者，甚至茶余饭后的看客，都能在这里碰撞、交融，形成一股力量。

围绕开源做商业，应该被允许和接受。开源和商业是互相成就的关系。最新的开源报告显示，在 GitHub 上，开发者工作日比周末明显活跃。这说明全职的开源开发者正在增加，开源正在给开发者带来收入。这些收入可能来自某个基金会、某家商业公司、某些赞助商，支持着开发者全身心地投入开源。

基于开源的商业模式需要思考几个问题。

开源能给产品带来什么？开源不仅仅是将源码托管在 GitHub，而是需要管理和运营社区，借助社区的力量积攒人气、扩大影响力。

为什么用户要使用这个产品？开源并不意味着降低了对产品的要求，产品的领先性是开源成功的关键因素之一。打磨一个好的产品并不是一件容易的事。需要对领域有深入理解，对用户习惯有所把握，才能通过产品填补沟壑，实现价值的传导。

能为这个产品提供怎样的服务？开源是免费的，但服务是收费的。如果没有持续的收入，商业是难以稳定投入开源的。这种收入通常不直接来源于开源，而是以开源为基础进行衍生。开源软件可以免费使用，但如果需使用培训、增强安全、适配场景、修复问题、咨询方案、定制开发、分发应用等，就有商业机会。

2. KubeSphere 的开源之路

自 2018 年 04 月正式立项, KubeSphere 同年 07 月 发布 1.0, 2019 年 04 月 发布 2.0, 2020 年 08 月 发布 3.0。

连续三年，每年千万级别的研发投入，青云对 KubeSphere 期待很大，称之为青云 2.0，面向云原生的新生代。提供 HC、增加人力是上层对下层最直接的支持方式。最近几年，KubeSphere 团队来来往往的人很多，但总体人数一直是保持增长的。值得一说的是，KubeSphere 开始渗透到青云的其他团队，周边的团队在以 KubeSphere 为模板加速融入云原生。

而 KubeSphere 交出的答卷是:

• 主仓库 kubesphere/kubesphere 超 5.1K star
• 安装工具 ks-installer 下载量达 1M+
• 中文论坛/Slack/微信群均达到了 1~2 K 人

从数据上看，KubeSphere 完成了原始积累，拿到了云原生的门票。下面从几个不同的方面对其进行讨论。

2.1 产品研发

产品研发的策略是，先堆积功能吸引用户，再拆分做可插拔的架构。

纯 ToB 的公司，最难的是找到愿意尝鲜的用户。如果没有用户持续地使用、反馈，是开发不出好产品的。因此，从一开始 KubeSphere 就在追赶功能，不断地集成组件，用来吸引更多用户。1.0 管理原生 Kubernetes 基础对象、DevOps、Prometheus 监控、应用商店；2.0 Istio、日志；3.0 多集群、网络管理。

但是，仅集成组件积攒人气是不够的。不能带来收入，向上面对老板的压力大，向下回报少离职率高。幸运的是青云属于 IaaS 厂商，有很多的组件可以对接到云原生生态，比如存储、负载均衡器、云主机等。通过提供全独立的 Kubernetes + KubeSphere 服务，不仅带动了青云 IaaS 及周边产品的销售，还给 KubeSphere 打入用户心智带来了可能。

与此同时，研发有机会接触用户真实的使用场景，反哺产品的设计。

在未来的 4.0 架构中，预期是以 KubeSphere 为核心架构，以应用商店作为分发渠道，构建一个类似 IOS 的生态。与之配套的还有一个服务销售系统 kubesphere.cloud，提供工单、定制化开发等服务。

至此，就是一个很常见的架构模式了。我之前参与过的一个项目也是这个想法。我也写过一些关于平台的思考，可以参考《领域输出才是 PaaS 的核心竞争力》 。

下面是引用的一张图:

KubeSphere 的平台目标对应到 PaaS 层。但在 KubeSphere 设计之初，更像是以 SaaS 的定位进行开发的，并没有提供公共的运行时，也没有抽象公共的 SDK 库。这其实对应着 aPaaS 和 iPaaS 两部分。

首先，需要下沉基础的功能，比如统一的错误码、日志输出方式、鉴权控制、前端脚手架等，这其实就是一套开发框架。KubeSphere 以微服务的形式提供核心的用户、权限、应用商店等功能。

然后，基于开发框架，对 DevOps、微服务、日志、网络管理等组件进行重构，上线到应用商店。但这不会是一个短暂的过程，主要有两方面的原因。

1. 架构解耦有难度

如果你看过 KubeSphere 源码就会发现，这些组件都是通过功能开关控制，而且相互之间具有依赖关系。KubeSphere 在架构演进、协作模式上在学习 Kubernetes ，忽略了其面向应用的定位，对开发者并不友好。

1. 风格惯性很强

下面是 KubeSphere 1.0 的 UI:

和 3.0 很像。风格一旦形成，是很难改变的，这就是产品的基因。SaaS 拆分为 PaaS/SaaS 也会面临很大挑战。

代码拆分可能只是其中很小一部分，Monorepo 改成 Polyrepo 不会很耗时，风险在于用户习惯、文档、FAQ 、博客等前期的积累都会失效，之前参与者的经验都需要更新。参考 SkyWalking 的发展路线，其也经历了数次重构，从原型验证、产品化，到社区化、丰富功能，最后是性能优化。但能被津津乐道，也正说明其稀有，KubeSphere 任重而道远。

2.2 发展阶段

这里我想引用一下鸿沟理论，如下图:

CNCF 孵化项目的三个阶段对应着鸿沟理论中的三个群体:

• Sandbox, 沙箱, 创新者
• Incubating, 孵化, 早期采纳者
• Graduated, 毕业，早期大众

KubeSphere 已经完成了从 0 到 1, 证明了其市场存在的空间，同时培养了一批粉丝。我认为，KubeSphere 目前进入了早期采纳者的视野，正在向上爬升。

在不同的阶段，需要有不同的侧重点。长期应该有战略，遇事有方向；短期应该有战术，实践有方法。这样积小胜才有大胜。

在项目的初期，研发更加重要，早期打好根基，用心开发产品，证明其价值。

目前 KubeSphere 在功能上基本已经补齐，处于走量推广的阶段，重视运营、拉新、留存、增量市场。主要的目标是规模化地铺开，积极响应反馈，维护好用户群体。

在后期大规模应用时，会暴露很多的问题。用户对产品更加挑剔，需要再次回归到研发，将上一个阶段的反馈改进到产品中，产品也因此从早期采纳者步入早期大众的视野。

2.3 服务方式

一共有三种服务方式，公有云、私有云、纯服务。

借助青云的公有云 IaaS，KubeSphere 提供全独立的 Kubernetes 服务 QingCloud KubeSphere Engine（简称 QKE）。用户只需要在青云的控制台选择 QKE ，即可获取基于青云 IaaS、云硬盘、负载均衡器的 Kubernetes 集群。同时，还提供免费的集群工单服务。除此，业界另外两种服务方式，半托管和全托管的 Kubernetes 集群服务，技术上更具挑战，目前并不适合 KubeSphere 。

在私有云市场上，结合青云公、私有云一致的技术架构，KubeSphere 能提供自 IaaS 到容器的全套解决方案。私有云中标后的分成，是 KubeSphere 的主要收入来源。

纯服务是更大的梦想，这也是我觉得有意思的地方。从 OpenPitrix 到 kubesphere.cloud, 青云似乎总能找到好主意。OpenPitrix 意在统一运行时，实现应用的全生命周期管理，无论是部署在阿里云、亚马逊云、VMware，还是 Kubernetes。而 kubesphere.cloud 将服务从厂商剥离开，单独进行销售，同时允许开源社区的其他参与者作为卖家参与。

目前的服务方式依靠的是工单值班人员、售前、售后、研发，以人工为主，往往客户会击穿中间环节，直达研发。这并不是一种 Scalable 方式，服务卖得越多，团队越难协作，我认为这是急需解决的问题之一。

3. 一些关于组织和经营策略的思考

3.1 创新至关重要

创业不是将别人的蛋糕抢到自己的碗里，而是要将蛋糕做大。

创业时，不要选择存量市场，而应该选择增量市场。“Cloud Native is eating the world”, Kubernetes 就是一个增量的市场。云原生会接管运维基础设施、研发流程，存在巨大的市场机会和发展空间。

KubeSphere 选择了一个好的赛道。Kubernetes、云原生、Istio 能吸引用户和资本的眼球。KubeSphere 选择了一个大家嫌不够技术含量的 Dashboard 作为切入点，避开了竞争，又抓住了用户的痛点，还提供了很大的想象空间。

不要走别人走过的路，否则你永远只能跟随。

3.2 注重内部知识流动

创业公司的人才梯度落差很大，内部知识的流动非常重要。

创业公司的回报可能和大公司很不一样，创业公司会将成本集中到极少数人身上。虽然保证了极少数人不流失，但是高离职率会带来很多潜在的问题，也明显降低了团队整体的效率。

钱可以解决一部分问题，但快速成长的机会、开心的工作环境、行业的发展前景也是可以留住人心的。

注重内部知识的流动可以避免人员单点、提升人员能力、减少人员离职。创业公司通常没有实力组建自己的学院，更多需要内部形成一种机制和氛围。

内部不仅仅指的是同一个团队，其实也包括售前、售后等其他合作者，这就需要发挥制度创新，将利益相关者聚合起来。

3.3 靠机制而不是靠人

人的服务是不利于规模化的，人的决策蕴含较大风险，人的流失也意味着业务的风险。我们要将经验、思考都转换为可见的东西。

处理业务问题时，要学会记录，形成解决方案，进而行文至文档，编写为脚本等自动化工具，输出为产品，转化为自助服务。

我们需要的是一套能替代人的工作流。任何人都可以启动，执行，得到一致的结果。

另一方面，培养员工也需要形成一套制度，让实习生也可以成为主力，就不会担心人员流失了。

3.4 意愿大于技巧

方向是错的，不要紧，只要有人愿意不断地纠正，起步反而是最难的。

考虑得很全并不是一件很好的事，事倍而功半。这种考虑局限于现有的经验和当前的环境，一旦经验增长、环境发生变化，以前的结论就会被推翻。

kubekey 是一个很好的例子，运维愿意学 Go 搞研发，那么就随他干。现在 kubekey 也是 KubeSphere 核心产品矩阵之一了。

有意愿做，那么就小步快跑地做，不要犹豫。很多时候，退一步就会节节败退; 反过来抗住了就会打开一片新的天空。

3.5 分区办公要根据职责划分

分区办公指的是一个团队在物理上被隔离在不同的地方。一个团队被分割在不同城市，北京、上海、武汉、成都，甚至有的在家里，看似很 nice，非常 global，但如果架构得不好，人员流失率会很高。

一个团队构成一个系统架构。一个团队分成很多个小组，一个组有一个具体的目标，一个小组共同为这个目标而努力。

一个组应该被分配到一个区域，比如微服务在武汉，多集群在成都，DevOps 在北京。而不能一个组三个人分布到三个地区，这样会造成极高的沟通成本。即使现在远程办公在家被逐步接受，但这种没有建立感情的小组人员极易流失，而且不会替项目考虑太多，说走就走。

根据职责划分区域是比较合适的一种方式。一个分区的成员可以充分的沟通，不同分区之间相互协作，构成一个完整的团队。

4. 参考

• https://www.chenshaowen.com/blog/make-decisions-through-data.html
• https://log.qingcloud.com/archives/4855

原文链接 https://www.chenshaowen.com/blog/the-road-to-open-source-for-tob.html