Community of Peers
Community of Peers 可以翻译成『同侪社群』，意即社群由地位相同的成员组成，这是 Apache 软件基金会（ASF）的开源理念之一。
ASF 强调个体组成社群，每个成员代表他们自己而不是其所属的组织。不管成员是否受雇参与贡献，社群视角下他们都是一视同仁的志愿者。尽管只有 Committer 才有合并代码的权限，只有项目管理委员会（PMC）成员才能对项目的关键决议投有效票，但是除此以外，成员内部是真正平等的。ASF 的开源项目不存在『仁慈的独裁者』，项目管理委员会主席（PMC Chair）也只是承担代表项目向董事会报告的职责，而不意味着其他独特的权限。
这样的理念非常符合传统文化所推崇的『和而不同』与『周而不比』。理解这一点，能够帮助我们在参与认同『同侪社群』理念的开源社群的时候如鱼得水；相反，如果一味追求『和光同尘』，或者把等级观念带到这些社群当中，则容易寸步难行。
和而不同
Apache SkyWalking 的第一个例子说明了社群成员之间意见不同是一种常态。
@darknesstm 提出希望在 SkyWalking 的服务端增加过滤功能以忽略部分应用上报的数据。项目作者 @wu-sheng 认为这是客户端应该处理的问题，如果服务端无法信任客户端上报的数据，而必须要自己再做一次过滤，这会浪费服务端的计算资源。@darknesstm 进一步说明在他的企业场景中，维护服务端的团队和编写客户端逻辑的团队是分开的，他只能在他的职责范围内解决问题。
这其实是企业二次开发开源软件“微创新”的一个典型案例：通过把业务团队无力解决或不想解决的问题下推到基础设施软件，定制功能后就号称自己比上游解决了更多“痛点”。这里我不做展开讨论，只说这样的修改往往很难成功推进上游。
开源协议允许任何人对软件做出修改，并分发修改之后的软件，这使得大规模的开源协同成为可能。Linux 是开源历史上独一无二的大型项目，首创作者 Linus 几近凭一己之力，在三十年间持续协调了超过一万名开发者百万个以上的提交。Apache Hadoop 和 Kubernetes 这两个各自开启一个时代的软件，都有多家公司的复数开发者参与共建，并能积极适应不同企业和用户多样的需求。凡此种种，无不在昭示这一个美好的开源世界：社群成员愉快地协同开发出一个满足各方需求的软件。
然而，实际情况是，所有需求的最大公因数是极小的。同侪社群是和而不同而非和光同尘，你的意见与其他人平等，就意味着其他人对你的观点的反对意见也是平等的。这些反对意见，往往也只是出于项目本身的定位和技术考量，开发者在理解软件发展到今天做出的假设和取舍的基础上做出的判断。
如果你发现对方误解了你的意思，那么你可以进行解释澄清；如果对方提出的建议你也可以接受，那么可以做出折衷。否则，ASF 项目社群没有仁慈的独裁者意味着可以投票解决争端。唯一不需要的，就是投入大量时间和心力说服一个只是意见相左的人。
换个角度看，为什么 @wu-sheng 的意见很大程度上能影响乃至决定社群最后的整体意见呢？这是因为他是 SkyWalking 项目的第一作者，前面提到的“软件发展到今天做出的假设和取舍”，许多决定就是他做的。根据 ASF 开源理念的另一条 Earned Authority 即赢得的权威，个人对项目发展的影响力取决于他为项目做出了多少公开的贡献。这种权威没有直接为投票带来加权，但是它在社群当中深刻影响了每一位成员对项目定位和什么该做、什么不该做的判断。
如果确实无法达成一致，开源协议赋予任何人 hard fork 的权力。StarRocks 团队的商业考量和 Apache Doris 社群的其他成员无法达成一致，选择了硬分支；Apache Doris 初始代码重度基于 Apache Impala 项目，但是也没有选择在上游开发；Trino 团队和 Facebook 的 PrestoDB 团队运营理念不合，选择了硬分支。ASF 的开源理念强化了公平的概念，要求 ASF 项目的社群必须基于平等的个人形成的集体决议运作，而开源协议本身保留了最基础的公平：任何人都有 hard fork 的权力。
和而不同是开源协同的主流模式。这里无法要求所有人达成一致，而是由贡献组成的生产力决定健康的项目能够存续。对于习惯了内定、全票通过的新成员来说，这是需要转变的一个观念。
周而不比
第二个例子是口述的例子。某位开发者在成为某项目 Committer 以后，被另一位项目 PMC member 建议承担下次版本发布的职责。他虽然心里不愿意，但还是接下了这个任务。一个周末的辛苦过后，新的版本成功发布，但是他就觉得是这位 PMC member 赶着他去做本不想做的工作。
这个例子分享出来以后，包括我在内的几个长期参与开源社群的人都深感不解。在了解清楚这位 PMC member 的措辞是 would you mind... 之后，我分享了自己上周建议 Apache Curator 的新 PMC member 进行下次发版的案例。
在这个案例里，我询问这位新晋的 PMC member 是否愿意主导下次发版，并给出了需要了解的发版流程指南。这是因为他最近正活跃，且新版本将会包含若干个他贡献的补丁。
对我来说，推动新人主持发版，虽然有一定的躺平成分在，但是主要还是出于主导版本发布是项目发展的重要工作之一，有机会让新人上手就尽量指导避免 release manager 日渐成为单点。另一位参与过多次版本发布的朋友补充到：“这种就是一般问问，你真做起来，其实他指导你，比自己做都麻烦”。
事后，我仔细想了想为什么一开始的那位新 Committer 会认为自己是被赶着做版本发布的工作，其中最有可能的原因，还是在老板 vs 员工的模式下工作久了，下意识觉得这是在给自己派活儿。
《论语》中说『周而不比』，指的是以公正之心对待众人，没有预定的成见及私心，不徇私护短。健康的开源项目，其参与者也是如此。我们不应该假设其他人就是非要为难自己，套用办公室政治那一套“新人”“老人”的逻辑，而应该以项目的发展和问题解决为出发点，量力而行尽一份力。
如果觉得其他人做得不合适，在 ASF 项目里可以发送邮件到 private 列表里讨论，在 PostgreSQL 等项目里可以寻求 Moderation Team 的帮助。其他项目，至少可以和对方一对一的沟通。这类对人的指控，开源社群的普遍实践是先尝试私下调解，避免激发和扩大纷争，甚至最后骑虎难下。实际上，很多时候，情况是像这里提到的例子一样，文化差异或者措辞问题所导致的误会。