迈向健康的生态系统 - MariaDB.org

围绕 MariaDB Server 的健康生态系统需要一个活跃的社区。大量的乐于贡献代码的人能促进新功能的快速开发，也能提高用户的采用率。用户认为贡献者社区的活力是健康的标志，这是理所当然的。因此，如同“每日锻炼和良好饮食习惯”一样的预防性保健，是 MariaDB 基金会日程上的重要事项。

但在实践中，改善 MariaDB 在代码开发方面的习惯就像改善个人生活习惯一样困难，尤其是在受到公众监督的情况下。在此，我想分享一些关于我们进展的看法，并征求一些意见。

背景：开放性、亚马逊和 MariaDB plc

首先，MariaDB 基金会将开放性作为我们使命宣言中的三个关键价值观之一。它也是一个普遍接受的价值观，原则上让所有致力于 MariaDB Server 的人朝着同一个方向努力。这是件好事，但开放性也是一个含糊的词，人们对其赋予了不同的含义。

其次，亚马逊 AWS 是 MariaDB 开发者生态系统中备受赞赏的新来者。好的，“新来者”是一个相对概念，因为 AWS 已经积极贡献了一年多——正如我们的首席贡献官 Andrew Hutchings 的季度概述所证明的那样。

第三，MariaDB plc 仍然是最大的代码贡献者，无论是从提交次数、代码行数还是提交者数量来看。过去五年提交给 MariaDB Server 的代码中，超过 90% 来自 MariaDB plc，这些贡献者通常在该项目工作了十多年。

不同的期望

情境设定：MariaDB 基金会正在维护一个拥有众多代码贡献者的生态系统。一个主要参与者 (MariaDB plc) 原则上支持开放性，但其工作实践建立在 GitHub 出现之前；而另一个主要参与者 (亚马逊 AWS) 原则上了解该项目旧习惯的深厚根源，但期望能迅速朝着以 GitHub 为中心的现代化开源最佳实践迈进。

好的一面是，我在这里没有看到利益冲突，只是期望不同。

MariaDB 基金会的角色

MariaDB 基金会掌握着 MariaDB Server 代码仓库的钥匙，并为社区制定参与规则。然而，我们只有十个人，并且在代码库中没有足够的专业知识来审查和合并所有贡献，这需要 MariaDB plc 员工的帮助。这意味着我们更像是调解者和教练，而不是管理者或裁判。

作为 MariaDB 基金会的首席执行官，我正努力代表贡献者的利益，与 MariaDB plc 内部的两种合作方沟通。简单来说，就是管理者和开发者。我正努力说服管理者分配资源并建立对贡献者友好的实践，同时我也努力让开发者更容易且更愿意与贡献者合作。

贡献者的期望

贡献者们，不只是亚马逊的，都期望能够使用 GitHub pull requests 进行工作。他们期望及时得到审查，并且在 Pull Request 层面有充分的记录。他们也期望能够通过审查其他人的代码来提供帮助。他们期望 Buildbot 构建树是绿色的，这意味着代码库在任何平台上都没有构建相关的 bug，而不仅仅是他们自己开发的平台。他们希望在代码库中得到认可，也就是说，贡献者编写的代码能够归功于他们。

总的来说，来自 MariaDB plc 外部的代码贡献者期望得到与 MariaDB plc 内部代码贡献者相似的待遇。

因此，MariaDB 基金会与这些贡献者的期望是一致的。这些期望是合理的。

审查者的期望

审查者们有着略微不同的期望，但这些期望也是合理的。他们希望流程高效，开销小。历史上，他们直接将代码提交到开发分支，在某些情况下，提交甚至在没有经过任何审查的情况下就被接受了。他们乐于看到 Pull Requests 的使用，只要它们不是强制性的。他们也期望 Buildbot 构建树是绿色的，但有时他们可能会将代码推送到非绿色的分支上。他们乐于审查代码，但也有自己的开发截止日期，这是由他们的经理设定的。而且在审查过程中，他们可能会发现 Pull Request 的一部分才能被合并，这给正确的代码归属带来了问题。

总的来说，长期担任审查者的人对开发文化和流程有自己的主张。是否使用 pull requests 的选择权在于他们。我们可以以耐心和理解的方式鼓励他们，通过展示社区审查的价值以及自动合并等技术优势。

MariaDB 基金会的期望

我们 MariaDB 基金会处于中间位置。

总的来说，为 MariaDB 基金会工作的审查者们乐于使用与外部贡献者完全相同的流程，因为我们认为让这些流程尽可能高效很有价值。我们乐于“自尝狗粮”（即内部先使用自己的产品），因为我们有动力确保它对我们自己来说足够美味。

总结一下：我们想要贡献者，并且我们希望使对 MariaDB Server 的贡献既有意义又容易。

请原谅我的傲慢，但 MariaDB 是不同的

与此同时，我们对审查者一方的一些保守主义有相当的理解。

让我这样说吧：MariaDB Server 是互联网和整个 IT 世界基础设施的核心部分。

像许多 IT 基础设施的核心部分一样，我们很难找到愿意在预发布阶段协助测试我们服务器的人，在这个阶段可以检测并纠正潜在的缺陷，以免它们最终进入生产环境。

像 PostgreSQL 一样，MariaDB 可以与诸如 Linux 内核或 gcc 相媲美。它不应该与 Angular、Vue 或 React，也不应该与任何进行每周发布并随意放弃功能的“年轻”开源项目相提并论。

向后兼容性对 MariaDB Server 至关重要，而且这并非理所当然。有些系统在升级时几乎总是会崩溃；我们为避免此类问题而感到自豪。

这意味着我们接受不良代码的成本要高得多，远超一个不太基础的项目。我们必须选择合适的榜样。

寻找平衡

请注意，我们已经采取了一些措施来满足“现代”贡献者的期望。我们确实接受 Pull Requests（即使它们不是强制性的）。Pull requests 也是 MariaDB plc 内部许多用户选择的方法（但不是所有）。审查意见是公开留下的（即使有时在 commit messages 中，而不是在 Pull Requests 中）。我们使用 Buildbot 进行 CI（即使构建树并非总是绿色的）。

诚然，我们并未完全依赖 GitHub，因为我们的功能和 bug 跟踪是在 Jira 上进行的。诚然，有些审查是面对面、通过电话或屏幕共享进行的——在某些情况下，评论并未被持久保存并对所有人可见。

但我们正在采取进一步的措施

首先，我们正努力清理红色的 Buildbot 构建树使其变绿，并建立确保其保持绿色的流程。这应该会简化所有人的工作，并随着时间推移实现诸如根据在 GitHub 中定义的设置自动合并已通过审查的代码等功能。

其次，我们已设定目标，要使 commit messages 更具描述性。这应该有助于所有个人贡献者相互学习。

第三，我们正在研究流程，以便拥有中级审查者，他们负责提供建议，而不是在提交时做出“最终判决”。随着时间的推移，这将增加完整的审查者队伍。

最佳实践是双向的。这些实践既要对老成员有利，也要对新贡献者有利。MariaDB Server 不是一般的开源项目，因此制定这些实践需要时间。但我们正在努力。

魔鬼藏在细节里

以上所述意味着我们必须审慎行事。除此之外，还有一些特殊性和细节问题。

最棘手的细节在于代码归属。我提到过，一个 PR 可能包含可合并的部分和尚未准备好合并的部分。在将 PR 分割成块时，贡献者愿意给予审查者多大的自由度？如果审查者可以将一个优秀贡献者 PR 中的一部分代码拿来并在自己的 PR（或提交）中使用，那么仅仅以 GitHub 上“共同作者”标签的形式进行归属是否可以？

另外，审查者进行的修改应该如何处理？是否应该先接受 PR（不包含审查者修改），然后再进行一次包含审查者修改的推送？是否应该将审查者修改直接整合到原始 PR 中，但这会使得代码的归属有些模糊不清？或者审查者是否应该将 PR 退回给贡献者并附带审查意见，直到贡献者将 PR 修改到可以直接推送的状态？在这里，快速进展与代码归属之间存在矛盾。

如果在中间阶段也要求代码始终保持绿色（即构建通过），这可能会使事情变得更加复杂。