厚积薄发——开源公司商业化之路

作为一个独立运营的企业，商业化一定是不可或缺的一环，开源公司也是如此，最近一直有小伙伴问Jesse，我们应该如何看待开源公司的商业化和时点选择问题，Jesse为此也特意翻阅了资料。今天我们就来聊聊开源公司的商业化以及时点选择，也希望抛砖引玉，供大家探讨。 

本文仅代表个人观点，如有偏颇之处，还请海涵～

开源商业模式与挑战

其实之前的很多文章都提过开源公司的商业模式。我们就此回顾一下，简单来说，开源公司主要就3种商业模式，即：Support & Service（支持服务）、Open Core（开放核心）和Multi-Licensing（多重授权）。在Open Core模式下，我们又可以拆分为Feature-based、Hosting / SaaS、Paid distribution三种细分模式。

Support & Service模式角度来看，实际上我们看大多数美国的开源上市公司Service都是其收入来源的一块，但都占比不高。其主要指的其实是用户向原厂购买的一些咨询服务。这里面所面临的主要挑战就是可扩展性问题，因为其不算是纯license付费，还是需要一些人员支持，并不是可无限扩展、边际效率递增的，其次，这里面也存在一些支持服务和代码质量的潜在冲突。如果我的代码质量越好，其实会用到支持服务的人也就越少。但如果太不好了，又没有人用。典型的靠这种模式成长起来得公司就是Red Hat。

我们再看Open Core模式下的几种细分模式的问题和挑战。首先来看Feature-based模式，其关闭了一部分Feature作为其未来的商业化部分，这里面其实我们主要会聚焦在两点：第一是Product-market fit，第二就是Code basis。其挑战就是我们要决定哪些Feature必须开源，哪些可以闭源。再看Hosting / SaaS模式，也就是我们常说的上云，云租用模式，这种模式目前最具前景和最流行。其可以让客户弹性付费，按需采购，快速扩展。这种模式下的风险主要就是云厂商“Fork”了你的项目直接去卖钱，而不给你分钱。最后就是Paid distribution模式，这种情况下的数据库公司比较多，也就是单节点开源，集群版付费。但目前这种模式其实也存在问题：其一这种模式下很多开源数据库公司失去了自己的用户；其二，本身分布式协议这种编排层其实并不算厚重，你失去了客户，客户很可能还自己做了，得不偿失。InfluxDB就存在这个问题，但是积重难返，如果要改成分布式开源，又会冲击他们代理商的巨大利益。

第三个大的变现模式就是Multi-Licensing，也就是社区产品是开源的，商业公司需要特殊的License。Confluent就是此种模式，此种模式也存在一些挑战。比如，Kafka是捐献给了ASF所以实际上Kafka的社区属于ASF，社区归属权不在公司。其次，任何公司都可以基于Kafka的社区，去成立商业化公司，但他们可能并不是开源社区的主导者，这在开发者群体里其实接受度是较低的，也容易造成社区割裂。

所以综上所述，开源公司还是应该根据自身情况选择好自己的商业化之路。

厚积薄发，商业化逐步加强

数学老师曾教导我们两点之间直线最短，但在物理的世界中，其却不是最快，有些我们看似直接的路并不是最优得选择，开源公司的商业化也是如此。Jesse为此也特意查阅了开源上市公司和独角兽公司的历史，我们发现一家开源公司在进行首次商业化前，大约要花费3年多的时间来进行社区建设。

在社区的起步阶段，大家主要希望去吸引更多的开发者来活跃社区，其目标并不是大公司，而是更希望通过运营，帮助Commits、PR、Contributor等数据迎来增长，从而扩大社区的规模，使Project-Community Fit。当社区完成了一定的积累，我们进入到Product-Market Fit阶段，这时候我们的目标更多是User，希望社区形成良好的氛围和自治，开源产品的下载量和使用者增加。当开源公司真正进入到商业化进程，也就是Value-Market Fit时，开源公司需要去谨慎的平衡开源公司和商业化的关系，一方面需要防止Contributor的大规模离开，一方面也要开始注重自己的商业化收入增长。因为之前社区的积累，所以我们也观察到，当开源公司开始商业化之后，其变成独角兽公司的时间也更快，可以说这是一种厚积薄发的商业模式。所以当我们看待一家开源公司时候，可能不能以传统的眼光来看待他的增长曲线，大家都需要更多的耐心。

今天我们聊到这里，我们下期再见。

CnosDB简介

CnosDB是一款高性能、高易用性的开源分布式时序数据库，现已正式发布及全部开源。

欢迎关注我们的代码仓库，一键三连🙇🙇🙇：https://github.com/cnosdb/cnosdb