观察：阿里巴巴的开源战略究竟怎么样？
背景
开源目前已经成为全球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 企业可以在开源方面有更多的实际行动，让中国这个世界上除了美国之外第二大的互联网大国在开源方面也取得相应的成就。