登录
国产开源社群的运营，为何总是画风奇特？
在过去几年的投入和关注下，国产开源社群如雨后春笋一般冒了出来。今天，以 GPT 为首的 AI 新势力接过话题度的接力棒，我们可以在降温周期里回顾一下过去几年间冒出来的国产开源社群都有什么样的成绩，有些什么样共性的问题可以改进。
本文标题是国产开源社群的运营总是画风奇特，这也符合近几年来作为理论上开源社群的主要参与者，即软件开发者们的主流感受。从眼花缭乱的开源营销，到一次性开源、开关式开源的另类创新，再到同质化开源的内卷、打擂台……凡此种种，不仅和开发者熟悉的黑客精神驱动的开源运动有很大的出入，也很难说实现了开源政策想要的达到数字技术创新目标。
支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务。
《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》
从开源社群的建设和运营角度来看，我想造成这个局面的主要原因分成三个方面：运营人员的问题、核心团队开发人员的问题，以及根本的软件产品力问题。
运营人员的问题
运营人员的问题主要来自用面向消费者 (2C, to customer) 的小白营销思维做面向开发者 (2D, to developer) 的开源社群运营。
应当说，运营的对象从 2C 到 2D 都是面对个人，都可以认为是某种形式的用户运营：消费者是平台或终端产品的用户，而开源开发者主要是开源软件的用户。在高层次的用户运营策略上，这两者都需要围绕用户群体梳理画像、理解需求，利用资源给到用户及时反馈，使得用户投入更多时间在你的社群当中，创造你期待的价值。
不过，驱动 2C 运营的消费者产品通常具有较短的销售周期和较低的门槛，这就导致 2C 运营的最优策略是小白营销，也就是把用户当成小白，只在地域、年龄、性别和职业等属性上作区分，用快速反馈的活动来刺激用户的即时欲望，赚取平台所需的流量或者产品的出售，即冲动消费。
一个典型的例子是大街上送小礼物换关注的地推营销。例如，住宅区内新建了一家配送超市，通过雇佣一批没有任何背景要求的地推员，在人流量大的地方发传单，关注超市公众号或者下载 APP 就能领取几元的代金券或小礼物。目标人群基本也不用太作区分，能走到大街上的人都是超市的潜在用户。
这个画风是不是有点熟悉？
在开源运营概念炙手可热的时候，不少企业为自己发起的开源社群招聘的运营人员就是用同样的方式在做用户运营的。
这两个例子都引起开发者的强烈反感。
开发者不乐意见到这类活动，不是因为不能送小礼物，更不是因为运营有“原罪”，而是这些利用企业资源抢占开发者注意力的活动违反了软件开发的常识。
对于 OceanBase 点“赞”送礼的案例，star 在 GitHub 平台上被某些开发者作为选择开源软件库的辅助指标，是因为自然增长的 star 基本来自用户的主动好评和二次传播。star 并不是开发者采用一个软件的关键指标，软件已经被自己或其他人验证过了，有可复制的使用方案才是决定性的优势。star 暗示用户主动好评，是软件已被验证过的一个弱相关的参考。OceanBase 搞点“赞”送礼活动，其实也不会有大范围的影响，只是破坏了自己 star 数原本有的一点价值。
至于把任何形式的 star 增长解释为社群规模的成长，则是无稽之谈。star 背后的行为只是一个简单的点击动作，没有任何门槛。一个接过超市传单的人，不用任何培训都能成为超市的消费者。但是一个凑热闹去给代码仓库点“赞”的人，是没有任何理由做进一步地参与的。其实，由于众所周知的原因和软件开发本来的小众特点，哪怕就看增长 star 的目标，这样的推广活动甚至不会给 OceanBase 带来 1k 以上的新增 star 数。而且，以 OceanBase 的大厂背景、技术实力和生产实践，基本不需要也不太可能用刻意增长 star 的方式达成提高 awareness 的目标。
对于 TDengine 搞灭虫计划，这个问题还微妙一些。因为它看起来是跟写代码相关的，似乎也是给开源软件的发展创造了价值，这样的活动难难道不值得推广吗？OceanBase 的运营人员就觉得可以推广，也搞了一波复刻：
这些活动的问题，@Xuanwo 在《开源运营当论迹不论心》的评论代表了开源开发者的主要观点：
我们要看这个活动创造出了什么价值，而不是活动组织者的动机。
灭虫活动有价值吗？有，但是只有一点点，跟维护者需要花时间去找 typo 的代价相比，这个活动的价值可能是负的。
GSoC 等活动的项目都是实际的需求，项目都需要配备一名导师，贡献者可以获得来自导师的全程指导。通过参加 GSoC 项目，开源项目可以解决一些长期的需求，贡献者可以深入了解一个开源社区并做出自己的贡献。
我在参与 TiDB 社群的时候，曾经也发起过一个类似的低门槛工作 Tracking issue for restructure tests 来迁移现有测试到一个 IDE 集成友好的框架上。在我完成了一些关键的工具函数和接口开发之后，大部分的工作都是比较机械的翻译。
这个 issue 跟上面活动的不同点在于它来自实际的需求，开发方式符合软件工程的常识。我在第一次发现不能在 GoLand 上跑起来的时候就觉得应该优化测试框架的选型。在 @disksing 成功将 PD 的测试框架从 PingCAP fork 的 check 迁移到 testify 之后，同时也是在 TiDB 社群里我看到了两三个有同样想法的新人表达出对 IDE 集成不足的意见之后，我开始推动这项工作。
这个 issue 里 track 多个 subtask 的经验后来被传播到很多其他项目上，也在引导参与者对 TiDB 代码祛魅的过程中激发了其他的代码贡献。不过，由于 TiDB 核心代码的开发门槛依旧不低，最终我记得是没有通过这个 issue 成为 TiDB 核心开发者的例子。
TiDB 也做过 linter 相关的工作，但是开展方式是利用自动化工具，一个一个模块扫过去，而不是像 TDengine 或 OceanBase 那样，人工看到一个记一个 issue 等“外部”开发者来修，生怕解得太高效了影响数字增长。
- Make some linters really happy
- Make linter facter by enabling bazel nogo to implement fast incremental linter
对于 typo 的问题，Rust 社群有一个 typos 工具可以自动扫描、报告和修复。它在 Databend 的项目群里已被重度采用，基本可以根绝 typo 的问题。
另外，上面提到的这些工作跟前面列举的反面例子还有一个差别，就是开发者是能够认识到这些工作是 chore 即杂务的。除了在 issue 组织方式和工具框架选型开发上还有讨论的价值，开发者很少会对具体的杂务工作做营销，而反面例子当中，营销的对象就是杂务本身。难怪开发者对这样优先级倒转的营销手段很不感冒。
行文所限，还有其他存在的问题和针对这些问题的解法，本文不做展开，但是在这里做一个简单的罗列。
面向开发者的运营，在海外的行业实践相对丰富，他们创造了诸如开发者关系（Developer Relationship, DevRel）、开发者体验（Developer Experience, DX）和社群布道师（Community Evangelist）这样的概念和职位。
这方面值得参考的文字和富文本材料有：
- 《社群运营的艺术》
- 《People Powered》
- 上面两本书的作者，前 Ubuntu 社群经理 Jono Bacon 的 YouTube 频道
- 《开发者关系：方法与实践》
- Developer Experience at Vercel
其中，《开发者关系》是最符合运营人员背景的首选读物，它会讨论开发者用户群体的画像、细分和旅程，也会讨论如何在企业中制定和成功落实开发者关系战略。
不同于国内开源运营的招聘需求一锅端，分工完善的开源社群团队大致由以下几类角色组成：
- 社群团队的 manager 制定社群战略和增长目标。
- 运营专家策划和组织活动或比赛，负责场地和物料协调。
- 内容专家在社群策略的基础上制定内容策略并执行。
- DevRel 专家负责技术宣讲，并记录演进的参与和反馈情况，跟进高潜力的开发者，挖掘意见领袖。
除此以外，如果还能找到相应的人才，会考虑做课程开发和跟进用户场景，转化潜在商机的工作。
其中值得一提的是内容专家制定内容策略，生产和传播具体技术内容是一项非常有挑战性的工作。可以参考 StreamNative 文档工程师 Sherlock 的《英文技术文档工程师的培养与发展》。进一步地，开发课程和开发者内容的全面覆盖，可以参考 Confluent Developer 网站的设计和实现。
最后，国内开源社群运营的经验，有以下的参考材料：
值得注意的是，在销售软件产品或提供技术服务的企业当中做开源社群运营的从业者，很容易模糊 2B (to business) 和 2D 的区别。这些文章里讨论如何跟用户开发者打交道，如何生产高质量的内容的部分是值得参考的，对于 2B 和 2D 的认识问题，建议加上《开发者关系》第 8 章做对比理解。
开发人员的问题
通常所说的开源社群是围绕一个特定的开源软件形成的社群。软件不是一成不变的，而是响应需求不断迭代的。主导和完成这个迭代过程的成员是开发者。因此，开发者是开源社群的主要参与人群，也是核心生产力。
企业发起的国产开源社群，开发人员导致的运营变形的问题，起因几乎都是缺乏开源战略和理论指导下被迫突然开源的应激反应。
很多企业决定开源某个内部系统，实际上只是一个跟风行为，没有开源战略，也没有开源经验：开放源代码本身就是目的。
这个时候，作为工作在这个系统上的一线研发人员或是基层研发主管，突然被告知自己每天打交道、提交变更的代码仓库要开源了，下意识的自我保护策略就是 Open Source Code Only - 开放源代码就是源代码用开源协议公开发布？点击发布……好，完事啦！至于研发计划和开发流程，这跟开放源代码有什么关系？我不是已经开源好了吗，这些照旧就可以了。
于是，企业开源出来的是一个内部系统的代码仓库镜像。这其实也无可厚非，毕竟源代码只要是完整的，开放给所有人阅读就是一种社会贡献，没有说法是必须让企业完全公开软件研发的流程和设计讨论内容。
但是，企业对外宣传甚至决策者心里实际预期的效果，并不是单纯地开放源代码，他们要的是“共建”。虽然我在《共建的神话》里已经批评过这一说法的模糊性和异想天开，但是我们暂且从字面意思，以开源社群常见的协同方式来理解实现“共建”的要求。
马上，你会发现共享工作流是必须的。如果没有统一的开发流程，至少是主线流程，那么即使是资深的开发者，缺少必要的信息和充分的讨论，也无法更进一步参与。我在《企业如何实践开源协同》开篇就提过这个观点，并以 OceanBase、Apache InLong、TiDB 和 Taichi 四个项目为案例做了详细讨论。
开源社群能够为企业带来的最大杠杆，来自有一定开发能力和使用经验的开发者，基于能够访问源码的前提，将软件在具体场景下遇到的未实现需求、兼容性问题和易用性问题做就地定制，而后将这些定制反馈到上游，以求自己能够在使用上游软件新版本的时候不再需要重复二次开发。如果是自己无法就地定制解决的问题，由于能够访问源码，开发者可以做一些基础调试，报告一个更清楚的问题。基于相同的源码和统一的开发工作流，不同组织的开发者能够在相同的上下文当中交流，共同推进问题的解决。
企业发起的开源社群，初始的开发者必然是企业的雇员。如果企业的雇员没能率先实践这种开放工作流的做法，那么企业之外的开发者就更不可能推动社群往这个方向发展。最终，社群仍然是一个只有镜像代码的死气沉沉的平台，没有任何生机。
衡量一个开源社群的上游有没有开放工作流，一个最基本的指标就是观察它是否有良好的开发环境配置体验。因为所有基于源码的开源协同，至少开发者要能够搭建起一个自己的开发环境，能够跑通基本用例和运行单元测试。否则，任何改动都是文本编辑，脑内调试，这倒不是做不到，只是门槛非常高。而且是无谓的门槛，即使有这个能力的人，也能看出来工作流的不合理，不愿意浪费这个时间去做本不用做的努力。
最后，我们深挖一下这种开发人员自我保护式的 Open Source Code Only 策略，为什么在个人发起的开源项目社群里很少出现。
直接的原因是个人开发者往往没有自己另建一套工作流的动力和精力，这些项目往往一开始就是在公共空间用通用的工具链搭建起来的。本来就没有内外两套工作流，自然是“全过程开源”。
深层次的原因，探究个人开发者为什么更加容易接受开源协同的开发方式，这是因为项目作者往往是实打实的通过开发出高质量的软件和极强的 ownership 招徕参与者的。对于能够帮助自己的开发者，项目作者通常心怀感激。对于其他开发者提交的问题和补丁，由于软件的核心功能设计和实现是自己完成的，通常项目作者能做出准确的判断，而且有足够的 credit 做决定，因此在协同过程中不会感到受制于人。
反观企业开源的情况。能够被企业选择开源出来的软件，多少还是有点实力的。在目前的研发序列晋升体系下，这些软件的第一作者基本已经高升，否则就是依靠这一成就高薪跳槽：他们是不会参与到软件的开源社群当中的。实际会被指派处理开源社群工作的员工，往往没有足够的 credit 做决策，至少在大部分研发团队完全不管开源社群的情况下，他们很难讲清楚一个开源协同的要求为什么需要其他“内部”开发者也知悉和配合改变工作方式。
因此，这些被指派的员工不管从动力上还是权力上，都只能处理最简单的事务。这就导致高水平的“外部”参与者体验到低效的协同流程，基本无法完成任何工作而离开；而“内部”开发者对不时出现的“外部”需求，又不是工单系统派过来的公司的活，却要花时间去处理，感到不胜其烦。
如果某一天企业又想起来“共建”的故事，开始给这个“开源团队”下达社群人数增长的需求，一方面是短时间内低门槛的手段只有上一节提到杂活，另一方面，不止如此，“开源团队”的人还得求着“外部”开发者来参与，以达成自己的业绩。这种既瞧不起来人贡献的内容，又被迫跪舔式服务的情形，我在很早的一篇文章《Two Hats of Developers》当中就有过讨论。
如果企业开源的项目的第一作者仍然在社群当中，那么这些问题出现的几率就和个人发起的开源项目社群一样低。
例如，前文提到的 Apache InLong 项目是腾讯捐赠的。原创作者之一张国成仍然重度参与社群开发和方向计划。他希望通过代码开源和 ASF 的影响力，把自己创作的软件带到更多用户的生产环境。同时，他也需要维护腾讯内部的 InLong 使用实例。出于这样的动机，以及他就是软件的原创作者，他能够把内外的版本发布流程做到主线统一。同样把自己的职业生涯赌在 InLong 项目上的 PMC Chair Charles 是腾讯内部 InLong 项目的主管，在极强的责任心驱使下，他能够主动的对外宣传 InLong 的设计理念和用例，并且积极发展社群的开发者。根据我对 InLong 项目的观察，基本上每隔两三个月，就有几个 qualified 的开发者被提名进 Committer 队伍。
例如，我最近带到 ASF 孵化器的 OpenDAL 项目是 DatafuseLabs 捐赠的。当然你可以认为它源头上近似于 @Xuanwo 个人的开源项目，但是它确实也是 DatafuseLabs 公司立项的项目，@Xuanwo 的主业也包括开发和维护 OpenDAL 项目。@Xuanwo 在 BeyondStorage: why we failed 一文介绍了 OpenDAL 的前世今生。在他的个人博客上，还有一系列 OpenDAL 的技术介绍和运营分享。
这里的关键点在于，开源社群的建设不只是代码开发。虽然好的软件是核心，但是社群想要建设起来，自给自足的运转，近乎需要创业的热情。对于第一作者来说，软件是他本人的作品，软件成功可以带动自己成功，同时从原创开发软件的过程里，他也得到了指明软件发展方向的权威，因此，这样的社群才能在方法论的加持下腾飞。TiDB 的崛起显然也是一个例证，且在创始人淡出核心社群，转由跟项目也没什么感情的职业经理人担任技术主管以后，开始出现各种大厂开源的典型异味。
当然，并不是说不是原创作者就只能被动等待了，只不过后继者想要通过努力得到近似原创作者的声誉更加困难，而且后继者往往也很少有动力去做这样的事情。我记得有这样做还挺成功的案例，应该算阿里巴巴集团的资深工程师们参与和逐渐继承 Flink 社群主导权。
关于开发人员应该如何参与开源社群，如何组织和建设开源社群的相关材料，首推的自然是《大教堂与集市》。其中的第二篇《大教堂与集市》和第三篇《开垦心智层》分别讨论了开源协同的方式和优势，以及开源软件的所有权和声誉问题。
此外，制造开源软件是一份很有价值的参考材料，GitHub 推出的 Open Source Guides 是几个精练的主题小册子，《开放式协作》是一本有趣的 GitHub 平台上的开源社群及其模式的综述书籍。
软件的产品力
应该说，运营人员的执行问题主要来自行业不成熟，经验尚未广为人知。在诸多好的案例和坏的案例的曝光下，我相信运营人员是能够快速找到新定位，建立起面向开发者的运营能力的。这一点其实已有苗头，也有一些开拓性的人才已经出现。
开发人员的立场问题和激励问题，企业一旦认识到开源社群的成功基本是内部创业，那么如果还决定要走开源路线，相关的资源和人才配备就不再缺失。开发者方面，在成功开源项目社群的引领和经验分享的帮助下，以开发者务实的精神，我相信也能理解建设开源社群所需要的方法论。当然，从知道到实际执行，目前看来还是一个很难跨过去的坎。
除此以外，国产开源社群要想发展，要想获得广阔的运营空间，最后最难的问题，是如何提高开源软件的产品力，或者叫开源软件的质量。
SkyWalking 的作者吴晟在《开源没有黑魔法，两年后泡沫将会破灭》的访谈里提到：
开源最核心的是要具备产品思维。在某种角度上，社区 Leader 一定要是一个非常懂技术的人。但从另外一个角度上看，社区 Leader 更重要的还是要把开源项目看作一个产品或者能够售卖的商品。
开源最忌惮的就是比拼快和性能。如果你一味地追求快，这导致的结果是，你的功能出来后，别人也可以通过某种优化，快速地追赶上来，这就会导致你丧失掉生存的空间。只有持续地保持创新，才能不断地走下去。而这个过程中，如果一味地靠 KPI 以及营销带来的数据指标指导开源项目发展，而不是回归开源项目需要解决的问题本身，这将会成为开源项目发展的灾难。
历史上很多红极一时的项目，在热闹过后留不下什么东西，其核心原因就是软件的产品力不行，也就是不能解决实际问题，甚至号称要解决的问题并不存在。
这个讨论要展开涉及到的内容太复杂，我想抛出这个问题已经达到本文的目的。我在《大厂开源之殇》的第一节“用户不买账：我要怎么用起来？”里举了一些具体的例子，可做参考。
知识星球
这篇文章起初的想法我记录在同名知识星球〖夜天之书〗。
上面讨论过程中，例如社群运营在启动阶段是需要技术地推的，这个要怎么做？社群增长进入平台期以后，如何激发存量用户的创造力和主动性？内容传播的渠道如何建设、定位和维护？对于开发者，如何识别和参与国产开源社群？对于维护者，具体的在某个主题上和特定的开发者怎么开展合作？这些话题都没有展开甚至没有出现。一方面是篇幅所限，另一方面也是文章发布需要大量的时间梳理清楚框架和去繁就简。
如果你想就开源参与和社群建设的问题做深入的交流，或者想要订阅的不成文的一线内容输出，欢迎加入我的同名知识星球《夜天之书》。
