该篇博客紧跟上一篇关于活跃度的介绍继续展开，根据上文提出的活跃度设计了一种新的上层算法，并希望可以通过该算法来解决活跃度度量存在的一些问题。

这篇文章系统介绍了一种基于全域开发者协作网络的项目影响力评估方法，该方法对于分析整个开源生态有极大的帮助。在一次性评估出所有项目的协作影响力的同时，也可以对项目的协作关联度进行深入探索，并对项目的所属类别进行自动判断。

上图中的 OpenGalaxy 2019 就是基于协作影响力指标构建的。

背景

上一篇中提到了直接基于活跃度这种统计型指标对项目进行分析所带来的一些思考和问题。总体而言，对于特定的项目这种分析方法可以有效的追踪整体项目的运转情况，并且通过一些参数的调整可以影响每个开发者的价值取向，起到一定的引导作用，例如维护者对代码 review 投入更多精力，或吸引更多的开发者参与到社区中。

但事实上，这种统计算法没有考虑到开源是一个完整的生态，GitHub 上的开发者一般不会只在一个项目上活跃。而这种在每个项目上各自独立进行统计的方式不仅没有利用到项目之间的关系，同时也会导致在项目间比较时出现一定的问题。

下面两类项目可以说明活跃度在全域分析时的一些问题：

• 1、自动化行为较多的项目。例如 pddemo 这个项目，其说明为“该仓库中每分钟自动生成一个 Issue”。即该仓库的作者使用自动化的手段，每分钟在这个仓库中会提交一个新的 Issue，且该 Issue 的标题是随机的，没有任何内容，并且会定期删除以前生成的空 Issue。这导致该项目在全年的活跃度极高，即使该项目只有 Open Issue 这样一个事件，且都是同一个账号操作的。类似的项目还有 Google 测试团队的 CLA 签署程序的测试项目 signcla-probe-repo，该项目上会产生大量的自动提交的 PR，用于测试 CLA 签署功能，是由一些机器人账号提交的，目前项目中的总 PR 数量高达 46W 多个。
• 2、不完全使用 GitHub 功能的项目。这个问题则是由于某些项目缺乏特定事件所导致的问题。例如很多开源项目，虽然在 GitHub 上进行协作，但事实上并不会在 GitHub 上利用 Issue 进行需求的提交与追踪，而会使用例如 JIRA 一类的工具，这会导致这类项目的活跃度较真实情况偏低而不容易被发现。尤其是 Apache 基金会下的众多项目，都是这种情况，例如 spark、hbase、flink 等等，都没有开启 GitHub 的 Issue 功能。

考虑到上述问题，我们希望可以充分利用开源项目的行为数据来评判项目的协作影响力，故提出了开源协作网络，旨在通过开发者在不同项目间的协作情况来对全域开源生态中的所有项目进行影响力的计算。

开源协作网络与协作影响力

开源协作网络

开源协作网络的构建思想非常朴素，基本逻辑是：如果有开发者同时在两个项目上都非常活跃，那么这两个项目就存在着较高的协作关联度。在这里我们暂不考虑这种关联产生的动机，只是一种对开发者行为的观察。事实上根据后续的采样，发现基本符合最初的想法。即大部分情况下，是由于项目存在着上下游的关系，或存在某种使用上的依赖或合作关系，才会有开发者同时在两个项目上高度活跃。

最典型的例子就是 VSCode 与 flutter 的高度关联性，最初我们以为是两个项目使用了相同的协作机器人导致了高关联性。通过深入分析发现，是开发者 Danny Tuppeny 把他们关联了起来。这是一名来自英国的开发者，是 Dart 语言的 VSCode 插件 Dart-Code 的作者和 flutter 的贡献者。由于 Dart 语言目前主要用于 flutter 的开发，他的高度活跃度将 VSCode 和 flutter 这两个世界顶级项目给关联在了一起。

也正是协作网络这种数学工具，为我们发现开源生态中这些有趣的关系提供了一种有效的手段。

而协作网络中协作关联度的计算也非常直观，其中每个开发者在项目上的活跃度符合上一篇中对活跃度计算的介绍。假设开发者 $d$ 在项目 $p1$ 上活跃度为 $A_{d,p1}$，在项目 $p2$ 上的活跃度为 $A_{d,p2}$，则该开发者对这两个项目协作关联度的贡献为 $\frac{A_{d,p1}A_{d,p2}}{A_{d,p1}+A_{d,p2}}$。这里使用了调和平均的计算方法，其含义就是只有开发者在两个项目上都非常活跃时，才会对这两个项目的关联度产生较大影响，仅在一个项目上活跃不会导致两个项目的关联度大幅增加。

协作影响力

基于上述构建的开源全域生态中所有项目的协作网络，我们可以利用一些图分析的算法来计算每个项目的协作影响力。这里我们使用了 PageRank 算法，关于这个算法的计算过程，可以在链接中看到，这里就不再赘述。

PageRank 是一个经典算法，该算法被发明并应用于 Google 搜索引擎的网页排名中，收到了非常好的效果。而且这个算法的计算效率很高，它对网页质量的判断并不基于网页本身的内容，而是基于网页之间的引用关系。

即其基本主张是：一个高质量的页面，会被更多的页面所引用；而高质量的页面，其引用的其他页面的质量也是较高的。仅凭借着这样一个基本的价值假设和互联网上不计其数的网页之间的引用关系，Google 就可以很好的给出网页质量的判断和排名。（关于算法开放可能带来的作弊行为我们在这里暂不讨论）

而在开源协作网络的协作影响力中，我们使用了非常类似的思路：即一个影响力较大的项目，会和更多的项目有协作关系；对于影响力较大的项目，与其协作关联度较高的项目影响力也会较大。

凭借着这样一个认识，给出 GitHub 在 2019 年全域协作影响力前 10 的项目如下：

可以看到 VSCode 作为被开发者广泛使用并大受欢迎的 IDE 项目，以极高的协作影响力占据了开源世界的中心位置。通过各种语言的插件项目，VSCode 与这些语言和它们开发的顶级项目之间都建立起了较大的关联性，展示了其在开发者生态中的重要性。

关于整个算法更详细的说明和实验结果，可以参考这篇博客。

思考

• 1、协作影响力基于活跃度构建，但同时又规避了很多活跃度会带来的问题，并且利用了开源生态的全域数据所蕴含的一些重要的关联信息。
• 2、之前提到的自动化项目，虽然某种行为的数量极大，但由于其自动化账号没有与其他项目产生关联，这种异常的高度活跃在网络构建时就被消除了。
• 3、这也带来了另一个巨大的好处，就是对于刷分行为，在这种模型下几乎无法生效。即对自己项目的高活跃的刷分无法带动自己项目的影响力，除非有更多的其他生态项目的开发者在你的项目中活跃。
• 4、之前提到的不使用 GitHub Issue 功能的项目，由于其开发者不仅在该项目上，也会在其上下游项目中高度活跃，导致了这些项目相较活跃度指标表现出了更好的影响力。
• 5、由于使用了网络关系这种重要的信息，原始的活跃度计算中权重人为指定的影响就会变小。只要还是满足大致的价值判断，即代码贡献大于 review 大于一般问题讨论，则活跃度中权重的变化几乎不会影响到影响力的排名。因为影响力中活跃度虽然是一个基础数据，但协作网络的结构信息使得整个算法具有了更好的稳定性和鲁棒性。
• 6、这种协作网络构建，除了计算项目的协作影响力外，还带来了额外的一些分析能力。
  • 协作孤岛。所谓协作孤岛，是指有些项目群，上面活跃过的开发者不会在其他项目上活跃，而其他开发者也不会在这些项目上活跃，导致这个项目群是游离在整个大的开源生态之外的。在 2019 年活跃的近 90W 个项目中，有 90.4% 的项目构成了核心的开源生态，还有不到 10% 的项目形成了数量巨大的游离孤岛。其中最常见的就是由于语言隔离导致的协作孤岛，例如一些日本、俄罗斯、法国、乌克兰、白俄罗斯的开发者群体等。
  • 项目聚类。由于协作关联度较高的项目之间存在某种联系，说明他们可能是具有相似的属性的，则利用一些聚类方法，可以对项目所属的类别有所判断。具体的算法和结果可以参考之前的博客。

问题

• 1、开源协作网络目前仅能对项目进行分析，在对开发者进行分析时，如果使用类似的网络，其有效性有限。主要是原因是大量的自动化协作账号在这种模型下具有非常大的优势。
• 2、开源协作网络仅仅利用到了开发者协作的 GitHub 行为数据，而开源世界中还有更多元的数据可以被利用。但目前在这个模型下无法兼容更多的数据。
• 3、开源协作网络仅仅利用了关系，这也是 PageRank 算法的局限，但同时也是优势之一，就是初值无关性（或更准确是马尔科夫性质）。这意味着我们无法在该模型中使用一些先验知识，例如项目或开发者的固有属性等。
• 4、开源协作网络的设计对活跃度虽然不敏感，但却有要求。即如果活跃度中引入 star 或 fork 这类低成本的行为，会导致大量项目之间产生连接关系，进而导致对项目类别判断的准确率下降。也就说目前聚类的效果很大程度上依赖于底层的活跃度设计。

总结

总体而言，基于开源协作网络的项目协作影响力解决了基于统计的活跃度指标中存在的诸多问题，对整个开源生态中项目影响力的评估和洞察提供了一种非常有效的手段。但同时也存在一些其他的固有问题，这些问题使得整个模型和指标在可扩展性上存在较大的局限性。

我们希望可以找到一种具有高可扩展能力的图模型，可以引入更多元的开源数据，对开源项目、开发者等可以有更加深刻、准确的洞察和分析，并且也能规避指标刷分带来的一些问题。关于开源生态的价值流网络模型，请继续关注该系列文章。

原文链接：http://blog.frankzhao.cn/how_to_measure_open_source_2/