编者按：

长久以来，个人开发者在开源社区中的贡献都是在被一把无形的尺粗略衡量，比如模糊的个人知名度、信服力等等，又或是开源社区赋予的 Maintainer、Committer 等称谓。与此相对应的是，个人开发者如何从开源贡献中获得收益、如何准确评估这份收益等问题，迟迟没有一个可以量化的衡量指标。

为了能更准确地评价开源项目内的个人贡献度和影响力，X-lab 开放实验室赵生宇尝试建立一套具体的度量体系，通过构建一个开源项目内的协作网路，去衡量开发者的贡献。赵生宇认为，贡献评价也是对开源精神很好的补充与支持，同时，付出与回报的匹配，对开源协作的持久性、开源社区的规模化发展，也都是有益处的。

在文末，赵生宇也邀请大家参与一个简单的投票调查，希望大家可以留下自己的选择和看法。

嘉宾：赵生宇 X-lab 开放实验室核心成员

OSCHINA：为什么想到要建立一套度量体系，去评价开源项目内的个人贡献度？

赵生宇：在过去数十年中，开源对于软件行业，尤其是对于基础软件带来了巨大改变，极大程度上促进了软件行业的发展。而与其形成强烈对比的则是开源软件的作者无法从自己创造的价值中获利，甚至难以维持生计。

我虽然之前提到开源作为一种大规模的协作方式，需要有完整的价值闭环才能持续健康的发展，并且也喊出了「在开放协作的世界里，每一份贡献都值得回报！」的价值口号，但即使解决了开源项目本身的商业化和盈利问题，如何将这部分利益再有效的分配到具体的开发者手中依然是个难题。

事实上，开源世界中生产力高度自由流动，与依赖传统公司雇佣形式的生产关系之间的矛盾，已经日益凸显，对于社区中流动开发者的贡献如何量化，是解决开源价值分配中最为重要的一环。

虽然企业内的贡献中，大部分的分析方法会使用代码变更或类似工单计件的方式来统计贡献量，但我还是希望可以挖掘开源中社交开发的特点，利用协作关系来构建一个更加科学有效的度量方法，从而可以更好的解决开源中价值分配的问题。

OSCHINA：我们目前看到的项目中开发者的贡献评价基本上是通过开发者的Issue、PR 数量或提交代码行数来统计得到的，如何理解“利用协作关系来构建一个更加有效的度量方法”呢？

赵生宇：

那我们就以搜索引擎为例，讲一下网页排序的计算方法。其实最早的搜索引擎中，大家会使用网页的内容作为网页排名的依据，这样虽然搜索的相关性很好，但网页的质量排序依然是个难题。谷歌的 PageRank 算法利用网页之间的外链关系来评价网页的质量，基本的假设是高质量的页面更容易被其他高质量的页面所引用，这个算法在不需要关注网页内容本身的情况下，为网页质量排序带来一个高效而优质的解决方案。

而协作网络也是类似，其实我的基本假设是高影响力的开发者更容易吸引其他高影响力的开发者与其进行协作，例如在同一个 Issue 上深度交流或在 PR 上就代码细节进行讨论等。

在全域协作网络中，我们以项目与开发者为节点，以活跃度为边构建了一个庞大的协作网络，事实上其含义就是以项目作为开发者的协作单元，即在同一个项目上活跃就看做是一种协作。

在项目内部，最直观的就是使用 Issue 和 PR 作为基本的协作单元，在同一个 Issue 或 PR 进行的讨论就被看成是一种协作。因此我们就得到了如下一个项目内的协作网络图：

由此就构建出了一个开源项目内的精细化协作网络，之后使用 OpenRank 算法就可以计算出每个开发者、每个 Issue 和 PR 的价值了。与 PageRank 类似，我们不需要关注具体的 Issue 和 PR 中每次讨论和代码提交的内容，而通过开发者之间的协作关系就可以计算出一个开发者的影响力。

但与 PageRank 不同的是，我们不仅仅考虑关系信息，而且 Issue 和 PR 也是具有初始价值的，这个价值对于修正和精细化评判开发者的贡献具有重要的作用。

OSCHINA：Issue 与 PR 的初始价值是如何确定的呢？

赵生宇：Issue 与 PR 的初始价值计算需要重点说明，因为某个具体的项目中，与全域项目不同，我们可以通过制定社区的规则，使社区中的成员可以常态化的表达更多的价值倾向，从而帮助我们更好的评判每个节点的价值。

在 Issue 与 PR 的初始价值计算中，我们使用了低成本的 GitHub reactions 来进行，即所有开发者都可以对 Issue 和 PR 进行 reactions 评价，如👍 2 倍、❤️ 3 倍、🚀 4 倍，所以如果一个开发者使用了三个 reactions 进行评价，则最多可以把一个 Issue 或 PR 的基础倍率提高到默认的 9 倍。

但这里我们对不同开发者做出的评价权重是不同的，一个开发者的评价倍率对最终倍率的影响与其在项目中的上个月的影响力有关。如一个开发者在上个月的影响力占比是 20%，那么如果他对一个 Issue 给出了 9 倍倍率的评价，但仅有他给出了评价，则最终这个 Issue 的基础倍率将是 0.2∗9+(1−0.2)=2.6。因此 9 倍看上去是一个非常高的倍率，但其实个别账号的高评价并不会带来非常大的影响。

也就是说这是一种去中心化的评价体系，每个开发者如果想要自己的评价更有意义，就需要自己在项目中的影响力更大才行，如果一个对项目完全没有贡献的开发者，他的 reactions 评价则完全不影响结果。

所以可以认为这是一种专家经验，只是这里的专家必须是对项目有深度贡献的人。

OSCHINA：开发者可以如何参考这套评价体系来提升自己的影响力？会不会出现为了提升个人影响力而刷Issue, PR数量的情况呢？

赵生宇：正如管理学中的一句话：“你考核什么，就会得到什么”，那么在上述的数学模型和计算方法下，如果一个开发者想要在社区中获得更高的影响力，他应该做什么呢，以及这些行为会对社区后续带来什么变化呢？

提升与社区中影响力较高开发者的协作频次

由于协作网络是构建在 Issue 和 PR 等协作单元之上的，因此最简单的一种策略就是要提升与社区中影响力较高的开发者的协作频次。

• 刚刚进入社区的开发者，最简单的方式就是在社区高影响力开发者的 Issue 或 PR 中进行交互，无论是进行讨论或者去 Review 他们的代码提出一些问题都是可以的。
• 对项目已经有一些了解的开发者，则更好的策略是通过自己高质量的 Issue 和 PR 来吸引核心的开发者与自己进行协作，例如参与自己提出的问题的讨论，或来 Review 自己提的 PR 等。所以这里就已经对开发者有一些价值引导了，即需要想办法与社区中的核心开发者交流协作，而不是自己一味的提低质量的 Issue 或 PR，若没有人愿意与你讨论，则你的影响力依然是很难提升的。
• 对于项目中的核心开发者，其策略其实是要与更多的开发者产生协作关系，即尽可能去与其他的开发者进行交流与协作来巩固自己的核心位置。

提升自己在社区中的贡献质量

上一项是鼓励协作的频次，但这一项则更加强调贡献的质量。由于 Issue 和 PR 具有初始价值，而这个初始价值其实对于提升开发者的影响力非常重要。

那么如果一个开发者希望社区中的核心开发者来给自己的 Issue 和 PR 点赞，从而获取更高的初始价值，那么他们就要想办法去提高自己贡献的质量，来赢得其他开发者的认可。

事实上，在真正落地运作时，我们会发现这个价值引导会带来额外的好处，那就是常态化的相互点赞，可以很好的活跃社区的氛围。毕竟很多时候并没有那么多严肃的讨论可以进行，这种点赞在评价的同时，也变成了一种社交手段，使得在较严肃的开发环境中，社区中开发者之间有了更融洽的氛围，这种潜移默化的变化对我来说是一个惊喜。

尽可能长期参与贡献

在该算法中，任何刚刚进入社区的开发者的初始影响力均为 1，这意味着开发者如果仅有短期的贡献，一定很难上升到一定的高度，而由于每个月都会继承上个月的影响力作为初始值，那么长期贡献基本意味着影响力的长期增长。

而一旦贡献中断，则影响力会以 85% 的速度逐渐衰减，其实这里之所以选择 85% 这样一个并不高的比例，而不是直接清零，就是防止贡献者因为偶然中断的贡献而流失。85% 的速度意味着 4 个月停止贡献依然保留超过原始 50% 的影响力，而一年不贡献还保有 15% 的影响力。则开发者随时回到社区时，就可以快速续接之前的影响力，不会需要从头再来。

其他风险

其实对于任何的算法，都无法完全避免刷榜，事实上如果一个开发者通过大量提交无意义的 Issue 或 PR，也可以短期小幅提升自己在项目内的影响力数值，但显然这是对项目无益的。

所以这套算法本身不是要完全替代维护者来评判开发者的贡献度，而是一个参考与引导，如果出现破坏性的行为，我们可以通过社区规范来屏蔽甚至驱逐那些投机型的开发者。

其实信任是低成本高效协作的基础，而在数据越来越完善和开放的未来，个人信用也必将越来越重要，投机型的开发者不仅无法在一个项目中短期受益，甚至可能会严重危害他个人的长期发展，这是制度设计需要考量的事情，在这里其实我们可以大量借鉴已有的一些社会制度的设计原则。

OSCHINA：目前这套算法机制有没有在哪些开源社区落地呢?对社区和开发者带来了什么变化？

赵生宇：自己的狗粮肯定要自己先吃，事实上我们这套方案已经在 X-lab 开放实验室落地有半年左右的时间了，我们尽量将实验室的工作都线上化，沉淀在 GitHub 平台上，然后通过这套算法来评判同学们在实验室项目中的贡献情况并提供每月的额外补助。

从实验室所有项目的全域影响力来看，整体提升还是比较明显的，每月都有稳定的增长。而从我自己主要负责的项目上来看，同学们的参与热情还是有了较大的提升，而且由于算法本身的特性，没有来刷 Issue 的同学，而是多了几个长期深度参与到项目中的同学。

X-lab 开放实验室创始人王伟老师也总结道：“这段时间的运转甚至使得  X-lab 开放实验室的的社区文化也发生了一些潜移默化的变化：大家更愿意将自己的工作用 GitHub 的开放协作模式来运营了，例如论文阅读与分享；更愿意参与项目的讨论以及表情点赞了，甚至很多时候都是秒赞；更愿意拉一些其它同学一起来讨论与协作了，包括主动告诉大家发布了一个新功能或修了一个新 Bug；更主动为自己参与的项目打广告与宣传了，发展新的参与者。大家的成长是看得见的！”

另外，我们也和一些外部社区有深度合作，Sealos 社区也基于我们这套算法来做社区中的外部开发者回馈，据反馈效果也是相当不错的，外部贡献比例一直在稳步上升，而且也培养出了多个外部的长期贡献者。

所以从目前来看，我对这个算法未来的应用前景还是非常有信心的，但可能需要在更多的场景中落地来观察效果。

OSCHINA：用一套具体的数据和框架去评价开发者贡献，这是否和我们所提倡的 Geek、共享的开源精神所悖？

赵生宇：我认为贡献评价是对开源精神很好的补充与支持，不会和Geek、共享的开源精神所悖。

开源精神强调共享与奉献，但经济系统的有效性则来自于付出与回报的匹配。可能早期的 Geek 可以不计回报的开源出优秀的项目，或者将名誉上的收益看做是一种回报，但当开源作为一种开放协作的模式被大规模的推广，且开源软件伴随云等模式开始释放出巨大价值时，我们必须考虑到其长期发展中需要解决的问题。

OpenRank 的核心思想与传统的软件数据分析不同，并不强调数学模型和统计特性，而是更多的考虑协作中的社交属性，这与开源的开放协作模式也是高度匹配的。

我相信在付出与回报可以更好的统一和协调的未来，开源必将以更大的协作规模对世界带来不可估量的改变。

互动问答：如果你参与的开源社区使用该算法公开贡献者的排名，你会支持吗？

欢迎在评论区说出答案，我们会随机揪出 3 位小伙伴赠送精美福袋一份！