觀察：阿里巴巴的開源戰略究竟怎麼樣？

背景

開源目前已經成為全球IT 界和網際網路界一致推崇的文化和戰略，而阿里巴巴作為國際頂級的網際網路企業之一，在開源方面也一直秉持堅定而熱忱的態度，積極地將其一些成熟或發展中的產品和技術以開源、開放的態度回饋到社群。

據目前已知的資料，阿里巴巴（以下簡稱阿里）已經貢獻了上百款軟體專案，其中去年到現在就開源了三十個左右的專案，得到了開源界和業界積極關注和參與，其中不乏重量級的開源專案。

不過，對於阿里的開源舉措，業界也有一些不同的聲音，比如有人認為阿里的開源專案虎頭蛇尾，往往開源後就置之不理，活躍度走低，缺乏進一步的維護；也有人認為阿里的開源專案實際並沒有得到社群的廣泛參與和認可，更多還是阿里自身的員工在進行維護，社群並沒有對這些專案提供有力的貢獻，也沒有衍生出重要的分支專案。

為了對中國企業在開源方面的情況進行深入的瞭解，從而對開源和企業之間的關係做一些定性、定量的分析，那麼，讓我們來具體分析一下阿里高調開源幾年以來的開源專案的發展情況。

說明：我們本次的分析僅以阿里在 GitHub 上的開源專案的公開資料為基礎，並不涉及到阿里在其它開源社群和程式碼託管網站的情況。

首先，我們在 GitHub 上找到阿里的開源團隊，其在 GitHub 以團隊形式出現的有幾個，這裡我們主要分析 https://github.com/alibaba 和 https://github.com/ant-design 兩個團隊的情況。

在上述的 alibaba團隊中，我們可以發現，其名下的程式碼庫（repository）截止至本文寫作時多達 133 個。但是有些專案僅僅是對上游專案的復刻（fork），並無或甚少進行修改提交，也有一些專案無實際意義，因此經過篩選後，我們得到了大約110 個專案。

而在 alibaba 團隊中正式公開登記的成員（員工和前員工）有101 個，有不少參與貢獻的成員沒有公開登記，但是我們在做資料分析時，將郵件字尾域是 alibaba-inc.com、alipay.com、taobao.com、aliyun.com 的貢獻者也歸類為阿里員工。

阿里團隊在 GitHub 旗下的專案數量和登記成員數在國內網際網路公司來說，已經不算少了，雖然據統計，阿里團隊所獲得的星標（star）數全球排名第12位，國內排到了第一，但是和國際上的一些開源領袖公司相比，還有較大距離。（注：如果累計 ant-design 團隊專案的星標數，由於該團隊旗下的開源專案包括了去年的一個重點專案 ant-design，其排名應該可以更高一些。）

在本文中，我們將從這些開源專案的各個維度的資料來進行分析，主要關注於以下兩個方面：

• 專案的活躍程度
• 社群的參與程度

在分析之前，我們需要先了解哪些資料對我們來說是重要的，以及其背後反映的意義。

GitHub 上的開源專案指標

在 GitHub 上開源的專案有那些指標呢？可以反映出什麼資訊？

我們認為可以從以下幾個指標進行分析：

1、專案的提交（commit）數量、分支（branch）數量、釋出（release）數量。

這代表了專案程式碼的活躍程度，其中提交數量是主要指標，而分支數量和釋出數量雖然也可以側面反映出程式碼的活躍程度，但是更多是不同的相關專案管理方式導致的。

2、專案的拉取請求（pull request）（PR）數量、貢獻者（contributor）數量、問題（issue）數量。

這代表了專案參與者的參與程度，其中拉取請求數量是主要指標，而貢獻者數量和問題數量與之正相關，可以反映出貢獻者分佈密度和專案反饋速度。

3、專案的復刻（fork）數量、星標（star）數量、關注（watch）數量。

這代表了專案的受關注程度，其中復刻數量是主要指標，因為復刻一個專案往往代表了社群更多的參與意願，並進而通過提交拉取請求、問題等進行參與，這也是社群生態發展不同的下游衍生版本的必由之路。而星標數量和關注數量，現在由於逐漸蔓延的 GitHub 營銷潮流，其水分比較大，可以作為輔助指標參考。

4、專案的持續時長和最後更新時間。

專案的持續時長是從專案建立開始到最後更新時間之間的時長，這代表了專案的生存時間。如果最後更新時間是很久以前，則代表該專案已經陷入消亡中。

專案的提交數量

阿里開源的專案很多，但如同大多數企業組織一樣，各個專案的活躍程度大相徑庭。有的活躍專案得到了來自社群上萬的星標（star）、數千的復刻（fork）乃至上千的拉取請求（pull request），專案本身也擁有數萬的提交（commit）乃至幾十個分支（branch）；而有的專案則資料寥寥，基本上陷入沉寂，其中有一半數量的專案最後提交於一年前，甚至還有 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 開創性的使用了拉取請求（pull request）（經常簡稱為 PR）的方式來為開源專案提供社群協作支援。無論是專案成員還是外部合作者，以及偶爾的關注該專案的貢獻者，都可以通過發起拉取請求來給某個專案提交補丁，專案維護人員可以對該拉取請求進行稽核，如果稽核通過，就會“拉取”該合併請求到專案中，從而將貢獻者提交的程式碼融合到專案程式碼之中。

作為社群貢獻者，對一個專案發起貢獻的主要方式就是給該專案發起拉取請求。雖然也有不少專案要求幾乎所有成員都必須以拉取請求的方式來提交其程式碼，而不允許直接提交到倉庫中，但是通常而言，一個專案的拉取請求數可以從側面反映出一個專案的社群（外部）參與程度。

而對一個專案作出貢獻的方式不僅僅是貢獻程式碼，還有對專案中發現的問題、缺失功能所提交的報告也是一種重要的方式，這些資訊在 GitHub 中統一被稱之為問題（issue）。

每個拉取請求和問題，都會被專案維護者進行稽核，並進行處置。比如對於拉取請求，可以接受、可以拒絕；對於問題，可以回覆、也可以忽略/關閉。

一般來說，活躍的專案其拉取請求數量和問題數量也會越大，但是我們這裡不去做這些數量的排名，我們感興趣的是，這些拉取請求和問題中，開放和關閉的比例情況。

如下表，我們列出了拉取請求未接納比例最高的前十名（這裡略去了拉取請求數低於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 企業可以在開源方面有更多的實際行動，讓中國這個世界上除了美國之外第二大的網際網路大國在開源方面也取得相應的成就。