编辑导语：开源社区是指面向开发者和企业或者在开发者之间形成的社区。那么，开源社区能带来哪些利益？开源社区又需要消耗什么资源？本篇文章中作者分享了对于开源社区运营的经验，一起来看看吧。

一、什么是开源社区？

相较于C端消费者社区，比如团购社区、读书社区、运动社区，B端社区露脸的机会本就不多，开源社区由于其技术门槛和其以技术开发者为核心的组成结构就更是小众的存在，开源社区运营相应也少一些。

所以在分享开源社区运营经验之前，有必要先对「开源社区」进行一些基础扫盲。

什么是开源社区？

简单来说就是围绕某项技术/产品需求，开发者和企业及开发者之间相互产生内容互动的平台。

常见的开源社区包括：

1）主张多元化内容分享的媒体类开发展社区，如CSDN、InfoQ、51CTO、掘金等社区，不局限于某一项技术/产品讨论。

2）提供开放源代码托管服务及资源的开源基金会，如Linux 基金、Apache 软件基金会，以及本土的 Gitee、木兰协议、开放原子开源基金会也逐渐发展起来。

3）互联网、软件、IT制造等企业自建的开发者社区比如腾讯云的云+社区、阿里云的云栖社区和华为开发者社区。

一般我们在招聘市场上看到的开源社区运营或者开发者生态运营，都是基于第三种社区存在的，因为企业赚钱的动力是最强的，也是最需要维护开发者关系的。

二、运营开源社区的价值

围绕开源技术/产品，技术开发者们天然形成了社区。CSDN发布的《2020-2021中国开发者调查报告》显示，超过九成的开发者使用过开源软件，三成左右的开发者参与了开源项目，35%的人群愿意付费学习，但与此同时，77%的受访者表示未曾从开源项目上获得过收入。

花时间花钱，但大部分人却没有因此获得物质收入。

？？？三个问号，油然升起。

作为趋利避害的动物，人不会干亏本的买卖，尤其是聪明的开发者们。

实际上，开源社区对于开发者们来说好处多多，比如

1）直接和社区专家对话，获取免费的专业回复，以解决实际应用问题；

2）在社区给其他开发者答疑帮助，获得情感满足和社区认同；

3）被社区官方授予证书等荣誉，让简历更好看，方便以后找工作；

4）在社区成为技术KOC之后，可以被推荐到大会分享，进行课程输出，形成自己的代表作；

5）认识并和不同行业的开发者进行交流，收获知识以及合作机会；

6）预算充足的社区对于contributor还会进行丰厚的物质奖励，比如MacBook Pro等奖品或者直接予以现金激励。

对于开源社区的另一边——企业而言，或许一开始也有情怀，想要推动行业技术发展，有改变世界的梦想，但真正落地下来，核心仍旧是为了卖货赚钱。

开源社区也是企业商业化的手段之一，通过用户、内容和活动运营，加强用户对企业及其产品的了解和信任，实现商机线索的获取与孵化。

开源产品的社区用户，在产生购买意向之前，往往已经了解甚至使用过社区版本，对产品价值有了非常深刻的理解，无需销售人员从头开始冷启动。简言之，运营开源社区能够有效缩短销售周期，加速企业产品商业化。

具体来说，开源社区可以从以下方面加快企业技术/产品的商业化，提升经营效率。

1）用户反馈反哺产品迭代，完善技术文档等，打造更加坚实的产品价值。相较于闭源模式的闷头开发与摸索，开源开发模式最大的优势就在于群众的力量能够帮助技术产品更好更快的试错迭代，快速验证PMF（Product Market Fit），同时在丰富性上也有更好的保障。

2）通过内容传播和活动运营盘活社区，给企业带来第一批种子用户，为后续的产品推广、品牌传播打下良好的用户基础。一个健康活跃的社区，完全可以自运营，甚至因为有了共同的理念和目标，自觉维护和共创社区生态。

有一件发生在社区里的小事，让我至今难忘：社区混入了竞争对手，在社区攻击我们的产品，官方还没有来得及说话，已经有不少开发者在自觉辩护，维护我们。那一天，真的有种“平时累死累活，终于有收成了”的感觉。

3）挖掘商机线索，完成技术产品的市场教育，促成意向客户的合作。关于开源和商业的矛盾之争一直存在，但开源≠无钱可赚。这里就不过多展开，以后有机会再说。

三、开源社区通用价值指标

前面已经说了开源社区对于企业产品商业化的意义，但由于B端业务尤其是技术类产品本身具有决策周期长、销售转化低等特点，所以通常来说社区运营不会直接考核商机数量或者客户交易金额，而是以社区规模、社区活跃度、社区健康度作为指标。

就我自己所运营的社区，考核指标在不同阶段也会有所区分。

第一阶段，产品刚上线，初级版本只具备基础功能，更多考虑可用性而非易用性。这时候其实最需要的是活跃开发者的使用反馈，从而帮助技术团队更好的迭代产品。社区的价值在于让开发者感受到自己的需求和问题是被快速响应的，从而愿意在社区提出自己的问题甚至是解决方案。

活跃度而非规模成为了社区的主要考核指标。因为这个时候盲目进行社区规模的增长，当大量用户涌入却没有足够强大的产品进行支撑的时候，反而会破坏产品口碑，导致后续增长拉胯。

但活跃度不是一个明确的数据指标，需要往下拆解到更加具体的可以被观测的行动数据，比如每周提问次数，为社群其他成员答疑，参加官方活动，提交issue和PR等动作。对开发者不同动作的投入成本进行分数化，比如提问就是1分，为他人答疑3分，提PR可能就是20分。活跃度可以结合开发者在一个项目上不同的生命周期，取平均值，再定义自己的社区开发者活跃度是否在一个健康的可接受的区间。

比如，新用户进来很难给你提PR，资深用户则不会有那么多的问题，反而是更愿意贡献。一个新用户大概多久可以转向资深用户，官方的人力资源可以支持每周进多少新人，活跃度不够是哪个环节出了问题，新老用户在各个社群的分布比例，不同层级活跃度用户的整体数量分布……这些都要做到自己心里有数。

第二阶段，产品版本完善到一定程度，沉淀出各种技术文档，用户整体反馈不错。等于是跑通PMF，这个时候就社区考核指标就转向了社区规模。不然你几十上百人的圈子，就算活跃度高达100%，影响力也是有限的。除非刚好这个圈子里的人都是行业大佬，是影响这个行业发展的那1%。

社区规模指标如何定？

一方面是参考同类型社区。注意一定是同类型社区！就好比我是做机器学习技术社区的，就没必要去和人家关注减肥瘦身的社区比较。因为本身关注机器学习的人群就少，规模自然要小得多。

找到对标的同类型社区之后，如果发现差距太大，比如人家已经20万，你才200人，可以通过长期规划和短期目标的形式让增长策略显得更加合理和现实。大白话就是，我们也要做20万的规模出来，人家花了5年做到20万，我们通过xxx和xxx手段预计3年做到（显得咱有点水平），具体到今年，我们的目标是2万，这个季度是先做到2000。

另一方面是参考过去的增长表现。首先看看过去的增长手段都有哪些，最给力的是哪个，最突出的历史成绩达到了多少，能否复现……在了解自己几斤几两的情况下，设置一个跳一跳能达到的目标。

完全没有挑战的目标，老板也是不认的，过高的KPI，自己扛不动，做事容易泄气。

而且向上管理还容易有问题，如果你的老板懂业务，看到你不合理的目标且没有给力的增长策略，只会认为你是个盲目激进的人，如果你的老板不懂业务，看到你这个目标乐开了花，但最后却是期望越高失望越大。

第三阶段，产品以及整个项目开始进入商业化阶段，开源社区也需要服务商业化这个大目标。因而有了社区孵化商机线索数量的指标。

这里我想说的是，即使在老板没说的情况下，也需要考虑到商业化的部分。

一来是，我认为会不会主动思考自己负责的业务能为团队整体业务带来什么价值，提出想法并且能够执行，不仅是初级执行运营和资深策略运营的差异，也是区分开真正有创造力的人和那些看起来工作了十年但其实只有三年工作经验人士的关键。一开始，我们需要正确的做事，做完事，保证执行力，越走到后面越需要去做正确的事，而要做正确的事就需要主动思考和判断的能力。

二来是，运营要想长期发展下去，一定要懂商业化。不要觉得不扛商业化指标，压力小，活少轻松，长期下去，人很容易圈在自己的舒适区里废掉的。而主动靠近业务，才能成长的更快。

四、开源社区运维所需资源

前面三部分解决了「开源社区是什么」「为什么要做开源社区」「如何定义开源社区运营指标」，那……接下来就是开干了？

还得先把资源摸摸底，才能开始。总不能自己单枪匹马，一人承受了所有吧。

张一鸣认为世界是由人流、信息流、物流和资金流组成的。社区其实也是如此。我会按照上述逻辑梳理「社区健康运转的必备要素」。

1）人流：运营3名（分管内容、活动、用户）；设计师1名；工程师N名（社区技术问题答疑，完善文档，培训讲师，沙龙嘉宾，考虑到身兼多职和专职专岗的情况，人数不定）；商务N名（负责跟进需求，转化潜在商机）。

2）信息流：技术文档（产品说明、安装、部署、更新文档等）；客户案例（不同行业、不同级别的客户案例）；常见QA（常见问题集合、大咖问答等）；课程分享（自主研发的课程、沙龙分享讲义等）；干货资料（行业白皮书、方法论、工具包等）。

3）物流：社区定制周边礼品，如文化衫、徽章、帽子等；以及提前采购一些贵重礼品，如MacBook Pro等。

4）资金流：非常重要！因为小到社区活跃氛围，大到办活动、贡献者激励制度等都需要用钱，一定要把预算申请下来。

以上，丰俭由人，大家可以根据自己的情况进行适当调整为低配或者高配版本。

在明确开源社区运营的背景和价值，并且确认公司能够提供相应的资源之后，就可以着手搭建社区运营策略了。请大家期待《开源社区运营经验分享（二）：如何从0开始搭建开发者社区运营策略》。

#专栏作家#

板栗，微信公众号：南有板栗，人人都是产品经理专栏作家，2019年年度作者。专注互联网营销/运营/增长领域，擅长内容运营/社会化营销/品牌营销咨询。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议