TiDB 开源社区建设实践
开源在 IT 技术的发展中起到了不可替代的作用，而开源社区是保持其生命力的重要因素。PingCAP 是一家非常热爱开源的公司，其开源数据库产品 TiDB 也获得了来自全球各地的开发者的认可。随着近两年开源在国内受到越来越多的关注，开源运营也逐渐进入大家的视野，我们看到越来越多的项目开始主动加强运营，同时也会听到一些声音说，开源项目并不需要运营。在一个开源社区的建设和发展过程中，运营究竟是在解决什么问题、发挥什么作用？
本文整理自 PingCAP 社区运营负责人刘辰在 DIVE 全球基础软件创新大会 2022 的演讲分享，主题为“TiDB 开源社区建设实践”。分享主要以 TiDB 社区的实践为例，解构开源战略和社区建设要点，总结了 TiDB 社区在不同阶段的关键问题与实践体会，并探讨了开源社区运营这一角色在社区发展中的作用和边界。
以下是分享内容，正文约 6000 字：
说到为什么一定要开源，我们先回归到开源是什么——它既是一种软件的“生产”方式，也是一种“分发”方式。在这个基础上，不难理解开源带来的力量：第一，开放本身即是一种构建信任的方式；第二，通过开源，让项目本身开放可获取，也可实现全球化的技术传播（从下图中给 TiDB star 的开发者分布情况可见一斑）；第三，开源作为一种软件的生产和协作方式，能够让更多人直接参与产品的反馈、构建，大大加速产品的迭代。
而 TiDB 过去 6 年产品的迭代过程也在不断证明开放的力量，技术的开放性带来更多的连接、更快的迭代速度和更多的可能性。
关于 TiDB 社区的建设，我们总结了一个社区飞轮模型，来体现产品、用户、贡献者这三个要素之间的相互作用：
这里我们所称的“社区”，并不是狭义的贡献者社区，而是把我们的产品、贡献者、用户都视为社区的一部分，彼此之间相互影响，像一整个生态，而这个交互过程中的效率、质量都在影响着社区的成长。而“Contributor”也不仅包括代码贡献者，也包括了社区对文档、文章、答疑、布道等方面做出贡献的成员们。
建设和运营开源社区的过程，就是去识别每一环存在的问题和机会，去助推这个飞轮的运转，形成正向循环。
当然，飞轮是一个非常简化的模型，体现的只是最核心的逻辑。当我们加上“时间”这个维度去看待社区的成长，会发现在开源项目发展的不同阶段，主要矛盾以及每种角色的数量、增长速率、对产品演进的影响是有区别的。甚至每个元素的内涵和外延，也在随着时间的推移变得更加丰富。
以 TiDB 为例，当我们加上时间的维度去看社区飞轮，在每一阶段的主题大致呈现为下图的状态：
这里需要注意两点：
1、飞轮的三要素在每个阶段都非常重要，图中突出显示的部分，只是强调需要重点突破的主题；
2、这里的阶段划分仅以 TiDB 为例，可能并不具有普适性，不同的产品因产品属性、发展目标不同，其成长路径和每阶段的主要矛盾也会呈现出多样性。
在项目早期，产品通常还是比较基础的状态，可能还没有什么用户，从长期发展的角度而言，这一阶段最关键的是验证和完善产品。早期的贡献者也通常是基于对产品技术本身的兴趣而加入，这也是为什么在图示中，存在双向的箭头。
TiDB 开源之初，我们花了很大精力去写，主动地、勤奋地和大家介绍 TiDB 技术，吸引贡献者，也收获了一些小伙伴加入了 PingCAP。技术交流的过程同样也是寻找早期用户、了解产品需求的过程。
现在回看，我们认为有三个方面的基础工作是非常关键的：一是要把文档写好，这是基础中的基础，它能够让其他的开发者更好地理解产品；二是与开发者和早期用户建立直接面对面的交流机会，比如通过 meetup 更高效地沟通；三是快速反馈，对早期使用者提出的需求快速给出反馈，快速修复他们提出的问题。
贡献者的参与体验，是从 Contributor 到 Product 的过程中很重要的一个问题，说到这里，可能要提一下社区治理——也是热爱开源的朋友们非常关心的议题，业界有不少比较成熟的治理结构、范式，TiDB 社区也尝试过一些治理模型。在这个探索的过程中，我们最深的体会是要去关注那些更为本质的问题，比如贡献者是不是容易理解产品和代码、是不是知道可以参与哪些工作（issue 是否友好）、有没有得到及时的反馈等。治理结构和框架是为解决问题服务的，带着具体问题去参考前人的做法，会更有心得。当社区能够致力于优化信息同步和开发基础设施、关注贡献者的体验，在这个过程中会沉淀出适合自己的流程，而随着产品和社区的成长，也总是需要对社区治理的方式进行相应的迭代。
当经过前一个阶段的发展，社区在所在的技术领域已获得了更多的认知度，也沉淀下来贡献者的参与机制，贡献者开始稳定增长。与此同时，产品已验证了发展方向、积累了一些用户。用户与产品之间的直接互动变得更加高频。
随着产品逐步完善，我们接下来面临的一个重点考验是：用户增长。
用户增长的问题有很多种参考模型，但归根结底，就要解决两个问题：
如何能够让更多人了解产品？
怎样才能够帮助更多用户更好地用起来？
当然这两个问题对任何产品的任何阶段都很重要，放在成长期去讲，主要是因为它们会在很大程度上决定着一个产品、社区能走多远。我们用更多篇幅来拆解这两个问题：
即解决价值传递问题。内容和活动是开源项目做价值传递最常见的两种载体。
在发展期，内容与早期相比会有一些变化，早期更多的是我们自己的产研去做产出，但是随着越来越多的贡献者和用户加入，内容也有了更多的生产者，相应的也出现了更多的分发方式和路径。
而活动方面，为了更好地传递产品理念、传递产品的价值，我们也开始需要对活动做出更精细的维度设计，比如说针对产品使用可以划分成不同的场景，面向不同的受众划分不同的行业。
有市场背景的同学们到这里会发现，这和市场营销在解决的问题非常类似。的确如此，这也许正是为什么在不少企业中，开源运营属于市场部门。但我们也要看到，尽管问题相似，但在开源社区的语境下，具体的解决路径方面会存在一些特殊性，这是由开发者群体本身的特性、偏好（特别是对技术产品的认知和选择偏好）所决定的。这也是为什么开发者关系（Developer Relationship）这个职业越来越受到欢迎。
这里隐含了用户使用成本、社区技术支持成本的问题。对 TiDB 这样的 infra 产品而言，难以避免存在一定的学习和使用门槛。如果仅靠我们的自己技术支持，瓶颈是非常显著的——当然这也是几乎所有 toB 产品都会遇到的一个难题。
尽管 infra 产品很难像有良好交互界面的 SaaS 产品那样通过优化交互设计、引导体系等来帮助用户上手使用，但依然可以借鉴其解决使用成本问题的核心理念——自服务（self-service）。
通常，当用户遇到问题时，首先会去查看官方文档，如果文档里没有，那就搜一搜网络上有没有这方面的内容，看看其他人遇到了这个问题是怎么解决的，如果再没有，那么就去社区提问，看看有没有其他人可以帮忙回答。这种找答案的方式、顺序，是具有相当程度的普遍性的。这也正对应了自服务体系的三个层次：文档、UGC 内容、互助问答。
这三个层次的顺序很重要，它们的通用性依次降低，而信息生产和获取成本却是依次升高的，只有每一层都能够发挥相应的过滤作用，整体的效率才会最大化。
TiDB 社区的自服务，主要是通过网站来实现的，除了文档主要由我们的工程师撰写，其他的技术文章、互助问答，社区用户参与的程度在稳步提升，今年 3 月我们对社区 1 万多个问答贴子做了个统计，其中已有 80% 是由社区用户互助解决的。
我们在探索建立自服务体系的过程中也总结出来一些要点：
关注用户的信息获取效率。一方面做好通用问题的收敛，持续从问答中发现通用问题，除了在产品中改进之外，也要及时在文档中补充和完善；另一方面是要持续优化内容的组织方式、可检索性，用分类、标签、合集等方式，帮助用户更方便地找到相关内容。
质量优先。这一点的底层逻辑其实与前面一点是高度一致的，也很容易理解：减少重复性的问题，提升质量，是可以降低用户的信息筛选成本的。但似乎这一点比较容易被忽视，特别是当面对“追求数量”的诱惑时。我们也时常提醒自己这一原则、保持克制，比如社区上线了“专栏”板块，设定了评审小组对质量把关，“问答”板块也持续在优化搜素、发帖体验，减少重复性的内容。
讲到这里，大家会发现，如果我们把内容、技术互助也视为一种“贡献”（我们很建议如此看待），那么发展期“从 User 到 Contributor”这个环节的发展也会越来越快，这也意味着一个社区逐渐走向成熟。
如果顺利通过前面两个阶段的考验，迈入成熟期，社区的飞轮会较为显著地展示出它的增长力，三个要素之间形成良性循环，绽放开源的魅力。这个阶段的主要特征，也许可称之为“生态驱动增长”。
在成熟期，飞轮中的三要素也有了更大的概念外延，比如 Product 不仅仅包括了开源项目本身，也会包括衍生的工具、应用等生态产品，而 Contributor 也将包括参与生态产品的贡献者。TiDB 社区刚刚 7 岁，我们还在成长和探索的路上，还未达到真正意义的成熟期，也无法从实践的角度去讲，这个部分还比较粗浅，只是一些观察、思考和对自己的期待。
这个阶段，从 Product 到 User 已具备相当成熟的路径，这里就不再多聊，主要探讨另外两个环节在成熟期的新挑战，以及一个无形中影响整个社区每个环节的因素——社区文化。
实际上在每个阶段，都会从用户中产生直接的社区贡献者，比如在成长期提到的参与内容、技术问答贡献的情况，特别放在成熟期来讲，主要是因为这个阶段社区发展更为成熟、生态更丰富，可贡献的范围更大相应的，从用户中产生贡献者的路径和方式也更多。
影响从 User 到 Contributor 这个环节的关键：
产品本身的开放性。开源的开放性本身会带来这种可能性，用户可以以开源的方式参与到整个社区的贡献中。
用户参与贡献的意愿以及能力。这就取决于参与路径的打磨情况，以及社区吸引力。
在成熟期，贡献者可以以更多的方式参与到产品及生态产品的建设，给产品的发展提供更多维的助力。生态产品也留意到一个特殊的挑战：
对于主产品而言，成长期和成熟期的“Contributor 到 Product”存在一些共性的挑战，即随着开源项目的成长，产品（特别是在做商业化发展的产品）获得了越来越多的用户甚至客户，当需求的声音越来越多、而资源有限时，如何取舍和平衡。
需要注意的是，这个问题只是在成长和成熟期比较显著（时间相关），并不是与开源有因果关系，更不是开源项目所特有的。确切来讲，这是一个产品在成长过程所必然面对的产品定位、设计与研发效率平衡问题。归根结底是产品需要有良好的 PMF（产品市场匹配度），否则，无论是否开源都难以为继。只是在开源社区的语境下，需要同时关注社区体验，保持开放与透明。
对于生态产品而言，这一环节少了前述的约束，有更为自由的发挥和成长空间，这时的关键就成为开放生态的建设、方向识别及参与激励。
在成熟期，尽管贡献者参与社区路径更为多样、复杂，但基本逻辑、策略与改进思路与前两个阶段并无本质差别。也许与一个组织的发展类似，体量越大，文化的因素就越显重要。对开源社区而言，它的活跃度、生命力无不与社区的氛围紧密相关。但这种精神内核究竟是什么，我目前也未找到答案，只能谈一些个人的感受。
社区文化的建设绝非一朝一夕之功，需要长久的维护与共识。在 PingCAP 这个带着开源基因的公司，能够感受到很重视工程师文化、重视社区，研发流程开源化。也有很多热爱开源的小伙伴，他们考虑问题时不仅仅是一个 PingCAP 的员工，也会在一个社区成员的角度去思考和行动，正是这些点点滴滴的“小事”，构建起一个有料、有爱的社区。
经过前面的拆解，我们可以看到，社区飞轮不仅存在单向的循环，也有局部的相互作用，也需要一些助力去更好地运转起来：
我们再回到开头的问题，开源社区需要运营吗？
要回答这个问题，首先要厘清概念，在一个相对明确的内涵和外延中讨论。
作为一个多年在开源领域的从业者，我十分理解，当大家说“开源社区不是运营出来的”时，其实特指的是对于代码贡献者社区，运营人员并非必要的。对此我也表示赞同，毕竟在代码贡献的场景下，其实就是在进行技术交流、协作开发，当然也存在一些产品层面的交流协作，在这个场景下，直接与技术人员、产品交流，大概率比隔一层运营的角色更加高效、直接。
但如果我们把开源社区视为包括产品、广义的贡献者、用户的广义社区，再结合前面我们提到的社区发展阶段的问题、解法来看这个问题，也许答案就不一样了。我们常说开源生态，生态这个词挺准确地反映了开源社区本身的复杂性。而在解决复杂问题时，通常都会需要多种角色的共同作用。
那么为了更好地建设一个开源社区（广义），需要运营这个角色来解决什么问题？
实际上运营这个职业本身，虽然还是个历史不太久的年轻的职业，已经发展出很多分支了，但怎么定义，还是不太容易描述，有一些模糊性，但归根结底是解决连接产品和目标受众的问题，即需要理解需求（Why），并掌握实现的路径（What）和方法（How），最终拿到结果。具体到开源社区的运营，我们会发现，它跟普遍意义上的互联网运营有一些共性，也有一些个性的部分。
共性的部分体现在 How——具体的实现路径、执行技巧方法方面。比如，一场活动的宣传，在设计、文案如何更好呈现主题、清晰易懂，在不同渠道如何传播更有效，这些技巧的底层逻辑是通用，用户运营、产品策略运营也是类似，已有一些相对成熟的知识体系和方法论。
个性的部分体现在 Why 和 What，这就涉及对需求的方向理解和策略选择了，而这恰恰是决定具体执行怎么做的前置因素。
目前国内的开源社区运营，按来源大约有两类：一类是从其他领域的运营 / 市场转到开源领域，这里如果在掌握一定的 How 和 What 判断力的基础上，难点主要在于补充 Why 的部分、并且需要一些时间调整和适应 What 策略。另一类是从技术转运营，优势是对 Why 理解很深，但也需要打磨 What、以及补充 How 方面的知识。
我自己属于第一种情况，虽然转到从事开发者、开源相关的运营工作也有 5 年多了，但一直以来最大的感受还是关于 Why、What、How，要学习和更新的知识非常多，不仅要增进自己对所运营的产品本身的理解、对产品受众的理解、对业务的理解，也要保持对互联网用户习惯变化的感知、对其他相关领域知识的吸收。
对“人”本身的理解，也会制约着对“需求”理解的深度。对开发者的理解，特别是对开源相关的开发者，是开源社区运营非常重要的一项基本功。涉及的维度很多，时间关系，我们只谈谈开源的精神内核。
开源本身是个很丰富的概念，如果简化来看，我尝试总结为三个关键词：第一个是理想，是用技术进行创造的一种内生驱动因素；第二个是协作，特别是开源作为一种协作开发的方式，有其规则和理念，这些让素不相识的一群人能够一起创造；第三个是真诚，虽然看起来虽然普通，但也是一切的基础，开源社区的建设，是一个长期的信任关系的构建，离开真诚，信任无从谈起。
而当我们谈到开源社区运营的边界时，这个问题本身一方面与如何理解开源社区建设有关，另一方面也与运营能解决的问题范畴有关。尝试总结了几个不成熟的观点：
社区建设是所有参与者的合力，这个参与者一定包括公司本身；
技术的交流是最高效的，特别是在面向代码贡献者的环节中，项目维护主体是工程师，而非运营；
运营更加侧重的是从 1 到 100 的过程，运营应该重点关注的是这个过程的效率提升。
最后用这张图做一个小小的总结，开源社区的运营、开发者关系是有趣也比较庞杂的话题，今天所聊到的也只是截取了一些局部的点，而且是基于有限的认知和探索，在这里抛砖引玉，谢 InfoQ DIVE 提供的交流机会：）
点个在看少个 bug 👇
微信扫码关注该文公众号作者