刷 KPI or 真实贡献？如何客观评价华为对 Linux kernel 的贡献情况？

最近，Linux 邮件列表出现了一封名为《Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk)》的邮件。Linux 内核维护者 Qu Wenruo 在邮件中指出，华为开发者提交的补丁有刷 KPI 的嫌疑，在社区引发热议，详见：《Linux 内核维护者批华为开发者刷 KPI》。

后续，华为 Linux 内核贡献者 Leizhen 在邮件列表对此事作出了回复。他在邮件中提到自己过去对内核的主要贡献是优化 Arm64 SMMU 驱动的性能，包括 iova 优化、严格模式优化以及懒模式优化，此外还曾参与 Arm SoC 驱动的开发。而在时间和精力允许的情况下，他也为 Linux 内核的其他模块进行贡献，尝试找到可以改进的地方，在此期间他做了一些“清理”工作。最后，Leizhen 表示未来将继续为 Linux 社区做出越来越重要的贡献。

原始邮件的发布者 Qu Wenruo 也很快回复了 Leizhen。他对 Leizhen 过去对 Linux 内核做出的重要贡献表达了认可，同时表明了对“清理”工作的态度——并非不重要，但请将这些细小的修复合并成一个更大的 patch 再进行提交，毕竟 maintainer 的审核工作非常繁忙，不要让他们将时间浪费在这些无关紧要的问题上。最后，Qu Wenruo 列举了一些对 Linux 内核社区有意义的尚待完成的贡献工作。

根据 2020 年 12 月发布的 Linux 内核 5.10 开发统计数据，华为向 Linux Kernel 5.10 提交的补丁数量排名第一，修改代码行数排名第二，仅次于 Intel。

那么华为在 Linux kernel 的贡献到底是刷 KPI 还是真实的？该如何客观评价华为对 Linux kernel 的贡献情况？

如何客观评价华为对 Linux kernel 的贡献情况？

如果按照提交次数来统计贡献情况，华为的贡献仅次于个体开发者（gmail.com 和 kernel.org邮箱后缀），位列全球科技公司之首。

如果我们想屏蔽掉邮件中指出“刷 KPI”的情况，则还有另外两种排名方式 —— 按照开发当量（代码逻辑复杂度指标）或影响力排名，又会得到新的结果。

如果我们按开发当量 ELOC 计算，通过程序分析在代码层面分析工作量，并屏蔽空行、死代码等噪音，那么华为的排名会掉到十名左右，如下表所示。排在前三名的科技公司是 Intel、AMD 和 NVIDIA。

如果我们把代码间的依赖关系也算进来，则综合影响力排序如下：

我们可以看到华为依然排在十名左右，与 Google、微软等公司相近。

从提交数这种浅层指标，到 ELOC 或 Impact 这类深度指标，华为的贡献排名有所不同，可见程序分析能为贡献的度量提供新鲜的视角和信息，评价一位开发者在项目中的贡献，不能仅看提交数，还有 ELOC、Impact 等指标，它们更能反映开发者在项目中的贡献情况，降低不同的开发习惯对度量准确性造成的影响。

当然即便按照更科学的评价指标，华为仍然排在全球科技公司的前十，是国内公司做出贡献最多的。从这个层面来说，虽然我们更鼓励核心贡献，但也不能一刀切认为华为的“第一”是刷 KPI 所得。

最后，我们希望告诉初学者或者刚刚参与开源的朋友“勿以善小而不为”，初学者不必过分在意贡献是否足够核心，开始贡献大于一切，哪怕只是修改几个错别字一样值得点赞。

相关名词解释

关于 ELOC（开发当量）

开发当量是对程序员代码产出的一种合理量化和测量。与代码行数、提交数等浅层统计指标相比，开发当量的优势体现在两个方面：一是不易受到编程习惯或特定代码行为的干扰（如换行、空行、注释、括号等），并且能更好地反映代码开发所涉及的逻辑量。
具体来说，开发当量计算抽象语法树的复杂度。我们既可以计算开发当量的绝对值，也可以计算开发当量的累积值。软件开发是一个动态的过程，代码随着提交发生变化，相应的抽象语法树也会演变。
开发当量的绝对值，可以理解为对代码在一个提交切面上的抽象语法树进行计算，会考虑抽象语法树的高度、节点数、不同节点的权重等。开发当量的绝对值随着开发过程而上下浮动，通常呈现“持续增加—小幅回落”的模式并不断反复。
开发当量的累积值，则是对代码在各个提交前后变化的计算，基于每个提交前后的抽象语法树之间的最小编辑距离累加，其中代码删减也被视为贡献，只是权重会显著低于代码增加。开发当量的累积值是一个单调递增的变量，主要用于反映团队或项目的产出和进度。

关于 Impact（开发价值）

开发价值是综合了开发当量和代码调用关系的综合指数。为便于理解，我们以百分比的形式计算该指数，可以直观理解为贡献比例。
其中调用关系反映代码间相互依赖的关系，包括函数的调用、类的继承、接口的调用等。代码并非线性的表达，而是基于依赖关系构成的图，越多代码直接或间接地依赖于某段代码，那么该代码的影响力就越高；也意味着，如果该段代码作出修改，回归测试的范围相应越大；通常来说，这类代码修改的成本和重要性也越高。

相关阅读：