共计 3157 个字符，预计需要花费 8 分钟才能阅读完成。
中国开源码力榜是由 SegmentFault 思否、开源社、腾源会、X-lab 实验室独特发动的中国开源开发者榜单。
来自 X-Lab 的 OpenDigger 团队对 GitHub 凋谢的归档日志进行剖析，筛选出了 2021 全年 GitHub 合作影响力排名前 10,000 的账号，并号召了社区中数十位开发者及十余家单干社区，通过开放式合作独特核实标注信息、排除机器人账号，并在第一阶段甄选出了 99 位中国开发者。
中国开源码力榜公布后失去了很多开发者的关注，十分多开发者十分关怀这个排名是如何产生的，背地的算法模型是什么样的？咱们邀请了 OpenDigger 开源我的项目发起人赵生宇博士写了一篇博客来分享开源码力榜背地的算法模型 。
赵生宇是开源社理事、长期正式成员，同济大学计算机博士在读，Wuhan2020、OpenDigger 等开源我的项目联结发起人，在 2020 年入选中国开源先锋 33 人
以下内容转载自赵生宇博士的博客《开源码力榜背地的算法模型》
近期与思否单干公布的中国开源码力榜受到了泛滥开发者的关注，而其中大部分开发者会更加好奇这个排名是如何产生的，背地的算法是什么，为什么有些开发者上榜了，而有些没有。这篇博客就会大家理解一下这个榜单背地的算法，并心愿失去大家的一些反馈，能够继续优化该榜单，使其能够更加全面和公正。
开源价值网络
之前的三篇博客曾经介绍了一种基于合作数据的开源价值网络的异质图 PageRank 算法，而本次应用的就是仅蕴含合作数据的 GitHub 全域开发者 - 我的项目的价值网络，其构造如下所示：
这是原先设计的价值网络的一个简化版本，没有纳入开发者对我的项目的关注度关系（star、fork）、开发者之间的关注关系（follow）和我的项目之间的依赖关系（dependent），次要是思考到算力的问题，以及某些尚未反对的对于缺失数据的鲁棒问题。
在建设起残缺的网络后，咱们按月对全域的开发者和我的项目进行协同排序，并失去所有开发者和我的项目的价值排名。即咱们能够失去 2015 年至今每个月全域中沉闷的所有开发者和我的项目的排名状况，而中国开源码力榜应用的则是 2021 全年的开发者加和数据。
与传统 PageRank 相比
这个算法模型与传统的 PageRank 算法相似，是应用全域的关系数据来进行协同排序，有几个根本的价值主张：
1、越有价值的我的项目容易吸引到越有价值的开发者来奉献
2、越有价值的我的项目容易吸引到越多的开发者来奉献
3、越有价值的开发者会在越有价值的我的项目上沉闷
而与传统 PageRank 算法不同的中央在于，在开源价值网络中，不同类型的节点（开发者、我的项目）的计算形式能够是不同的，而且这个算法引入了先验常识，即节点的固有属性作为一部分参考，而不仅仅应用网络关系的数据。
也就是说：在开源价值网络中，每个月的我的项目和开发者的价值，将不仅仅取决于开发者和我的项目当月的沉闷状况，也有一部分是继承于上个月的数据，这使得整个算法失去的后果具备十分好的平滑性，而且也是因为咱们置信开源的长期价值，是不仅仅依赖当下的状况的。
具体参数
在本次的模型中，咱们应用了如下的一些参数：
1、开发者 - 我的项目活跃度，应用的是实验室在今年的中国开源年报、GitHub 洞察报告中应用的计算形式，即
$$
A=\sqrt{1 * C_{issue_comment} + 2 * C_{open_issue} + 3 * C_{open_pull} + 4 * C_{pull_review_comment} + 2 * C_{merged_pull}}
$$
即 Issue 评论计 1 分，关上新 Issue 计 2 分，提交 PR 计 3 分，PR 上的 review 评论计 4 分，合入 PR 额定计 2 分，最终开方，用以修改过高的活跃度。
2、开发者和我的项目的初始价值，即第一次开始沉闷时的价值均为 1。
3、开发者每个月有 50% 的价值来源于本身的历史价值，50% 来源于当月的开源价值网络。
4、我的项目每个月有 30% 的价值来源于本身的历史价值，70% 来源于当月的开源价值网络。
常见问题
- 为什么有些用户量和人气极高的我的项目作者没有入选，如 Vue 的作者尤大？
其实看完下面的阐明，大家就应该明确了，本次的算法次要是以协作关系来计算的，并没有纳入如开源软件的用户数量这样的指标（当然，开源软件用户量始终是十分难以获取的，即使是我的项目本人可能也无奈晓得具体的数值）。所以对于那些有少量开发者继续沉闷的我的项目来说，其较有劣势，而对于用户量较大的我的项目，则无奈体现，这与应用的数据和模型的参数有极大的关系，尤其是 Vue 是一个以尤大为外围绝对独立保护的我的项目（可参考 2019 年 Vue 我的项目合作网络图）。
- 为什么有些十分沉闷的开发者没有呈现在榜单中？
尽管咱们对全域的开发者和我的项目进行的协同排序，但咱们没有方法精确晓得哪些账号是中国开发者，所以咱们花了较大精力进行了人工标注，但仍然不免疏漏，目前曾经有标注的中国用户清单已积淀到 OpenDigger 中，能够从这里看到。如果有新的账号心愿标注为中国开发者，能够提 Issue 给 OpenDigger，合入后之后的计算就会纳入进来。
将来改良
1、引入 star、fork 关系。在本次的榜单中，从算力角度思考，咱们没有引入 star 和 fork 等数据，因为类 PageRank 的迭代类算法的工夫复杂度与图密度是正相干的，而 star 这种低成本的操作会使得整个图的密度十分快的晋升，从而使运算工夫大幅减少，尤其是在对数千万节点的协同排序时。
2、引入开发者之间的 follow 关系。开发者的 follow 关系对于辨认开发者 KOL 有很好的指导意义，但这里有一个数学层面的问题，就是在解决不齐全数据下的 Rank Sink 问题，目前还没有来得及实现，会思考引入相似 LeaderRank 的形式来低成本解决单向关系导致的一些问题。
3、我的项目依赖关系。事实上从用户角度登程，如果无奈无效失去用户数量，那么我的项目的依赖关系是一个非常适合的数据，能够用来标识我的项目之间的应用关系，尤其在语言生态内会极为无效。但同样有与上述开发者 follow 关系一样的问题，并且还有额定的一些其余工程问题。
- 以 Node.js 生态为例，曾经公布到 npm 的包很好追踪其依赖关系，而只有仓库并未公布制品包的我的项目，就须要进一步以仓库中 package.json 文件的内容来解析其依赖关系，在全域上做这件事的老本是极高的。
- 以 Java 生态为例，Maven 核心仓的元数据中并不蕴含上游仓库地址的信息，所以制品和仓库的关联是较大的问题，而且 Java 的公布策略中，仓库与制品包多对多的状况较多，这使得构建我的项目依赖关系更加简单。
如果有同学对上述问题比拟相熟，而且晓得如何解决，请肯定分割我~~
对于中国开源码力榜
中国开源码力榜是由 SegmentFault 思否、开源社、腾源会、X-lab 实验室独特发动的中国开源开发者榜单。
来自 X-lab 的 OpenDigger 团队对 GitHub 凋谢的归档日志进行剖析，筛选出了 2021 全年 GitHub 合作影响力排名前 10,000 的账号，并号召了社区中数十位开发者及十余家单干社区，通过开放式合作独特核实标注信息、排除机器人账号，第一阶段选出了 99 位中国开发者。
榜单公布后，咱们收到社区反馈，新增了一位符合标准的来自中国的“开源码丽”Huan (李卓桓)，也请开源世界的每一位开发者通过 Github 我的项目地址能踊跃的向咱们反馈，咱们会不间断的进行更新。
通过中国开源码力榜，咱们心愿开源世界的超级码丽、开源我的项目背地的开发者们能够被更多人晓得、意识和 respect。让更多人关注开源、关注开源开发者成长。
我的项目地址： https://github.com/OpenSourceWin
我的项目官网： http://opensource.win/
