作为一个独立运营的企业,商业化一定是不可或缺的一环,开源公司也是如此,最近一直有小伙伴问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社区交流群:
扫描下方二维码,加入CC进入CnosDB社区进入社区交流,CC也会在群内分享直播链接哒