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

本文为 Grank（Github Rank）的简介及相关思路的介绍。

在深圳刚刚结束的 CosCon 2018 大会上发布了《中国开源调查报告》，Grank 作为其中数据篇的部分数据提供者，构建了一个 Github 项目活跃度、社区化的模型，并以 Python 实现。

项目地址： https://github.com/lctt/grank/

Grank 模型

我们认为，一个健康的开源项目应该体现为以下两个方面：

• 项目的活跃度趋势
• 项目的社区化（去中心化）程度

而这两个方面分别有多个因素组成：

活跃度和活跃度趋势

项目的活跃度，我们定义为项目的提交数、 拉取请求数和贡献者数（其它数据，如代码行数、文件数、issue 数、 fork 数、star 数，要么是权重相对低得多，要么是代表意义不够确定，此处忽略不计入模型）。

但是，对于不同的项目，其横向比较其活跃度，或有不同的活跃度形态，或不具备可比性。很难说一个项目比另外一个项目的提交数高，而拉取请求（PR）数低代表的确切含义。因此我们不认为对不同项目的这些数据进行绝对值的比较有太多的科学意义。

所以，我们认为一个项目本身的活跃度变化的趋势和幅度，会更有项目间比较的意义。

如果以三维空间来描述一个项目的活跃度，以提交数、拉取请求数、贡献者数为三维，可以确定在某个时间点某个项目的坐标，那么计算一段时间内，该坐标点的移动轨迹和速率，可以真实的反映该项目的活跃度趋势。

考虑到按周工作的作息时间的普遍影响，我们以一个工作周作为一个时间采样点，然后计算连续的几周内该坐标的移动速率。这反映了该项目的发展速度。

社区化程度

开源诞生于社区，繁荣于社区，根植于社区，虽然现在大型组织、商业公司也纷纷投身于开源生态，但是我们认为，开源项目的生命力仍然在于社区。我们并不否认机构、商业公司对开源的巨大贡献和影响力，但是如果一个开源项目变成了一家或几家大企业的私人游戏，其必然失去开源项目的生命力，它或许会在商业上取得成功，但是那个成功不是开源项目的成功模式。

因此，我们认为需要有一个评估开源项目的社区化（去中心化）程度的指标。项目（尤其是软件项目）的一个重要属性是开发人员的社区化身份，因此，我们以实际向项目贡献了代码的人员的社区化离散程度来评估项目的社区化程度。

每个参与项目开发的人员均有其身份属性，这个身份可能是企业雇佣身份，也可能是社区志愿者身份。我们通过对项目的提交中的提交者数据进行收集，然后根据开发人员的身份信息、邮件后缀等依优先级来判断其所属身份。然后对这些信息进行聚类，以一个离散评估模型来评估该数据集的离散程度。

虽然项目越中心化，其发展风险越高，但是，并不是社区化程度越高的项目就越健康，过于离散的项目也容易出现项目分裂、迭代缓慢等问题。这显然是存在一个适当的区域。

Grank 的结果长什么样子？

多项目活跃度：

多项目社区化：

单项目社区化及活跃度：

使用方法

1. 使用 pip 安装项目 pip install grank
2. 获取 Github 的 Personal Access Token
3. 使用 grank login 设置 Token
4. 使用 grank config 设置社区化企业关键词
5. 使用 grank analy <owner> [<repository>] 来分析特定用户 /组织和项目，比如 grank analy lctt grank,分析结果可以在执行命令目录的 result 目录中找到。
6. 使用命令行模式操作，如 grank --token=XXXX --start=2018-01-01 --stop=2018-05-21 --askrule=0 --rule=inc analy <owner> <repository> 其中 token 必须指定，其他可以使用缺省设置

Grank 是如何实现的？

Grank 使用 Github 的 GraphQL 来完成数据抓取的工作，抓取项目的所有提交和拉取请求来进行分析，并使用 Pandas、numpy、pandas 进行数据的分析，最终得出结果。

此外，Grank 目前为命令行工具，采用了 Click 来编写命令行的支持。

Grank 能够为你带来什么？

1. 评估自己的项目情况
2. 学习 Python 项目编写
3. 了解 Click 的使用
4. 了解 pytest 的使用。

项目地址：https://github.com/LCTT/Grank

Pypi 地址：https://pypi.org/project/Grank/