关于数据库:In-Community-We-Trust

作者简介：黄东旭，PingCAP 联结创始人兼 CTO

前些天在与友人喝咖啡的时候，正好聊到对于 PingCAP 和 TiDB 的一些历史以及对于开源软件公司外围竞争力的了解，回顾这几年的守业生涯和 TiDB 社区的成长壮大，就像是一场微小且正在进行中的社会学试验，本来零散的一些想法随着一条主线变得逐步清晰，就想着写成文章总结一下对于社区对于开源软件以及开源公司到底意味着什么。

无处不在的网络效应

两种网络效应

很多人据说过网络效应（梅特卡夫效应：网络的价值与联网用户的平方数成正比），许多平凡的产品和公司通过网络效应构建起了弱小的护城河。提到网络效应，经典例子在通信畛域，例如手机，每多一个用户，对于所有用户的价值就越大，尽管大家也无心为别人发明价值，然而一旦开始应用，该行为就会帮忙这个网络发明价值。很多咱们熟知的 to C 公司，尤其是社交网络和 IM（即时通信软件），通过这个效应构建了极高的壁垒。NfX Venture 在他们的一篇博客(https://www.nfx.com/post/network-effects-manual/）中详细描述了很多种网络效应，在介绍社区之前，我想着重介绍下其中和开源软件相干的两种网络效应。

1. 基于从众心理的网络效应

这类网络效应通常是从一些意见首领开始，可能是行业大咖，可能是社交潮人，经常呈现在一个新产品要去防御一个老产品的市场时。只管这个新产品相比市场的统治者来说不肯定成熟，但它通常会带着一些显明的特色或者更加前沿的理念，吸引那些对「支流」不满或者心愿突显本身前沿视线的意见首领的反对，造成一种「很酷的人都在用，你不必你就要被淘汰了」的感觉。

这种感觉会在新用户纷纷退出时，造成从众心理的网络效应，然而 这类网络效应的持续时间不会太长。细想一下就能晓得：如果晚期意见首领只是因为突显「不同」而退出，那么在这个社区成为支流后，这些意见首领就没有理由留下，追寻这些人的粉丝可能会随之而去。另外，对于这个新产品来说，欠缺水平通常不如老产品，美誉和差评会在晚期同时到来。此时，如果不疾速通过网络效应打磨产品，取得更好的迭代速度，那么，这个网络效应是根基不牢的。一个益处在于，该效应在晚期是事倍功半的。

回忆 TiDB 晚期的社区建设，也是因为几个创始人在 Codis 的工作以及在国内根底软件圈中积攒的名声，和一些互联网技术圈中敌人的反对，造成最早的背书。

1. 基于信奉的网络效应

所谓「信奉」，就是基于对一个理念的认可而退出，从而造成网络效应。这点在软件畛域也不少见，自由软件静止和开源静止都是很好的例子。人嘛，总是要置信点什么。这类网络效应的护城河是极深的，而且对于产品缺点的容忍度极高。因为信念是一个长期的念想，对于 TiDB 来说，这个念想形如：置信分布式是将来，置信云时代的业务须要像 TiDB 这样的数据库。然而这个指标又是足够有挑战的，值得长期为之致力。

基于信奉的网络效应可能在最晚期和从众心理网络效应有点相似，其中的要害是社区外围人群对于产品背地的理念是否有动摇信奉。反之，如果只是简略地秀自卑感，是不会短暂的，随着趣味衰减，网络效应也会崩塌。

网络效应对于根底软件的意义

对于根底软件来说，我始终保持两个观点：

• 根底软件是被“用”进去的，不是“写”进去的。
• 迭代和进化速度是这类软件的外围竞争力。

这两点恰好是网络效应能带来的，尽管价值链条不像 IM 那样显著，然而，网络效应存在的根底是新用户给老用户带来的额定价值。而根底软件的价值，体现为以下几点：

• 可控的危险（稳定性）
• 更多的场景适应性（发现新的实用场景和继续晋升性能）
• 良好的易用性

对于危险管制来说，越多人用意味着危险被越多人均摊，其中的一个假如是：我不特地，我遇到的问题他人应该也遇到过，肯定有人能比我早发现并修复它。这个假如在一个成熟且沉闷的根底软件社区是成立的，因为根底软件的场景边界绝对清晰，在适用范围内的门路大致相同，同一条门路走多了，坑天然就少了。只有有一个人踩到坑，反馈回社区，不论最初是谁修好的，这个行为对于其余用户都是受害的。

同样的逻辑，对于场景适应性来说也成立。个体的认知总是带有局限性，即便是我的项目的开创团队，也不见得对于某个具体的利用场景有深刻理解。社区用户的创造力是无穷的，一些设计外的应用门路可能会出奇地好用，从而倒退出新的劣势场景。同样地，只有有一个胜利案例，那么对于其余具备类似场景的用户来说，软件的价值就减少了，TiDB 和 Flink 组合成的实时 HTAP 数据处理计划，就是一个很好的例子。

对于易用性改良的逻辑和稳定性相似，我就不赘述了。利用网络效应带来的飞轮效应改良软件，这个思路我在《大教堂终将倒下，但集市永存》一文中也提到过。

社区的成熟度曲线和必经阶段

社区的诞生

在 GitHub 上凋谢你的源代码，甚至应用公开的 Git 工作流，都不是社区诞生的时刻。一个社区真正诞生，是在你和你的代码之外，开始有第三者染指并产生连贯的时刻，可能是收到第一个内部 PR，可能是收到第一个内部 issue，这些才是社区的开始。社区始于连贯，也成就于连贯。凋谢源代码并不等同于开源，很多团队和我的项目在凋谢源代码方面破费了很多工夫，却疏忽了代码及背地团队的社区化，这是很惋惜的。

死亡鸿沟和心愿之坡

就像《逾越鸿沟》这本书中提到的，开源软件也有本人的生命周期曲线，这是和社区非亲非故的。

图中断层呈现的起因是产品成熟度迟迟没有跟上，用户过去当前发现都是坑，随之而来的各种差评会让晚期支持者和创始人疲于奔命甚至而失去趣味。

对于一个开源软件，断层的体现可能是经验晚期快速增长后，来到长达 1~2 年的静默期，增长简直停滞。对于社区来说，简直所有的精力都用在给晚期用户填坑，期间会有用户天然增长但流失率也十分高。这个阶段对于资源的耗费十分大，社区的外围贡献者也会十分累，如果熬不过去就死了，所以说是“死亡鸿沟”。

好消息是，这个阶段终将会过来 ，bug 这种货色嘛，改掉一个就少一个，产品也会在这个阶段逐步摸索到本人的定位和最佳实际，而在最佳实际这个门路上，产品会变得越来越稳固和聚焦。如果定位是市场刚需， 那么就会迎来一个高速增长阶段（成熟期），而社区的生态也会随着产品的遍及开始加速度倒退。这个从上图的 Kubernetes 和 TiDB 的搜寻指数外面能看到这个鸿沟的一个侧写。

社区的终局

一个好的开源软件社区的终局会是什么样子？对于这个问题，其实咱们有很多能参考的例子，例如 GNU Linux、Hadoop、Spark、MySQL 等等。我认为，不论一个开源软件及社区是由商业公司发动还是其余形式发动、壮大，到最初肯定会呈现独立于某公司之外的中立组织来接管这个社区，这也是最天然正当的形式。

尤其是公司主导的开源我的项目，在前期会面临中立性的问题。因为对于公司而言，最重要的是客户胜利，对商业化的诉求肯定会影响开源软件性能设置和开发优先级。而且优先级往往是会变的（可能更紧急且更具体），变动兴许会和社区的开发节奏抵触，但我不认为这两者的矛盾不可和谐，我会在下文开展来讲。

中后期的开源软件曾经撑持着太多用户的场景胜利和商业利益，由一个中立的委员会来均衡各方的利益及监督各方的责任是目前看来比拟胜利的实际，而且开始有这样的组织，也从侧面阐明这个我的项目曾经成熟，曾经有良好的生态。还没有达到这个阶段的开源软件大多是由我的项目背地的公司主导社区，在我的项目成熟阶段，重点是一直地通过优化客户和场景的胜利让整个飞轮转动起来，当主导公司之外有越来越多的成员在思考和实际 governance rule，这就是一个踊跃的信号。

社区和商业化如何共存

种地和做菜 & 河与岸上的人

前文留下一个问题，就是开源与商业化的矛盾，不论我如何解释，实质上开源和传统的软件售卖模式肯定是抵触的。

我举一个比拟好了解的例子：如果将开源比作种菜，开源软件源代码相当于种子，业务胜利相当于长进去的菜，传统的软件商业模式相似于卖种子，然而种地施肥（hosting）都是客户本人的工作。开源软件的种子是收费的，地是客户的，种地的人也是客户的人，所以开源厂商大略只能提供种地领导服务，尤其在一些种子不是太好种的状况下，领导服务是有意义的。但认真想想，随着种子一直改进（性能、稳定性、易用性等），轻易撒到地里就能开花结果，那么业余的种菜服务就没什么必要性了。于是厂商只好卖一些额定的价值，比方保险服务，万一种子成长遇到极其天气，至多有专家团在背地帮忙解决。然而这种商业模式依然比拟顺当，因为价值链条大部分都在客户本人这边。所以，如果厂商对待社区只停留在潜在客户视角，很难做出好产品，因为没有外在能源去继续优化软件。

一个更好的视角是往后退一步，我再举个好了解的例子：将社区当成一条河流，不属于任何人，大家独特放弃河水的明澈和流动性，谁都不要适度捞鱼，不同的组织和集体都能够在河流周边构建本人的生态，至于岸上的人靠什么挣钱，那是另外一个问题，后文再讲。

客户胜利和用户体验：外在的一致性

尽管开源软件商业公司的第一指标是客户胜利，但这和做好社区并不矛盾。一个常见的误区是在开源软件公司外部，这两个团队造成对抗关系。商业团队认为社区就是给商业化养鱼的，养肥了就要收割，极其点就动不动要闭源；社区团队认为商业化会减慢生态流传的速度，应用门槛回升，极其做法是产生反商业化的偏向。如果都只在本人的地位上思考问题，当然单方都没错，那到底是哪里有问题呢？

问题出在了“阶段”和“客户抉择”，社区用户和商业用户应用开源软件的生命周期可能齐全不同，个别的开源软件公司会有两个漏斗，我称之为社区漏斗和商业漏斗。有些说法认为社区漏斗是商业漏斗的下层，我之前也深认为然，但通过几年的实际，我慢慢发现其实并不是那样。这两者是独立的，如果只是简略地作为一个漏斗，那么就会有很多问题，比方经典问题：不会流到商业漏斗的社区用户，其价值到底是什么？所以，必定不是一个漏斗，而是有很深的内部联系。

什么分割？为不便了解，还是用种菜举例说明。开源社区孵化进去的货色，例如用户胜利案例、社区奉献对产品的打磨、摸索进去的实用场景等，就像一个个生的菜和食材，而客户想要一盘鱼香肉丝，并不关怀盘子中的肉和菜是怎么来的，所以看到关键点了吗？商业化团队的角色就像是厨师，社区经营团队就像农民，二者的关注点并不一样，厨师关注点是如何做好菜，农民的关注点是如何种好地，产生更好的食材。从食材到一道菜，还要经验很长的过程，但没有好食材，能力再强的厨师也难做出一盘好菜。

对于开源软件公司来说，社区和商业这两个团队的外部一致性是：好产品和制胜场景。依据咱们的实践经验，比拟好的做法是，社区团队聚焦于两个关键点：

• 社区用户对于产品的打磨（在制胜场景下）；
• 发现更多的制胜场景。

这两个关键点会造成闭环，社区团队继续产生食材（制胜场景以及继续进化的产品），商业团队聚焦于制胜场景的进一步加工和客户旅程优化，两个团队互相配合拉动整个公司和我的项目的大循环。例如 TiDB 商业用户的场景和解决方案，大多是从社区用户中诞生并打磨成熟，只管可能两个用户群体齐全不一样，然而通过 TiDB 造成了一个大的生态——商业化的循环，而 PingCAP 就是两头的桥梁。另外，社区和商业化团队会有一个独特的北极星指标：用户体验。

可规模化变现的惟一前途：云

一个好的生意应该是能够规模化的，传统开源软件公司的商业模式，问题在于规模化中须要人的染指，销售 / 售前 / 售后交付等等，而基于人的生意是没法规模化的。在云诞生前这个问题是无解的，所以开源软件公司须要寻找一个和开源无关的软件商业模式（听起来有点顺当，然而认真想想的确如此），而云实质上是一个资源租赁生意。

还是以种菜的例子来说，过来传统的商业模式中，因为土地和种菜人都是客户本人的，所以开源软件公司的地位就比拟难堪，然而在云上，根底软件商业模式实质上是一个 hosting 服务，让原来价值链条中最重要的一部分“土地”（hosting 资源和基础设施）把握在了厂商手上，这对于用户来说也是好的，毕竟治理“土地”也是一件费神费劲的事件，而且很难做到按需购买。问题在于用户想要的只是一道好菜而已，留神这和开源（种菜）并没有什么关系，因为不论开不开源，用户领取的都是治理和租赁费用，相当于即便种子和食材收费，顾客去饭店吃饭，也须要为菜品买单，因为顾客购买的是好菜和服务体验。

另外，很多人认为开源社区是竞争壁垒，其实并不是，真正的壁垒是生态，而开源社区是构建生态的一种高效形式，如果一个产品不必开源也构建起了生态，那么成果是一样的。一个很好的例子就是 Snowflake，只管 Snowflake 没有开源，然而 2012 年诞生伊始，它在云数据仓库这个市场内简直没有任何竞争对手，留给 Snowflake 足够的工夫通过差异化定位和极佳的用户体验构建本人的生态，依靠云的崛起和规模化效应获得了巨大成功。

如何做好社区

上文形而上地探讨了很多对于哲学的内容，接下来聊聊落地实际。想要做好开源社区其实是有方法论的，但前提是有正确的思考形式和思考角度，否则在实际环节你就会发现有有数事件能够做，却不晓得哪件或哪些事件是更重要的，更好受的是你发现没法掂量对与错。以下是我的一些思考角度以及思考时思考的重点指标，可作为社区运营者的参考。

你是谁？你解决了什么问题？为什么是你？

好社区的根基肯定是好产品，要答复“你是谁”这个问题，肯定是通过答复“你解决了什么问题”而得出的，这点和 to C 产品的经营很不一样。一些社区运营者会将注意力转移到各种流动或者宣传拉新，同时夸张产品能力，导致与事实不符，这是最常见的误区。

很多做社区经营的敌人常常来找我：我也做了很多流动，写了很多文章，为什么看起来没有成果？通常这个时候我会问他：你能一句话说明确你的产品是做什么的吗？到底解决了什么问题？这个问题是广泛问题吗？非你这个产品不可吗？这个时候他就明确：完满的产品是不存在的，好的产品肯定是追随它的劣势场景呈现的，比方 Redis 显然不能用来做外围金融交易场景，但谁都不会否定 Redis 在缓存场景下是当之无愧的事实标准。同样的例子还有很多，例如 Spark、ClickHouse 等等。所以对于经营团队，在做任何动作之前要想分明下面的四个问题。

好用决定了漏斗的转化率

找到制胜场景就够了吗？当然不是，如果把整个用户旅程当成一个漏斗，找到制胜场景充其量是找到正确的入口而已，进入漏斗当前，重要的事件就变成了晋升各阶段的转化率，决定转化率的一个要害指标是产品的易用性，这点和做 to C 产品很像，很多做 to B 的团队会下意识疏忽这一点，通常可能是两种起因：

• 不太器重社区用户 Self-service，我的项目官网甚至激励用户分割官网团队，因为晚期晓得有人在用这个信息是很重要的，而商业客户根本服务和反对都是官网的，客户无感，对公司而言没有能源优化。
• 很多产品在诞生初期是救命型的产品，用户没有别的抉择。例如晚期的 TiDB，在 MySQL 扩大需要火烧眉毛的时候，用户更关怀如何立刻把问题解决掉，内核能力更重要，其余的能够先缓缓，忍着就好。

这两种起因导致的后果就是，对易用性和用户体验关注有余，这个谬误在市场竞争初期是很荫蔽的。一方面因为流进漏斗的 leads 数量不够大，人肉反对尚可，且市场的竞争还不强烈，用户没有其余抉择。试想一下，当这个市场终有一天变得成熟，大量客户被充沛教育后流入漏斗，团队的反对带宽必定是有余的；另一方面，因为市场曾经被教育成熟，肯定会有竞争对手能做相似的事件，这时，当你不是市场中惟一的救命抉择，用户肯定会抉择用着棘手且省心的一方，这不难理解。这就是为什么在开源软件竞争的中后期，易用性和用户体验要放在至高地位的起因。对于“用着省心”，假如曾经通过成熟的生态和案例背书解决了，而在“用着棘手”这一点上，中国诞生的开源软件团队相比世界先进程度而言，差距很大，毕竟海内的开源软件竞争比国内更加强烈，因为国外开源市场诞生工夫长，而且业务场景对于根底软件的需要也没有国内极其，通常好几个产品都能搞定同一个场景，那么这时当然就要比拼易用性（省心）和生态（释怀）。

有几个问题，作为开源我的项目的产品负责人能够问问本人，在你的产品畛域里，如何定义好用？最佳实际是什么？世界上最好用的同类程度是怎么样的？我置信思考这些问题对产品倒退会有帮忙。一个反映易用性的好视角是：用户可能 Self-servicing 的水平，其指标体系较多：比方在云上自助残缺整个产品生命周期的比例，在开源社区从接触到应用过程中不必发问的比例，开源社区沉闷贡献者数量等等。

二次流传是达成网络效应的要害

上文提到过，网络效应产生的前提是，任何一个新用户的应用对于老用户是有价值加成的，所以试想：如果一个社区用户默默地应用了软件，默默地看了文档和最佳实际文章，甚至出了 bug 本人默默地修好（不奉献回来），这对这个社区和产品是有价值的吗？

我认为是没有的。

只管我晓得肯定会有这样的用户存在，就像缄默的大多数人一样。对于社区运营者来说，最要害的工作不是让沉默者更多或更深度地应用，而是让他们和网络中的其余用户建设更多的连贯，例如分享教训（写案例文章）、造就贡献者、踊跃向社区反馈应用中的问题等等，而且肯定要将这些内容传递到网络的其余节点，确保产生价值。例如：一个用户的应用场景帮到了另一个用户选型，一个用户反馈帮忙产品发现了一个 bug 并修复，这些都是产生价值的例子。切忌让用户变成一个个孤岛，社区运营者如果看不清这个关键点，可能会陷入为了数字（使用量）而谋求数字的状况，做了很多工作，但从全局看不到提高。

网络效应的转移

社区经营的最高境界是将网络效应从使用者的网络效应转移到基于信奉的网络效应，将社区核心从开源公司外部转移到内部以取得更大的势能。这两者都不容易，对于前者可能更多的是形象和总结提炼理念以及持续保持久远而正确的 insight（洞察），加之寻找适合的布道者群体，这点并不容易。对于后者来说，只有在以公司为核心的阶段积攒足够多的胜利案例和劣势场景，并且投入资源教育市场，剩下的交给工夫就好，这个阶段关注的指标是品牌力。开源软件社区经营是一个指数曲线的游戏，要抱着长期主义的心态去耕耘。

最初作为结尾，我想谈谈，一个平凡的开源根底软件产品应该是什么样的？

我眼中一个平凡的根底软件产品不仅仅是解决眼下的具体问题，而是开启一片新的天地，一个新的视角，发明新的可能性。就像智能手机的创造，它作为平台催生出了微信这样的平凡利用，开启了一个全新的世界。就像云、S3 和 EBS 的创造，给开发者提供了新的设计形式，催生出了 Snowflake 这类的新物种，彻底改变了人们应用剖析数据的形式。而 开源社区正是这类平凡根底软件诞生的最合适的土壤，就像鱼和水一样。

我不晓得社区会带来什么，我也不敢高估本人能力，毕竟在群体智慧背后，集体的力量永远是渺小的。