由 TODO Group 出品
原文链接：
https://github.com/todogroup/ospology/tree/main/ospo-model/en
本文由 vivo 互联网 OSPO 成员整理翻译， 目前已提交贡献至上游。
vivo 作为 TODO Group会员，推动了 TODO Group官网中文版的发布，并基于全球同行共识，翻译发布了 OSPO 定义2.0、OSPO 思维导图。
OSPO（Open Source Program Office）：开源项目办公室，被视为开源治理的最佳实践。
组织 OSPO 模型分类标准
我们希望这是一份动态文件，旨在建立 OSPO 模型的分类标准并确定有助于不同组织学习和实施的关键组件（模式）。
社区可以对五阶段 OSPO 成熟度模型进行颠覆式贡献，以更好地满足特定垂直行业和/或地区的需求。
OSPO 模型 1 —— 五阶段 OSPO 成熟度模型
随着 OSPO 的激增和普及，这些专项也日趋成熟。通过把 OSPO 领导者和专家的对话与 OSPO 调研结果相结合，我们建立了一个 OSPO 成熟度模型，以描述 OSPO 的典型演进过程。
请注意，一刀切并不适合所有情况。
事实证明，该模型在那些最初没有传统上在其日常运营中实施开源的环境中效果更好。
此外，组织的规模和类型也会影响 OSPO 的成熟程度。在规模较大的组织中，多个业务部门可能会制定不同的开源策略，每个部门都有不同的技术文化；而纯数字化的技术公司更有可能在早期消费 OSS 并为其做出贡献，也更有可能接触到开源技术和理念。
揭秘 OSPO 模型
此外，每个阶段都是累积性的。这意味着，在跨级推进时，OSPO 也要承担上一级的任务和责任。
例如，一旦 OSPO 涵盖了与开源合规和安全（级别 1）相关的所有必需任务，该 OSPO 可能已准备好迁移到级别 2。现在，该 OSPO 应该负责第一级的开源法律责任以及与传播 OSS 文化和生态系统参与（第二级）相关的法律责任。
0
阶段 0：临时采纳开源
如今，几乎所有的组织都在使用 OSS。他们采纳和开始使用 OSS 的方式各不相同。他们可能将 OSS 作为产品或工具中的模块或类库，或者作为供应商产品栈的关键部分，或者支持供应商提供的服务。开发人员可能将 OSS 用于快速原型开发或微服务和小型应用程序。开发人员还经常采用 OSS 开发工具，如集成开发环境（IDE），或构建在 GitHub 和 GitLab 等开源平台之上的工具。现代云原生应用几乎默认使用开源系统进行容器编排、可观测性、数据存储、消息通信等。对于前端应用程序，开发人员非常依赖开源库和框架。RedHat 报告称，“90% 的 IT 领导者都在使用企业级开源”。Synopsys 等软件成分分析供应商表示，超过 75% 的代码库包含开源组件。
换句话说，几乎每个组织都在使用开源。然而，最早的采用形式是临时性的，由开发人员使用现成的工具和技术解决问题。这种“临时采用”通常意味着很少考虑默认情况之外的许可证合规，也很少考虑使用开源和分发使用开源组件构建的产品的长期影响。在大多数情况下，少数工程师会积极寻求开源，而工程团队的其他人员可能会偶然使用开源，但不会将其活动视为依赖开源。因此，企业既没有一个专注于开源的集中式团队，也没有为企业制定最高级别的开源战略。这些都是至关重要的，因为一旦采用，这些开源组件就会默认成为组织软件供应链的一部分，这就更有必要采取战略措施。
1
阶段 1：提供 OSS 合规、清单和开发者教育
一般来说，当一个组织意识到其员工正在使用开源产品和代码，几乎涉及所有工程和开发部门及职能部门时，就会组建一个 OSPO。这种使用通常是内部使用，而不是作为向客户或用户提供的产品或服务的一部分。实际上，任何拥有大量 IT 服务能力和先进的在线系统或应用程序为中心的组织都会使用开源，因为开源在整个技术栈中无处不在，从 Linux 服务器和 MySQL 数据库到 NodeJS 和 Python 等编程语言以及 React 和 Vue.js 等前端框架。
在这一早期阶段，各组织通常为 OSPO 使用许多不同的名称。例如，IBM 公司最初将其计划性开源工作称为 "开源指导委员会"。不过，在所有情况下，处于第一阶段的组织都认识到 OSS 是其业务和技术战略的重要组成部分。他们知道 OSS 项目的安全实践与专有软件公司的不同。例如，OSS 项目的披露规则往往比专有项目的披露规则更严格。因此，他们必须明确自己的法律和安全风险。降低风险的策略包括谨慎许可、开发人员教育和严格盘点。
管理法律风险和许可
一个组织的法律团队或技术领导往往会启动 OSPO 的第一阶段的推进工作，以确保其员工（以及承包商、供应商等）都按照许可条款使用 OSS ，并确保该组织的 OSS 消费不会使其面临法律风险。目前使用中的 OSS 许可证有几十种。在 2020 年的调查中，受访者将合规性列为大型企业 OSPO 的最大收益，而合规在中型企业仍然是第二大收益。公司一开始通常会有很多困惑。
尽管 OSS 用户一直在考虑法律合规性，但一些 OSS 贡献者还是设计了新的许可证，以阻止大型云提供商基于开源项目创建专有服务。其中最著名的是 Affero 通用公共许可证 (AGPL)。公司可以使用根据该许可证条款发布的 OSS 向客户提供专有软件即服务（SaaS），但如果 AGPL 条款没有明确区分内部和外部交付，OSS 的创建者可能有理由起诉公司违反许可证规定。许多企业还在业务单元之间建立了内部财务结算系统，进一步模糊了付费服务和内部服务之间的界限。
教育开发者
为保持合规性，处于 OSPO 成熟度第一阶段的组织应制定教育计划，帮助其开发人员在创建新产品或服务时决定何时使用开源软件。“许多没有接受过开源教育的开发人员认为，因为他们没有购买软件，所以不涉及许可证，因为他们没有签署合同。” VMware 公司开源营销和战略总监 Suzanne Ambiel 说，“开源软件可能是免费的，也可能是无价的，但如果以不合规的方式使用，成本也可能很高。[OSS] 始终附带许可证。任何 OSPO 最重要的职责之一就是确保开发人员了解选择不同许可证的影响。”
通过开发人员教育，高层管理者往往会承认开源软件的价值和重要性。在这些项目中，开发人员可以学到：
不同许可证类型的细微差别
引入新的开源软件产品的正式审批程序
消费不合规开源软件的实际风险，包括使用来自项目的开源软件产品或没有正式许可证的代码
-
使用贡献者许可协议 (CLA) 来覆盖为开源做出贡献的组织开发人员
有时，组织会在这一阶段引入正式的 CLA 政策。作为决定在组织的技术栈或基础设施中使用哪些开源软件的标准的一部分，它还可能为判断开源软件项目的健康状况提供指导。
盘点软件清单
开发人员可能会临时部署开源软件，而不对该工作进行系统地归类。法律团队和技术领导层倾向于推动编制组织内在使用的所有开源软件清单。这种清单将组织代码库（如 GitHub、GitLab）和系统中的开源软件逐项列出。阶段1的组织建立了特定的软件清单流程，以创建全组织范围的软件物料清单（SBOM）。有了这份清单，法律团队（通常与 OSPO 团队合作）就可以持续监控开源软件的使用情况，并提示法律、安全或其他项目风险。有了详细的 SBOM，首席技术官（CTO）或首席信息官（CIO）等技术领导层就可以识别并密切监控最关键的业务用途，维护组织安全。
本阶段建议参与的 OSS 社区列表
横向技能
项目 / 社区
合规
Open Chain
安全
OpenSSF
SPDX
2
阶段 2：布道 OSS 应用和生态参与
在组织认识到 OSS 的价值以及合规、教育和 SBOM 的需求后，他们开始意识到 OSS 使用的经济效益并寻求扩大它。第二阶段的 OSPO 创建了相关的内部机制，如推广使用经批准的 OSS 产品的大使、良好 OSS 健康教育计划以及 OSS 技能建设和认证的技术培训或学费报销等。通过这些举措，组织可以加强对 OSS 的应用并进一步强化：OSS 不仅重要，而且比专有软件产品更理想、更可取。
员工教育包括制定与 OSS 项目交互的最佳实践，例如如何请求功能、提交错误报告和贡献基本代码。在此阶段，组织增强其协作能力并体验 OSS 项目和社区的社交生活。此时，OSPO 向员工和管理人员传达贡献而不仅仅是消费 OSS 的重要性。这种外联活动包括倡导和推动活动赞助、预约项目领导和维护人员作为公共编程论坛的发言人或小组成员，以及确保组织资源（如人才、资金）用于关键任务的 OSS 项目。
对于组织来说，积极和看得见的参与会产生多种好处：更好的知名度、更好的声誉、更具吸引力的雇主品牌。为此，许多非科技组织购买展位，参加重要的 OSS 活动，与这些社区进行更多互动，并招募喜欢在 OSS 生态系统中工作的开发人员。活跃于开源领域的技术公司可以将教育计划扩展到想要与 OSS 社区和供应商互动的客户。
随着进入第二阶段，组织开始激励开发人员参与对其运营至关重要的 OSS 项目，从而使开发人员成为高度活跃的贡献者或主要维护者。对于技术组织而言，雇用一个著名的 OSS 项目的贡献者是一项有价值的投资：他们中的大多数贡献者，比如 Linux 内核—— Linux 操作系统的核心组件以及计算机硬件和软件之间的关键接口——的贡献者都是全职员工 (FTE)，其工作是为 Linux 编写代码。
在技术领域之外，很少有组织能够分配全职员工从事开源工作，但他们正在这样做。例如，康卡斯特和彭博社都有员工全职从事 OSS 项目。在生命周期的这个阶段，OSPO 开始探索如何简化开发人员使用 OSS 的流程。这种开发人员效率可能包括简化 CLA、将具有可接受许可证类型的 OSS 添加到工单系统以实现快速审批、促进 OSS 架构和软件的就地重用（内部采购的变体）以及标准化库选择和开源开发工具，从而混合 OSPO 和平台运营职责。
通常在 OSPO 成熟度周期的第二阶段（或者有时在第一阶段，如果是一家软件或技术为核心的公司的话），OSPO 开始为其开发人员简化和优化对外开源的贡献流程。对外参与的请求和获得批准的过程在早期通常是临时的且痛苦的。
本阶段建议参与的 OSS 社区列表
横向技能
项目 / 社区
社区健康与指标
CHAOSS
内部开源文化
InnerSource Commons
3
阶段 3：发起开源项目和发展社区
在第三阶段，组织发起并主导 OSS 项目或充当其主要发起人。他们将为一个项目投入一名或多名全职员工（FTE），并承担培育项目社区并确保其健康发展的责任。他们不会将这种级别的组织承诺与决定开源其项目的员工个人混淆。在第三阶段，组织领导者支持在公共领域孵化和启动开源项目，因为他们了解这些项目如何使他们的组织受益。此类项目往往会在关键能力方面提供更好的业绩和经济效益，这些能力可能不是组织价值主张的核心，但对其技术基础设施至关重要。
此外，创建和启动开源项目的组织在开源社区中建立了广泛的信誉；从事开源技术的可能性对许多开发人员来说很有吸引力。我们采访的大多数 OSPO 都将招聘新的工程人才和保留现有人才视为开源工作的关键动机。
用 FTE 和资金支持项目是开源游戏中真面目。跨越这一门槛并成功启动多个开源项目的组织会开发内部资源和流程，以孵化并确保这些项目启动后的成功。OSPO 不仅仅是项目形成和启动的守门人和导师；他们向项目创建者提供教育培训，帮助其了解健康的开源生态系统的要求，并指导项目负责人为他们担任 OSS 项目所需的更公开的领导角色做好准备。
随着 OSS 组织的成熟，其 OSPO 会开发内部流程、行动手册、清单、工具和其他机制来审查、组织和运营开源项目，并培养和指导其领导者。一些 OSPO 更愿意在主要开源基金会或 TODO Group 等协作机构的协助下启动项目，以增强能力或提供基础设施、战术援助和其他资源。这种选择需要的资源较少，但会将项目的控制权让渡给更广泛的社区。
本阶段建议参与的 OSS 社区列表
横向技能
项目 / 社区
社区健康和指标
CHAOSS
特定项目与伞式基金会
Linux 基金会
CNCF
Eclipse 基金会
Apache 基金会
4
阶段 4：成为战略决策合作伙伴
在这一成熟阶段，OSPO 成为技术决策的战略合作伙伴，帮助指导选择并形成对项目的长期承诺。在第四阶段，CTO 和其他技术领导者会向 OSPO 及其领导层咨询应依赖哪些开源技术以及在判断开源项目时使用哪些决策标准。由于主要的开源技术选择往往会产生大量的二级和三级成本，并影响上下游技术以及招聘计划，因此开源项目的选择成为一项重大的业务决策。
从广义上讲，OSPO 在第 4 阶段提供三种类型的战略指导。
首先，OSPO 就应采用或从组织的技术栈中删除哪些开源技术向 CTO 和技术领导层提供建议。鉴于当今 OSS 选项众多（大多数主要软件类别都有数十种选择，如图 2 所示），OSPO 可以提供对 OSS 趋势的洞察，例如不同语言的流行程度、API 设计或不同 NoSQL 数据库的功能。在此角色中，OSPO 成为 CTO 的内部技术顾问和 OSS 的内部专家。
在第二种类型的战略指导中，OSPO 率先对可接受的 OSS 项目的构成进行基准测试。OSPO 经常评估项目的行为和表现，特别是限制使用的许可证类型的变化，或项目路线图的突然变化，以确定项目管理者是否考虑到社区的最大利益。大多数 OSPO 依赖于粗略的信息评估项目行为的指标，比如：
它使用哪种类型的许可证？
它的行为准则是什么？违反它的后果是什么？
其治理结构是什么？该结构能否确保独立性？
响应 PR 或错误报告需要多长时间？
该项目发布新版本的频率如何？
项目是由一方（公司或组织）还是整个社区控制的？
-
该项目有多少贡献者？随着时间的推移，这个数字的变化趋势如何？
第三类指导是帮助组织理解和驾驭项目政治，例如当多个有影响力的参与者试图引导项目时保持中立立场，或者阐明社区成员潜在的政治考虑。在更高层面上，OSPO 可以帮助公司在技术民族主义问题上保持中立姿态，并通过培养超越国界和政治领域的个人和工作关系来弥合政治分歧。这种价值越来越多地延伸到基金会和非营利组织的工作中，因为这些领域成为开源中非常重要的中立空间。
本阶段建议参与的 OSS 社区列表
横向技能
项目 / 社区
社区健康和指标
CHAOSS
特定项目与伞式基金会
Linux 基金会
CNCF
Eclipse 基金会
Apache 基金会
OSPO 检查清单
根据 OSPO 五阶段成熟度模型，本清单可帮助从早期阶段到经验丰富的 OSPO 指引每个 OSPO 阶段及其任务。OSPO 检查清单可在"OSPO 研究的演变" 中找到。
阶段 1
定义项目品牌（如 OSPO、开源倡议、开源运营负责人）。
管理法律风险和许可证，创建新的流程和文档，以确保员工根据其许可证条款使用 OSS，并且组织消费 OSS 不会使其面临法律风险。
创建教育计划，帮助开发人员决定何时使用 OSS 来创建新产品或服务。
建立特定的软件库存流程，以创建全组织范围的软件物料清单 (SBOM)。
总之，要认识到 OSS 的价值以及合规、教育和 SBOM 的必要性。
阶段 2
列出与 OSS 项目交互的最佳实践，例如如何请求功能、提交错误报告和贡献基本代码。
向员工和管理者传达贡献 OSS 而不只是消费 OSS 的重要性（包括倡导和推动活动赞助、在公共技术论坛上预约项目负责人和维护者作为演讲者或小组成员，以及确保组织资源用于关键任务 OSS 项目）。
激励开发人员参与对其运营至关重要的 OSS 项目，使其成为高度活跃的贡献者或主要维护者。
阶段 3
发起和领导 OSS 项目，或者作为其主要赞助者。
创建并启动开源项目，在开源社区建立广泛的信誉。
为项目配备一名或多名全职员工，并承担起培育项目社区和确保其健康发展的责任。
开发内部流程、操作手册、检查清单、工具及其他机制，以审核、组织和运营开源项目，并培养和指导其领导者。
阶段 4
成为技术决策的战略合作伙伴，帮助指导选择并形成对项目的长期承诺。
向 CTO 和技术领导层提供建议，说明应采用哪些开源技术，或从组织的现有技术栈中删除哪些开源技术。
牵头制定可接受的 OSS 项目的基准。
帮助组织理解和驾驭项目政治。
更多内容：
vivo 正式加入 Linux 基金会旗下 TODO Group
本文分享自微信公众号 - vivo互联网技术（vivoVMIC）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。