GMTC北京站优惠购票最后一周!13个热点专题,50+大厂案例,这里一览 了解详情
写点什么

TiDB 开源社区建设实践

  • 2022 年 6 月 06 日
  • 本文字数:6363 字

    阅读完需:约 21 分钟

TiDB 开源社区建设实践

开源在 IT 技术的发展中起到了不可替代的作用,而开源社区是保持其生命力的重要因素。PingCAP 是一家非常热爱开源的公司,其开源数据库产品 TiDB 也获得了来自全球各地的开发者的认可。随着近两年开源在国内受到越来越多的关注,开源运营也逐渐进入大家的视野,我们看到越来越多的项目开始主动加强运营,同时也会听到一些声音说,开源项目并不需要运营。在一个开源社区的建设和发展过程中,运营究竟是在解决什么问题、发挥什么作用?

 

本文整理自 PingCAP 社区运营负责人刘辰在DIVE全球基础软件创新大会 2022 的演讲分享,主题为“TiDB 开源社区建设实践”。分享主要以 TiDB 社区的实践为例,解构开源战略和社区建设要点,总结了 TiDB 社区在不同阶段的关键问题与实践体会,并探讨了开源社区运营这一角色在社区发展中的作用和边界。

 

以下是分享内容,正文约 6000 字:

Why:开源战略


说到为什么一定要开源,我们先回归到开源是什么——它既是一种软件的“生产”方式,也是一种“分发”方式。在这个基础上,不难理解开源带来的力量:第一,开放本身即是一种构建信任的方式;第二,通过开源,让项目本身开放可获取,也可实现全球化的技术传播(从下图中给 TiDB star 的开发者分布情况可见一斑);第三,开源作为一种软件的生产和协作方式,能够让更多人直接参与产品的反馈、构建,大大加速产品的迭代。

 


而 TiDB 过去 6 年产品的迭代过程也在不断证明开放的力量,技术的开放性带来更多的连接、更快的迭代速度和更多的可能性。

How:解构开源社区飞轮

关于 TiDB 社区的建设,我们总结了一个社区飞轮模型,来体现产品、用户、贡献者这三个要素之间的相互作用:


这里我们所称的“社区”,并不是狭义的贡献者社区,而是把我们的产品、贡献者、用户都视为社区的一部分,彼此之间相互影响,像一整个生态,而这个交互过程中的效率、质量都在影响着社区的成长。而“Contributor”也不仅包括代码贡献者,也包括了社区对文档、文章、答疑、布道等方面做出贡献的成员们。

 

 

建设和运营开源社区的过程,就是去识别每一环存在的问题和机会,去助推这个飞轮的运转,形成正向循环。

 

当然,飞轮是一个非常简化的模型,体现的只是最核心的逻辑。当我们加上“时间”这个维度去看待社区的成长,会发现在开源项目发展的不同阶段,主要矛盾以及每种角色的数量、增长速率、对产品演进的影响是有区别的。甚至每个元素的内涵和外延,也在随着时间的推移变得更加丰富。

 

以 TiDB 为例,当我们加上时间的维度去看社区飞轮,在每一阶段的主题大致呈现为下图的状态:

 


这里需要注意两点:

1、飞轮的三要素在每个阶段都非常重要,图中突出显示的部分,只是强调需要重点突破的主题;

2、这里的阶段划分仅以 TiDB 为例,可能并不具有普适性,不同的产品因产品属性、发展目标不同,其成长路径和每阶段的主要矛盾也会呈现出多样性。

早期:从 Contributor 到 Product


在项目早期,产品通常还是比较基础的状态,可能还没有什么用户,从长期发展的角度而言,这一阶段最关键的是验证和完善产品。早期的贡献者也通常是基于对产品技术本身的兴趣而加入,这也是为什么在图示中,存在双向的箭头。

 

TiDB 开源之初,我们花了很大精力去写,主动地、勤奋地和大家介绍 TiDB 技术,吸引贡献者,也收获了一些小伙伴加入了 PingCAP。技术交流的过程同样也是寻找早期用户、了解产品需求的过程。

 


现在回看,我们认为有三个方面的基础工作是非常关键的:一是要把文档写好,这是基础中的基础,它能够让其他的开发者更好地理解产品;二是与开发者和早期用户建立直接面对面的交流机会,比如通过 meetup 更高效地沟通;三是快速反馈,对早期使用者提出的需求快速给出反馈,快速修复他们提出的问题。

 

贡献者的参与体验,是从 Contributor 到 Product 的过程中很重要的一个问题,说到这里,可能要提一下社区治理——也是热爱开源的朋友们非常关心的议题,业界有不少比较成熟的治理结构、范式,TiDB 社区也尝试过一些治理模型。在这个探索的过程中,我们最深的体会是要去关注那些更为本质的问题,比如贡献者是不是容易理解产品和代码、是不是知道可以参与哪些工作(issue 是否友好)、有没有得到及时的反馈等。治理结构和框架是为解决问题服务的,带着具体问题去参考前人的做法,会更有心得。当社区能够致力于优化信息同步和开发基础设施、关注贡献者的体验,在这个过程中会沉淀出适合自己的流程,而随着产品和社区的成长,也总是需要对社区治理的方式进行相应的迭代。

成长期:从 Product 到 User


当经过前一个阶段的发展,社区在所在的技术领域已获得了更多的认知度,也沉淀下来贡献者的参与机制,贡献者开始稳定增长。与此同时,产品已验证了发展方向、积累了一些用户。用户与产品之间的直接互动变得更加高频。

 

随着产品逐步完善,我们接下来面临的一个重点考验是:用户增长。



用户增长的问题有很多种参考模型,但归根结底,就要解决两个问题:

1. 如何能够让更多人了解产品?

2. 怎样才能够帮助更多用户更好地用起来?

 

当然这两个问题对任何产品的任何阶段都很重要,放在成长期去讲,主要是因为它们会在很大程度上决定着一个产品、社区能走多远。我们用更多篇幅来拆解这两个问题:

如何让更多人知道产品


即解决价值传递问题。内容和活动是开源项目做价值传递最常见的两种载体。

 


在发展期,内容与早期相比会有一些变化,早期更多的是我们自己的产研去做产出,但是随着越来越多的贡献者和用户加入,内容也有了更多的生产者,相应的也出现了更多的分发方式和路径。

 

而活动方面,为了更好地传递产品理念、传递产品的价值,我们也开始需要对活动做出更精细的维度设计,比如说针对产品使用可以划分成不同的场景,面向不同的受众划分不同的行业。

 

有市场背景的同学们到这里会发现,这和市场营销在解决的问题非常类似。的确如此,这也许正是为什么在不少企业中,开源运营属于市场部门。但我们也要看到,尽管问题相似,但在开源社区的语境下,具体的解决路径方面会存在一些特殊性,这是由开发者群体本身的特性、偏好(特别是对技术产品的认知和选择偏好)所决定的。这也是为什么开发者关系(Developer Relationship)这个职业越来越受到欢迎。

怎么样让更多人用起来


这里隐含了用户使用成本、社区技术支持成本的问题。对 TiDB 这样的 infra 产品而言,难以避免存在一定的学习和使用门槛。如果仅靠我们的自己技术支持,瓶颈是非常显著的——当然这也是几乎所有 toB 产品都会遇到的一个难题。

 

尽管 infra 产品很难像有良好交互界面的 SaaS 产品那样通过优化交互设计、引导体系等来帮助用户上手使用,但依然可以借鉴其解决使用成本问题的核心理念——自服务(self-service)。



通常,当用户遇到问题时,首先会去查看官方文档,如果文档里没有,那就搜一搜网络上有没有这方面的内容,看看其他人遇到了这个问题是怎么解决的,如果再没有,那么就去社区提问,看看有没有其他人可以帮忙回答。这种找答案的方式、顺序,是具有相当程度的普遍性的。这也正对应了自服务体系的三个层次:文档、UGC 内容、互助问答。

 

这三个层次的顺序很重要,它们的通用性依次降低,而信息生产和获取成本却是依次升高的,只有每一层都能够发挥相应的过滤作用,整体的效率才会最大化。

 

TiDB 社区的自服务,主要是通过网站来实现的,除了文档主要由我们的工程师撰写,其他的技术文章、互助问答,社区用户参与的程度在稳步提升,今年 3 月我们对社区 1 万多个问答贴子做了个统计,其中已有 80% 是由社区用户互助解决的。

 

我们在探索建立自服务体系的过程中也总结出来一些要点:

 

1. 关注用户的信息获取效率。一方面做好通用问题的收敛,持续从问答中发现通用问题,除了在产品中改进之外,也要及时在文档中补充和完善;另一方面是要持续优化内容的组织方式、可检索性,用分类、标签、合集等方式,帮助用户更方便地找到相关内容。

 

2. 质量优先。这一点的底层逻辑其实与前面一点是高度一致的,也很容易理解:减少重复性的问题,提升质量,是可以降低用户的信息筛选成本的。但似乎这一点比较容易被忽视,特别是当面对“追求数量”的诱惑时。我们也时常提醒自己这一原则、保持克制,比如社区上线了“专栏”板块,设定了评审小组对质量把关,“问答”板块也持续在优化搜素、发帖体验,减少重复性的内容。

 

讲到这里,大家会发现,如果我们把内容、技术互助也视为一种“贡献”(我们很建议如此看待),那么发展期“从 User 到 Contributor”这个环节的发展也会越来越快,这也意味着一个社区逐渐走向成熟。

成熟期:全面协同


如果顺利通过前面两个阶段的考验,迈入成熟期,社区的飞轮会较为显著地展示出它的增长力,三个要素之间形成良性循环,绽放开源的魅力。这个阶段的主要特征,也许可称之为“生态驱动增长”

 

在成熟期,飞轮中的三要素也有了更大的概念外延,比如 Product 不仅仅包括了开源项目本身,也会包括衍生的工具、应用等生态产品,而 Contributor 也将包括参与生态产品的贡献者。

TiDB 社区刚刚 7 岁,我们还在成长和探索的路上,还未达到真正意义的成熟期,也无法从实践的角度去讲,这个部分还比较粗浅,只是一些观察、思考和对自己的期待。

 

这个阶段,从 Product 到 User 已具备相当成熟的路径,这里就不再多聊,主要探讨另外两个环节在成熟期的新挑战,以及一个无形中影响整个社区每个环节的因素——社区文化。

从 User 到 Contributor


实际上在每个阶段,都会从用户中产生直接的社区贡献者,比如在成长期提到的参与内容、技术问答贡献的情况,特别放在成熟期来讲,主要是因为这个阶段社区发展更为成熟、生态更丰富,可贡献的范围更大相应的,从用户中产生贡献者的路径和方式也更多。

 

影响从 User 到 Contributor 这个环节的关键:

  1. 产品本身的开放性。开源的开放性本身会带来这种可能性,用户可以以开源的方式参与到整个社区的贡献中。

  2. 用户参与贡献的意愿以及能力。这就取决于参与路径的打磨情况,以及社区吸引力。

从 Contributor 到 Product


在成熟期,贡献者可以以更多的方式参与到产品及生态产品的建设,给产品的发展提供更多维的助力。生态产品也留意到一个特殊的挑战:

 

对于主产品而言,成长期和成熟期的“Contributor 到 Product”存在一些共性的挑战,即随着开源项目的成长,产品(特别是在做商业化发展的产品)获得了越来越多的用户甚至客户,当需求的声音越来越多、而资源有限时,如何取舍和平衡。

 

 

需要注意的是,这个问题只是在成长和成熟期比较显著(时间相关),并不是与开源有因果关系,更不是开源项目所特有的。确切来讲,这是一个产品在成长过程所必然面对的产品定位、设计与研发效率平衡问题。归根结底是产品需要有良好的 PMF(产品市场匹配度),否则,无论是否开源都难以为继。只是在开源社区的语境下,需要同时关注社区体验,保持开放与透明。

 

对于生态产品而言,这一环节少了前述的约束,有更为自由的发挥和成长空间,这时的关键就成为开放生态的建设、方向识别及参与激励。

社区文化


在成熟期,尽管贡献者参与社区路径更为多样、复杂,但基本逻辑、策略与改进思路与前两个阶段并无本质差别。也许与一个组织的发展类似,体量越大,文化的因素就越显重要。对开源社区而言,它的活跃度、生命力无不与社区的氛围紧密相关。但这种精神内核究竟是什么,我目前也未找到答案,只能谈一些个人的感受。

 

社区文化的建设绝非一朝一夕之功,需要长久的维护与共识。在 PingCAP 这个带着开源基因的公司,能够感受到很重视工程师文化、重视社区,研发流程开源化。也有很多热爱开源的小伙伴,他们考虑问题时不仅仅是一个 PingCAP 的员工,也会在一个社区成员的角度去思考和行动,正是这些点点滴滴的“小事”,构建起一个有料、有爱的社区。

 

小结


经过前面的拆解,我们可以看到,社区飞轮不仅存在单向的循环,也有局部的相互作用,也需要一些助力去更好地运转起来:

 

开源社区运营迷思


我们再回到开头的问题,开源社区需要运营吗?

 

要回答这个问题,首先要厘清概念,在一个相对明确的内涵和外延中讨论。

 

作为一个多年在开源领域的从业者,我十分理解,当大家说“开源社区不是运营出来的”时,其实特指的是对于代码贡献者社区,运营人员并非必要的。对此我也表示赞同,毕竟在代码贡献的场景下,其实就是在进行技术交流、协作开发,当然也存在一些产品层面的交流协作,在这个场景下,直接与技术人员、产品交流,大概率比隔一层运营的角色更加高效、直接。

 

但如果我们把开源社区视为包括产品、广义的贡献者、用户的广义社区,再结合前面我们提到的社区发展阶段的问题、解法来看这个问题,也许答案就不一样了。我们常说开源生态,生态这个词挺准确地反映了开源社区本身的复杂性。而在解决复杂问题时,通常都会需要多种角色的共同作用。

 

那么为了更好地建设一个开源社区(广义),需要运营这个角色来解决什么问题?

关于开源社区运营


实际上运营这个职业本身,虽然还是个历史不太久的年轻的职业,已经发展出很多分支了,但怎么定义,还是不太容易描述,有一些模糊性,但归根结底是解决连接产品和目标受众的问题,即需要理解需求(Why),并掌握实现的路径(What)和方法(How),最终拿到结果。具体到开源社区的运营,我们会发现,它跟普遍意义上的互联网运营有一些共性,也有一些个性的部分。

 

共性的部分体现在 How——具体的实现路径、执行技巧方法方面。比如,一场活动的宣传,在设计、文案如何更好呈现主题、清晰易懂,在不同渠道如何传播更有效,这些技巧的底层逻辑是通用,用户运营、产品策略运营也是类似,已有一些相对成熟的知识体系和方法论。

 

个性的部分体现在 Why 和 What,这就涉及对需求的方向理解和策略选择了,而这恰恰是决定具体执行怎么做的前置因素。

 

目前国内的开源社区运营,按来源大约有两类:一类是从其他领域的运营/市场转到开源领域,这里如果在掌握一定的 How 和 What 判断力的基础上,难点主要在于补充 Why 的部分、并且需要一些时间调整和适应 What 策略。另一类是从技术转运营,优势是对 Why 理解很深,但也需要打磨 What、以及补充 How 方面的知识。

 

我自己属于第一种情况,虽然转到从事开发者、开源相关的运营工作也有 5 年多了,但一直以来最大的感受还是关于 Why、What、How,要学习和更新的知识非常多,不仅要增进自己对所运营的产品本身的理解、对产品受众的理解、对业务的理解,也要保持对互联网用户习惯变化的感知、对其他相关领域知识的吸收。

 

对“人”本身的理解,也会制约着对“需求”理解的深度。对开发者的理解,特别是对开源相关的开发者,是开源社区运营非常重要的一项基本功。涉及的维度很多,时间关系,我们只谈谈开源的精神内核。

 

 

开源本身是个很丰富的概念,如果简化来看,我尝试总结为三个关键词:第一个是理想,是用技术进行创造的一种内生驱动因素;第二个是协作,特别是开源作为一种协作开发的方式,有其规则和理念,这些让素不相识的一群人能够一起创造;第三个是真诚,虽然看起来虽然普通,但也是一切的基础,开源社区的建设,是一个长期的信任关系的构建,离开真诚,信任无从谈起。

社区运营的边界

 

而当我们谈到开源社区运营的边界时,这个问题本身一方面与如何理解开源社区建设有关,另一方面也与运营能解决的问题范畴有关。尝试总结了几个不成熟的观点:

 

  1. 社区建设是所有参与者的合力,这个参与者一定包括公司本身;

  2. 技术的交流是最高效的,特别是在面向代码贡献者的环节中,项目维护主体是工程师,而非运营;

  3. 运营更加侧重的是从 1 到 100 的过程,运营应该重点关注的是这个过程的效率提升。

 

最后用这张图做一个小小的总结,开源社区的运营、开发者关系是有趣也比较庞杂的话题,今天所聊到的也只是截取了一些局部的点,而且是基于有限的认知和探索,在这里抛砖引玉,谢 InfoQ DIVE 提供的交流机会:)

 


2022 年 6 月 06 日 13:301831
用户头像
蔡芳芳 InfoQ高级编辑

发布了 700 篇内容, 共 375.2 次阅读, 收获喜欢 2481 次。

关注

评论

发布
暂无评论
发现更多内容

基于多源数据画像的失败用例智能分析

华为云开发者联盟

云原生 测试 日志 失败用例 智能分析

C语言-数组

DS小龙哥

C语言

评委拍案叫绝、项目惊喜不断,这是一届怎样的 Hackathon ?丨TiDB Hackathon 2021 回顾

PingCAP

在Mac上运行Rainbond,10分钟快速安装

北京好雨科技有限公司

2021大厂面试题之redis篇

小麦

面试题 redis' 大厂面经

C语言-函数的可变形参(不定形参)

DS小龙哥

C语言

Hadoop中mapreduce作业日志是如何生成的

华为云开发者联盟

hadoop hdfs mapreduce YARN 作业日志

Java中方法重写和方法重载的6个区别?

王磊

2021年vivo互联网技术最受欢迎文章TOP25

vivo互联网技术

数据库 前端 服务器 年度总结 Vivo

C语言-语句(if,for,while,switch,goto,return,break,continue)

DS小龙哥

C语言

区块链,元宇宙时代的“基础设施”

CECBC

阿里云何川:开放兼容的云,计算巢帮助合作伙伴云化升级

阿里云弹性计算

弹性计算 年度峰会 计算巢

深入解析Kafka的offset管理

编程江湖

kafka

2022年中科柏诚服务再提升,为银行数字化转型提供精准化助力

联营汇聚

再见esdsl,搜索引擎 elasticsearch扩展,使用通用表达式搜索

中间件XL

搜索引擎 elasticsearch

发挥好数字人民币促“双碳”作用

CECBC

2021关键词:重新起航

faiting

数据结构算法 盘点 2021

详解数据中台的底层架构逻辑

五分钟学大数据

数据中台 数据仓库 1月月更

C语言-基本数据类型与位运算

DS小龙哥

C语言

抢占先机!为何说区块链通证经济象征未来?

CECBC

如果你是加勒比海盗首领,会选择哪种算法来使价值最大化?

博文视点Broadview

从内存管理原理,窥探OS内存管理机制

华为云开发者联盟

cpu 内存 内存管理 应用程序 OS

城墙上的“云镜派”,如何守护云上资产安全?

白洞计划

Ubuntu LNMPR环境搭建(Ubuntu 20.04 + Nginx1.8 + PHP 7.3 + Mysql8.0 + Redis5.0)

Owen Zhang

ubuntu LNMPR

最佳实践:青藤云安全发布国内首个K8S ATT&CK攻防矩阵

青藤云安全

缓存一致性最佳实践

得物技术

缓存 分布式 数据 一致性 实践

ONES 收购为知笔记,全面升级企业知识库产品

万事ONES

ONES 知识库

C语言-函数的定义、声明、传参

DS小龙哥

C语言

Hyperf结合PhpOffice/PhpSpreadsheet实现Excel&CSV文件导出导入

Owen Zhang

php hyperf php扩展 PhpOffice/PhpSpreadsheet

Ubuntu 基于Nginx1.8的Golang环境搭建(Ubuntu 20.04 + Nginx1.8 + Golang 1.17 )

Owen Zhang

golang nginx ubuntu

Golang:定时器的终止与重置

恒生LIGHT云社区

golang 定时器 语言 Go 语言

金融行业数据库架构实践与运维

金融行业数据库架构实践与运维

TiDB 开源社区建设实践_语言 & 开发_刘辰_InfoQ精选文章