这其中就隐含着用户使用成本和社区技术支持。对于 TiDB 这样的基础设施产品，难免存在一定的学习和使用门槛，如果单纯依靠自身的技术支持，瓶颈会非常大 —— 当然这也是几乎所有 toB 产品都会遇到的问题。
虽然infra产品很难像具有良好交互界面的SaaS产品那样通过优化交互设计和引导系统来帮助用户上手，但是他们解决成本问题的核心理念——自助服务，我们还是可以借鉴的。
通常，用户遇到问题，会先查看官方文档，如果文档没有给出答案，就会上网搜索相关内容，看看其他人是怎么解决这个问题的。如果还是没有答案，就会去社区提问，看看有没有人能帮忙解答。这种寻找答案的方式和顺序相当具有普适性。这也对应了自助系统的三个层级：文档、UGC内容、相互问答。
这三个层级的顺序很重要，它们的通用性依次降低，而信息生产和获取的成本则依次升高，只有每一层都能起到相应的过滤作用，才能使整体效率最大化。
TiDB 社区的自助服务主要通过网站实现，除了我们工程师主要撰写的文档之外，社区用户对其他技术文章、相互问答的参与程度也在稳步提升。今年 3 月我们对社区内超过 1 万条问答帖进行了统计，其中 80% 的问题都得到了社区用户的相互帮助解决。
在探索建立自助服务体系的过程中，我们也总结了一些要点：
注重用户信息获取效率。一方面做好常见问题聚合，不断从问答中发现常见问题，除了在产品中完善外，也应及时在文档中补充完善；另一方面，持续优化内容的组织和可搜索性，利用分类、标签、合集等方式帮助用户更便捷地找到相关内容。
质量第一。这一点的底层逻辑其实和上一点高度一致，也很好理解：减少重复问题，提高质量，可以降低用户的信息筛选成本。但似乎这一点很容易被忽视，尤其是在面对“追求数量”的诱惑时。我们也经常提醒自己这个原则，保持克制。比如社区推出了“专栏”板块，并成立了审核小组来把控质量。“问答”板块也不断优化搜索和发帖体验，减少重复内容。
此时大家会发现，如果我们把内容和技术互助看成是一种“贡献”（我们强烈推荐这样做），那么“从User到Contributor”的发展阶段会发展的越来越快，这也意味着一个社区在逐渐成熟。
成熟期：全面协同
如果社区顺利通过前两个阶段的考验，进入成熟阶段，社区的飞轮将更加显著地展现出其成长的威力，三要素之间形成良性循环，绽放开源的魅力。这一阶段的主要特征或许可以称之为“生态驱动成长”。
在成熟阶段，飞轮中的三要素有了更大的概念外延，比如 Product 不仅包括开源项目本身，还包括衍生的工具、应用等生态产品，Contributor 也包括生态产品的贡献者。TiDB 社区才刚成立 7 年，我们还在成长和探索的路上，还没有到达真正的成熟阶段，还不能从实践的角度去谈。这部分还是比较肤浅的，只是对自己的一些观察、思考和期待。
在这个阶段，从Product到User的路径已经比较成熟，我们这里就不再详细讨论了，而是重点讲一下另外两个环节在成熟阶段面临的新挑战，以及一个无形中影响着整个社区各个环节的因素——社区文化。
从用户到贡献者
其实每个阶段都会从用户中产生直接的社区贡献者开源问答社区软件，比如成长期提到的内容参与、技术问答贡献等。成熟期尤其如此，主要是因为这个阶段社区发展更加成熟，生态更加丰富，贡献范围更大，相应地从用户中产生贡献者的路径和方式也更多。
影响从用户到贡献者转变的关键因素是：
产品本身的开放性。开源本身的开放性带来了这种可能性，用户可以以开源的方式参与到整个社区的贡献中。
用户的贡献意愿和能力取决于参与路径的打磨和社区的吸引力。
从贡献者到产品
在成熟阶段，贡献者可以通过更多方式参与到产品和生态产品的建设中，为产品发展提供更多维度的支持。生态产品也面临一个特殊的挑战：
对于主力产品而言，在成长和成熟阶段的“Contributor to Product”阶段会面临一些共同的挑战，即随着开源项目的成长，产品（尤其是商业开发的产品）的用户乃至客户越来越多，当需求越来越多但资源有限时，如何取舍和平衡。
需要注意的是，这个问题只是在成长期和成熟期（时间相关）更加显著，与开源没有因果关系，也不是开源项目独有的。准确的说，这是一个产品在成长过程中必须面对的产品定位、设计、研发效率平衡的问题。归根结底，产品需要有很好的 PMF（产品市场契合度），否则无论开源与否都难以持续。只不过在开源社区的背景下，更需要注重社区体验，保持开放透明。
对于生态产品来说，这个环节已经摆脱了前述的束缚，有了更多的自由发挥和成长空间，此时的关键就变成了开放生态的构建、方向的确定和参与的激励。
社区文化
在成熟阶段，贡献者参与社区的路径虽然更加多样复杂，但基本逻辑、策略和改进思路与前两个阶段本质上是一样的。或许与组织的发展类似，规模越大，文化因素就越重要。对于一个开源社区来说，它的活跃度和活力与社区的氛围息息相关。但这个精神内核到底是什么？我至今还没有找到答案，只能说一些个人感受。
社区文化的建设不是一朝一夕就能完成的，需要长期的维护和共识。在 PingCAP 这个有开源基因的公司，你能感受到它对工程文化、社区、开源研发流程的重视。这里也有很多热爱开源的朋友，他们在考虑问题时，不仅仅是 PingCAP 的员工，也站在社区成员的角度去思考、去行动。正是这些点点滴滴的“小事”，才构建了一个有内容、有爱的社区。
概括
经过上面的分析，我们可以看出社区飞轮不仅有单向循环，有局部互动，同样需要一些助力才能更好地运转：
关于开源社区运营的误区
我们回到最开始的问题：开源社区需要运营吗？
要回答这个问题，首先必须明确概念，并在一个比较明确的内涵和外延下进行讨论。
作为一名在开源领域多年的从业者，我完全理解人们说“开源社区不是通过运营而产生的”时，特指的就是代码贡献者社区，运营者并不是必需的。我认同这一点，毕竟在代码贡献的语境下，其实就是技术交流与协同开发。当然也有一些产品层面的沟通与协同，在这种语境下，直接与技术人员、产品沟通很可能比一层层的运营更加高效、直接。
但如果我们将开源社区视为一个包括产品、广泛贡献者、用户的广泛社区，并将此与前文提到的社区发展阶段的问题和解决方案结合起来，答案或许会有所不同。我们经常谈论开源生态系统，生态系统这个词准确地反映了开源社区本身的复杂性。在解决复杂问题时，通常需要多个角色的共同努力。
那么为了更好地建设开源社区（广义上来说），这个角色需要解决什么问题？
关于开源社区运营
其实，运营这个职业本身虽然还是一个年轻、历史不长的职业，但已经发展出了很多分支，如何定义它，依然是一个很难描述的话题。虽然有些模糊，但归根结底还是要解决产品和目标受众之间的连接问题，也就是要理解需求（Why），并掌握实现需求的路径（What）和方法（How），最终得到结果。说到开源社区的运营，我们会发现它和一般的互联网运营既有共通之处，又有各自独特的部分。
共性在于“如何”方面，即具体的实施路径、执行技巧与方法。比如在活动推广中，如何在设计和文案中更好地呈现主题，使其清晰易懂，如何通过不同的渠道进行更有效的传播。这些技巧的底层逻辑是通用的，用户运营、产品策略运营也大同小异，已经形成了一些相对成熟的知识体系与方法论。
个性部分体现在Why和What，涉及对需求方向的理解和策略的选择，而这恰恰是确定如何实施的前提。
目前国内开源社区运营主要分为两类，一类是从其他领域的运营/市场转行到开源领域的，如果对how和what有一定的理解，难点在于补充why部分，需要一定的时间去调整适应what策略；另一类是从技术转行到运营的，优势在于对why理解深刻，但也需要打磨what，补充how的知识。
我属于第一种情况，虽然从事开发者和开源相关运营有五年多了，但最大的感受一直是Why、What、How，需要学习和更新的知识点非常多，不仅需要增强对产品本身、产品受众、业务的理解，还需要保持对互联网用户习惯变化的警觉，吸收其他相关领域的知识。
对“人”的理解也会制约对“需求”理解的深度。理解开发者，特别是开源开发者，是开源社区运营非常重要的基本功。涉及的维度很多，但由于时间关系，我们只谈开源的精神内核。
开源本身是一个非常丰富的概念，如果简单概括的话开源问答社区软件，我试着把它概括为三个关键词：第一是理想，是利用技术去创造的内生动力；第二是协作，尤其是开源这种协作开发的形式，它有自己的规则和理念，可以让一群陌生人一起创造；第三是真诚，虽然看起来很平凡，但也是一切的基础。开源社区的建设，就是长期信任关系的建设，没有真诚，信任就无从谈起。
社区运营的边界
当我们谈论开源社区运营的边界时，这个问题本身就关系到一方面如何理解开源社区建设，另一方面运营能解决的问题范围。我曾尝试总结出几种不成熟的观点：
社区建设是所有参与者的共同努力，其中必须包括企业本身；
技术沟通是最高效的，尤其在代码贡献者环节，项目维护主体是工程师，而不是运营。
运营更关注从1到100这个过程，运营要注重提高这个过程的效率。
最后用这张图做一个小结，开源社区的运作和开发者关系都是有趣又复杂的话题，今天讨论的只是一些局部的点，是基于有限的知识和探索，在这里抛出一些想法，感谢InfoQ DIVE提供的交流机会：）
今日推荐文章
点击观看更少错误
