【开源生态60问】——什么是开源项目的健康指标？
Yinchunyuan
开源项目的健康指标是用于全面衡量和评估开源项目可持续性、社区活跃度、代码质量及生态影响力的量化与质性标准。这些指标在开源生态系统中发挥着举足轻重的作用，能够为项目的维护者、贡献者以及各类相关利益者提供深入洞察项目实际情况的有力工具，对于把握项目的当前状况、预测其发展趋势以及提前识别未来潜在风险，都具有重大的价值。
1. 开源项目健康度评估的主流框架
在开源领域，主要有以下一些评估框架在探索如何评估开源项目、开源社区的健康度：最早也是目前发展最活跃的是由Linux基金会于2017年8月发布的“Community Health Analytics in Open Source Software”（开源软件中的社区健康分析，以下简称CHAOSS），还有在2021年3月红帽公司发布的“衡量开源项目健康状况的清单”，2023年2月，我国首个开源生态健康评估平台“OSS Compass开源指南针”正式诞生！
注：OSS Compass 由国家工业信息安全发展研究中心、开源中国、南京大学、华为、北京大学、新一代人工智能开源开放平台（OpenI）、百度、腾讯开源联合发起并协作开发。
1. CHAOSS指标体系
CHAOSS是Linux基金会旗下的项目，专注于通过指标分析来定义社区的健康状况。CHAOSS项目有以下4个目标：
（1）建立衡量开源社区健康状况的指标和模型；
（2）开发用于衡量社区健康状况的开源软件和举措；
（3）制定计划，部署无法通过跟踪数据实现的指标;
（4）与全球合作伙伴合作，塑造理解开源社区健康的方式。
CHAOSS的早期阶段
在早期阶段，CHAOSS提出了5个指标领域，并设立了5个工作组。
-
通用指标工作组（2024年1月后改名为指标开发工作组，Metrics Development Working Group），工作重点是确定多个工作组使用的指标或对社区卫生非常重要的指标，专注的领域又分为：
-
贡献——确定作出了哪些贡献（例如，代码提交、维基编辑、文档）；
-
人员——确定作出贡献的组织和个人（如贡献类型、人口统计等）；
-
地点——确定贡献发生的物理和虚拟地点（如GitHub、聊天频道、论坛、会议等）；
-
时间——确定作出贡献的时间（如回复时间）。
-
多样性与包容性工作组（后改名为多样性、公平和包容工作组，Diversity, Equity, and Inclusion Working Group），旨在定义衡量标准和方法，以帮助其他人在自己的开源项目中衡量和关注多样性、公平性和包容性，专注的领域又分为：
-
沟通包容性——确定我们如何与贡献者和潜在贡献者沟通；
-
贡献者社区多样性——确定社区内贡献的多样性，以及如何重视这些不同的贡献；
-
活动多样性——确定活动的多样性和包容性；
-
管理——确定我们的管理是否具有多样性和包容性；
-
领导层——确定我们社区领导层的健康程度；
-
项目和社区——确定我们的项目场所（社区参与的场所）的多样性和包容性；
-
表彰优秀作品——确定我们如何表彰/奖励社区中的优秀作品。
-
演进工作组，主要制定评估开源项目生命周期的指标，专注的领域又分为：
-
代码开发活动——了解代码开发活动的类型和频率；
-
代码开发效率——了解代码开发活动的解决效率；
-
代码开发流程质量——了解用于提高/审查质量的流程（例如：测试、代码审查、标记问题、标记发布、响应时间、CII徽章）；
-
问题解决——确定社区在解决社区参与者发现的问题方面的效率；
-
社区增长——确定项目社区的规模，以及它是在增长、缩小还是保持不变。
-
价值工作组，主要制定衡量标准，描述个人和组织参与开源活动的价值，但是现在已经不再活跃了。
-
风险工作组，重点关注与开源中的风险问题相关的衡量标准，专注的领域又分为：
-
业务风险——了解围绕/支持特定软件包的社区的活跃程度；
-
代码质量——了解特定软件包的质量；
-
许可——了解与使用特定软件包相关的潜在知识产权问题；
-
安全——了解与软件开发相关的安全流程和程序；
-
透明度——了解特定软件包在依赖性、许可证、安全流程等方面的透明度；
-
依赖性风险评估——了解软件依赖性风险。
CHAOSS的最新发展是“指标平铺，另外建立指标评估模型”。
通过阅读上述的分类，我们可以发现，CHAOSS指标体系存在交叠的现象，如演进工作组与风险工作组关心的内容就存在很多交叠，甚至在风险工作组的内部，与透明度相关的指标也会关注许可的风险。因此，在CHAOSS的官网上，目前（截止到2025年2月）的做法是将所有（89个）指标全部平铺展示，不再分类。另外，越来越多的社区实践者发现，原先对于指标定义的颗粒度过小，不能够具体地描述某个社区的实际场景。因此，在2021年，华为倡议成立了指标评估模型工作组，首次提出了评估模型的概念。经过近两年的发展，到2023年，CHAOSS社区把重心转移到了评估模型工作组方向。（来自2023年4月庄表伟对王晔晖的访谈。）到2025年2月为止，CHAOSS一共发布了17个指标模型（Metrics Models）。
试举一例，介绍指标模型与指标的关系。开发响应度（development responsiveness）是一个指标模型，这个指标模型的计算结果反映了与项目有效运营和扩展能力相关的一系列因素。响应度可以反映项目的投资（包括放弃）、能力，并且可以指示工程优先级，有时还会偏向于某些类型的交互和人员——响应度可以揭示很多东西，包括你没有注意到的东西，包括机器人在解决常见痛点方面的效果（或效果不佳）。
在开发响应度指标模型中，包含了4个指标。
-
变更请求审核周期。审核周期的时间长度衡量的是变更请求中一个完整审核周期所需的时间。一个审核周期从提交或更新变更请求时开始，到接受、拒绝或进一步请求变更时结束。这一指标可帮助维护人员评估代码审核流程的效率，找出潜在的瓶颈和出现延迟的地方。通过了解这些周期的持续时间，可以深入了解审核实践的有效性和项目中贡献的整体工作流程。具有不同周期模式长度的审核的特点。审核周期中的放弃或半放弃流程，即维护者或提交者响应缓慢。
-
变更请求持续时间。变更请求持续时间是从变更请求开始到结束（被接受并合并到代码库中）的持续时间。这仅适用于已接受的变更请求。
-
问题响应时间。此指标衡量问题从作者以外的贡献者收到首次回复所需的时间。问题响应时间是衡量项目响应能力及其吸引贡献者的能力的关键指标。响应时间短可能表明社区健康活跃，而响应时间较长则可能凸显出管理社区贡献方面的潜在问题。
-
缺陷解决持续时间。缺陷解决持续时间是指从报告软件缺陷到解决缺陷之间的中位时间，解决问题可能通过代码修改（合并修复）或拒绝报告/问题来实现。不同贡献者的问题或报告的解决时间可突出显示贡献者在处理报告/问题时是否面临延误。每个数据点都与缺陷报告/问题及其相应的解决行动相关联。如果缺陷解决速度较快，则表明项目的维护团队积极主动、反应迅速，有助于提高软件的整体质量和用户满意度。
对CHAOSS指标体系的评价
CHAOSS指标体系是一个非常活跃且依然在快速变化的指标体系。作为一个全球协作的开源项目，CHAOSS提出的很多关于开源项目健康指标相关的思想都非常值得借鉴。但是由于社区，成员的兴趣比较分散，各种各样的指标层出不穷，但却难以落地。在开源社区中实际工作的很多朋友都逐渐产生了疑惑，也不太在实际工作中使用消费他们的指标体系了。
2. 红帽公司发布的衡量开源项目健康状况的清单
2021年3月，红帽公司发布了“衡量开源项目健康状况的清单”，相对于CHAOSS，这个清单提出了一个简明扼要的框架（检查清单），将衡量一个开源项目的健康状况分为7个大类，10多个小类，若干检查项，至于如何进行具体的检查看起来是一个完全手工的过程。另外，这个检查清单也不提供综合评价的计算方案，或者不同的项目之间如何比较健康度的机制。
衡量开源项目健康状况的检查清单具体如下。
-
基础设施
-
最基本的基础设施
-
项目网站
-
治理
-
项目授权协议
-
项目领导
-
治理模式与过程
-
发布管理
-
发布频率
-
发布约定
-
发布工具
-
发布可用性
-
新人培训
-
新人指南
-
贡献者培养计划
-
文档
-
文档内容和样式
-
文档编写实务
-
推广运营
-
项目讯息
-
项目讯息
-
推广频率
-
推广活动
-
贡献
对红帽公司“检查清单”的简单评价
这样的检查清单有助于快速了解开源项目健康度的相关概念与涵盖范围，但是对进一步实操没有太大的帮助。
3. OSS Compass开源指南针
2023年推出的开源生态健康评估平台——OSS Compass开源指南针，是一个兼具理论深度与实用价值的平台，由国内的多家高校、企业、开源社区联合打造。开源指南针展示的开源生态评估体系包括开源生态、“协作、人、软件”和评估模型，如图2-2所示。
图2-2 OSS Compass 开源指南针的开源生态评估体系
基于南京大学的陶先平老师、汪亮老师的研究成果，开源指南针针对开源生态构建了生产力、稳健性和创新力三大核心维度的模型。
（1）生产力：开源生态将投入转化为产出的能力，包含协作开发指标和社区服务与支撑指标两个主要的评估模型，如表2-*和表2-*所示。
表2-* 协作开发指标
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表2-* 社区服务与支撑指标
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（2）稳健性：生态系统面对内部或者外部冲突自我恢复的能力，目前只包含活跃度一个评估模型，如表2-*所示。表2-* 活跃度指标
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（3）创新力：生态系统持续创造多样性创新的能力，即社区生态向前演进的动力，目前只包含组织活跃度一个评估模型，如表2-*所示。
表2-* 组织活跃度指标
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
另外，开源指南针还根据生产力评估一个开源生态将投入转化为产出的能力，包含3个模型。
-
贡献者领域划分模型：将贡献者分为观察、问题、代码、论坛聊天、媒体平台、活动和赞助。
-
贡献者角色划分模型：将贡献者分为组织/个人管理者、组织/个人参与者。
-
贡献者里程模型：将贡献者参与社区的里程分为核心、常客、访客、静默与无状态。
对开源指南针指标体系的评价
开源指南针指标体系是一个面向实用的开源生态指标体系，从一开始就有一个思路清晰的顶层架构，然后层层追问，层层分解，落实到各个可观测的数值。另外，开源指南针还提供了一个方便部署的开源的Compass平台系统，既可以通过这个项目的官网直接使用，也可以在自己的本地部署、内部使用，具备相当高的使用价值。
2. 深入思考开源指标体系
在经过上述的三个开源指标体系的介绍之后，我们需要按下暂停键，不必急着开始使用这些指标，而是思考一下这些指标是怎么来的，到底意味着什么。
面对开源生态，有两个目标是非常明确的：一个是从问题出发指向数据的，我们有很多很多的问题，这些问题需要寻找答案，而我们希望通过数据得到答案；另一个是从实际已有的数据出发指向问题的，我们有很多很多的原始数据，这些数据需要确认他们的意义，用来回答可能会被用户提出的问题。
而在问题与原始数据之间，我们试图通过指标来实现上述两个目标。但是，难点在于：从问题出发，想要设计指标来寻求答案的努力，很可能找不到合理的、正确的原始数据；从原始数据出发，通过各种“拍脑袋”的计算方法得到的指标，说不清能够回答什么问题。
还有一个难题，是因果关系的复杂性。从社区活跃到用户增长，从用户增长到产品成熟，从产品成熟到商业成功，我们隐隐约约感觉到其中是存在着因果关系的，但是如何通过“可观测的现象”建立“量化的指标”，再通过各个指标之间的相互影响证明因果关系真实存在，也是非常困难的。
另外，建设真正合理的开源指标体系，还需要更加规范化的案例研究，比如一个项目有10万个点赞，有5万个用户下载（假设能够统计到），每天有100个新增的问题，这样的项目到底算不算成功？算不算健康？到底成功或者健康应该和哪些项目进行比较？不同的编程语言、不同的技术领域、不同的商业场景，开源项目之间很可能是无法横向比较的（或者即使能够进行比较，也是不公平的）。可能我们首先需要基于实际的、成千上万的开源项目案例，达成定义、分类、判定优劣方面的共识，在此基础上建立的指标体系，可能才是更有说服力的。
至于现在已经出现的这些指标体系，可能还处于早期探索的阶段。我们在实际的工作中，可以参考这些指标，但不必迷信具体的数值，同时也建议积极参与到指标体系的建设社区中去（他们本来也是欢迎所有人参与贡献的开源项目）。
转载自 庄表伟 阅读思考与生活 【开源生态60问】——什么是开源项目的健康指标？