从业者指南：评估可行性
如果您还没有阅读 从业者指南：简介 - 解释指标时要考虑的事项，请现在暂停并阅读该指南。
受众/范围
本指南主要面向开源项目办公室 (OSPO) 和组织内需要了解其所使用的开源软件的可行性和风险的其他团队。
介绍
97% 的代码库（Black Duck 2025）中都可以找到开源软件，但与大多数软件一样，质量参差不齐，一些开源项目从长远来看比其他项目更具可行性。评估参与特定开源项目的可行性及其风险非常重要，这样可以避免工作中断，从而影响向客户交付产品和服务的能力，尤其是在某个关键依赖项突然变得不可行的情况下。将可行性和风险视为一个连续体非常重要，因为项目在各种类别中的可行性或多或少都会有所不同，而是否应该接受一个项目并接受随之而来的风险是一个战略决策，取决于您组织的需求和相关技术的用例。评估开源项目的可行性，尤其是那些可能影响您业务的项目，是管理风险和降低潜在业务中断可能性的良好开端。
使用开源软件的公司（即 他们都是) 越来越多地考虑物料清单、漏洞和许可证风险。这尤其体现在最近的 美国的努力 和 欧盟网络弹性法案（CRA） 关于软件物料清单 (SBOM)。这次推动是观察和报告软件供应链的好机会。我们都可以通过了解软件依赖关系来学习！ 物料清单, SAST （静态应用程序安全测试） SCA 软件组件分析 (Software Composition Analysis) 扫描工具可以帮助软件用户和开发者更好地了解其风险组合。大多数人认为，使用这些报告可以发现至关重要的漏洞、许可证信息以及其他可能影响您正在使用的开源项目可行性的问题，从而获得巨大的价值。
安全性是决定开源项目可行性的重要因素，但任何软件组件的安全性都取决于其依赖项的安全性，因此评估可行性需要超越单个项目。需要注意的是，热门软件包遵循良好安全实践的可能性并无高低之分 (Imtiaz 2022)。这不仅关乎依赖项的选择，还需要考虑如何保持这些依赖项的更新，因为使用过时的依赖项时，出现安全问题的可能性会增加四倍 (Cox et al. 2015)。
在考虑开源项目的可行性时，安全性可能是首要考虑因素，但还有其他因素也需要考虑。项目的治理方式以及社区如何协作构建软件也同样重要。我们也有一些用于评估项目可行性的战略指标。本指南提供了评估以下四个类别的可行性的建议：合规性和安全性、治理、社区和战略。
挑战
在许多公司中，并没有严格的流程来选择最有可能长期有效的依赖项。产品团队，甚至是个人软件开发人员，通常会选择开源项目，因为它们满足了特定的技术需求，而没有对项目的可行性或使用项目可能承担的风险进行任何评估。挑战性的问题包括：
- 在选择开源软件时我们还应该寻找什么？
- 我们可以提供什么指导来鼓励做出正确的决定，而不仅仅是在维护软件时？
- 这种指导是否应该与人们决定使用哪种软件时的指导有所不同？
- 我们能否提供工具和指标来指导决策？
- 我们怎样才能在选择中减少风险，提供更可持续的软件基础设施？
通常，有意引导技术讨论的团队必须依赖现有的安全或许可合规性架构。对于使用这些框架的主题专家来说，主要挑战在于缺乏指标和系统来传达在选择开源依赖项时需要考虑的其他重要因素。利用可行性，我们可以创建度量标准，从而对软件依赖项进行更彻底的分析。
经验教训
我们最近看到一波单一供应商开源项目从贡献者许可协议 (CLA) 转向更严格的许可，在某些情况下，重新许可导致了原始项目的硬分叉。例如 Elasticsearch / OpenSearch、Terraform / OpenTofu 和 Redis / Valkey。这些重新许可事件及其导致的分叉可能会对使用原始开源项目的公司和个人造成干扰 (Foster 2024)。当这种情况发生时，公司通常会争先恐后地决定是否能够继续在新许可下使用该项目，是否需要支付许可费，或者是否应该切换到其他技术（可能是分叉）。
除了重新授权之外，公司还可能做出其他商业决策，导致不再资助员工参与开源项目，这可能导致项目一次性失去大量维护人员 (Egbahl 2016)，从而降低其生存能力。Avelino 等人 (2019) 发现，即使是热门项目也可能被永久放弃，如果大部分工作由一个人或少数人完成，那么一旦该人或这些人不再参与项目，项目就可能变得不可持续，风险就会增加。
过去几年，我们遇到了几个备受瞩目的漏洞，这些漏洞表明广泛使用的项目也可能存在可行性问题。以 OpenSSL 为例，在 Heartbleed 安全漏洞爆发时，许多人了解到这个广泛使用的项目是由两个工作过度且薪水过低的人维护的，他们难以完成 OpenSSL 所需的工作量。几年后，XZ 项目也出现了一个类似的例子，这表明，如果有人参与项目并做出了足够多的优秀贡献，说服了一位工作过度的维护者让他们帮忙维护项目，但最终却引入了恶意代码，那么会发生什么。这两个例子凸显了评估我们所使用的开源项目可行性的重要性。因此，我们评估贡献者缺席因素，以了解有多少维护者像 XZ 那样领导了大多数项目代码贡献。我们还可以了解变更量及其随时间的变化趋势，从而了解项目何时会受到复杂性和贡献不足的影响——就像 OpenSSL 的情况一样。
这些只是一些可能导致项目使用风险增加、可行性降低的例子。通过提前评估可行性，组织可能会决定不使用某个开源项目。在其他情况下，组织可能会决定使用可行性较低的项目，但在项目内部进行改进以提高可行性，从而降低评估过程中发现的一些风险。
如何采取行动
在评估使用开源软件项目的风险时，通常会关注安全漏洞和许可；然而，还有很多其他方面也需要考虑。CHAOSS 的可行性指标模型将可行性分为四个关键类别，每个类别包含许多指标，但其中一些指标会重叠出现在多个类别中： 合规与安全、治理、社区、 和 策略.
本节的其余部分将介绍我们正在使用的指标以及它们之间相互关联的缘由。我们总结了每个类别中的指标，并概述了它们相互关联的缘由。我们还将介绍跨类别指标的价值主张，并提出行动和缓解措施的建议。
合规性与安全性
合规性和安全性评估项目许可的适用性、漏洞风险和维护活动。用户必须履行其对组织或开源软件项目创建者的任何责任。
CHAOSS 指标：
- 这是一个代理指标，用于确保项目能够响应安全事件，并拥有足够的保护措施，从而大致解释可靠的合规性和安全策略。它还可以避免在每个开源项目上使用昂贵的 SCA / SAST 扫描。
- 许可证覆盖范围用于决定使用未经许可的软件的风险。
- 声明的许可证可以透明地显示软件包中存在的潜在许可证冲突，并可用于确定软件的用例是否与提供的许可证兼容并符合组织许可证政策。
- 符合 OSI 标准的许可证为如何按照这些许可证使用软件提供了信心。
- 该指标提供了一种方法来考虑项目之间出现缺陷时的不同响应率。
- 通过同时考虑被评估的项目及其依赖项，可以确保项目的依赖项也包含在任何可行性评估中。
- 该指标衡量了软件依赖关系的新鲜度，突出了使用可能因依赖关系未定期更新而产生隐藏维护成本或安全漏洞的项目所带来的风险。
其他注意事项：
- 这使我们能够考虑项目如何应对安全漏洞。
- 项目的安全政策文档应包含一个流程，允许任何人私下报告漏洞，并快速有效地处理这些报告。此外，还应包含一个禁令流程，用于私下通知使用项目的组织，以便这些组织在漏洞公开之前有时间应用安全修复程序。
合规性和安全性对于可行性意味着什么
此指标模型有助于衡量社区和应用程序维护人员对其应用程序安全性和合规性的考量程度。我们期望使用这些指标来评估风险。我们关注的重点包括许可证（许可证可能与我们预期的用例不兼容）、以安全为中心的徽章和指标，以及团队维护其应用程序依赖项和缺陷报告的速度和频率。
此外，与其他模型一样，某些指标难以追踪或可视化。我们保留了灵活性，可以根据一些难以收集的指标对应用程序进行排序。例如：与缺陷解决时长类似，项目需要多少 Libyears 才合适始终取决于维护人员。Libyears 的计算需要根据应用程序的运行方式、运行位置以及更新频率进行慎重考虑。
治理
治理类别主要关注维护者及其工作，因为开源项目治理有助于定义决策流程。理解“维护”是项目整体可行性的重要组成部分，因为项目的维护者是即将发生的变更、新版本发布以及未来项目方向的守门人。
仅包含在此类别中的指标：
- 问题标签包容性衡量项目问题对于不同技能水平和背景的贡献者的可访问性和包容性。
- 文档可用性通过确保清晰度、可读性、包容性和可访问性来评估开源项目文档为贡献者提供的服务效果。
- 这衡量了贡献进入项目所需的时间
- 问题年龄考虑的是问题、建议和其他问题在项目中通常停留多长时间而未得到解决或关闭。
- 这有助于了解一个项目是否有足够的维护者来跟上项目的贡献。
- 该指标是其他较小指标（例如，喜欢、星星、徽章、分支、克隆）的集合，可提供使用情况和采用情况的指标（Vargas 等人，2024 年）。
- 发布频率有助于了解项目将更改和安全修复纳入发布需要多长时间，以及何时可以预期安全补丁、错误修复和新功能。
- 该指标衡量了软件依赖关系的新鲜度，突出了使用可能因依赖关系未定期更新而产生隐藏维护成本或安全漏洞的项目所带来的风险。
其他注意事项：
治理文档:
- 了解协作如何发生以及决策如何做出对于可行性很重要，因为它可以清楚地说明项目的管理方式，并意味着人们能够做出更容易被接受的贡献。
- 作为项目治理的一部分，协作和决策过程应明确记录。
- 项目内部应该有关于领导层的记录，包括领导者的组成和选拔方式。理想情况下，应该有一个公平透明的流程来选拔领导者，并由具备相应专业知识和足够时间来领导项目的人员担任领导职务。
- 整体所有权结构通常会影响项目的日常管理方式以及其他人对项目的看法。
- 中立基金会提供了一个公平的竞争环境，个人贡献者可以平等地做出贡献，这使得公司可以在一个中立的环境中合作，没有任何一家公司能够控制项目。
- 公司或个人拥有的项目可能不太可行，因为他们可以做出影响项目用户的单方面决定（例如，许可证变更）或停止继续开发和维护（例如，重大生活变化或停业）。
治理对于生存力意味着什么
这些指标有助于展现项目治理的意图。例如，如果问题缺乏包容性标签，则表明在欢迎新贡献者和通过工作流筛选现有贡献者方面存在差距。贡献、理解或依赖项目的能力与治理背后的努力密切相关。
这并不是说糟糕的治理指标表明项目是由傻瓜管理的。例如，变更请求关闭率低可能仅仅表明维护人员不足以支持贡献社区。缺乏新问题可能是由于最近发布的大型版本解决了许多重复出现的问题。这些指标对于汇总这些原因很重要，而不是对项目维护人员产生专业怀疑。这些指标有助于识别软件组合中各个项目的治理能力和工作量。
如果其中一些指标感觉可以成为强有力的社区指标，那么它们确实可以。这里的许多共享指标都结合了社区对项目的努力以及项目管理机构的努力。考虑到贡献者和维护者在创建开源软件方面共同承担的责任，共享指标的重叠部分很好地体现了这种关系。
社區
可行性的一个关键因素是社区活跃度和采用率，因为如果没有活跃的社区，开源项目就不可能持续发展壮大。项目周边活跃的社区更有可能推动项目性能提升、漏洞管理和功能完善，从而简化后续开发。
CHAOSS 指标：
- 克隆的数量衡量项目从存储库拉入本地机器的次数，作为采用率的指标。
- 分叉的数量表示对项目做出贡献的兴趣。
- 开源项目不仅仅是代码，其他类型的贡献（例如，策略、问题、评论、事件、撰写文章）表明了维持项目的能力。
- 定期请求的数量有助于了解项目社区的实力、模式和可持续性。
- 与提交者数量相关的趋势可以深入了解项目的生命周期以及贡献者数量是增长、稳定还是下降。
- 这有助于了解一个项目是否有足够的维护者来跟上项目的贡献。
- 该指标是其他较小指标（例如，喜欢、星星、徽章、分支、克隆）的集合，可提供使用情况和采用情况的指标（Vargas 等人，2024 年）。
- 该指标衡量了软件依赖关系的新鲜度，突出了使用可能因依赖关系未定期更新而产生隐藏维护成本或安全漏洞的项目所带来的风险。
其他注意事项：
沟通包容性：
- 拥有互相尊重和友善文化的项目更具生存力，因为人们会愿意继续贡献，因此请仔细观察人们在讨论、代码审查、Slack 和其他沟通渠道中如何相互对待。另一方面，文化不良的项目会将社区成员（包括组织员工）置于风险之中。
社区对于生存力意味着什么
通过社区，我们力求了解项目中发生的“修修补补”，并能够衡量所做的贡献。克隆和分叉表明有多少软件用户从源代码构建、检查源代码、提交贡献或将项目带向新的方向。这种受欢迎程度对于追踪社区对项目的参与度意义重大。如果项目被许多其他组织采用，则可以降低接受开源项目的风险，因为拥有大量用户的活跃项目不太可能被放弃。拥有强大的用户基础可以降低项目被放弃的风险。
通过提交者趋势、贡献类型和变更请求，我们可以了解社区的互动情况。Markdown RFC 的创建数量可能比功能多，反之亦然。了解贡献类型及其频率后，我们可以对项目的可行性做出更明智的判断。例如，如果一个项目在三个月内失去了 90% 的提交者，那么该项目的可行性就低于提交者趋势稳定（持平）的项目。反之，则可能表明一个正在发展或稳定的项目在特定技术趋势下越来越受欢迎。有些“修补”指标显得比较微观，而其他指标则更具宏观视角。
通过测量一些共享指标，我们得以从社区如何维护项目以及项目总体关注程度的角度来审视该模型。我们发现这与治理角度截然不同，尽管两者之间存在很大重叠，因为这些指标的趋势几乎从不完全归咎于社区或特定项目的维护者。这些数字对于任何一个领域都可能有意义，因此它们存在于两个模型中。
策略
与其他可行性类别相比，项目策略在数值上可能感觉不那么明显。策略的衡量标准是我们可以观察到的因素，以及个人和组织对项目可能产生的影响。
CHAOSS 指标：
- 项目中使用的编程语言会影响组织是否具备上游贡献的技能，如果无法纳入错误修复，则会影响可行性。
贡献者缺席因素 （有时称为巴士因子或彩票因子）
- 对一段时期内占活动量的 50% 的最少提交者数量进行计数，以便更好地了解使用特定项目或一组项目的风险，以及如果顶级贡献者离开，该项目将获得多少支持。
- 大象因素统计了占项目活动 50% 的最少组织，并用于推断特定组织对项目的影响，以及如果该公司改变优先级并停止贡献将造成多大的损害。
- 组织影响力衡量的是组织在项目中的控制力。这是一个估算值，并综合了其他几个指标，包括： 组织多样性.
- 发布频率有助于了解项目将更改和安全修复纳入发布需要多长时间，以及何时可以预期安全补丁、错误修复和新功能。
其他注意事项：
贡献者许可协议（CLA）
- 贡献前需要签署贡献者许可协议 (CLA)，这可能会降低可行性，因为 CLA 通常赋予控制组织重新授权或执行其他操作的能力 地毯拉.
战略对于可行性意味着什么
我们在此模型中追踪的指标追踪的是策略，或者说是个人和组织的预期影响力。例如，如果贡献者缺席系数为 1，则很有可能由于倦怠或其他因素导致唯一贡献者停止维护项目。随着贡献者人数的增加，我们更有可能看到稳定可行的维护策略。
我们在策略和治理之间共享发布频率。这将项目维护者提供治理计划和维护策略的方式的重叠部分进行了分类。
行动与缓解
前四节涵盖了可用于更好地理解可行性许多不同方面的指标类别，但组织需要超越理解并采取行动。
贡献作为风险缓解策略
开源项目的价值之一在于，我们可以共同努力，提高开源项目的可行性，并降低使用这些项目的风险。是否使用开源项目通常取决于风险与回报之间的权衡，因为组织需要判断一个项目是否足够可行，能够满足其用例的需求。
理解、影响和提升项目未来可行性的最佳方法是分配员工时间来参与项目。让员工参与项目工作，有助于您了解项目的优势和劣势，同时还能从内部影响项目的未来方向。
组织还可以贡献资金和其他资源来帮助维持开源项目并提高其可行性。
依赖管理
这些指标的应用使软件的选择和维护任务变得可操作化。在评估依赖关系时，工程师可以更好地了解开源项目哪些部分表现优异，哪些部分可能存在不足。根据预期的应用，开源项目负责人、应用团队和运营团队可以决定是否值得共同承担项目风险。
可行性评估为哪些依赖项需要更新提供了方向。与其将旧的依赖项归结为模糊的“技术债务”，不如评估合规性、许可、社区、战略和治理与特定项目的契合度。我们还可以估算未以利益相关者可量化的方式处理项目的风险，并评估优先级的审核。
重新评估作为实践
开发团队经常在没有时间仔细研究代码库以寻求优化的情况下工作。因此，优先处理那些能为其所在组织带来可衡量价值的任务至关重要。这种可行性框架允许将技术债务重新定义为风险缓解措施。正如我们避免漏洞或许可问题一样，我们也避免了不可行的开源项目。
拥有一个在项目生命周期内进行评估和再评估的工具和框架，可以让我们基于指标，就工程师有时设定的远大目标进行对话。我们建议每季度在讨论开源项目优先级时，就这些指标进行一次讨论。通过这样做，为开源项目做贡献并升级主要依赖版本（从而学习更新的编码实践）更有助于降低风险。评估可行性是定期与非技术利益相关者进行富有成效对话的一种方式。
结语
根据您的用例，您可能会发现使用此可行性评估框架的不同机会。它最初是为评估特定公司内部开源产品的使用情况而开发的，因此每个模型类别的阈值会根据您组织的风险假设而有所不同。
例如：
- 开始开发更正式的开源软件流程的组织通常从合规性和安全性开始，使用许可和漏洞信息来选择他们的软件。
- 对于有意参与开源社区或为项目贡献新功能的组织来说，治理至关重要。如果一个组织愿意投入时间和资源来维护一个项目，那么该项目的治理就变得非常重要。
- 社区对于尖端技术或较新的技术实现至关重要。虽然较老的技术可能拥有一个相对稳定的社区，维护者和新贡献的流动可以随着时间的推移进行评估，但新项目可能需要一个更强大的社区，对竞争对手保持更高的警惕，以确保软件栈不会被抛弃。
大多数商业决策归根结底都在于风险评估和权衡利弊。组织应该根据项目使用方式，从战略角度思考项目风险。如果项目是技术栈的关键组成部分，则应尽可能降低风险。另一方面，如果开源项目只是某些非关键基础设施的一小部分，组织可以承担更多风险。评估可行性，并从风险角度思考并确定可以接受哪些风险是重要的第一步，但思考哪些风险可以降低以提高可行性也同样重要。降低这些风险的最佳方法是向员工支付报酬，让他们为组织最重要的项目做出贡献。这不仅提供了提高可行性和可持续性的机会，还能洞察项目的走向和进展情况，以便如果项目发生进一步增加风险的变化，更容易预测这些变化。
注意事项和注意事项
- 如何评估可行性和风险承受能力，很大程度上取决于您所在组织的具体需求和用例，因此没有“一刀切”的方法。科技初创公司和金融服务公司可接受的风险可能有所不同。同样，如果组织使用开源基础设施项目作为创收产品的基础，其风险承受能力和可行性可能低于小型开发团队使用的项目。
- 虽然本指南中的一些内容可以实现自动化并进行大规模评估，但其他指标和其他考虑因素需要更手动的评估，因此这些内容可能只适用于可行性对组织至关重要的项目。
- 并非所有风险都能预见，项目可能会意外地以无法预料的方式变得不可行。本指南涵盖了可行性评估的许多方面，但现实情况是，开源项目是由人来运营的，有时人们会采取不可预测的行动，从而影响他人。
- 对于刚开始评估可行性的组织来说，本指南可能有点难以理解，因此，选择几个领域先重点关注，然后再逐步扩展，对许多组织来说可能是一个不错的方法。我们建议从一两个模型开始，甚至可以从通用模型开始。 入门模型 作为第一步。
延伸阅读
- 我们有一个 短片 （< 8 分钟）专门介绍 CHAOSS YouTube 频道上的本指南。
- 5个可行性指标模型： 入门版, 合规+安全, 治理, 社区参与和 策略
- 可行性：开源混沌度量（超级）模型
- OSS 生存能力指标
- OSS 生存能力指南：混沌度量模型
- CHAOSS 从业者指南
- 2024 年开源安全和风险分析报告
- 云、代码和控制：新的开源权力斗争
- CHAOSScast 第 84 集：社区生存能力——Verizon 如何看待 OSS 风险
合作者
以下人员为本指南做出了贡献：
- 加里·怀特
- 黎明福斯特
- 马特·杰蒙普雷斯
案例
- Avelino, G.、Constantinou, E.、Valente, MT 和 Serebrenik, A.（2019 年 XNUMX 月）。 关于开源项目的放弃与生存：一项实证调查。在 2019 ACM/IEEE 国际经验软件工程与测量研讨会（ESEM） （第 1-12 页）。 IEEE。
- 黑鸭子（2025）。 2025 年开源安全和风险分析报告.
- Cox, J.、Bouwers, E.、Van Eekelen, M. 和 Visser, J.（2015 年 XNUMX 月）。 测量软件系统中依赖项的新鲜度。在 2015 IEEE/ACM 第 37 届 IEEE 软件工程国际会议 （第 2 卷，第 109-118 页）。 IEEE。
- Eghbal，N.（2016 年）。 道路和桥梁：数字基础设施背后无形的劳动力. 纽约，纽约州：福特基金会。
- Foster, D.，2024 年，《开源的新动态：重新授权、分叉和社区影响》，提交至 OpenForum Academy 研讨会的论文，马萨诸塞州波士顿，11 月 13-14 日，可在以下网址获取 https://doi.org/10.48550/arXiv.2411.04739
- Imtiaz, N.、Khanom, A. 和 Williams, L. (2022)。 公开还是偷偷摸摸？快还是慢？轻还是重？：调查开源软件包的安全版本。 IEEE 软件工程学报, 49（4），1540 1560。
- Vargas, S.、Link, G. 和 Lee, J.（2024 年 4 月）。 估算开源项目的使用情况。在 第21届国际软件存储库挖掘会议论文集 （pp。652-653）。
CHAOSS 从业者指南是 MIT 授权的动态文档，我们欢迎您的反馈和意见。您可以在以下位置建议对本文档进行修改 https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/viability.md