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

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

• 开源的贡献者想知道哪些开源项目具有影响力，自己该往哪个方向努力？

• 开源Community则希望能够吸收到更多的成员、确保始终如一的质量、以及奖励那些做出重大贡献的成员。

• 拥抱开源的公司则希望知道哪些Community和软件项目是值得合作的？通过交流能够产生一定的影响，以及想评估自己的员工在开源当中的工作。

• 开源非盈利组织，如基金会则希望能够识别出Community的需求，最好能做到积极的响应，进一步评估自身的工作，以促进community的良性发展

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

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

目前来说，有三类目标：

• 建立与实施无关的度量标准，以衡量Community活跃度、贡献以及健康度

• 开发和集成相应的开源软件，来分析Community的开发

• 构建可复制的项目健康报告

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

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

1. 多样性和包容性：目的是在开放源代码项目中引入经验以衡量一致性和包容性，并在可能的情况下获得软件的支撑。

2. Evolution指标（用于软件开发项目）：专注于开源项目的生命周期，

3. 通用指标：所有的用于Community和开源相关的指标均在这个工作组进行，除非需要特别的对待进而分离出更多的工作组。

4. 经济价值：围绕开源项目和Community的相关经济活动。

5. 风险评估：重点关注与开源风险有关的指标。

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

公司或企业项目的技能需求    有多少公司在使用该开源项目，如果一位工程师掌握了相关的技术，被雇佣的几率有多大？   

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

• 具体描述

• 目标

• 策略

• 成功的指标

         ????定性因子

         ????定量因子

• 已知的软件实现

• 参考资料

下面以开源之道最为关注的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/