观察：阿里巴巴的开源战略究竟怎么样？

背景

开源目前已经成为全球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 开放比	提交数
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

这说明这些项目的活跃不是没有道理的。

究竟是由于社区参与积极性不高导致的未接纳比例高，还是反之，我们认为或许是彼此互相影响导致的。

再让我们来看看问题数。

项目	创建天数	星标数	关注数	日均星标数
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 企业可以在开源方面有更多的实际行动，让中国这个世界上除了美国之外第二大的互联网大国在开源方面也取得相应的成就。