中國開原始碼力榜是由 SegmentFault 思否、開源社、騰源會、X-lab 實驗室共同發起的中國開源開發者榜單。
來自 X-Lab 的 OpenDigger 團隊對 GitHub 開放的歸檔日誌進行分析，篩選出了 2021 全年 GitHub 協作影響力排名前 10,000 的賬號，並號召了社群中數十位開發者及十餘家合作社群，通過開放式協作共同核實標註資訊、排除機器人賬號，並在第一階段甄選出了 99 位中國開發者。
中國開原始碼力榜釋出後得到了很多開發者的關注，非常多開發者非常關心這個排名是如何產生的，背後的演算法模型是什麼樣的？我們邀請了 OpenDigger 開源專案發起人趙生宇博士寫了一篇部落格來分享開原始碼力榜背後的演算法模型。
趙生宇是開源社 2022 年度理事，同濟大學計算機博士在讀，Wuhan2020、OpenDigger 等開源專案發起人，在 2020 年入選中國開源先鋒 33 人。
以下內容轉載自趙生宇博士的部落格《開原始碼力榜背後的演算法模型》
近期與思否合作釋出的中國開原始碼力榜受到了眾多開發者的關注，而其中大部分開發者會更加好奇這個排名是如何產生的，背後的演算法是什麼，為什麼有些開發者上榜了，而有些沒有。這篇部落格就會大家瞭解一下這個榜單背後的演算法，並希望得到大家的一些反饋，可以持續優化該榜單，使其可以更加全面和公正。
開源價值網路
之前的三篇部落格已經介紹了一種基於協作資料的開源價值網路的異質圖 PageRank 演算法，而本次使用的就是僅包含協作資料的 GitHub 全域開發者-專案的價值網路，其結構如下所示：
這是原先設計的價值網路的一個簡化版本，沒有納入開發者對專案的關注度關係（star、fork）、開發者之間的關注關係（follow）和專案之間的依賴關係（dependent），主要是考慮到算力的問題，以及某些尚未支援的對於缺失資料的魯棒問題。
在建立起完整的網路後，我們按月對全域的開發者和專案進行協同排序，並得到所有開發者和專案的價值排名。即我們可以得到 2015 年至今每個月全域中活躍的所有開發者和專案的排名情況，而中國開原始碼力榜使用的則是 2021 全年的開發者加和資料。
與傳統 PageRank 相比
這個演算法模型與傳統的 PageRank 演算法類似，是使用全域的關係資料來進行協同排序，有幾個基本的價值主張：
1、越有價值的專案容易吸引到越有價值的開發者來貢獻
2、越有價值的專案容易吸引到越多的開發者來貢獻
3、越有價值的開發者會在越有價值的專案上活躍
而與傳統 PageRank 演算法不同的地方在於，在開源價值網路中，不同型別的節點（開發者、專案）的計算方式可以是不同的，而且這個演算法引入了先驗知識，即節點的固有屬性作為一部分參考，而不僅僅使用網路關係的資料。
也就是說：在開源價值網路中，每個月的專案和開發者的價值，將不僅僅取決於開發者和專案當月的活躍情況，也有一部分是繼承於上個月的資料，這使得整個演算法得到的結果具有非常好的平滑性，而且也是因為我們相信開源的長期價值，是不僅僅依賴當下的情況的。
具體引數
在本次的模型中，我們使用瞭如下的一些引數：
1、開發者-專案活躍度，使用的是實驗室在往年的中國開源年報、GitHub 洞察報告中使用的計算方式，即
$$ A=\sqrt{1 * C_{issue_comment} + 2 * C_{open_issue} + 3 * C_{open_pull} + 4 * C_{pull_review_comment} + 2 * C_{merged_pull}} $$
即 Issue 評論計 1 分，開啟新 Issue 計 2 分，提交 PR 計 3 分，PR 上的 review 評論計 4 分，合入 PR 額外計 2 分，最終開方，用以修正過高的活躍度。
2、開發者和專案的初始價值，即第一次開始活躍時的價值均為 1。
3、開發者每個月有 50% 的價值來源於自身的歷史價值，50% 來源於當月的開源價值網路。
4、專案每個月有 30% 的價值來源於自身的歷史價值，70% 來源於當月的開源價值網路。
常見問題
- 為什麼有些使用者量和人氣極高的專案作者沒有入選，如 Vue 的作者尤大？
其實看完上面的說明，大家就應該明白了，本次的演算法主要是以協作關係來計算的，並沒有納入如開源軟體的使用者數量這樣的指標（當然，開源軟體使用者量一直是非常難以獲取的，即便是專案自己可能也無法知道具體的數值）。所以對於那些有大批開發者持續活躍的專案來說，其較有優勢，而對於使用者量較大的專案，則無法體現，這與使用的資料和模型的引數有極大的關係，尤其是 Vue 是一個以尤大為核心相對獨立維護的專案（可參考2019 年 Vue 專案協作網路圖）。
- 為什麼有些非常活躍的開發者沒有出現在榜單中？
雖然我們對全域的開發者和專案進行的協同排序，但我們沒有辦法準確知道哪些賬號是中國開發者，所以我們花了較大精力進行了人工標註，但依然難免疏漏，目前已經有標註的中國使用者清單已沉澱到 OpenDigger 中，可以從這裡看到。如果有新的賬號希望標註為中國開發者，可以提 Issue給 OpenDigger，合入後之後的計算就會納入進來。
未來改進
1、引入 star、fork 關係。在本次的榜單中，從算力角度考慮，我們沒有引入 star 和 fork 等資料，因為類 PageRank 的迭代類演算法的時間複雜度與圖密度是正相關的，而 star 這種低成本的操作會使得整個圖的密度非常快的提升，從而使運算時間大幅增加，尤其是在對數千萬節點的協同排序時。
2、引入開發者之間的 follow 關係。開發者的 follow 關係對於識別開發者 KOL 有很好的指導意義，但這裡有一個數學層面的問題，就是在解決不完全資料下的 Rank Sink 問題，目前還沒有來得及實現，會考慮引入類似 LeaderRank 的方式來低成本解決單向關係導致的一些問題。
3、專案依賴關係。事實上從使用者角度出發，如果無法有效得到使用者數量，那麼專案的依賴關係是一個非常適合的資料，可以用來標識專案之間的使用關係，尤其在語言生態內會極為有效。但同樣有與上述開發者 follow 關係一樣的問題，並且還有額外的一些其他工程問題。
- 以 Node.js 生態為例，已經發布到 npm 的包很好追蹤其依賴關係，而只有倉庫並未釋出製品包的專案，就需要進一步以倉庫中 package.json 檔案的內容來解析其依賴關係，在全域上做這件事的成本是極高的。
- 以 Java 生態為例，Maven 中心倉的後設資料中並不包含上游倉庫地址的資訊，所以製品和倉庫的關聯是較大的問題，而且 Java 的釋出策略中，倉庫與製品包多對多的情況較多，這使得構建專案依賴關係更加複雜。
如果有同學對上述問題比較熟悉，而且知道如何解決，請一定聯絡我~~
關於中國開原始碼力榜
中國開原始碼力榜是由 SegmentFault 思否、開源社、騰源會、X-lab 實驗室共同發起的中國開源開發者榜單。
來自 X-lab 的 OpenDigger 團隊對 GitHub 開放的歸檔日誌進行分析，篩選出了 2021 全年 GitHub 協作影響力排名前 10,000 的賬號，並號召了社群中數十位開發者及十餘家合作社群，通過開放式協作共同核實標註資訊、排除機器人賬號，第一階段選出了 99 位中國開發者。
榜單釋出後，我們收到社群反饋，新增了一位符合標準的來自中國的“開原始碼麗”Huan (李卓桓)，也請開源世界的每一位開發者通過 Github 專案地址能積極的向我們反饋，我們會不間斷的進行更新。
通過中國開原始碼力榜，我們希望開源世界的超級碼麗、開源專案背後的開發者們可以被更多人知道、認識和 respect。讓更多人關注開源、關注開源開發者成長。
專案地址： https://github.com/OpenSourceWin
專案官網： http://opensource.win/