OpenDigger

在国内开源项目活跃度PAM(Project Activity Metric)中，SRS排第38名，这是音视频圈大师兄都认可的排名算法，要知道大师兄认可的东西那不容易，必须得客观才行。

这个不仅仅是个名次问题，更重要的是它代表了开源项目的健康度，是非常难得的一种算法，值得每个开源的开发者了解，特别是开源项目的维护者。

开源项目好不好，先看Star，再看PAM。

我先从SRS的经历，分享下为什么对这个PAM指标这么重视。

备注：本文有不少链接，可以阅读原文，打开Github的版本。

Why Important

如果按Star算，SRS是全球开源音视频服务器Top1，明显Star不能完全代表江湖地位，特别是项目的健康度。

我们SRS社区委员会早就达成了共识：开源项目的健康程度是社区，而不是代码或者Star。这都是人性的贪婪吧，有了Star了，就觉得不重要了。

只有健康的社区，才能长长久久的维护开源项目，如果项目都不维护了，跟不上技术特别是音视频技术的的快速发展，迟早要淘汰，谁选择谁就是跳到大坑里，一辈子都填不完。

那么SRS的社区健康程度怎样？Star只能说明受欢迎程度，并不能衡量社区。衡量社区，明显Star这个指标是不行的，应该用核心开发者的活跃程度，也就是PAM(Project Activity Metric)。

何况还能刷Star。。。

开源项目的活跃度PAM，有个专门的开源社区open-digger在研究这个，用以下的指标来计算项目的开发者的活跃度：

• Issue comment和Open issue: 就是Bug的讨论和评论，Bug是开发者交流的一个地方，也是项目沉淀的方式，有问题肯定先在Issue里面搜。
• Open pull request，Pull request review comment和Pull request merged：PR更加明确了，包括PR的次数，以及Review的Comment，健康的项目肯定有很多的PR以及探讨的过程。
• Watch和Fork：没有Star，有Watch和Fork，这代表订阅项目的动态，以及想保留一份副本使用。

具体算法参考Github 2020: Digital Insight Report第8页。

开源项目的活跃度，是用项目的开发者活跃度计算的，大概可以认为是加权平均吧，就是参与的越多越活跃，分数就越高。

具体算法参考Github 2020: Digital Insight Report第15页。

这么多指标，能刷么？能刷一两个月吧，但这个活跃度是会清零的，是一定时间的分数，所以一年两年，五年十年，肯定就刷不了了。

对于开发者的价值，是在选择开源项目时，除了Star还应该要关注项目的活跃度，这样才不会用着用着发现入坑了。

对于维护者的价值，是可以了解目前社区的建设，如果一个人在维护也是有活跃度的，当然不如建立社区多个活跃的开发者的分数高。

说到这里，大家可以理解，为什么大师兄觉得这个指标很赞了吧，它反映的是项目健康程度。活跃的项目就是健康的项目，不活跃一定是不健康的。

终于，除了Star，我们还可以看看项目的活跃度了。

SRS的PAM

SRS在2021年的活跃度PAM(Project Activity Metric)是中国开源项目的38名，分数是700分左右，而180天的活跃度是575分。

之所以单独弄个中国区的开源项目，是全球排名还排不上，太让人绝望了。

SRS的活跃度PAM其实不算高的，因为我们这两年才开始建立核心开发者的社区，加入木兰社区孵化后，我们有了旗帜知道为了什么在贡献，也会有线下的聚会，也有了文化衫。

作为SRS的维护者，我更关注的是SRS的趋势，因为社区运营会尝试很多方法，比如我们每周六的直播答疑，就是2021年的重点工作。无疑这是提升活跃度的方法。

明年SRS还会尝试其他的社区活动，这些社区活动，对于活跃度的影响是什么，我们当然能够定性的感受到，但是能有量化的指标，会更方便确认和展示，以及经验的积累和复制。

从目前的活跃度PAM，给我的启示是：

• 这三个月的分数，比全年的低，实际上我们感知的核心开发者的活跃度是在上升的。我想很有可能是我删除了大量无效的Issue，大约2/3的Issue吧，沉淀下来的Issue都是有效的。长远来看活跃度会回升，相当于挤掉了之前活跃度的水分。
• 之前Reivew PR上花的时间太少，现在我们技术委员会已经在投入固定的时间看PR和解决Issue，所以这个也是我们意识到的问题点，长远看活跃度也会提升。
• 还有很多开发者，喜欢在Issue中提Patch，可能不熟悉提PR的流程，或者觉得太麻烦了，或者觉得成为项目贡献者没有什么必要，所以未来这也是值得投入的。

从这些改进措施来看，项目活跃度PAM指标，确实能指导我们平时的工作方向。当然如果能给出各个指标的趋势，那会更好。

我们在社区委员会讨论过，是否PAM也能作假？肯定有作弊的可能，雇人一直刷Issue当然可以，但是这样做的价值很少。之所以刷Star，是因为Star是累积的，而PAM并不是累计，而是看一段时间的数据，这样作弊的难度高价值就不大了。

如何看自己项目的PAM

可以在open-digger中提交Issue或者PR，来统计自己项目的活跃度，当然这个不能立刻看到数据。

还有个简单的办法，安装Chrome扩展hypertrons-crx，安装扩展（注意有两个，别装错了，看下备注，id是ijchfbpdgeljmhnhokmekkecpbdkgabc）。

然后在Github上生成Token，Settings / Developer settings 创建一个Token，填到扩展的配置中。

打开项目的主要，就会多了一个Perceptor的选项卡，是这个扩展添加的，点开就可以看到项目的分数了。

在Project Correlation Network的中心的项目，就是本项目的分数。

Next

OpenDigger Global Study Report可以看到Github上全球活跃度的趋势，也有全球Top活跃的项目的分数。呃，SRS差得不远，也就是一个到两个数量级吧，哈哈哈，这是我们要努力的方向。

Chinese open source study report这是中国开源项目的活跃度情况，SRS挣扎着还是可以在TOP100之内的，我们目标，是争取10年左右自然发展到Top10吧。

我使用下来还有一些建议：

1. 我了解到，算法还会有些调整。当然是为了更好的完善活跃度，当然我认为最好别整天调来调去，否则历史图就没有作用了。如果要调整，最好能让用户指定算法，这样可以使用同样的算法来评估一年的活动。我认为分数重要，更重要的是变化，自己和自己比较的变化图，对于指导社区工作是有很大作用的。
2. 目前还没有历史图，当然SRS是自己隔一个月左右会记录下目前的数据，自己在官网绘制的历史图。除了PAM我们还有Star，也是自己会记录历史图。因为历史图的曲线会有斜率变化，是比固定的值更有意义。
3. 还没有分垂直领域的项目的分数对比，这对于开发者选择自己领域的开源项目，也是很有参考价值的。当然，更卷了。

其他的可以改进的点：

1. 算法比较隐晦，给了我一个链接，打开看和一本书差不多。不过我还是在第8页和第15页找到了算法怎么算的，有数学公式，这对于其他开发者无疑是在劝退了。建议在报告中大概说明下怎么算出来的，不用很精确，这样让开发者大概了解就行。
2. 建议不要特别纠结于精确的算法，一定要重视兼容性，不要把算法改来改去的。就好像高考的评分标准，每个月改一次，还怎么考试，每次算法修改，都应该看作是一次大重置。数据当然是直观的，但是也别期望数据能有多正确，比如我把没用的Issues清理了，分数还下降，但这肯定对于项目活跃度是好的。数据应该是参考的定位，而不是决定性的。
3. 使用说明比较少，我也是花了大概3小时搞明白这个怎么算的，以及到底是否有作用。开发者和开源维护者，虽然很聪明，但他们是不可能花多少时间了解包子是怎么制作的，所以比较方便的看到自己的项目，还是要多投时间。

总结起来说，个人认为项目活跃度PAM(Project Activity Metric)是非常非常有价值的指标，大家多关注下官方的Github和微信群。

• open-digger：PAM(Project Activity Metric) 计算
• hypertrons-crx：PAM(Project Activity Metric) Chrome扩展
• Frank: GitHub 开源行为大数据分析： PAM(Project Activity Metric) 解读

End

最后，感谢木兰社区，加入木兰社区孵化后，SRS的社区能力逐步增强，核心开发者越来越活跃，项目的活跃度也越来越高了，越来越健康了。

木兰社区是开放的开源社区的社区，欢迎大家加入。