OSPO成熟度模型和操作指南目录清单，用于帮助在企业环境中实施 OSPO 或开源计划。人们可以在这里阅读和下载完整的白皮书。

通过将与 OPSO 领导者和专家的对话映射到 OSPO 的调查结果，我们开发了 OSPO 成熟度模型来描述 OSPO 的典型演变。模型是通用的：组织的大小和类型影响 OSPO 的成熟方式。在较大的组织中，多个事业部可能会开发不同的开源方法，每种方法都有不同的技术文化；纯数字技术公司更有可能在早期消费和贡献 OSS ，并有更多的机会接触开源技术和概念。

以企业基础设施软件提供商 VMware 为例。他们的工程师与许多网络、云计算和其他关键领域的开源社区合作并做出贡献，原因很简单，他们知道使用开源构建会带来更好的结果和更强的互操作性——对于社区和 VMware 的客户来说。

与之形成对比的是首家上市的开源公司红帽。它将整个业务实践建立在开源软件的基础上，压缩了它的成熟度生命周期，实际上，这使它的整个公司有点像一个开源软件开发组织。今天，红帽将更多的资源投入到早期的生命周期活动中，例如教育内部利益相关者(例如，销售团队、营销人员、新聘的工程人员)，促进上游社区的合作。

对于我们研究中的大多数其他公司，成熟度模型的一般阶段在消费、贡献、协作和参与以及领导力方面严密布局了 OSS 组织的轨迹。我们采访过的一些组织现已把开放源码参与和使用列入具体指标。

这些指标包括 OSS 项目中的项目参与率(pull requests、comment、commit)、出席和参与开源活动、撰写的博客文章、发表演讲以及参与开源项目等等。更高级的开源组织可能有关于项目成功增长的度量标准，这些项目是由他们自己的工程团队发起的或部分由他们自己的工程团队创建的。一些领先的组织，如 Comcast、VMware 和 Red Hat ，或已正在构建先进的度量标准和度量工具。

也就是说，即使是一些跟踪指标的复杂组织也不会明确地使用指标来跟踪或设置 OSS 目标。

以微软为例，这个组织曾经几乎只专注于私有软件，但现在已经成为开源项目的主要支持者和其自有产品开源的广泛用户。“我们专注于让我们的开发人员更容易与 OSS 合作，鼓励他们为他们所依赖的项目做出贡献。我们跟踪所有人的参与，但开源项目办公室确实在个人或团队层面设定了目标，”微软开源项目办公室前负责人斯托米·彼得斯( Stormy Peters )说。“我们的开发者可以自愿将他们的公司 ID 与他们的 GitHub 登录联系起来，这让我们可以在公司层面衡量参与程度。大多情况下，系统收集和分析指标发生在采用的后期阶段，此时 OSS 成为企业和更大组织的技术路线图和战略的关键元素，与此同时，OSPO 计划、预算和人员也在增长。

第 0 阶段 采用开源 ad hoc

今天，几乎所有的组织都在使用开源软件。他们最初使用它的方式各不相同。他们使用开源软件作为产品或工具的构建块或库，或供应商产品栈的关键部分，或支持供应商的配套服务提供。开发人员可以将开源软件用于快速成型技术或微服务和小型应用程序。开发人员也经常采用开源软件开发工具，如集成开发环境( IDEs )，或基于 GitHub 和 GitLab 等开放源码构建的工具。现代云原生应用程序几乎默认使用开源系统进行容器编排、可观察性、数据存储、消息传递等。在应用程序的前端，开发人员严重依赖开源库和框架。

Red Hat 报告称，“ 90% 的 IT 领导者都在使用企业版开源软件。”像 Synopsys 这样的软件组合分析供应商确定 75% 以上的代码库包含开源组件。换句话说，几乎每个组织都在使用开源。然而，最早期的采用形式是 Ad Hoc ，由开发人员使用现成的工具和技术来解决问题。这种“ad hoc adoption”通常意味着默认值之外的许可证合规性会较少考虑，或消费开源、分发开源组件构建的产品的长期影响。在大多数情况下，只有少数开发者在积极寻求开源，而其他的开发组织可能碰巧使用开源，但并不认为其活动依赖于开源。因此，这些组织既没有集中关注开源的团队，也没有相应的顶级开源战略。这些是非常重要的，因为一旦采用，这些开源组件默认情况下将成为组织软件供应链的一部分，这使得战略方法变得更加重要。

第 1 阶段 为 OSS 合规、目录清单和开发人员培训做充分准备

一般来说，当一个组织意识到项目部和开发部几乎所有人都在使用开源产品和代码时，就会形成一个 OSPO 。这种用法通常是内部的，而不是给客户或用户的一部分产品或服务。实际上,任何一个有较为可观的IT功能和先进的线上的或以应用程序为中心的组织都使用开源，从 Linux 服务器、像 NodeJS 和 Python 的 MySQL 数据库编程语言和如 React 和 Vue.js 的前端框架的开源技术堆栈无处不在。

早期阶段，组织对 OSPO 使用过许多不同的名称。例如IBM最初将其程序化的开源工作称为“开源指导委员会”。然而，在所有情况下，阶段1中的组织都认识到开源软件是他们业务和技术战略的关键部分。他们明白开源软件项目的安全实践与私有软件公司的安全实践不同。例如，开源软件项目的披露规则往往比专有项目更严格。因此，他们必须确定他们的合规性和安全风险。降低风险的策略包括重视许可证风险、开发人员培训和识别准确的 OSS 清单。

管理法律风险和许可 组织的法律团队或技术领导倾向于启动第一阶段开发之前， OSPO 需要确保其员工(以及承包商、供应商等)都根据其 license 条款使用开源软件，并且组织使用 OSS 后不会被置于法律风险之中。他们有数十个开源 license 在使用。在 2020 年的调查中，受访者将合规列为大型企业 OSPO 的最大好处，中型企业的第二大好处。“企业在刚开始时通常会有很多困惑。目前还没有相应的许可策略，开发者只能做他们认为正确的事情。”弗里德里希亚历山大大学的开源软件教授 Dirk Riehle 说。他补充道:

我曾经走进一家公司，有个开发人员说:“我们没有开源策略”。另一个人打趣道:“我们有，而且是:没有开源”。对此，第三个人皱着眉头说:“你在说什么？我们为开源项目做贡献已经有一段时间了。”这并不罕见。他们最终将成立一个开源项目办公室，负责处理开源的使用和贡献。

尽管开源软件用户一直在考虑法律的合规性，但一些开源软件贡献者已经设计了新的许可证，以阻止基于开源项目创建专有服务的大型云供应商。其中最突出的是 Affero 通用公共许可证( AGPL )。企业可能会使用开源软件提供专有软件即服务( SaaS )给他们的客户，遵从 license 协议授权的条款，这进一步模糊了商业服务和内部服务之间的界限。

开发者培训 为了保持合规，处于 OSPO 成熟度阶段1的组织创建了教育项目，以帮助他们的开发人员判定在创建新产品或服务的何时使用开源软件。“许多没有接受过开源教育的开发人员认为，因为他们没有购买软件，没有签署合同，所以不涉及许可证。”VMware 的开源营销和战略总监 Suzanne Ambiel 说。“开源软件可能是免费的，不用花钱；但如果以不合规的方式使用，它也可能是昂贵的。开源软件总是伴随着许可证。任何开源软件最重要的角色之一就是确保开发者理解不同选择的许可含义。”通过对开发人员的培训，高级管理人员很认可开源软件的价值和重要性。在这些项目中，开发人员可以学习到：

• 不同类型许可证的细微差别
• 推出新的开源软件产品的正式批准流程消费不兼容开源软件的真正风险，包括使用项目中未经正式许可的代码或 OSS 产品
• 使用贡献者许可协议( CLAs )保护组织里为开源做出贡献的开发人员

有时候，组织在这个阶段引入正式的 CLA 策略，为判断开源软件项目的健康状况提供指导，作为其决定在组织的技术堆栈或基础结构中使用哪些开源软件标准的一部分。

清点软件清单 开发人员可能会临时调用开源软件，而不会系统地对他们的工作进行编目。法律团队和技术领导倾向于要求一个组织中使用的所有 OSS 的清单。清单逐条列记了组织代码库(例如，GitHub, GitLab )和系统中的 OSS 。阶段1组织建立特定的软件库存过程，以创建一个全组织范围的软件物料清单( SBOM )。

有了这个清单，法律团队(通常与 OSPO 团队一起工作)就可以持续地监视 OSS 的使用情况，并标记出法律、安全或其他项目风险。通过详细的 SBOM ，技术领导(如首席技术官 CTO 或首席信息官 CIO )可以识别并密切监视最关键的业务使用，保护组织的安全性。

第 2 阶段 宣传 OSS 使用和参与生态系统

在组织认识到 OSS 的价值以及合规、教育和 SBOM 的必要之后，他们开始意识到使用 OSS 的经济效益，并寻求扩大它。阶段2中的 OSPO 创建了这样的内部机制，例如作为大使推广已批准的 OSS 产品的使用方法、好的 OSS 知识管理教育计划、OSS 技能建设和认证的技术培训或学费报销。

有了这些计划，组织就可以增加对 OSS 的使用并扩大。OSS 不仅重要，而且比专有软件产品更可取的信息。员工教育包括与 OSS 项目交互的最佳实践，例如如何请求特性、文件错误报告和贡献基本代码的特点。

在这个阶段，组织加强了它的协作力量，并体验了 OSS 项目和社区的社交生活。在这一点上，OSPO 向员工和管理者传达了贡献而不仅仅是使用 OSS 的重要性。这种推广包括倡导和推动活动赞助，在公共编码论坛上预定项目负责人和维护人作为演讲嘉宾或小组成员，并设法获得关键任务 OSS 项目的组织资源(例如：人才，资金)。

对于组织而言，积极和可见的参与会产生多种好处：更高的知名度、更好的声誉、更具吸引力的雇主。鉴于此，许多非技术组织在重要的 OSS 活动上购买展位，以与这些社区进行更多互动，并招聘喜欢在 OSS 生态系统中工作的开发人员。活跃于开源领域的技术公司可能会将教育计划扩展到希望与 OSS 社区和供应商互动的客户。Red Hat 开源高级总监 Deborah Bryant 说：“我们收到了很多客户的请求，希望我们在如何参与开源、贡献开源，以及如何与我们在项目上进行合作给予帮助和指导。”

随着阶段2的推进，组织开始鼓励开发人员从事对组织运营起至关重要的 OSS 项目，以使开发人员成为高度活跃的贡献者或主要维护者。对于技术组织来说，为重要的 OSS 项目聘请贡献者是一项有价值的投资：他们的大多数贡献者，比如说，Linux 内核（操作系统的核心组件和计算机硬件和软件之间的关键接口）都是全职员工，他们的工作是为 Linux 编写代码。

在技术领域之外，很少有组织能够分配全职员工从事开源工作，但他们正在这样做。例如，康卡斯特和彭博都有员工全职从事 OSS 项目。在生命周期阶段，OSPO 开始探索如何简化开发人员使用 OSS 的过程。这种开发者效能包括简化 CLA ，将具有可接受许可类型的 OSS 添加到工单系统中以便快速审批，促进 OSS 架构和现有软件的重用(内部采购的一种变体)以及标准化库选择和开源开发工具，从而融合 OSPO 和平台运营职责。

在这个阶段，组织会向 OSPO 寻求有关如何积极参与开放生态系统的指导。“你需要确保你得到的和你所回馈的一样多。你不希望人们认为你只是在通过开源赚钱，而没有为社区做出贡献。”Futurewei 技术有限公司 OSPO 负责人 Chris Xie 说，“我们强烈考虑到这一点——比以往任何时候都更加强烈。” 电信等受监管行业的公司还必须了解其国家出口法律并驾驭政治紧张局势，以保护 OSS 社区并避免国际纠葛。“我们一直希望确保我们的贡献是真正开放的，能造福社区、造福整个行业的。” Xie 解释道。

通常在 OSPO 成熟度周期的第2阶段(如果是软件公司或以技术为核心的公司，也可能是在第1阶段)，OSPO 开始为其开发人员简化和优化开源贡献。早期，请求和获得外部参与的批准的过程通常是临时的和痛苦的。“我们建立 OSPO 时，首先关注的事情之一就是贡献的流程。” SAP OSPO 首席架构师 Michael Picht 说， “使用 Word、Excel 和电子邮件，这个过程根本没有自动化。当我们打开 OSPO 时，我们做的第一件事就是简化流程并实现端到端工具支持。我们将 GitHub 用于解决不同的流程步骤。”

第3阶段 成长中的OSS项目托管社区

在第 3 阶段，组织发起并托管或充当 OSS 项目的主要发起人。他们将为一个项目指定一名或多名 FTE，并承担培育项目社区和确保其健康的责任。他们不会将这种级别的组织承诺与决定开源项目的员工混淆。在第 3 阶段，组织领导者支持在公共领域孵化和启动开源项目，因为他们了解这些项目如何使他们的组织受益。此类项目往往在关键功能上提供更好的性能和经济性，这些功能可能对组织的价值主张不核心，但对其技术基础设施至关重要。

此外，创建和启动开源项目的组织在开源社区中建立了广泛的信誉，开发开源技术的可能性吸引了许多开发人员。我们采访过的大多数 OSPO 都将招聘新人才和留住现有人才作为开源工作的关键动力。

在 Linux 基金会最近对金融服务行业的一项研究中，53% 的贡献者表示他们为 OSS 做出贡献是因为“它很有趣”。用 FTE 和资金支持项目是开源比赛的真实面目。跨越这一门槛并成功启动多个开源项目的组织开发的内部资源和流程，可以孵化并确保这些项目在启动后的成功。OSPO 不仅仅是项目形成和启动的守门人和导师；他们教育项目创建者培养健康的开源生态系统的要求，并指导项目负责人让他们为 OSS 项目所需的更公开的领导角色做好准备。

随着 OSS 组织的成熟，其 OSPO 开发内部流程、战术手册、检查表、工具和其他机制，以审查、组织和运营开源项目，并为其领导者做好准备和指导。一些 OSPO 更愿意在主要开源基金会或合作组织（如 TODO Group）的协助下启动项目，以增强性能或提供基础设施、战术援助和其他资源。这种偏好的资源密集度较低，但会将项目的控制权交给更广泛的社区。

第4阶段 成为战略决策合作伙伴

在这个成熟阶段，OSPO 成为技术决策的战略合作伙伴，帮助指导选择并形成长期投入的项目。在第 4 阶段，CTO 和其他技术领导咨询 OSPO 及其领导层，依赖哪些开源技术，使用哪些决策标准来判断开源项目。由于主要的开源技术选择往往会产生大量的二级和三级成本，并影响上游和下游技术以及招聘计划，因此开源技术选择成为一项重大的商业决策。

从广义上讲，OSPO 在第 4 阶段提供了三种类型的战略指导。首先，OSPO 建议 CTO 和技术领导采用或从组织的技术堆栈中删除哪些开源技术。鉴于当今有许多 OSS 选项——大多数主要的软件类别都有数十种选项。如下图所示，OSPO可以洞察OSS的趋势，例如不同语言的流行程度、API 设计或不同 NoSQL 数据库的功能。在这个角色中，OSPO 成为 CTO 的内部技术顾问和内部OSS专家。

在第二种类型的战略指导中，OSPO 带头对构成可接受的 OSS 项目的内容进行基准测试。OSPO 经常评估项目的行为和绩效，特别是限制使用的许可类型的变化，或项目路线图的突然变化，以确定项目经理是否考虑到社区的最佳利益。大多数 OSPO 依赖粗略的指标来评估项目行为，例如：

• 它拥有哪种类型的许可证？
• 它的行为准则是什么，违反它的后果是什么？
• 它的治理结构是什么，这种结构是否确保独立性？
• 响应pull请求或漏洞归档需要多长时间？
• 项目发布新版本的频率?
• 是由一方（公司或组织）还是整个社区控制项目？
• 该项目有多少贡献者？这个数字是如何随时间变化的？

第三种指导是帮助组织理解和驾驭项目政治，例如当多个有影响力的参与者试图引导一个项目保持中立立场，或者阐明社区成员潜在的政治考虑。在更高的层面上，OSPO 可以通过培养超越国界和政治领域的个人和工作关系，帮助公司在技术民族主义上保持中立姿态并弥合政治分歧。

随着这些领域成为开源中重要的中立空间，这种价值逐渐延伸到基金会和非营利组织的工作中。Red Hat 的黛博拉•布莱恩特( Deborah Bryant )表示，她的 OSPO 不得不管理参与开源基金会工作的成本，包括赞助和派遣员工担任领导角色。“我们发现，我们需要花更多时间在参与软件基金会的一些集中管理和行政管理上，以确保我们的投资获得回报，并定期重新评估我们的参与。”在这个职位上，OSPO 拥有数百万美元的基金会预算，参与 OSS 生态系统的形成和增长的战略重要性与对基金会和非营利组织的货币投资相是相同的。在这个阶段，我们倾向于看到 OSPO 的快速增长。VMware 的 Ambiel 说：

今天，OSPO 的主要目标之一是帮助提供最佳指导实践以及如何成为一名优秀的开源公民。当你在开源社区时，你就是在参与开放——每个人都可以看到你在做什么。重要的是，一个组织要尽其所能。无论是在会议上发言，还是为参加Kubernetes这样的大型项目社区贡献一个小型库，OSPO都能帮助人们始终如一地、充满信心地做到这一点。

INFOBOX

1.利用开源项目办公室:新研究揭示了OSPO的演变：https://linuxfoundation.org/blog/leveraging-the-open-source-program-office-new-research-unpacks-the-evolution-of-the-ospo-and-a-whole-lot-more/

2.开源项目办公室(OSPO)的发展：https://linuxfoundation.org/tools/the-evolution-of-the-open-source-program-office-ospo/