中國開源項目 Grank 分析報告（2019）

Linux 中國曾在 2018 年末參與了開源社發布的《2018 中國開源年度報告》的《數據篇 - Grank 篇》的撰寫，並為此提出和開源了 Grank 模型。

時光飛逝，如今已是 2020 年，是時候對主要發源於或活躍於中國的開源項目們進行一次年終總結了，因此我們再一次協同開源社完成了這次的 Grank 分析，並將本報告的簡化版本作為《[2019 年中國開源年度報告](/article-11739-1.html "2019 年中國開源年度報告（問卷篇）")》的一部分出現。

在 2019 年報告中，我們使用和 2018 年報告相同的模型進行分析。但與 2018 年報告不同的是，在 2019 年度報告中，我們引入了大量的企業項目和個人項目，整體分析項目數達到了 1200 余個，並對參與分析的項目進行了分離，按照其所屬企業、個人等不同的角度進行分類，讓讀者能夠更加明確不同項目、企業之間的關係。

在我們看具體數據之前，先看一下我們從這些數據中得到感受。

洞察

今年在進行 Grank 數據分析的過程中，我們發現了不少有趣的變化，一年時間，如此多的變化，也值得我們思考和討論。

洞察一：文檔類活躍度可達開發類項目的 10 倍

GitHub 項目上一直都有一些文檔類的項目，比如各種 Awesome 、各種電子書。我們會發現， 這些項目經常會引起開發者討論：XXX 到底能不能算做開源項目？。 GitHub 官方的態度是明確的，文檔類項目 azure-docs 出現在了 GitHub 2019 年度開發者報告中。

近兩年來，我們發現越來越多的企業，開始將自己的文檔放置在 GitHub 上，與整個社區共同協作，構建更好的文檔。在此次分析中，我們發現騰訊雲文檔、阿里雲文檔、PingCAP 等企業文檔早已開始在 GitHub 上協作

當我們真正將文檔類開源項目進行數據分析後，我們會發現，文檔類項目得益於其低參與成本和學習成本，在項目的活躍度層面可以獲得極高的評分，同樣的原因，文檔類項目也獲得了極高的社區化程度。文檔類項目已經逐漸成為開源項目中的一個非常重要的組成部分。這樣的現象值得我們思考，在開源世界，是代碼重要，還是社區重要？

今年的文檔類活躍項目最為亮眼的項目，莫過於來自於 騰訊雲的 tencentyun/qcloud-documents，此項目的活躍度遠超其他項目，總活躍度達到 685.33 ，是同類項目第二名的 5 倍，是開發類項目第一名的 10 倍。

近兩年，我們看到大量的企業開始將自己的企業項目文檔放在 GitHub 與社區開發者共同協作，獲取來自社區開發者的貢獻。大量的企業文檔類項目的出現，表現出了企業對於開源價值觀的認同和投入。

洞察二：企業開源治理水平差異較大

在今年的分析過程中，我們將所有參與分析的賬號進行企業級別的分類。通過分類後的數據，我們可以明顯看出不同企業在開源治理上的水平和成果。

今年參與分析的的項目中，阿里巴巴的 GitHub 賬號有 31 個（源自其開源項目官網），而國內其他一線互聯網企業百度有 12 個賬號、華為有 7 個賬號、騰訊有 4 個賬號、美團有 3 個賬號。

這些賬號背後，我們看出的是各企業對於開源的態度和治理能力。顯然，擁有 31 個賬號的阿里巴巴在治理能力上可能會受到質疑，但 31 個賬號，換來的是阿里巴巴開源的生態和聲勢最為浩大。而賬號更少，治理能力更強的騰訊、百度、華為、美團是否就做的更好呢？也不是。這些企業的賬號維護的更好，但是，其開源項目的聲量、體量卻難以與阿里巴巴旗下的眾多項目所抗爭。

對於阿里巴巴來說，面臨的問題是如何教育開發者，以正式、正規、合規的方式來運營、運作開源項目，而對於其他企業，面臨的問題可能是如何激勵開發者去做開源項目。

洞察三：程序員亞文化興起

亞文化一直是主流文化的一個陰影，亞文化往往不為人所知，不為廣泛群眾所接受。但數據不會騙人。在 2019 年的年度報告中，我們評估了一個著名的項目：komeiji-satori/Dress。這是一個在 GitHub 上擁有 16K 星標，3.2K 復刻和 198 位貢獻者的項目。

這個項目的數據，讓我真正意識到，亞文化或許依然替代不了主流文化，但不代表亞文化就沒有自己的存在價值和空間。 Dress 項目的誕生和發展，是亞文化向主流文化發聲的存在。這些我們過去忽視的亞文化，正在以自己的方式，表達觀點。

洞察四： JavaScript 生態不斷擴大

「能被 JavaScript 所實現的，終將被 JavaScript 所實現」，過去這只是一個梗，但是在如今這個梗在開源項目領域中，不斷的變成了現實。在今年的榜單中，我們看到其中出現了大量的 JavaScript 開源項目

JavaScript 得益於其腳本語言的特性和其簡單易學的語法，在近幾年獲得了大量的關注度和開發者。而其無需編譯，在瀏覽器環境可以直接運行的特性，也讓 JavaScript 項目在活躍度的提升上佔據了優勢。相比於編譯一次需要花費大量時間的 C++ 、Rust 項目，顯然 JavaScript 優勢十足。

洞察五：服務端相關開發依然非常重要

雖然 JavaScript 佔據的席位越來越多，但是我們所熟悉的傳統的服務端開發、服務端中間件等領域類依然是佔據了更多的席位。在今年的活躍度榜單前 100 名中，50 個項目是服務端開發，佔據了所有榜單的一半份額。不僅如此，資料庫中間件項目 —— TiDB 佔據了非文檔類項目的活躍度榜單第一名、總活躍度榜單第三名。

對於開發者來說，雖然前端開源項目的聲量赫然，但服務端開發項目依然是目前開源項目的主流。對於開發者來說，如果不願意貢獻 JavaScript 相關項目，服務端中間件項目會給你更多的選擇。

洞察六： 各家布局物聯網

今年由於拆分出了多個子榜單，所以也能夠讓我們更加清楚的看到不同的企業布局。今年的物聯網榜單中，我們看到了華為 2015 年開源的 LiteOS 、阿里巴巴 2017 年開源的 AliOS-Things ，一直到 2019 年的的 TencentOS-Tiny（此項目因為開源時間短，活躍度也不高，總體健康度排名在 200 名左右，故沒有出現在後續的榜單中），各家企業都在積極地布局物聯網領域。在 2020 年，我們預期物聯網領域還能誕生出重要項目。

數據

分析方案

由於軟體開發項目的迭代周期、研發難度有所不同，各種不同類型的項目放在一個榜單內評比略顯不公，因此，2019 年的 Grank 報告我們將參與分析的開源項目切分為以下四個類目，開源項目在同一類目下進行對比，具體分為以下四個類目：

1. 前端類：包括 iOS、Android、Web 大前端，主要為用戶可感知的內容，常見為各種類庫
2. 服務端類：包括 Java、Rust、PHP、Node.js、Python，主要為常見業務後台類庫和中間件
3. 工程類：不限制語言，主要為可直接交付給 C 端客戶使用的項目，不作為開發工具參與到開發流程中。
4. 文檔類：主要是各類型的文檔項目。
5. 物聯網類：面向物聯網場景下的服務端應用、操作系統等應用。
6. 其他類：無法被涵蓋在上述分類範圍的項目

前端類分析結果

榜單情況

項目點評

ant-design/ant-design

這是一個「服務於企業級產品的設計體系」，是由螞蟻金服體驗技術部採用 React 封裝的一套組件庫。同時，也是去年的 Grank 評分的第一名。 Ant-Desgin 項目在整體的大方向上於去年並沒有太大的區別，甚至從數據的角度上來，2019 年 Ant-Design 有更多的數據更新，保持其一貫優秀的活躍度與社區化程度。

tencent/omi

Omi是一個基於 Web Components 並支持 IE、小程序端的前端跨平台框架。

從數據上來看， Omi 項目的活躍度從 2018 年 9 月開始，有大幅度提升，並在 2019 年年初達到了數據的頂峰。在社區化程度方面，從 2019 年年中開始，其社區活躍度出現了下降的趨勢，猜測可能是其在內部擁有了更大的話語錢，致使更多的企業內部開發者開始參與到 Omi 項目的開發。

elemefe/element

Element 是由餓了么前端團隊開源的 Vue UI 框架。從項目活躍上看， Element 近年來的更新乏力，略顯頹勢。整個項目開始逐漸走向減少維護的階段。

服務端類分析結果

榜單情況

項目點評

pingcap/tidb

TiDB 項目是 PingCAP 公司的明星項目，是一款定位於在線事務處理/在線分析處理融合型開源資料庫產品。

從數據上來看，TiDB 項目近年來的活躍度不斷攀升，與之成為鮮明對比的，是其項目的社區活躍度的不斷下降。不過，PingCAP 是業界非常典型的開源企業，其協作模式是所有開發人員通過 GitHub 進行協作，對於合適的開發人員，PingCAP 會選擇提供其職位，允許其遠程辦公，以這樣的方式來吸收社區的優秀開源力量，其社區化程度不斷下降也實屬正常。畢竟，優秀的開發者都被 PingCAP 轉化為正規軍，也不失為一個好的方法。

apolloauto/apollo

apollo 是百度開源出來的自動駕駛解決方案，從 2017 年開源至今，已經迭代至第 5 個版本。

apache/incubator-shardingsphere

shardingsphere 是由京東數科捐贈給 Apache 的分散式資料庫中間件解決方案，其中包含了 Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar 三款獨立的產品。

工程類分析結果

榜單情況

項目點評

diygod/rsshub

RSSHub 是一個幫助用戶將各種各樣的內容轉化成 RSS 的工具，今年也是他的第一次上榜，RSSHub 以 23 的活躍度積分位列榜單 12 名。

作為一個個人項目，RSSHub 可以說做的是非常棒了，而且，RSSHub 的社區化做的非常好，一直處在高位， 擁有 300 位貢獻者。

ant-design/ant-design-pro-site

文檔類分析結果

榜單情況

項目點評

tencentyun/qcloud-documents

此項目為騰訊雲文檔，一個令人驚訝的項目，擁有 543 個貢獻者和 119441 個提交 ，平均更新頻次為 5 分種/次，有非常驚人的高頻維護，估計是騰訊雲將其整個文檔放置在 GitHub 上進行開放協作，同時，所有的內部合作，都需要通過 GitHub 來完成。

此項目雖然活躍度高，由於項目的貢獻指南並未說明，絕大多數開發者沒有明確的規範參與到項目的更新。

lctt/TranslateProject

此項目為歸屬 Linux 中國旗下的翻譯組主倉庫，該項目擁有 464 名貢獻者和 47776 個提交 以及 1.5k 星標 ，平均更新頻次為 2 小時，更新頻次較高。

此項目擁有完善的貢獻說明，對於新手開發者來說，更加的友好，對於無法參與到開發階段的開發者，可以考慮從翻譯開始。

xitu/gold-miner

此項目為掘金翻譯計劃的官方倉庫 ，來自社區的開發者們在一個倉庫 上協作，貢獻自己的翻譯文章，該項目擁有 417 名貢獻者和 9754 個提交，以及超過 24.9K 的星標。

物聯網類分析結果

榜單情況

項目點評

rt-thread/rt-thread

RT-Thread 是一個 2006 年創建的項目，十餘年來專註於物聯網實時操作系統。其項目自 2018 年起，開始出現明顯的活躍度增加。回望 2017 、2018，物聯網生態企業和產品的蓬勃發展，讓開源項目也隨之獲得了大量的關注度，項目維護團隊、社區開源愛好者的參與，讓 RT-Thread 能夠跑的更快。

liteos/LiteOS

LiteOS 是華為開源的物聯網操作系統，從 2015 年發布，到 2019年結束，LiteOS 的各項數據有著明顯的變化。從 2017 年的不怎麼維護，到 2018 年的迅猛發展，再到 2019 年的歸為平淡，從某種角度來說，LiteOS 頗具 KPI 項目的潛質。而社區化程度的低位，也會讓用戶去思考，這個系統是否值得我去使用？

alibaba/AliOS-Things

AliOS-Things 源自阿里巴巴，自 2017 年開源以來，項目總體來說，維護的節奏比較平穩，從初期的大幅度維護，到後期的小幅度維護。從活躍度的角度來看，是一個不錯的項目，不過，社區化的變化，可能是由於 AliOS-Things 在內部的權重變重，更多的企業開發者參與到項目中來，去推進項目的進度。

其他類分析結果

榜單情況

項目點評

996icu/996.ICU

996.ICU 項目作為 2019 年現象級的一個項目，一度得到了社會和社區的廣泛關注，但是由於種種原因，這個項目的消亡也很快。不勝嘆息。

活躍度總榜前 100 名

致謝與反饋報告問題

由於時間有限，本次報告僅收錄部分項目，如果其中存在數據錯誤或希望補充收錄，請通過 郵件 聯繫我們。

如果報告撰寫過程中出現文字錯誤等問題，你可以直接訪問 GRank 倉庫，提交 PR 修正。

本次數據分析所引用的企業賬號的部分數據源自《InfoQ:中國互聯網公司開源項目調研報告》。

附錄

附錄一 研究方法綜述

Grank 是本報告制定的一個指數，用於綜合評估一個開源項目、開源組織的健康程度。

Grank 模型介紹

我們認為，一個健康的開源項目應該體現為以下兩個方面：

• 項目的活躍度趨勢
• 項目的社區化（去中心化）程度

而這兩個方面分別有多個因素組成：

活躍度和活躍度趨勢

項目的活躍度，我們定義為項目的提交數、 拉取請求數和貢獻者數（其它數據，如代碼行數、文件數、提案數、復刻數、星標數，要麼是權重相對低得多，要麼是代表意義不夠確定，此處忽略不計入模型）。

但是，對於不同的項目，其橫向比較其活躍度，或有不同的活躍度形態，或不具備可比性。很難說一個項目比另外一個項目的提交數高，而拉取請求（PR）數低代表的確切含義。因此我們不認為對不同項目的這些數據進行絕對值的比較有太多的科學意義。

所以，我們認為一個項目本身的活躍度變化的趨勢和幅度，會更有項目間比較的意義。

如果以三維空間來描述一個項目的活躍度，以提交數、拉取請求數、貢獻者數為三維，可以確定在某個時間點某個項目的坐標，那麼計算一段時間內，該坐標點的移動軌跡和速率，可以真實的反映該項目的活躍度趨勢。

考慮到按周工作的作息時間的普遍影響，我們以一個工作周作為一個時間採樣點，然後計算連續的幾周內該坐標的移動速率。這反映了該項目的發展速度。

社區化程度

開源誕生於社區，繁榮於社區，根植於社區，雖然現在大型組織、商業公司也紛紛投身於開源生態，但是我們認為，開源項目的生命力仍然在於社區。我們並不否認機構、商業公司對開源的巨大貢獻和影響力，但是如果一個開源項目變成了一家或幾家大企業的私人遊戲，其必然失去開源項目的生命力，它或許會在商業上取得成功，但是那個成功不是開源項目的成功模式。

因此，我們認為需要有一個評估開源項目的社區化（去中心化）程度的指標。項目（尤其是軟體項目）的一個重要屬性是開發人員的社區化身份，因此，我們以實際向項目貢獻了代碼的人員的社區化離散程度來評估項目的社區化程度。

每個參與項目開發的人員均有其身份屬性，這個身份可能是企業僱傭身份，也可能是社區志願者身份。我們通過對項目的提交中的提交者數據進行收集，然後根據開發人員的身份信息、郵件後綴等依優先順序來判斷其所屬身份。然後對這些信息進行聚類，以一個離散評估模型來評估該數據集的離散程度。

雖然項目越中心化，其發展風險越高，但是，並不是社區化程度越高的項目就越健康，過於離散的項目也容易出現項目分裂、迭代緩慢等問題。這顯然是存在一個適當的區域。

通過上述兩個指數，我們可以對項目進行象限劃分，以「項目活躍度」和「社區化程度」為兩個象限軸。

附錄二 數據採集方式、工具與時間

• 數據採集方式：基於 Github Developers API V4 進行數據抓取
• 數據採集所用工具：https://github.com/LCTT/Grank
• 數據抓取時間範圍： 2017 年 1 月 1 日 ～ 2019 年 12 月 31 日

附錄三 參與分析賬號

企業及組織賬號

百度

阿里巴巴

騰訊

華為

美團

360

小米

PingCAP

有贊

京東

位元組跳動

RT-Thread

網易

滴滴出行

唯品會

武漢深之度

hyperf

微眾銀行

SwiftOldDriver

SwiftGGTeam

豆瓣

Linux 中國

studygolang

濤思數據

攜程

去哪兒

噹噹

個人賬號

在 Github 上關注者數大於 10000 的賬號。

• 996icu
• diygod
• ruanyf
• yyx990803
• michaelliao
• daimajia
• JacksonTian
• Trinea
• phodal
• stormzhang
• cloudwu
• lifesinger
• astaxie
• onevcat
• justjavac
• breakwa11
• RubyLouvre
• hongyangAndroid
• laruence
• ibireme
• bailicangdu
• bestony

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive