提起TiDB 开源社区建设实践大家在熟悉不过了，被越来越多的人所熟知，那你知道TiDB 开源社区建设实践吗？快和小编一起去了解一下吧！
(资料图片仅供参考)
作者 | 刘辰
策划 | 蔡芳芳
开源在 IT 技术的发展中起到了不可替代的作用，而开源社区是保持其生命力的重要因素。PingCAP 是一家非常热爱开源的公司，其开源数据库产品 TiDB 也获得了来自全球各地的开发者的认可。随着近两年开源在国内受到越来越多的关注，开源运营也逐渐进入大家的视野，我们看到越来越多的项目开始主动加强运营，同时也会听到一些声音说，开源项目并不需要运营。在一个开源社区的建设和发展过程中，运营究竟是在解决什么问题、发挥什么作用？
本文整理自 PingCAP 社区运营负责人刘辰在 DIVE 全球基础软件创新大会 2022 的演讲分享，主题为“TiDB 开源社区建设实践”。分享主要以 TiDB 社区的实践为例，解构开源战略和社区建设要点，总结了 TiDB 社区在不同阶段的关键问题与实践体会，并探讨了开源社区运营这一角色在社区发展中的作用和边界。
以下是分享内容，正文约 6000 字：
Why：开源战略
说到为什么一定要开源，我们先回归到开源是什么——它既是一种软件的“生产”方式，也是一种“分发”方式。在这个基础上，不难理解开源带来的力量：第一，开放本身即是一种构建信任的方式；第二，通过开源，让项目本身开放可获取，也可实现全球化的技术传播（从下图中给 TiDB star 的开发者分布情况可见一斑）；第三，开源作为一种软件的生产和协作方式，能够让更多人直接参与产品的反馈、构建，大大加速产品的迭代。
而 TiDB 过去 6 年产品的迭代过程也在不断证明开放的力量，技术的开放性带来更多的连接、更快的迭代速度和更多的可能性。
How：解构开源社区飞轮
关于 TiDB 社区的建设，我们总结了一个社区飞轮模型，来体现产品、用户、贡献者这三个要素之间的相互作用：
这里我们所称的“社区”，并不是狭义的贡献者社区，而是把我们的产品、贡献者、用户都视为社区的一部分，彼此之间相互影响，像一整个生态，而这个交互过程中的效率、质量都在影响着社区的成长。而“Contributor”也不仅包括代码贡献者，也包括了社区对文档、文章、答疑、布道等方面做出贡献的成员们。
建设和运营开源社区的过程，就是去识别每一环存在的问题和机会，去助推这个飞轮的运转，形成正向循环。
当然，飞轮是一个非常简化的模型，体现的只是最核心的逻辑。当我们加上“时间”这个维度去看待社区的成长，会发现在开源项目发展的不同阶段，主要矛盾以及每种角色的数量、增长速率、对产品演进的影响是有区别的。甚至每个元素的内涵和外延，也在随着时间的推移变得更加丰富。
以 TiDB 为例，当我们加上时间的维度去看社区飞轮，在每一阶段的主题大致呈现为下图的状态：
早期：从 Contributor 到 Product
在项目早期，产品通常还是比较基础的状态，可能还没有什么用户，从长期发展的角度而言，这一阶段最关键的是验证和完善产品。早期的贡献者也通常是基于对产品技术本身的兴趣而加入，这也是为什么在图示中，存在双向的箭头。
TiDB 开源之初，我们花了很大精力去写，主动地、勤奋地和大家介绍 TiDB 技术，吸引贡献者，也收获了一些小伙伴加入了 PingCAP。技术交流的过程同样也是寻找早期用户、了解产品需求的过程。
现在回看，我们认为有三个方面的基础工作是非常关键的：一是要把文档写好，这是基础中的基础，它能够让其他的开发者更好地理解产品；二是与开发者和早期用户建立直接面对面的交流机会，比如通过 meetup 更高效地沟通；三是快速反馈，对早期使用者提出的需求快速给出反馈，快速修复他们提出的问题。
贡献者的参与体验，是从 Contributor 到 Product 的过程中很重要的一个问题，说到这里，可能要提一下社区治理——也是热爱开源的朋友们非常关心的议题，业界有不少比较成熟的治理结构、范式，TiDB 社区也尝试过一些治理模型。在这个探索的过程中，我们最深的体会是要去关注那些更为本质的问题，比如贡献者是不是容易理解产品和代码、是不是知道可以参与哪些工作（issue 是否友好）、有没有得到及时的反馈等。治理结构和框架是为解决问题服务的，带着具体问题去参考前人的做法，会更有心得。当社区能够致力于优化信息同步和开发基础设施、关注贡献者的体验，在这个过程中会沉淀出适合自己的流程，而随着产品和社区的成长，也总是需要对社区治理的方式进行相应的迭代。
成长期：从 Product 到 User
当经过前一个阶段的发展，社区在所在的技术领域已获得了更多的认知度，也沉淀下来贡献者的参与机制，贡献者开始稳定增长。与此同时，产品已验证了发展方向、积累了一些用户。用户与产品之间的直接互动变得更加高频。
随着产品逐步完善，我们接下来面临的一个重点考验是：用户增长。
用户增长的问题有很多种参考模型，但归根结底，就要解决两个问题：
如何能够让更多人了解产品？
怎样才能够帮助更多用户更好地用起来？
当然这两个问题对任何产品的任何阶段都很重要，放在成长期去讲，主要是因为它们会在很大程度上决定着一个产品、社区能走多远。我们用更多篇幅来拆解这两个问题：
如何让更多人知道产品
即解决价值传递问题。内容和活动是开源项目做价值传递最常见的两种载体。
在发展期，内容与早期相比会有一些变化，早期更多的是我们自己的产研去做产出，但是随着越来越多的贡献者和用户加入，内容也有了更多的生产者，相应的也出现了更多的分发方式和路径。
而活动方面，为了更好地传递产品理念、传递产品的价值，我们也开始需要对活动做出更精细的维度设计，比如说针对产品使用可以划分成不同的场景，面向不同的受众划分不同的行业。
有市场背景的同学们到这里会发现，这和市场营销在解决的问题非常类似。的确如此，这也许正是为什么在不少企业中，开源运营属于市场部门。但我们也要看到，尽管问题相似，但在开源社区的语境下，具体的解决路径方面会存在一些特殊性，这是由开发者群体本身的特性、偏好（特别是对技术产品的认知和选择偏好）所决定的。这也是为什么开发者关系（Developer Relationship）这个职业越来越受到欢迎。
怎么样让更多人用起来
这里隐含了用户使用成本、社区技术支持成本的问题。对 TiDB 这样的 infra 产品而言，难以避免存在一定的学习和使用门槛。如果仅靠我们的自己技术支持，瓶颈是非常显著的——当然这也是几乎所有 toB 产品都会遇到的一个难题。
尽管 infra 产品很难像有良好交互界面的 SaaS 产品那样通过优化交互设计、引导体系等来帮助用户上手使用，但依然可以借鉴其解决使用成本问题的核心理念——自服务（self-service）。
通常，当用户遇到问题时，首先会去查看官方文档，如果文档里没有，那就搜一搜网络上有没有这方面的内容，看看其他人遇到了这个问题是怎么解决的，如果再没有，那么就去社区提问，看看有没有其他人可以帮忙回答。这种找答案的方式、顺序，是具有相当程度的普遍性的。这也正对应了自服务体系的三个层次：文档、UGC 内容、互助问答。
这三个层次的顺序很重要，它们的通用性依次降低，而信息生产和获取成本却是依次升高的，只有每一层都能够发挥相应的过滤作用，整体的效率才会最大化。
TiDB 社区的自服务，主要是通过网站来实现的，除了文档主要由我们的工程师撰写，其他的技术文章、互助问答，社区用户参与的程度在稳步提升，今年 3 月我们对社区 1 万多个问答贴子做了个统计，其中已有 80% 是由社区用户互助解决的。
我们在探索建立自服务体系的过程中也总结出来一些要点：
标签： pingcap开源社区运营
