美国政府已将在联邦机构中采用开源软件(OSS)作为优先事项。值得更深入地研究这一政策，以考虑如何解决 OSS 的支持性问题。
译自 A Guide to Navigating Open Source Support Requirements in the US Government 。
如果说软件正在吞噬世界，那么开源软件正在吞噬软件。Linux 已经成为主流的操作系统，越来越多的企业应用程序中包含了高比例的开源代码。作为回应，美国政府已将在联邦机构中采用开源软件(OSS)作为优先事项。国家安全和国防机构中的团队长期以来一直将 OSS 用于网络安全和快速响应的软件导向问题解决。也就是说，许多机构的 IT 管理者在遵守政府法规的同时，仍对如何使用 OSS 感到困惑。尤其是支持需求方面存在疑惑。
与美国政府关于软件供应链安全的 Executive Order 14028 等政策类似，国防部(DoD)对 OSS 支持需求也提供了具体指导。简要总结一下，DoD 开发和实施 OSS 的 IT 团队必须具有“支持计划”。DoD 设置的趋势通常会被其他部门效仿，因此所有美国政府的 IT 员工都应该注意这一政策。
尽管 DoD 的政策留有很大的灵活性，允许机构从许多方案中选择，但在实践中，这可能会变得有些模糊。即使对于 DoD 之外的机构，也值得更深入地研究这一政策，以考虑如何解决 OSS 的支持性问题。
在像国防部这样的政府机构中的复杂的软件管理环境中，支持计划是一个关键文件，它概述了开源软件在其生命周期中将如何被维护、更新和保护。随着最近对软件物料清单(SBOM)和其他透明度机制的要求，支持计划充当了维持软件完整性和功能的路线图。
广泛来说，DoD 的支持计划有三种可行的选择：
- 开源供应商 - 由开源供应商提供专门的商业支持
- 已知承包商 - 由作为项目一部分的承包商提供的捆绑商业支持
- 自行支持 - 由 DoD 机构团队进行的内部支持
值得注意的是，社区支持并不是一个选项。虽然它可能比较经济，但仅靠社区支持无法满足政府机构对国家安全和其他敏感功能的及时性、专业性和问责制的要求。 此外，社区支持没有提供服务级别协议(SLA)，这对于停机或安全漏洞可能带来重大后果的环境至关重要。
让我们逐一分析这三种可行选项(加上一个额外选项)以及它们的优势和缺点。
供应商支持类似于专有支持，不同之处在于供应商与 DoD 机构签署支持合同以维护和支持开源软件发行版。一个突出的例子是红帽企业 Linux 由红帽提供支持。
- 强大的专业知识 - 在这种情况下，供应商通常维护开源产品，这意味着支持人员可能对软件非常熟悉，并可能在性能和额外安全指导方面提供重大价值。
- 更及时的通知 - 当供应商也是维护者时，客户通常可以比由第三方提供支持更快收到关键更新和补丁的通知。 此外，供应商通常参与安全流程，在公开发布之前提供安全漏洞信息的非正式访问。 这可以确保您能够快速采取行动以维护安全性和性能，同时积极降低风险。
- 增值服务 - 供应商的深入专业知识还可以提高培训、架构设计指导和配置审核等增值服务的质量。
- 更高的成本 - 供应商支持可能需要多年的大量财务投入。 供应商需要能够计划和分配资源(这可能包括分配给该机构的美国公民)，因此这可能会导致一种微妙的供应商锁定。
- 缺乏专门的支持工程师 - 多层客户服务可能意味着您的需求没有单一的专门联系人。 这可能导致缺乏机构知识、响应质量不一和更慢的响应时间。
政府技术服务中的承包商很乐意作为持续的主服务协议(MSA)和其他合同的一部分提供开源软件的捆绑支持。这已经是一个数十亿美元的业务，许多主要承包商都有团队作为他们系统集成工作的一部分部署开源工具和产品。
- 服务捆绑 - 支持通常与系统集成等其他服务一起打包。这使支持合同能够与整个系统的构建和持续维护紧密集成，提供整体视图和机构记忆。
- 更低的成本 - 支持通常是可以以极小的额外成本添加到现有大型合同中的附加项，这是由于合同规模较大。 对于较小的捆绑包，成本效益不那么明显。 在最理想的情况下，支持可以以零成本增加。
- 补丁和安全的延迟 - 更新和修补过程中的中间人可能导致实施更慢。 此外，承包商可能必须与一个独立的安全团队处理修补程序和漏洞问题。 这可能导致信息分散和响应时间变慢。
- 专业知识不足 - 虽然承包商可能是开源软件方面的专家，但很难与实际开发和维护该软件的公司相匹配。 如果软件包含许多其他依赖项(库、包等)，这一点尤其重要，在这种情况下，对开源生态系统的深入理解至关重要。
- 合同转换风险 - 政府系统的使用周期往往超过支持合同的期限，因此当合同更换时，总会存在高昂的转换成本和机构知识丢失的风险。
与许多政府 IT 管理人员的认识相反，如果您能够设计和配备内部支持计划来满足标准，则不必协商或支付外部支持计划。 这可能包括内部支持的组合以及通过类似 Tidelift 的工具从实际项目维护者获得的维护者支持。
- 更快的响应和迭代 - 内部团队可以快速移动并更好地响应组织需求。 摩擦较小，机构应该能够更快地迭代支持需求。
- 更好的定制 - 因为内部团队更接近机构的实际用例并且完全嵌入，所以他们更能够提供定制和额外的配置修改以精确满足 DoD 实体的需求。
- 需要人手 - 无论是承包商还是全职员工，内部支持选项都需要活生生的人来做这项工作。 这包括为关键系统设置轮值支持。
- 共享资源的访问较少 - 与外部支持相比，内部团队可能不太容易从共享资源中受益。 例如，如果您的支持团队中的关键成员休假，您可能会遇到麻烦。
- 缺乏专业知识 - 选择这条路的机构的内部团队可能需要支持多个开源组件，这使得他们很难在每个组件上积累深入的专业知识。
尽管 DoD 指南中没有涵盖，但第四种可行的选择是混合支持计划，其中至少包括一两个内部资源与供应商合作形成一个完整的支持团队。这可以结合伙伴关系的连续性和专业知识与内部全职资源的速度和机构知识，实现最佳效果。
- 结合优势 - 这种选择结合了深入的维护者专业知识和安全升级的提前访问，以及内部团队的速度和机构背景。
- 灵活性强，覆盖广泛 - 通过两种支持模式，此选项提供更大的灵活性，并能够处理机构变化、流动性、假期或全天候覆盖。
- 更高的成本 - 不出所料，这可能是一个昂贵的选择，因为它包括支持合同和人力资源。
在选择支持计划时，风险很高，尤其是对 DoD 实体而言。 对使命关键系统的支持对于维护国家安全以及 DoD 技术系统的完整性至关重要。 在选择支持方式时做出明智的决定可以大大降低风险。
在作出选择之前，请考虑以下因素:
- 依赖程度 - 开源软件对您的机构或组织运营有多关键？
- 系统重要性 - 该软件是否在故障或延迟会造成严重后果的关键任务系统上运行？
- 使用范围 - 开源软件是否在多个团队或应用程序中使用，为任何问题或停机造成更广泛的曝光？
- 安全需求 - 您对漏洞和风险的修补时间的容忍度是多少? 您是否需要内部或就近的专家，他们可以在发布补丁之前潜在地补救风险？
软件世界有这样一句谚语：开源软件就像免费的小狗。收养它可能不花你任何钱，但每个小狗父母都同意，负责任的狗主人应该准备預算时间和金钱。将这个概念应用到开源软件和支持的领域，可以把支持计划看成保险单。当您的组织依赖于开源软件时，您必须拥有支持。
也就是说，支持的质量和类型取决于您的风险承受能力。如果您不太担心开源组件的健康状况，那么内部或承包商支持可能就足够了。但是，当该组件代表了重大的单点故障，并且宕机的后果非常严重时，开源供应商支持(或混合模型)是一个更安全的选择。
更昂贵不一定意味着更好的支持，但请记住，投资适合您组织的正确支持选项与故障排除和宕机时间节省直接相关。明智地选择！