刷 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（開發價值）

開發價值是綜合了開發當量和代碼調用關係的綜合指數。爲便於理解，咱們以百分比的形式計算該指數，能夠直觀理解爲貢獻比例。
其中調用關係反映代碼間相互依賴的關係，包括函數的調用、類的繼承、接口的調用等。代碼並不是線性的表達，而是基於依賴關係構成的圖，越多代碼直接或間接地依賴於某段代碼，那麼該代碼的影響力就越高；也意味着，若是該段代碼做出修改，迴歸測試的範圍相應越大；一般來講，這類代碼修改的成本和重要性也越高。

---

相關閱讀：

• 查看完整榜單可訪問 https://ranking.merico.build/oss-orgs/ ，背後的數據和分析工具來自這個項目 https://github.com/merico-dev/build
• Linux 內核維護者批華爲開發者刷 KPI
• 知乎：華爲 Linux 內核貢獻者被質疑刷 KPI，真實狀況是怎樣的？有哪些信息值得關注？