开源项目办公室的五个阶段

[本文由 OSI 附属组织 TODO 组 贡献]

在多年观察 TODO 组成员中开源项目办公室 (OSPO) 的演变后，我们已经识别出常见的模式，并将它们总结在一个共享框架中。 OSPO 有五个常见阶段，可以识别您的组织参与开源的状态：将其用作改进您的开源之旅的建议。本文是什么是 OSPO 以及为什么您需要一个的配套文章。

OSPO 不同阶段的演练

为了更好地解释 OSPO 的演变，TODO 组的成员每年都会进行一次OSPO 调查，并提出了一个成熟度模型，您可以在您的组织中使用它。该模型作为一个框架，用于理解 OSPO 的各个阶段，从而确定组织在开源参与方面的所处位置，并帮助他们发展到更成熟的采用阶段

该模型由两个变量和四个阶段组成

• Y 变量：执行能力
• X 变量：OSPO 级别
• 阶段 1：法律驱动
• 阶段 2：社区驱动
• 阶段 3：参与驱动
• 阶段 4：领导力驱动

阶段 0：临时采用开源

几乎所有组织都使用开源，尽管他们如何适应和使用它各不相同。他们可能会将其用作产品或工具中的构建块或库，或作为供应商产品堆栈的关键部分，或支持供应商的服务产品。 现代云原生应用程序几乎默认使用开源系统进行容器编排、可观察性、数据存储、消息传递等等。

然而，最早期的采用形式是临时的，由开发人员使用现成的工具和技术解决问题。这种“临时采用”通常意味着很少考虑默认设置之外的许可证合规性，或者考虑使用开源组件构建和分发产品对长期产生的影响。

阶段 1（法律驱动）：提供开源合规性、清单和开发者教育

一般来说，当一个组织意识到其人员正在几乎所有工程和开发部门和职能部门中使用开源产品和代码时，就会成立 OSPO。这种使用通常是内部的，而不是面向客户或用户的产品或服务的一部分。 在这个早期阶段，组织通常对 OSPO 使用许多不同的名称。例如，IBM 最初将其程序化的开源工作称为“开源指导委员会”。

处于阶段 1 的组织认识到开源是其业务和技术战略的关键部分。他们理解开源项目的安全实践与专有软件公司的安全实践不同。

组织必须识别其法律和安全风险。风险缓解策略包括

• 谨慎的许可
• 开发者教育
• 清单编制

阶段 2（社区驱动）：推广开源使用和生态系统参与

早期

在组织认识到开源的价值以及对合规性、教育和软件物料清单 (SBOM) 的需求之后，他们开始意识到开源使用的经济效益，并寻求扩大其使用范围。 阶段 2 的 OSPO 创建了内部机制，例如推广使用经批准的开源产品的大使、关于良好习惯的教育计划，以及开源技能建设和认证的技术培训或学费报销。 通过这些举措，组织可以增加其开源的使用，并扩大其信息，即开源不仅重要，而且是可取的，并且比专有软件产品更受欢迎。

增长期

随着在此阶段的推进，组织开始激励其开发人员从事对其运营至关重要的 OSS 项目，使其开发人员成为高度活跃的贡献者或主要维护者。

• OSPO 开始为其开发人员简化和优化开放出站源代码贡献。
• OSPO 创建并启动开源项目，以在开源社区中建立广泛的信誉

阶段 3（参与驱动）：托管开源项目和发展社区

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

在这个阶段，OSPO 开发流程、剧本和工具来审查、组织和运营开源项目，并准备和指导他们的领导者。

阶段 4（领导力驱动）：成为战略决策合作伙伴

在这个成熟阶段，OSPO 成为技术决策的战略合作伙伴，帮助指导选择并塑造对项目的长期承诺。 首席技术官和其他技术领导者就依赖哪些开源技术以及在判断项目时使用哪些决策标准咨询 OSPO 及其领导层。 由于重大的技术选择往往会产生重大的次级和三级成本，并影响上游和下游技术以及招聘计划，因此开源项目的选择成为一项重要的业务决策。

OSPO 成为技术决策的战略合作伙伴，帮助指导选择并塑造对项目的长期承诺。 OSPO 演变为提供战略指导

• 就组织技术堆栈中要采用/删除的开源技术向首席技术官和技术领导层提供建议
• 牵头制定构成可接受的开源项目的基准
• 帮助组织理解和驾驭项目政治