社区重要还是代码重要？

摘要：一个好的社区一定由核心的贡献者来带领，吸引更多的贡献者和用户来参与，这样才是一个健康发展的路子。

Apache Software Foundation，简称ASF，是世界范围内知名的软件基金会。旗下有很多世界知名的开源软件，比如Apache HTTP Server、Subversion、Hadoop等。ASF在社区治理上也有自己独特的理念，其中有一条中国开源软件圈子比较熟知，就是Community Over Code，通常中文会翻译为社区大于代码。

在Apache基金会官网上可以查到对这一条的解释：The maxim "Community Over Code" is frequently reinforced throughout the Apache community, as the ASF asserts that a healthy community is a higher priority than good code. Strong communities can always rectify problems with their code, whereas an unhealthy community will likely struggle to maintain a codebase in a sustainable manner. ASF的观点认为健康的社区比好的代码更重要，强大的社区总是可以纠正代码中的问题，而不健康的社区可能会难以以可持续的方式维护代码。

中国最近这几年也有不少项目捐献给了ASF，国内的开源社区在谈论到开源治理的时候，也常常会提到ASF的社区大于代码这一理念。那么如何来理解这一理念呢？我在网上做了一些搜索，找到了ASF的董事Shane的一个分享：《The Apache Way - Effective Open Source Project Management》。在这个PPT里面Shane阐述了The Apache Way，他分享的内容比较多，我重点说一下和社区大于代码这一部分相关的内容：

他开篇就讲到，Apache Way 是 ASF 开发的一套行为和实践，聚焦于通过稳定治理和鼓励新贡献者来促进开源项目的长期成功。谈到社区这个概念，他认为社区包含了开发者、内容创作者、测试者、用户。社区是属于大家的，不属于某一个人。和社区相对立的，是Jerks，翻译过来就是混蛋。在ASF看来，社区是不能有混蛋存在的。他为此作了一些解释：

Apache社区鼓励集体的贡献，而非独狼式的贡献者；

多元化的社区才能吸引到更多的贡献者；

PMC成员组里面不允许有仁慈的独裁者；

以个体的身份而非雇员的身份参与到开源项目中；

企业是不允许参与到ASF的；

每个项目都是独立的；

每一个志愿者的权力都是相同的；

每一个人需要作出贡献来获得相应的Merit（不是很好翻译，类似于功绩、影响力）；

Merit可以带来一些权力，比如代码的提交权限、投票权等等；

做得越多，可以有更多的权力；

……

更具体的大家可以参考： https://shaneslides.com/apachecon/TheApacheWay-Intro-ApacheConNA2017.html

我尝试来总结一下，ASF的目的是希望通过一系列社区、民主、自治的游戏规则来保证某一个开源项目不被某一个人或者组织所控制，从而实现长期发展的目的。从这个角度来讲，他们所提的社区大于代码也就很容易理解了。哪怕你是这个项目最开始的发起人，但当你把代码捐献给ASF之后，你就要按照ASF的游戏规则来玩。如果你想推动一些事情来发展，你需要做各种的贡献来获得相应的权力。用一张图来表示这种模型的话，大概是这样一个倒金字塔的形状：

最基础也是最核心的是代码的核心作者，然后是代码贡献者，然后是Bug的提交者，再其次是用户。所以从这个角度来讲，确实也是社区大于代码，因为社区是在代码之上的。：）

那我们来看看ASF旗下的项目实际的运作情况如何呢？我从ASF的github仓库里面查询了几个比较有代表性的项目，来看他们的贡献者的活跃度：

Apache Kylin是第一个中国人主导的顶级项目，我还有幸参加过他们的宣讲会。自Kylin以后才陆续有中国的开源项目捐献给ASF。但从数据来看，这个项目已经基本上不更新了。排名前两位的关键提交者已经基本上不参与这个项目了。

再来看看Echarts项目，情况稍好一些，但2023年更新也明显减少了。

当然也有项目会比较活跃，比如kafka。但无一例外，都是很少数的几位关键Commiter贡献了绝大部分的代码。

最起码有几点是可以达成共识的：

即使按照Apache之道来运营，也没有办法保证项目的长久健康运营。

运营比较活跃的项目，核心的贡献也是由少数的几位贡献者完成的。

世界上也有更重量级的项目不是按照Apache之道来运作的，比如Linux。

那么我们抛开具体的场景来谈社区大于代码，就有些空泛，会让开源软件的核心作者有些无所适从。既希望核心作者努力更新代码，保证软件更新，又要遵循Apache之道来约束自己的权力。那带来的问题就是核心作者做事就会受各种约束，很难快速决策、快速行动。长久以往，核心作者的热情和动力如何保证呢？很难！Shane的分享里面也专门提到了，Apache社区里面是不允许独狼存在的，也不允许仁慈的独裁者存在。但真正让改变发生，推动历史进程的，往往就是少数关键人。

如果我们从社区形成的先后顺序来看，也许这个问题就更容易有答案。一个开源项目的缘起往往是某一个人在自己的工作过程中发现了一些问题，然后写了一些代码来解决这些问题。然后他将这些代码开源出来，形成了一个项目。然后这个项目陆续被有相同问题的用户发现，然后围绕这个项目逐渐形成了社区。社区重要不重要？重要。代码重要不重要？重要。但更重要的是核心的作者。因为只有核心的作者才能真正推动项目进展，才能保证代码的更新。持续更新的项目，才能为用户带来价值，才能形成社区。所以如果只是空泛地谈社区大于代码，就好像抛开了基础需求谈人的高层次需求一样，不切合实际。

所以我更希望把前面的倒金字塔旋转九十度，一个好的社区一定由核心的贡献者来带领，吸引更多的贡献者和用户来参与，这样才是一个健康发展的路子。然后话题就回到，如何保证核心的贡献者的持续输出呢？我的答案就是一定要做商业化的运营。大家可以看我之前公众号文章写得关于开源商业化方面系列的文章。