# 2022-13: 开源运营当论迹不论心 最近跟不少朋友讨论 [TDengine](https://github.com/taosdata/TDengine) 开源社区运营中的一些失误，详见[参与 TDengine 代码灭虫计划，快速融入开发者社区](http://web.archive.org/web/20220403062947/https://mp.weixin.qq.com/s/mssWF5AoUG-vt-b5_QMtRA)(*微信公众号原文已删除，此处使用 Web Archive 替代*)。这个活动已经组织很久了，[phodal](https://github.com/phodal) 早在 21 年 10 月就把这个活动列入了 [开发者体验反模式：市场主导运营](https://dx.phodal.com/docs/anti-patterns/marketing-drive-developement.html) 的列表中。 现在旧事重提是为了纠正舆论场上一些错误的认识，并提出我的看法。 ## 灭虫活动没那么离谱 因为活动原文中一些不太谨慎的描述： > 每周初，我们都有 5～8 个小“虫”的放出 不少同学把这个活动理解成维护者主动在代码中写入 bug，然后交给社区修复。实情并非如此，taosdata 没有做这么离谱的事情。 根据 [TDengine good first issues](https://github.com/taosdata/TDengine/issues?q=label%3A%22good+first+issue%22+) 来看，这个活动的实际情况是维护者在项目中找到一些简单，容易修复的 BUG，并给出具体的指导，并交给社区修复。以 [Local variable loopCont is assigned only once...](https://github.com/taosdata/TDengine/issues/9128) 为例，维护者给出了具体的代码位置，解释了原因，并且说明了应当如何修复。 ## 灭虫活动的错误不在于动机 灭虫活动的错误不在于动机不纯。首先动机不纯不是什么可耻的事情，其次批评动机不纯无助于社区的改进和开发者体验的提升。 我在这个活动中看到的问题是这些： ### 为什么会出现这些 BUG？ 我简单地看了一下 TDengine 的 good first issue 列表，发现绝大多数问题都是简单的 `UNUSED_VALUE` 和 `STRING_OVERFLOW` 等。 是否有更好的解决方案呢？ - C/CPP 社区有没有 check/lint 工具可以自动检查，甚至自动修复这些错误？（我对 CPP 社区不了解，这种工具有吗？） - 在 PR 的时候是否有自动化的检查以避免不符合要求的代码被合入？ TDengine 没有配置 Github Actions，只有 Circle CI 的配置文件。从源码上看，Circle CI 也没有启用，只有一个简单的 welcome。自动的检查只出现在 PR merge 的时候有一个内部的 jenkins：[continuous-integration/jenkins/pr-merge](http://ci.bl.taosdata.com:8080/job/NewTest/job/PR-11242/1/display/redirect)，外部帐户无法访问（不过看起来是开放注册的，不知道是安全漏洞还是预期的，为啥不搞一个 Github 登陆呢？而且只提供 HTTP 访问- -） 有理由相信在 TDengine 完善 CI/CD 这些基础设施工作之后，这些简单的 BUG 能够在 PR 的阶段就消除，不需要所谓的灭虫活动。 ### 不尊重开源社区规律 对任何一家开源公司来说，贡献者数量都是一个重要的指标。众人拾柴火焰高，社区壮大了才有可能做更多的事情，触达更多的场景。但是公司需要想办法提升自己社区的吸引力，而不是通过市场运营手段强行把开发者推进来。 提升社区吸引力的手段包括但不限于 - 解决实际问题：这是最核心的手段，只有你的项目能够解决开发者的问题，开发者才会持续参与到贡献中来。 - 完善的文档手册：完善的文档能够降低开发者加入的门槛，从易用的 Get Started 到详细的设计文档。 - 良好的 RFC 流程：开发者能够清楚的知道社区目前的前进方向以及方式，从而能够自己发现可以参与贡献的地方。 - 优秀的开发体验：开发者能够获取快速的反馈，跟项目的维护者高效沟通，PR 的自动化测试能够提前检查出绝大多数简单的问题。 把简单的 typo 转化为 Issue 对社区吸引力是毫无贡献的，在短期的喧闹之后，社区只得到了一地鸡毛，因为阻碍开发者参与贡献的因素从来都不是 Issue 太难了。相反，贡献者往往能提出比维护者更具有创造性的方案，问题在于我们的社区是否具有足够的价值以吸引贡献者参与。 ## 灭虫活动与 GSoC 的区别 那灭虫活动和 GSoC，CommunityBridge 等项目的区别和界限在哪里呢？同样是找 Issue 出来给开发者，GSoC 等项目甚至会直接发钱，不少开发者就是冲着奖学金参与进来的，从某种意义上看动机更加不纯粹。为什么灭虫活动人人喊打，而 GSoC 大家却喜闻乐见呢？这就是我今天想说的开源运营应当论迹不论心：我们要看这个活动创造出了什么价值，而不是活动组织者的动机。 灭虫活动有价值吗？有，但是只有一点点，跟维护者需要花时间去找 typo 的代价相比，这个活动的价值可能是负的。 回到 TDengine 项目的核心价值来看： `High-Performance, Scalable Time-Series Database with SQL support`：灭虫活动对这个价值有贡献吗？灭虫活动中的 Issue 有解决实际的问题吗？引导开发者学会使用 Github 是这个项目的核心目标吗？我看这些问题都是否定的：开发者可以通过 [first-contributions](https://github.com/firstcontributions/first-contributions) 更快更好的掌握 Github 的使用。 GSoC 等活动的价值呢？ 活动中的项目都是实际的需求，项目都需要配备一名导师，贡献者可以获得来自导师的全程指导。通过参加 GSoC 项目，开源项目可以解决一些长期的需求，贡献者可以深入了解一个开源社区并做出自己的贡献。我就是 CNCF Community Bridge 计划的受益者，通过参与 TiKV 的暑期项目，我成为了 TiKV 的 reviewer 并且最终决定彻底投身于开源项目的行列。 ## 总结 参与开源是一个大趋势，大家都在经历一个学习的过程，运营的过程中出批漏是一件非常正常的事情。即使是 PingCAP 的社区内也有着大量的反模式，TiDB/TiKV 的 CI 是我一直在批评和吐槽的点。一方面，开源社区要积极参与开源治理，听取大家的反馈，改进运营操作，反思运营思路；另一方面，评价运营中出现的问题要坚持论迹不论心的策略，不要把具体的运营问题上升到抽象的开源精神。 动机无法证实也无法证伪：讨论某个活动是否只是为了完成开发者数量的 KPI 无助于开发者体验的改进，但是讨论具体的运营问题能够让更多的有志于开源社区的项目和个人了解到这样做是不好的，从而减少这种低效运营操作的出现。更何况，动机不纯从来就不是什么丢人的事情：开源机制的优秀正体现在它能够把有各自诉求的开发者力量凝聚到一起从而创造更大的价值。 > [@tison](https://github.com/tisonkun) 一直倡议开发者在开源运营领域发出自己的声音，我也鼓励大家多聊聊自己的看法和观点。大家所处的位置和思考的角度不同，得出的结论也各不相同。只有参与讨论的角度足够多样化，我们才能够得到更好的开源运营实践～ （当然，要是 TDengine 也来参与讨论而不是删除微信公众号文章就更好了） ## 参考资料 - [参与 TDengine 代码灭虫计划，快速融入开发者社区](http://web.archive.org/web/20220403062947/https://mp.weixin.qq.com/s/mssWF5AoUG-vt-b5_QMtRA) - [开发者体验反模式：市场主导运营](https://dx.phodal.com/docs/anti-patterns/marketing-drive-developement.html)