个人开发者在不同地方的 OpenRank 值，具体含义和区别是什么？

[will-ww]

以我个人为例，至少在三个地方有 OpenRank 值，它们的具体含义和区别是什么？差别还有些大~

1. codepen 的 oss101仓库上面：47.67
2. XSOSI 上面：9.29
3. GitHub 的个人档案上面：5.68

[frank-zsy]

OpenRank 目前有两个应用，一个是全域协作网络下的仓库和开发者的 OpenRank，一个是在某个具体仓库内的 OpenRank。

• 全域协作网络下的 OpenRank 值一般也被我们称为开源协作影响力，反映的是一个开发者在整个 GitHub 开源生态中的影响力，也就是在 GitHub 主页上的 OpenRank 值，即上图中的 5.68。
• 在某个仓库内的 OpenRank 也就是 CodePen 中展示的，是在某个具体仓库在某个具体月份中开发者在仓库协作网络下的 OpenRank 值，也就是上面的 47.67。这个值我们很少直接看到或使用，而是会配合仓库的全域 OpenRank 生成贡献榜单，即类似 XSOSI 或阿里开源开发者贡献榜的内容。
• XSOSI 和阿里开源开发者贡献榜这类榜单，对于每个开发者的总体贡献度，其实是根据开发者在仓库内的 OpenRank 比例让所有开发者来瓜分该仓库当月的全域 OpenRank。因此仓库的全域 OpenRank 会影响到该仓库中的开发者的总值，仓库内的 OpenRank 则影响了开发者如何进行分配。因此例如阿里开源开发者贡献榜中，一个项目内所有开发者当月的贡献度之和，就等于该仓库当月的全域 OpenRank，但贡献度的比例则与他们的仓库内 OpenRank 比例相同。这就是上面的 9.29，不过这个值是王老师在所有参与 XSOSI 的项目上的贡献度的总和。

[frank-zsy]

另外，我曾经提到过，如果有一个图数据库可以支持在全域上直接构建粒度到 Issue/PR 级的协作网络时，可以用同一个 OpenRank 来统一上面提到的两种 OpenRank，后来想了下是不可行的。

因为整体的 OpenRank 总值在节点初值给定的情况下，基本与节点数量正比，所以在 Issue/PR 较多的仓库中，仓库内 OpenRank 的总值是较高的，但这并不意味着其全域 OpenRank 应该更高。如果统一计算，就意味着仓库可以通过刷高 Issue/PR 的数量来提升自己的全域 OpenRank，这显然是不合理的。

全域 OpenRank 在仓库和开发者的协作网络上计算是相对公平合理的方式，因此虽然早期感觉是受到技术和算力的限制，但目前来看这种两层结构是非常合理的方式。

[will-ww]

全域上的应用，大家应该比较好理解，又分为两个：开发者的量化、项目仓库的量化，都是相对于全域的计算结果，并且这两个数值是没有什么明确的量化关系的，是各自独立的含义（姑且暂时称前者为开发者全域影响力，DevOpenRank，DOR、后者为项目生态影响力，RepOpenPank，ROR）。例如 3 月份，开发者 will-ww 的 DOR 是 5.68，而仓库 oss101 的 ROR 是 23.75。

那这两个数值之间会有具体的量化上的关系吗？例如，是否因为我在 oss101 上的活跃，带来了自身协作影响力的增长。感觉是有这个因果关系的，但应该还无法量化出来。

同时，还会引出几个基本问题：

• 单个 DOR 和 ROR 的值域范围大概是多少？从 oss101 和 OpenLeaderboard 看，个人的 DOR 可以到接近 200（除开机器人，机器人可以搞到上万！），而单个仓库 ROR 可以到 2000 以上；
• GitHub 上所有 DOR 和 ROR 的和是一直递增的吗？只要有空足够多的人力和项目，可以有无限上限？

[will-ww]

而某个仓库内的 OpenRank，是因为有了 CodePen 的可视化后才被大家看见，进而关注。

我以前也一直认为，以 oss101 为例，应该是 23.75 在所有仓库活跃者上的一个分配，这是个比较自然的想法。因此，当我看到 will-ww 在 oss101 上的 OpenRank 值为 47.67 的时候，就会觉得哪里没有对齐~

现在来看，这种两层的分离式设计，就很有用了：避免内部小团队在那里刷 Issue 和 PR 带来不合理性。因此，这里有还会引出一个问题：即便我这个仓库所有的参与者是提前一天刚注册的 GitHub 账号，且只在这个新仓库上活跃，形成了一个孤岛，但内部的 OpenRank 值还是可以计算的，应该是这个理解对吧？

第二个好处就是，可以像阿里的贡献度激励计划那样，对不同的仓库贡献进行倍乘计算等任意的操作，灵活性和可定制性是非常大的。

因此，内部 OpenRank 计算模式，重点是所有对象的“比例”关系，而不是绝对数值，包括开发者的贡献度 OpenRank 比例，以及 Issue、PR 等的 OpenRank 比例。咱们姑且把前者称作开发者项目内贡献度（DevInnerRank，DIR），而 Issue 和 PR 自然就分别是 ISIR 和 PRIR 了。

[will-ww]

最后一个，从数学上，OpenRank 的这种两层模型似乎也是可以关联的，就用该项目的 ROR（项目生态影响力） 来作为所有开发者的 DIR（开发者项目内贡献度） 分配总量。

这样做虽然符合直觉，但显然也是不合适的，因为 ROR 和 DOR 的尺度（或单位、量纲）是不一样的，如果这么来分配，那么 DOR 和 DIR 显然也就无法一致与对齐了。

但总觉得，这个两层模型，应该会有些什么好的关联关系~ :-)

例如，是否 ROR 和 ISIR、PRIR 等有某种函数关系呢？

总的来说，这些都是当我们将 PageRank 这种同质网络算法，迁移到异质网络上的时候，所需要解决和主意的问题~

[will-ww]

以我个人为例，至少在三个地方有 OpenRank 值，它们的具体含义和区别是什么？差别还有些大~

1. codepen 的 oss101仓库上面：47.67
2. XSOSI 上面：9.29
3. GitHub 的个人档案上面：5.68

基于上面的讨论，总结下这三个数字的背后原理：

• 47.67 是 will-ww 在 oss101 仓库上的一个 DIR（开发者项目内贡献度）数值；
• 5.68 是 will-ww 在 GitHub 全域上的一个 DOR（开发者全域影响力）数值；
• 9.29 解释起来稍微麻烦点。就是首先制定一个规则：根据开发者在仓库内的 DIR 比例，让所有开发者来瓜分该仓库当月的 ROR；在这个规则下，9.29 是 will-ww 在 XSOSI 计划下的所有仓库上的 DIR 求和。

[frank-zsy]

那这两个数值之间会有具体的量化上的关系吗？例如，是否因为我在 oss101 上的活跃，带来了自身协作影响力的增长。感觉是有这个因果关系的，但应该还无法量化出来。

ROR 和 DOR 是全域 OpenRank 中相互迭代的，是高度相关且有明确量化关系的，不考虑时序上的继承部分的话，一个仓库的 ROR 是在其上所有活跃的开发者的根据当月活跃度比例分配到该仓库的 DOR 的总和，反之亦然。

同时，还会引出几个基本问题：

• 单个 DOR 和 ROR 的值域范围大概是多少？从 oss101 和 OpenLeaderboard 看，个人的 DOR 可以到接近 200（除开机器人，机器人可以搞到上万！），而单个仓库 ROR 可以到 2000 以上；

目前从 OpenLeaderboard 看到的上限基本就是值域范围，但是属于经验性的，无法给出定论，例如一个仓库中突然有上万人协作，一定会超出这个上限。

• GitHub 上所有 DOR 和 ROR 的和是一直递增的吗？只要有空足够多的人力和项目，可以有无限上限？

GitHub 上的 OpenRank 总值目前看起来是递增的，但这与平台本身越来越活跃有关，由于时序上存在衰减，如果 GitHub 从现在开始完全不活跃，则总值会以 80% 每月的速率递减，并在大约一年后清零。

[frank-zsy]

最后一个，从数学上，OpenRank 的这种两层模型似乎也是可以关联的，就用该项目的 ROR（项目生态影响力） 来作为所有开发者的 DIR（开发者项目内贡献度） 分配总量。

这样做虽然符合直觉，但显然也是不合适的，因为 ROR 和 DOR 的尺度（或单位、量纲）是不一样的，如果这么来分配，那么 DOR 和 DIR 显然也就无法一致与对齐了。

ROR 和 DOR 是在同一个网络中计算的，他们之间有明确的量化关系，但尺度有较大的区别，原因是一个仓库可以有很多开发者同时参与，但同一个人类开发者的时间精力有限，无法同时深度参与大量项目。但 DOR 和 DIR 是无法对齐的。

但总觉得，这个两层模型，应该会有些什么好的关联关系~ :-)

例如，是否 ROR 和 ISIR、PRIR 等有某种函数关系呢？

总的来说，这些都是当我们将 PageRank 这种同质网络算法，迁移到异质网络上的时候，所需要解决和主意的问题~

ROR 和 ISIR、PRIR 是没有直接关系的，ISIR 和 PRIR 其实区别不会太大，例如他们的初值都是 2、5，根据点赞可以提高到最高 5 倍，因此值域就是 2-10 和 5-25，这是确定的。但其实在仓库内 OpenRank 中，仓库本身也是有一个 RIR 的，RIR 相当于仓库当月所有 ISIR 和 PRIR 总和的 10%。而且 RIR 和 ROR 是没有直接数值上的关系的，其实两层的算法设计本身就是为了防止 RIR 和 ROR 之间产生直接关系。

另外，如果要引入 InnerRank 这个名字，可能之后的困惑会更多，因为 OpenRank 可以应用的场景非常多，如果新增一个场景就新增一个名称，可能会有点难。

[birdflyi]

可以引入基尔霍夫定律来解释。PageRank值相当于结点留下的压降。

[tyn1998]

/ˌgɔ:(r)ˈ[R,D,P,O]/

GOR·R：Global Open Rank for Repository GOR·D：Global Open Rank for Developer GOR·P：Global Open Rank for Project （一个项目可能由多个仓库组成）（emm，这个读起来好像很有特色） GOR·O：Global Open Rank for Organization

/ˌlɔ:(r)ˈ[R,D,I,P]/

LOR·R：Local Open Rank for Repository LOR·D：Local Open Rank for Developer LOR·I：Local Open Rank for Issue LOR·P：Local Open Rank for Pullrequest

以上是我考虑到发音方便顺口（只有两个音节）而造的名词~