如何评价一个开源项目？是它了

到底哪些数值需要被纳入，例如 star、fork 是否应该被纳入，是不太确定的。尤其是在活跃度这样一个概念下，那些对项目没有带来实际反馈的行为是否要纳入进来极为微妙。

不同行为的权重是人为指定的，虽然包含了一定的专家经验，但这些数值的大小其实是还是具有相当的主观性，尤其是在项目之间比较时，权重的微小差别就会带来一些总体活跃度的波动。

这种活跃度计算方式缺乏基线。由于这里的活跃度是对一段时间内的行为次数的统计，所以时间段不同，则活跃度不同，时间段越长，活跃度越高。因此在不同时间段上无法进行直观的比较，这种缺乏基线的计算方式对于给出活跃度的参考阈值是不友好的。

这种活跃度计算方式在仓库层面不具有线性可加性。为了引入贡献者数量的因素，在仓库活跃度求和时对开发者活跃度开方，这个非线性操作导致了仓库活跃度在时间区间不能线性可加，这对多时间段的运算造成了比较大的影响，使得一些中间结果无法被复用。

个人活跃度到仓库活跃度的开方操作本身也是一个人为的经验做法，本质上就是想引入一个一阶导数单调递增，二阶导单调递减的函数来进行修正，模拟一种边际效益递减效应。显然不仅是开方，对数函数也满足这种性质，而且对数函数在此类计算中非常常用，而我当时选用开方是考虑了计算效率问题，因为开方运算在很多语言下都比对数运算要更快。

只要是简单的统计指标来进行计算，就一定无法避免刷指标的行为。事实上，当我们在阿里内部开始推行这个指标体系时，有部分开发者的活跃度有了一个跳变。原因其实是原先这个项目的负责人不知道如何在 GitHub 进行 review，在看到这个指标体系之前都是在即时通讯工具中进行同步聊天的 review，但在我们的推广和教育后，对过去的一些代码 review 进行了集中的补充。这也是我们认为好的指标体系可以起到的作用，即便是刷指标，但我们认为该指标是起到了正向的引导作用。而且之后也没有发现有其他项目通过刻意增加回复数量、拆分 PR 等方式恶意刷活跃度的情况，毕竟开方操作本身使得个别账号的这种刷分行为对整体仓库的影响是有限的。因此在这个指标下的刷分行为目前来看是起到了预期的价值导向作用。