中國開源專案 Grank 分析報告（2019）

Linux 中國曾在 2018 年末參與了開源社釋出的《2018 中國開源年度報告》的《資料篇 - Grank 篇》的撰寫，併為此提出和開源了 Grank 模型。

時光飛逝，如今已是 2020 年，是時候對主要發源於或活躍於中國的開源專案們進行一次年終總結了，因此我們再一次協同開源社完成了這次的 Grank 分析，並將本報告的簡化版本作為《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