觀察:阿里巴巴的開源戰略究竟怎麼樣?
背景
開源目前已經成為全球IT 界和互聯網界一致推崇的文化和戰略,而阿里巴巴作為國際頂級的互聯網企業之一,在開源方面也一直秉持堅定而熱忱的態度,積極地將其一些成熟或發展中的產品和技術以開源、開放的態度回饋到社區。
據目前已知的數據,阿里巴巴(以下簡稱阿里)已經貢獻了上百款軟體項目,其中去年到現在就開源了三十個左右的項目,得到了開源界和業界積極關注和參與,其中不乏重量級的開源項目。
不過,對於阿里的開源舉措,業界也有一些不同的聲音,比如有人認為阿里的開源項目虎頭蛇尾,往往開源後就置之不理,活躍度走低,缺乏進一步的維護;也有人認為阿里的開源項目實際並沒有得到社區的廣泛參與和認可,更多還是阿里自身的員工在進行維護,社區並沒有對這些項目提供有力的貢獻,也沒有衍生出重要的分支項目。
為了對中國企業在開源方面的情況進行深入的了解,從而對開源和企業之間的關係做一些定性、定量的分析,那麼,讓我們來具體分析一下阿里高調開源幾年以來的開源項目的發展情況。
說明:我們本次的分析僅以阿里在 GitHub 上的開源項目的公開數據為基礎,並不涉及到阿里在其它開源社區和代碼託管網站的情況。
首先,我們在 GitHub 上找到阿里的開源團隊,其在 GitHub 以團隊形式出現的有幾個,這裡我們主要分析 https://github.com/alibaba 和 https://github.com/ant-design 兩個團隊的情況。
在上述的 alibaba團隊中,我們可以發現,其名下的 代碼庫 截止至本文寫作時多達 133 個。但是有些項目僅僅是對上游項目的 復刻 ,並無或甚少進行修改提交,也有一些項目無實際意義,因此經過篩選後,我們得到了大約110 個項目。
而在 alibaba 團隊中正式公開登記的成員(員工和前員工)有101 個,有不少參與貢獻的成員沒有公開登記,但是我們在做數據分析時,將郵件後綴域是 alibaba-inc.com、alipay.com、taobao.com、aliyun.com 的貢獻者也歸類為阿里員工。
阿里團隊在 GitHub 旗下的項目數量和登記成員數在國內互聯網公司來說,已經不算少了,雖然據統計,阿里團隊所獲得的 星標 數全球排名第12位,國內排到了第一,但是和國際上的一些開源領袖公司相比,還有較大距離。(註:如果累計 ant-design 團隊項目的星標數,由於該團隊旗下的開源項目包括了去年的一個重點項目 ant-design,其排名應該可以更高一些。)
在本文中,我們將從這些開源項目的各個維度的數據來進行分析,主要關注於以下兩個方面:
- 項目的活躍程度
- 社區的參與程度
在分析之前,我們需要先了解哪些數據對我們來說是重要的,以及其背後反映的意義。
GitHub 上的開源項目指標
在 GitHub 上開源的項目有那些指標呢?可以反映出什麼信息?
我們認為可以從以下幾個指標進行分析:
1、項目的 提交 數量、 分支 數量、 發布 數量。
這代表了項目代碼的活躍程度,其中提交數量是主要指標,而分支數量和發布數量雖然也可以側面反映出代碼的活躍程度,但是更多是不同的相關項目管理方式導致的。
2、項目的 拉取請求 (PR)數量、 貢獻者 數量、 問題 數量。
這代表了項目參與者的參與程度,其中拉取請求數量是主要指標,而貢獻者數量和問題數量與之正相關,可以反映出貢獻者分布密度和項目反饋速度。
3、項目的 復刻 數量、 星標 數量、 關注 數量。
這代表了項目的受關注程度,其中復刻數量是主要指標,因為復刻一個項目往往代表了社區更多的參與意願,並進而通過提交拉取請求、問題等進行參與,這也是社區生態發展不同的下游衍生版本的必由之路。而星標數量和關注數量,現在由於逐漸蔓延的 GitHub 營銷潮流,其水分比較大,可以作為輔助指標參考。
4、項目的持續時長和最後更新時間。
項目的持續時長是從項目建立開始到最後更新時間之間的時長,這代表了項目的生存時間。如果最後更新時間是很久以前,則代表該項目已經陷入消亡中。
項目的提交數量
阿里開源的項目很多,但如同大多數企業組織一樣,各個項目的活躍程度大相徑庭。有的活躍項目得到了來自社區上萬的 星標 、數千的 復刻 乃至上千的 拉取請求 ,項目本身也擁有數萬的 提交 乃至幾十個 分支 ;而有的項目則數據寥寥,基本上陷入沉寂,其中有一半數量的項目最後提交於一年前,甚至還有 5 個項目的最後更新於 5 年前——基本上可以判定已經停止維護。
在統計時,我們發現一種情況,復刻或衍生的上游項目,會將上游的提交數量、分支數量等數據繼承下來,因此在針對阿里對該項目的貢獻和發展方面進行分析時,應該將這部分數據減去。這樣的話,在阿里團隊名下列出的一些知名項目,如復刻自 CocoaPods/Specs 的 Specs 項目擁有 14 萬之多的提交數,但是阿里本身並沒有對其復刻的版本進行任何提交;又比如阿里的重點項目 AliSQL 是基於 MySQL 官方版本的一個衍生版,因此其近 10萬的提交數中絕大部分是 來自MySQL 發展多年來積累下的提交數量,本身阿里在將其衍生為 AliSQL 之後,只有 52 個提交數;同樣 AliSQLBackup 的 10 萬多個提交數也是來自於上游項目,阿里幾乎沒有做過更新提交,並且也停止維護兩年了;因此,這些項目在統計時,我們會從阿里復刻或衍生該項目時開始計數提交數量。
當然,我們知道,僅僅以提交數來評估一個項目的活躍度是片面的,比如說,上述的 AliSQL 雖然只有 52 個提交,但是其由於開發模式和審慎態度的緣故,往往一次提交的代碼量比較多,其中某次提交行數高達 5 萬多行,而對上游 MariaDB 的貢獻雖然只有三次提交,但是已經佔到了總代碼量的 1%。鑒於此,我們會不僅僅從提交數,還從復刻數、問題數等多個方面來綜合進行觀察。
下表是阿里旗下開源的提交數前十的項目:
項目 | 創建天數 | 提交數 | 員工提交數 | 社區提交數 | 日均提交數 |
ant-design | 730天 | 8567 | 2494 | 5973 | 11.60 |
weex | 398天 | 5779 | 804 | 4975 | 14.52 |
druid | 1987天 | 4056 | 1067 | 2989 | 2.04 |
fastjson | 1987天 | 1883 | 834 | 1049 | 0.95 |
LuaViewSDK | 461天 | 1195 | 1189 | 6 | 2.59 |
rax | 180天 | 1001 | 768 | 233 | 5.56 |
tengine | 1848天 | 907 | 611 | 296 | 0.49 |
dubbo | 1758天 | 414 | 370 | 44 | 0.24 |
freeline | 252天 | 377 | 227 | 150 | 1.50 |
anyproxy | 975天 | 369 | 352 | 17 | 0.38 |
我們可從上表中看到,阿里旗下開源的項目提交數最多的是 ant-design 項目,這是螞蟻金服旗下推出的一種 UI 設計語言,在開源兩年來,得到了快速的發展。我們可以看到,其提交數約計比第二名高過 1/3,其中社區提交數是成員提交數的兩倍,並且日均提交數也達到了很高的水平。
第二名是 weex 項目,這是一個用於構建跨平台移動應用 UI 的框架,前些時間剛剛捐獻給 Apache 基金會孵化管理。項目開源於 2016 年底,目前已有近 6 千提交,其中社區提交數量是阿里員工的提交數的 6 倍!而且,日均提交數竟然達到了 14.52 個,其發展速度還要超過了第一名 ant-design。這代表了社區強烈的參與意願,並且該項目得到了社區的廣泛應用。
第三名是 druid 項目,這是一個是「為監控而生的資料庫連接池」,自稱「是 Java 語言中最好的資料庫連接池」。採用 Java 開發,也是阿里重點發展的項目之一,2011 年底開源發布,目前已經有 4 千餘個提交,代碼迭代很快。而且,非阿里員工的提交數量是阿里員工的提交數量的三倍左右。
應該說,這些排名較高的項目的活躍度都不錯,其中只有一個項目是更新於半年前的,其它的項目都在近期有不同程度的更新維護。
從上面的項目的提交來源看,提交數最高前三名來自社區的提交要超過了阿里員工的提交,甚至遠遠超過,這說明這三個項目得到了社區的普遍支持,我們在後面分析復刻情況時也可以看到,這兩個項目的復刻數都很高。而之後排名的項目,卻呈現了另外一種趨勢,即來自阿里員工的提交數要超過或遠超來自社區的提交數,相應的表示出這些項目在社區的受歡迎程度要差一些。
從整體的這些項目來看,各個項目的提交數明顯呈長尾樣分布:
項目提交數分布
而且,我們可以看到,從提交數排名第 8 位的項目開始,提交數呈斷崖式下降,但是整體的以正態分布呈現:
項目提交數分布(去除前 7 名)
從上述分布上來看,阿里旗下的開源項目的發展情況正常,既有活躍項目,也有消亡項目。
我們判斷,阿里對其開源項目的管理處於自由生長狀況,並沒有從統一管理的層面來督導、輔導各個開源項目的發展,也沒有對陷入消亡的項目進行進一步處置和收尾,也就是說,一些爛尾的項目並沒有進行妥善處置。
為了驗證這個結論,我們來看一下阿里旗下開源的項目的最近更新時間。
項目的最近更新時間
拋開一些項目內的無關緊要的更新(如修訂一些 README,pom.xml 等),我們發現這 133 個項目當中有 60 個項目更新於一年前,其中更新於 4 年前及以上的有 30 個。可見有不少遺留項目缺乏處置。
當然,根據上圖也可以反映出近年來阿里的開源項目整體的發展趨勢要超過過去幾年。
項目的拉取請求數和問題數
GitHub 開創性的使用了 拉取請求 (經常簡稱為 PR)的方式來為開源項目提供社區協作支持。無論是項目成員還是外部合作者,以及偶爾的關注該項目的貢獻者,都可以通過發起拉取請求來給某個項目提交補丁,項目維護人員可以對該拉取請求進行審核,如果審核通過,就會「拉取」該合併請求到項目中,從而將貢獻者提交的代碼融合到項目代碼之中。
作為社區貢獻者,對一個項目發起貢獻的主要方式就是給該項目發起拉取請求。雖然也有不少項目要求幾乎所有成員都必須以拉取請求的方式來提交其代碼,而不允許直接提交到倉庫中,但是通常而言,一個項目的拉取請求數可以從側面反映出一個項目的社區(外部)參與程度。
而對一個項目作出貢獻的方式不僅僅是貢獻代碼,還有對項目中發現的問題、缺失功能所提交的報告也是一種重要的方式,這些信息在 GitHub 中統一被稱之為 問題 。
每個拉取請求和問題,都會被項目維護者進行審核,並進行處置。比如對於拉取請求,可以接受、可以拒絕;對於問題,可以回復、也可以忽略/關閉。
一般來說,活躍的項目其拉取請求數量和問題數量也會越大,但是我們這裡不去做這些數量的排名,我們感興趣的是,這些拉取請求和問題中,開放和關閉的比例情況。
如下表,我們列出了拉取請求未接納比例最高的前十名(這裡略去了拉取請求數低於10的項目)。
項目 | 開放 PR 數 | 關閉 PR 數 | PR 數 | PR 開放比 |
LuaViewSDK | 8 | 3 | 11 | 72.73% |
DataX | 15 | 16 | 31 | 48.39% |
dubbo | 57 | 71 | 128 | 44.53% |
RocketMQ | 18 | 32 | 50 | 36.00% |
nginx-http-concat | 6 | 12 | 18 | 33.33% |
jstorm | 17 | 53 | 70 | 24.29% |
anyproxy | 9 | 30 | 39 | 23.08% |
atlas | 4 | 17 | 21 | 19.05% |
otter | 1 | 11 | 12 | 8.33% |
nginx-tfs | 1 | 13 | 14 | 7.14% |
我們可以看到,這些項目中拉取請求未接納的比例最高的有的高達 70% 以上,當然,另外一方面,我們也看到了這些項目的拉取請求數都不高。這可以反映出該項目的社區參與積極性不高。
但是幾個提交數比較高的項目,除個別情況外,其拉取請求未接納的比例都很低:
項目 | PR 開放比 | 提交數 |
ant-design | 0.10% | 8467 |
weex | 1.03% | 5779 |
druid | 0.50% | 4056 |
fastjson | 0.00% | 1883 |
LuaViewSDK | 72.73% | 1195 |
rax | 3.82% | 1001 |
tengine | 6.83% | 907 |
dubbo | 44.53% | 414 |
freeline | 0.00% | 377 |
anyproxy | 23.08% | 369 |
terraform-provider | 0.00% | 355 |
這說明這些項目的活躍不是沒有道理的。
究竟是由於社區參與積極性不高導致的未接納比例高,還是反之,我們認為或許是彼此互相影響導致的。
再讓我們來看看問題數。
項目 | 全部問題 | 開放問題 | 關閉問題 | 問題開放比 |
oceanbase | 12 | 12 | 0 | 100.00% |
mirrors | 46 | 45 | 1 | 97.83% |
ons | 12 | 11 | 1 | 91.67% |
simpleimage | 15 | 13 | 2 | 86.67% |
LVS | 25 | 21 | 4 | 84.00% |
tfs | 23 | 19 | 4 | 82.61% |
taokeeper | 31 | 23 | 8 | 74.19% |
nginx-http-concat | 44 | 29 | 15 | 65.91% |
dubbo | 423 | 273 | 150 | 64.54% |
AndFix | 341 | 219 | 122 | 64.22% |
DataX | 183 | 113 | 70 | 61.75% |
我們可以看到,有些項目,居然所有的問題都沒有處置,比如 oceanbase,甚至連被寄予厚望的 dubbo 和 DataX 也有相當比例的問題沒有解決——難怪有人對阿里開源項目爛尾頗有微詞。
那麼我們同樣來看看幾個活躍項目的問題解決比例:
項目 | 全部問題 | 問題開放比 | 提交數 |
ant-design | 5860 | 1.69% | 8467 |
weex | 2977 | 12.83% | 5779 |
druid | 1672 | 25.90% | 4056 |
fastjson | 1137 | 23.13% | 1883 |
LuaViewSDK | 76 | 25.00% | 1195 |
rax | 218 | 6.88% | 1001 |
tengine | 884 | 17.99% | 907 |
dubbo | 423 | 64.54% | 414 |
freeline | 758 | 3.30% | 377 |
anyproxy | 161 | 37.27% | 369 |
我們可以看到,這些活躍項目的問題解決比例還是比較高的。
項目的復刻數
下面我們來看看這些項目的復刻數。前面我們說過,開源項目的復刻數代表了(外部)社區參與該項目的積極性。因為復刻一個項目的意圖可能有以下幾種:
- 保留(凍結)該項目當前的代碼以做將來之用,以避免該項目出於種種原因被刪除、關閉。
- 要對該項目提交補丁(拉取請求),需要復刻一份,完成修改後發起拉取請求。
- 意圖衍生該項目,通常是為了發展不同的方向。
- 只是為了方便找到該項目?可能更習慣這種方式,而不是加以星標、關注等方式來標記該項目。
無論是哪種情況,我們可以看到,復刻這種行為基本上可以代表復刻者對該項目的積极參与意願。
以下是阿里開源的項目中復刻數最高十個項目:
項目 | 創建天數 | 復刻數 | 日均復刻數 | PR 數 | 全部問題 |
dubbo | 1763天 | 7946 | 4.51 | 128 | 423 |
fastjson | 1992天 | 3061 | 1.54 | 171 | 1137 |
druid | 1992天 | 2946 | 1.48 | 801 | 1672 |
ant-design | 730天 | 2659 | 3.63 | 1413 | 5860 |
RocketMQ | 894天 | 2108 | 2.36 | 50 | 479 |
weex | 402天 | 1918 | 4.77 | 1360 | 2977 |
tengine | 1853天 | 1532 | 0.83 | 571 | 884 |
jstorm | 1322天 | 1531 | 1.16 | 70 | 485 |
AndFix | 580天 | 1326 | 2.29 | 7 | 341 |
canal | 1555天 | 1168 | 0.75 | 42 | 291 |
從上面我們可以看到,復刻數最高的項目是一個名為 dubbo 的分散式、高性能的 RPC 框架,是阿里巴巴 SOA 服務化治理方案的核心框架,每天為 2,000+ 個服務提供 3,000,000,000+ 次訪問量支持,並被廣泛應用於阿里巴巴集團的各成員站點。Dubbo 的復刻數遠高於第二名的 fastjson,但是其相應的拉取請求數和問題數卻不相稱的低——這代表了什麼?社區或業界覺得這個項目有價值,但是鮮於應用場景,也缺乏參與回饋的能力(或動力?)。
而第二名,fastjson 卻顯著的問題數比較高,這表明社區在大量使用該項目,因此產生(發現)的問題或需求也比較多。但是其拉取請求數卻沒有與問題數相應的提高,側面說明了該項目本身參與開發的難度較高。
第三名 druid,是一個 java 的資料庫連接池,其問題數和拉取請求數都很高,我們認為它的活躍度和社區參與程度都很健康。
第四到六名 ant-design 、RocketMQ 、 weex 都是阿里重點發展的項目,並且後兩者都捐贈給了 apache 基金會孵化管理,而且 weex 的發展更是後來居上,就拉取請求和問題數來說,weex 的發展更健康一些。
那麼,結論呢?可以大致的看出,復刻數較高的項目其日均復刻數也存在較大的波動,說明其發展速度不一,但是復刻數可以作為一個項目是否健康發展的指標之一,但是該指標應和拉取請求數和問題數綜合來看。
項目的星標數和關注數
對 GitHub 上的開源項目的觀察久已有之,但是人們一般習慣於按項目的星標數來進行排名。不過,現在隨著 GitHub 的日益流行,星標這種成本低廉簡單操作已經逐漸失去了作為排名依據的意義,以至於一些 markdown 項目(也稱為 awesome 項目)雖然並無代碼,僅僅一篇以 markdown 格式提交的資源大全,也往往取得了不錯的星標數。我們認為,對於開源項目,尤其是特指代碼方面的開源項目時,其星標數並不應該與那些 markdown 項目進行橫向比較。當然,同樣作為開源代碼項目,星標數還是有一定的參考價值的。
我們來看看阿里旗下開源項目的星標數前十的項目:
項目 | 創建天數 | 星標數 | 關注數 | 日均星標數 |
weex | 402天 | 13864 | 1992 | 34.49 |
ant-design | 730天 | 12745 | 680 | 17.45 |
fastjson | 1992天 | 8674 | 945 | 4.35 |
dubbo | 1763天 | 8159 | 1765 | 4.63 |
druid | 1992天 | 6014 | 1125 | 3.02 |
tengine | 1853天 | 5384 | 778 | 2.91 |
AndFix | 580天 | 5167 | 438 | 8.91 |
atlas | 48天 | 4068 | 291 | 84.75 |
RocketMQ | 894天 | 3652 | 727 | 4.09 |
freeline | 257天 | 3511 | 195 | 13.66 |
dexposed | 657天 | 3475 | 392 | 5.29 |
啊哦,不出意外,這些項目基本上還是和復刻數排名比較相近。Weex 在該項排名中又取得了第一。令我們比較感興趣的是,排名稍後的幾個項目的開源時間並不算長。讓我們來以日均星標數排名看看,這回我們多取幾名:
項目 | 創建天數 | 星標數 | 關注數 | 日均星標數 |
atlas | 48天 | 4068 | 291 | 84.75 |
vlayout | 49天 | 3250 | 120 | 66.33 |
UltraViewPager | 19天 | 903 | 23 | 47.53 |
weex | 402天 | 13864 | 1992 | 34.49 |
Tangram-iOS | 19天 | 455 | 26 | 23.95 |
Tangram-Android | 19天 | 401 | 30 | 21.11 |
LazyScrollView | 46天 | 842 | 30 | 18.30 |
ant-design | 730天 | 12745 | 680 | 17.45 |
rax | 185天 | 2755 | 119 | 14.89 |
freeline | 257天 | 3511 | 195 | 13.66 |
ARouter | 124天 | 1551 | 60 | 12.51 |
AndFix | 580天 | 5167 | 438 | 8.91 |
BeeHive | 259天 | 1908 | 98 | 7.37 |
AliSQL | 264天 | 1877 | 375 | 7.11 |
dexposed | 657天 | 3475 | 392 | 5.29 |
dubbo | 1763天 | 8159 | 1765 | 4.63 |
fastjson | 1992天 | 8674 | 945 | 4.35 |
RocketMQ | 894天 | 3652 | 727 | 4.09 |
LuaViewSDK | 466天 | 1821 | 183 | 3.91 |
HandyJSON | 209天 | 810 | 41 | 3.88 |
發現什麼沒有?日均星標數的前幾名,或者說大多數都是相當年輕的開源項目,其星標增長速度要讓幾個已經開源了幾年的項目瞠目其後。我們判斷,這說明阿里現在在開源方面已經處於高調宣傳模式,對於新開源的項目,都有一波持續和明確的傳播意圖。但是我們認為,作為一家商業企業,這也代表了阿里已經將開源作為一個主流戰略、也是其企業文化和品牌形象推廣的重要方面,那麼是不是代表著阿里以後的開源項目的支持力度和維護熱情會更高、更持久呢?
總結
以上,我們通過對阿里旗下開源的多個項目的各個指標進行了橫向和縱向的比較,從中也觀察到了一些有趣的現象。但是這些數據並不能完全的反映出一個一致的結論,只是,從整體來看我們認為,阿里巴巴旗下的開源項目,正在以更快、更主動的方式在發展,至於說是否還會出現之前的那種開源之後被拋棄的情況,下定論還為時尚早。這或許要看阿里的開源委員會是否能夠制定更宏觀的發展戰略而定。
不過,無論如何,我們欣喜的看到,阿里在踐行開源理念、積極主動的擁抱、回饋開源方面,取得了矚目的成就。我們也期待國內的更多互聯網企業、IT 企業可以在開源方面有更多的實際行動,讓中國這個世界上除了美國之外第二大的互聯網大國在開源方面也取得相應的成就。
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive