首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >TiDB 开源社区建设实践

TiDB 开源社区建设实践

作者头像
深度学习与Python
发布2022-06-13 11:07:28
4430
发布2022-06-13 11:07:28
举报

作者 | 刘辰

策划 | 蔡芳芳

开源在 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-06-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 InfoQ 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档