开源软件项目的定性和定量分析指标 ———— CHAOSS 指标解析

“科学管理在实质上要求任何一个具体机构或机构中的工人及管理人员进行一场全面的心理革命，没有这样的心理革命，科学管理就不存在。” ———— 泰勒 《科学管理原理》

引言

笔者最近阅读了CHAOSS 在8月份发布的开源软件项目的量化指标，颇受启发，于是索性将所想所得和大家分享一番，开源之道走过了这几年，抽丝剥茧，一直试图找到和大家探讨的话题，一同解决令人困惑的难题，但是缺少必要的积累，一直倾向于定性的探索和研究，鉴于知识背景和视野的不同，于是很难找到让大家感兴趣的话题，甚至某位朋友善意的提醒：“多讲点实在的”，多年过去了，我也终于对关于定性的问题有了一些理解和认识，那么这也意味着是该集中起来做些定量的指标衡量的事情了。

当然，伴随着科技的进步，很多人开始迷信数据，比如流行GitHub star数量、fork数量等等，这尤其体现在某些公司做考核之用，非常的实惠。但是这并不是开源之道所看重的，尽管量化指标很重要，正如红帽开源项目办公室的高级首席社区架构师Brian Proffitt（同时也是CHAOSS的治理委员会成员）所言，你有了指标和衡量，就一定保证Community是健康的吗？对此开源之道是颇为赞同的，一直以来坚持在没有搞清楚性质之前，不要去迷信数据的缘由。

如果搞清楚了定性的问题，那么量化指标是自然而然的事情，毕竟这是一个科学管理为王的世界。所以开源之道接下来会有意的写一些关于指标量化方面的文章和知识输出。

什么是CHAOSS？

开源的重要是不言而喻的，大家默认都是承认开源对于我们所生活的世界的重要性的，也是可以看得到的，唯一的问题就是所有权下的经济形式限制了很多人的思考模式，如何从中获利？需不需要承担其中的道德责任？更有甚者便是随着开源生态的形成，问题反而更多，大家对其的关注度越来越高。例如：

• 开源的贡献者想知道那些开源项目具有影响力，自己该往哪个方向努力？
• 开源Community则希望能够吸收到更多的成员、确保始终如一的质量、以及奖励那些做出重大贡献的成员。
• 拥抱开源的公司则希望知道那些Community和软件项目是值得合作的？通过交流能够产生一定的影响，以及想评估自己的员工在开源当中的工作。
• 开源非盈利组织，如基金会则希望能够识别出Community的需求，最好能做到积极的响应，进一步评估自身的工作，以促进community的良性发展

所有的这些问题，都是需要一些数据和指标来进行衡量的。当然也是所有开源Community所必需的内容。

为了解决这些问题，CHAOSS 应运而生，开发开源的指标、方法论、以及相应的软件项目，旨在让开源项目能够良性的发展且具有可持续性，通过衡量开源项目的健康度和可持续性，进一步，CHAOSS 会寻求提高开源项目健康度和可持续性的可操作性，进而让所有的利益相关者能够做出更加明智的决策，而不是在盲人摸象般的行进。

CHAOSS 的目标

目前来说，有三类目标：

• 建立与实施无关的度量标准，以衡量Community活跃度、贡献以及健康度
• 开发和集成相应的开源软件，来分析Community的开发
• 构建可复制的项目健康报告

CHAOSS 是Linux基金会下的项目。区分了两个委员会和五大工作组。委员会主要区分为指标委员会和软件委员会。顾名思义，指标委员会即是实现上述目标一的决策机构。

五大工作组的任务和方向

工作组的目标即完善开源Community相关的指标，并确保其可以使用相应的软件可以实现。使用 GitHub 的项目进行组织和管理，具体的有：

1. 多样性和包容性：目的是在开放源代码项目中引入经验以衡量一致性和包容性，并在可能的情况下获得软件的支撑。
2. Evolution指标（用于软件开发项目）：专注于开源项目的生命周期，
3. 通用指标：所有的用于Community和开源相关的指标均在这个工作组进行，除非需要特别的对待进而分离出更多的工作组。
4. 经济价值：围绕开源项目和Community的相关经济活动。
5. 风险评估：重点关注与开源风险有关的指标。

解析指标

让我们回到CHAOSS在2019年8月份发布的指标本身上，总结起来可以使用下面这个表格来涵盖所有的内容：

具体良好的内容，在本指标中有如下格式来进行立体的叙述：

• 具体描述
• 目标
• 策略
• 成功的指标
  • 定性因子
  • 定量因子
• 已知的软件实现
• 参考资料

下面以开源之道最为关注的Elephant Factor为例给大家进行一番示例：

Elephant Factor 指标

描述：

所谓的“Elephant Factor”，其实来自于英语世界的“房间里的大象”这样的说法的，放在开源项目代码当中，即是指代码仓库中的总的提交中，公司的占比数量。例如，一种常见的过滤器是说50％的提交是由n家公司执行的，这就是“Elephant Factor”。先是以贡献度最大的公司，然后是贡献量次之的公司，以此类推。例如，如果一个项目有8个参与组织，每个组织贡献了项目中的12.5％的提交，如果将Elephant Factor参数化为50％，则Elephant Factor为“ 4”。如果在相同的情况下，其中一个组织负责50％的提交，则Elephant Factor将为“ 1”。

Elephant Factor 提供了清晰明了的指示，用来标识出一个项目中的最小化公司参数（如50%），Elephant Factor 这一专业术语是由Venters等人（2014）提出，主要用来表述软件的可持续性发展中非功能性部分的关键指标，但是他们并未在文献中像本文这样明确的定义。

具体的公式描述请见：Elephant Factor 公式

目标：

评估开源软件产品的公司可能会使用 Elephant Factor 来比较项目对一小部分公司贡献者的依赖程度。显而易见，一个低 Elephant Factor 的项目对于决策者来说更具吸引力，没有人愿意看到开源项目是某一家公司所事实上把控，当然，该参数在根据不同的项目应该有所调整，具有1000个组织参与的项目和只有10个组织参与的项目是非常不同的。也有仁者见仁智者见智的看法。

样本的过滤和可视化：

• 时间：要动态的看待Elephant Factor，也就是说查看结果的时候，要关注一下时间，要纵观全局，准确把握软件的生命周期。
• 仓库group：（现代）软件项目一般都拥有非常多且分散的代码仓库，在某些情况下，检查与任何给定项目相关联的所有代码仓库，可以更全面地了解Elephant Factor。

已知的软件实现：

1. Augur 已实现该功能。
2. Grimoirelab提供该功能，不仅仅是一串数字，还将之可视化了。按如下方式操作

• 查看有关Bitergia Analytics的CHAOSS实例的示例。
• 下载Grimoirelab 所给的示例代码。
• 按照如下步骤在GrimoreLab Kibiter面板中显示出来：
  • 新建一个饼图
  • 选择git的索引
  • 指标切片大小：Count聚合
  • Buckets 切片：Terms聚合、author_org_name、按metric: Count和Descending排序、500大小，如下截图所示：

参考资料：

• Colin C. Venters, Lydia Lau, Michael K. Griffiths, Violeta Holmes, Rupert R. Ward, Caroline Jay, Charlie E. Dibsdale, and Jie Xu. 2014. The Blind Men and the Elephant: Towards an Empirical Evaluation Framework for Software Sustainability. Journal of Open Research Software 2, 1. https://doi.org/10.5334/jors.ao
• 什么是大象因子
• eclipse新的开放式分析面板
• https://www.stackalytics.com/

开源之道点评

在定量分析的道路上，人类从未放弃过努力，统计学的蓬勃发展和人工智能的突破就是最好的明证。

软件工程是前所未有的复杂，随着技术的发展，大量人员的参与，复杂性日益增加，即使是在某个区域下的某个组织，开发一款软件也是足够复杂的了，更何况是充满不确定性的开源项目。但是由于开放的、多样性的、动态的实用主义的成功，诞生了非常重要的开源项目，并在人类的生活中发挥着非常重要的作用，那么其中发生效用的究竟是什么？是冥冥之中的神力吗？还是仅仅依靠运气？目前为止，还没有确切的答案，只有无数的试图找到答案的充满好奇和激情的人类。

或者正是因为没有确切的答案，才能够更加的吸引人，充满了迷人的魅力。但是也因为没有确切的答案，鱼龙混杂、真假难辨，被一些别有用心的人利用。人类和人类社会都是异常复杂的，一个微小的心理变化，产生出完全不同的历史后果，而挖掘的每一个量化的因素，都需要花去一群人相当的精力和时间，而且还要经历时间的验证。

从微观到宏观，在开源软件项目中，可以体现得非常明显！一连串的决策思路和基本条件都让我们有机会去捕捉和分析，想象力才是决定你能够走多远的极限。

接下来的工作

开源之道将会在2020年，做一些关于定量分析的学习和工作：

1. 参与到CHAOSS Community中，希望能够有所贡献吧。
2. 按照该方法论和软件、指标，分析一些较为特定的项目，能够形成一定的模板是最好不过的了。

Good Luck！