写点什么

瞰见 | 美股新贵 Confluent 背后的卡夫卡,不是那个魔幻小说家

作者:OpenTEKr
  • 2021 年 12 月 31 日
  • 本文字数:4558 字

    阅读完需:约 15 分钟

瞰见 | 美股新贵Confluent背后的卡夫卡,不是那个魔幻小说家

 有人正在走进元宇宙,有人正在向火星启程。这是一个最好的时代,这是一个最坏的时代。软件吞噬着世界,开源吞噬着软件,云吞噬着开源。


软件,开源,云,就像那不尽长江滚滚来,惊涛拍岸,卷起千堆雪,一时多少豪杰


狐狸知道很多事,而刺猬只知道一件大事”。 

Multa novit vulpes, verum echinus unum magnum.(希腊语)



这是来自古希腊诗人阿尔基罗库斯 的一句谚语,意思是:狐狸聪明机智点子多,刺猬见解不多但富于洞察。后来,英国哲学家伊赛亚·伯林写了一篇《刺猬与狐狸》的文章,把人类的思想家分成了“刺猬型”与“狐狸型”两类,堪称经典。再后来,吉姆·柯林斯(Jim Collins)在《从优秀到卓越》里提出了刺猬理念,以强调企业经营的深刻本质是简单和专注


而如今,同样这句话被作为开场白,出现在了几个月前 Jay Kreps 给投资人的信里。Jay Kreps 是开源独角兽 Confluent 公司的创始人。由于公司业绩飞速的增长和开源赛道的巨大潜力,Confluent 于今年 6 月在纳斯达克成功上市。并在短短 5 个月内,其市值从上市时 100 亿美金左右,一下张到现在的 210 亿美金左右,市值翻了一倍多。其最近发布的季度财报也分外靓丽,付费客户数量按年增长 75%,老客户净收入留存率 (NRR) 高达 131%,其他财务指标相应保持高速增长。



无疑,上述这些惊艳的数据,就是 Congfluent 公司以“刺猬”思维,在软件吞噬世界,开源吞噬软件的时代里,坚定专注于“软件开源,让数据流动”的成果。它赖以成功的关键策略就是紧紧围绕开源 Apache Kafka 平台为客户提供创新的流数据管理软件和云服务,以此实现了从优秀到卓越的鸿沟跨越。


那么,开源 Kafka 是什么?Confluent 又是一家什么样的公司呢?



1

  开源 Apache Kafka 是什么?

很多人知道卡夫卡(Kafka),是那个写出了《变形记》的魔幻小说家,但未必知道 Apach Kafka。Apache kafka,不是一个人,它是一个流数据的开源软件平台,可以将各类业务或者软件系统中产生的实时海量数据集成到统一的数据流平台上,就类似一个数据的“中枢神经系统”,以便于其他系统的访问和调用。应用领域从零售、物流、制造和金融服务到在线社交网络等相当广泛,是大数据时代里一项数据管理不可或缺的软件基础设施。


当初,Linkedin 公司为了解决将其社交网站和内部各类业务系统中的数据存贮整合到一个可以持续实时响应的系统里时建立的软件开发项目,然后由 Jay Kreps(美国加州人)和清华毕业的饶军(Jun Rao)及来自印度的女生纳赫(Neha Narkhede)组成了一个小组开发这个名为 Kafka 系统的初始版本。他们以开创性的技术建立了一套实时数据流的基础架构,一举解决了 LinkedIn 数十亿条消息的数据流。



他们希望自己所做的开创性技术能不仅仅用于一家公司,随后就说服了公司将 Kafka 开源,并将其捐赠给 Apache 软件基金会,在硅谷科技界建立了最初的用户和开发人员社区。Apache Kafka 目前已成为处理动态数据的底层技术的行业标准,并且有一个强大的开源社区生态系统。


2

  Confluent 的开源商业化之旅

很多软件工程师知道 Apache Kafka,但未必很多人知道 Kafka 背后的商业化公司 Confluent。Confluent 就是最初 kafka 开发小组的三人为联合创始人的创业公司,Confluent 平台的核心是利用 Apache Kafka。



Jay、饶军和纳赫三个来自不同国度而相信开源的软件人,因为工作聚在了一起,然后又因为同一个梦想开始了一段创业之旅。做开源他们是执着的,做开源商业化他们是幸运的。但 Confluent 确实是刺猬知道的大事,值得他们为之全心投入,他们在 LinkedIn 和 Index 及 benchmark 等风险资本的支持下,于 2014 年底开创了 Confluent 公司,并快速成长为了一个业内知名的开源独角兽。


除了基于 Apache Kafka 平台的 Confluent 产品以开创性的流数据技术成为各大企业和组织所不可或缺的基础设施之外,对于开源模式的采用则是基于创始人团队对于开源的深度理解,而“软件吞噬世界,开源吞噬软件”就是他们在创业之初对软件行业的简单而深刻的洞见。



3

  开源真的吞噬软件了吗?


Confluent 并没有简单地把开源商业化等同于开源就是一种商业模式。实际上,开源本身其实并不构成一个商业模式,以开源为基础的商业化才是开源创业企业需要去真正探索的商业模式。


从经济学的角度而言,开源最关键的是两点:它构建了一种新型的软件开发模式以及一种新型的软件分发模式。关于开源下实现的社会化协作开发模式及益处已经有很多讨论了,在这里我们就不特别展开了。这里,我们主要聊一下,开源作为软件的一种新型的软件分发模式是对于传统软件销售过程的一种颠覆和重构,这可能是很多人忽视的一个方面。因为,开源实际上造就了一个面向企业级销售过程中自下而上的销售方法。为何这样说呢?



我们已经看到了,以开源社区的形式让更多的开发者和用户参与进来后,通过对于代码的免费下载和使用,开源可以帮助软件产品进行推广和扩大知名度。Confluent 从自己的商业实践中发现,开源对软件销售事实上产生了另外一个重要的影响,即:


开源让企业的软件购买决策发生了一次权力转移,即从原来的“C-level”管理者转移到了基层软件工程师身上——在这里暂且称之为“软件工程师的购买权”。


这种权力的转移既不是授权任命式的,也不是基层工程师擅自越权式获得,而只是一种软件工程师在工作中非自愿发生但在事后被动式、追认式获得的权力


这和我们平常说的让生米煮成熟饭式的“先上车,后买票”也有所不同,因为那里有些强迫性的意味。但在软件工程师的购买权获得中,只是因为在快速变化的环境下,企业并不会及时意识,甚至完全没有意识到一些技术问题的解决方案需要去额外购买,而企业内的软件技术人员为了解决自己在工作中意外问题,为了更省力更省钱更快速(实际上工程师也很少有花钱的权力),就会自发想到在开源社区寻求免费的解决方案。



直到技术人员用此类开源技术事实上解决了企业的部分问题并有效果之后,企业才意识到这类开源技术的价值,为了进一步提升这些技术应用的可靠性,稳定性,安全性或功能加强时才产生了对此类技术的购买倾向。而当这个 CIO 或者 CTO 最终做出购买决策的时候,事实上软件工程师早已静静地把他们的决策做完了,也做好了。所谓领导最后的拍板也只是对该产品购买的一种形式履行。


就这样,开源下的免费代码分享和软件分发模式,实际上就在企业里不知不觉的完成了一次完美的自下而上的销售过程。


而传统的面向企业用户的软件销售基本上采用的是一种叫“Call High”的自上而下的销售方法,典型的过程如下:软件公司的业务人员通过和企业客户中的 C-level 管理者接洽沟通,并辅之以方案讲演,产品演示,技术验证测试和产品试用等方法来试图说服那些管理者决策者来采用自己所销售的软件产品。在这样的一个过程中,C-level 的管理者掌握着真正的决策权,而对于基层软件工程师而言,虽然他们作为这些软件产品的使用者或者维护者,但无任何决定权,即使他们可以发表一些客观的专业建议,有时候也不会被管理者采纳。



Confluent 的女性创始人纳赫在一次有关开源的访谈中,提及了他们公司在自己产品销售过程中对这种开源基础上产生的面向企业级客户自下而上的销售方法的发现和重视。


有一本书叫《开源吞噬软件》,虽然我还没有机会去阅读体会开源到底如何吞噬软件?但从 Confluent 在其销售实践中对于企业级客户以“自下而上”的销售方法来改变和替代传统的“自上而下”的销售方法,已经清晰地看到了一次开源对于传统软件在销售方法论上的颠覆和吞噬。


4

   云吞噬开源 

中国有句古话,“螳螂捕蝉,黄雀在后”。


在开源不断吞噬传统软件时,云巨头们却在开源背后不断渗透着开源,以至于“软件吞噬世界,开源吞噬软件,云吞噬开源”成为了一个行业内开始流行起来的口头禅,关于云和开源的恩爱情仇,实际也已经引起了很多纷争,如近期的 Elastic 和 AWS 的纠纷等(这个留待以后专文介绍)。Confluent 当然也无法避免面对云巨头对于云服务市场的争抢,但在云巨头面前,Confluent 显然不是那只螳螂。在面临着公有云试图吞噬他们的开源产品时,他们的反应比螳螂机敏多了。



Confluent 所采取的策略:一方面,毫无惧色与狼共舞将自己的产品和各公有云商的基础设施兼容运行。另一方面,Confluent 在 18 年底的时候就已经意识到了来自公有云的强大竞争,所以通过在开源许可证的改变,及时有针对性的建立了自己的防护策略,他们借鉴了 Elastic 的策略。在他们原先采用的 Open Core 模式下,对开源核心免费版和企业版发布的 Apache 2.0 协议 和商业软件许可协议之间,发布了第三个社区版同时配上了自己制定的的社区许可证,这样,所有的软件代码分成了三部分并对每一部分对应了不同的软件许可证。具体如下:

 01 核心代码遵循开放源码下的 Apache 2.0 协议

 02 社区级代码依然开放,但仅遵循社区自己颁布的许可证

主要增加了禁止公有云厂商应用此部分代码去部署成和 Confluent 的产品形成直接竞争的公有云产品的条款。除此之外,其他条款基本和核心免费代码的许可协议相同。

  03 企业级的商业许可



Confluent 社区许可证允许开发人员访问和下载源代码的权利,让他们有机会继续利用开源的平台功能,但明确限制其他人(包括云供应商)获取此源代码并使用它来提供可能于 Confluent 形成直接竞争的 SaaS 产品。


Confluent 以这种方式达到了三个目的:

    1)抵御了来自公有云巨头的竞争

    2)保护了企业的创新 

    3)同时可以各让类社区开发人员的思想和代码保持在社区共享,继续促进开发者社区的发展,也让 Confluent 商业化公司从社区获益。


云计算其实也始于开源,并因为开源而繁盛,以 AWS 为首的公有云们,在自己强大的基础生态上,不断并几乎垄断了全球的 IaaS/PaaS 市场。作为开源软件的商业化公司,也的确有必要去考虑和云厂商的竞争与合作问题,否则有可能失去一个重要的平台生态。但如何找到恰当有效的方法,让开源和商业化能够共同成长和进化, 虽然 Confluent 给出了自己的方案,但其他开源创业企业来说,依然是有待探索的问题。



对于 Confluent 而言,到目前为止,他们从开源走向商业化的实践应该说是富有成效的。如果按照 Jim Collins 的关于卓越企业的“热情,能力,经济引擎”三环理论,那们 Jay、饶军和纳赫三个创始人就应该是找到了开源创业成功的三环:就是对于开源的热情,对于流数据技术的开创性能力,和有一个让企业迅速发展的经济引擎。


而对每一个希望基于开源的创业者来说,我们也必须意识到:如果你对开源社区充满激情,而你对所创建的技术也有足够的天赋和能力,但如果你的项目不能找到有效的商业模式去创造经济效益,那么你可能会享受很多乐趣,但你未必能创造商业的辉煌。


当然,我们永远也可以这样鼓励自己:虽然不能获得辉煌的商业成就,但我们对开源的热情中,享受了很多人生的乐趣。事实上,这就是真实的人生,选择而已


如果那是我们热爱的,那就去热爱我们的热爱吧!无问西东,开源应如是。


文中图片源自网络,侵删。且本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。

source1:https://www.confluent.io/blog/license-changes-confluent-platform/

source 2: https://www.youtube.com/watch?v=S6sGuyBzJ1kThe History of Apache Kafka with Neha


/// 关于作者 ///


狄 安

OpenTEKr 创始人 & 开源布道者

企业级软件领域的连续创业家,开源领域的独立研究者。现从事开源和数字化领域的文化研究和理念布道,及开源和商业结合的探索与实践。


发布于: 2 小时前
用户头像

OpenTEKr

关注

以开源开放为理念,推动科技文明共同体。 2021.11.11 加入

OpenTEKr 是一家以推广开源软件和开放硬件技术为核心的开放式非营利组织,致力于构建可持续发展的开放科技生态圈。我们基于“众有、众享、众治”的信念,依循「自由与规则同在,免费与商业共生」的原则。

评论

发布
暂无评论
瞰见 | 美股新贵Confluent背后的卡夫卡,不是那个魔幻小说家