文末有彩蛋 | 第四周课程回顾与总结

我们在前三周的课程上（第一周、第二周、第三周），系统讲授了 FOSS 和 COSS 的课程内容，第四周，我们开始进入 OSPO（开源项目办公室）的部分。

 

本导学班在调研全球开源教育与课程的基础上，通过收集、整理、理解、拓展国际最新的前沿开源课程，采取众创的模式，由 X-lab 核心开源研究的成员共同进行协作学习，以最大效率的吸收国际前沿开源知识，共创、共享、共进。本导学班，以开源 FOSS 和开源 COSS 课程内容为基础，结合自己的理解，并进行适当拓展。

 

第四周的系列课程围绕以下七块内容进行：

1. 开源介绍

2. 开源商业战略

3. 有效的开源项目办公室 (OSPO) 管理

4. 开源开发实践

5. 开源许可与合规

6. 了解上游开源项目

7. 创建开源项目

 

一、开源介绍

关于什么开源与开源软件，我们前面的课程已经讲过很多了，这里再进行一些简单阐述。根据维基百科的定义，开源软件 (OSS) 是一种计算机软件，其中源代码是根据许可发布的，版权所有者授予用户研究、更改和分发软件给任何人和出于任何目的的权利。开源软件可以以协作的公共方式开发。

 

开源软件的诞生源生于自由软件运动，实用主义和理想主义是现代开源在公司业务和战略的关键组成部分。开源社区的构建可以追溯到计算机的早期，植根于学术/企业/共享/黑客心态。几乎所有社区都具有以下几个主要特征：去中心化、透明度和任人唯贤。社区往往表现出紧密的垂直层次结构和松散的水平结构，如下图所示。虽然公司内部也可以运用这些“敏捷”原则，但和企业不同的是，开源项目呈现不同的组织结构模式 —— 不以职位论英雄，异步沟通和决策透明。

 

 

企业使用开源可以提高速度、降低成本、提高可定制性、加速创新并形成差异化壁垒。因此本系列课程将重点介绍企业通过 OSPO （开源项目办公室）更好的涉及开源。

 

二、开源商业战略

有两种主流的围绕开源的商业模式——使用开源的公司（大多数），和主要生产开源的公司。也就是对开源的消费和生产。

 

先看消费。Gartner的研究表明，一流的软件和技术组织使用的80%的软件来自开源，基于这些开源组件构建剩余 20% 的附加组成构成产品。因为这样可以使企业把有限的精力和资源集中在差异化业务上，同时与开源生态系统的其余部分分担通用代码的开发成本。

 

再看生产。对开源的生产通常分为以下几种类型：

许可  这种模式依赖于商业许可和开源许可下的双重许可软件，通常会产生产品的“社区版”和“企业版”，客户根据需要的功能来选择对应的产品。

托管  公司在云托管的SaaS（软件即服务）中提供开源产品，如 AWS 和 Google Cloud。

支持  企业希望利用开源提供的技术创新，但更关心在开源产品上运行业务。如 RedHat 和 IBM 等公司会提供支持、技术指导、专业服务和培训，来帮助企业在开源平台上运行业务应用程序。

OpenCore   一个功能强大的核心产品是免费和开源的。围绕这个核心，商业实体提供闭源软件以增加或拓展其功能。也可以与支持模型结合来提供培训和技术支持。

 

作为一个公司，制定实用的开源战略时，要先想清楚三个问题：

• 公司希望在哪里使用开源？

• 使用开源实现了哪些业务目标？

• 公司如何确保谁先开源业务目标？

 

典型的开源之旅有几个落脚点：消费，参与，贡献，领导。公司在开源中扮演不同角色时，需要制定的战略也不相同，如下图所阐述的，如果某个开源项目是你公司的产品或技术需要用到的核心元素，这时候对应的就需要去考虑成为积极参与者，甚至去引领这个项目。另外需要注意的是，公司在某一个开源组件中的参与程度会随着时间而改变，需要定期（典型周期为半年到一年）审查开源策略，根据业务或经济状况调整参与度。

 

 

三、有效的开源项目办公室 (OSPO) 管理

开源项目办公室（OSPO）是一个是企业明确制定和执行开源战略的地方。它旨在成为公司开源运营和结构的中心，支持、培育、贡献、解释和发展开源，这可以包括设置代码使用、分发、选择、审计等，以及培训开发人员、确保法律合规性和促进和建立社区参与。

 

OSPO的主要职责包括：

• 清楚地传达公司内外的开源战略

• 监督战略的执行

• 促进开源在商业产品和服务中的使用

• 确保向开源社区高质量和频繁地贡献代码

• 与开发者社区互动并有效地回馈项目

• 在组织内培养开源文化

• 维护开源许可证合规性审查和监督

 

当然也不是所有 OSPO 都需要具备以上全部功能，这更多取决于公司的业务需求。从下图可以看出，在与开发者协作以外，OSPO 还需要支持非常多的非开发活动，像公共关系协作，开源法务合规，制定策略，与社区的交互和参与等。

 

 

建立一个有效的 OSPO，需要先考虑从哪里开始，可以是自上而下，得到高层管理者的支持；也可以是自下而上，由一小部分开发人员和开源爱好者发起。无论如何开始，一个合适的领导者至关重要，这个角色需要对公司的业务了解深刻，拥有商业敏锐度和管理技能，并需要能够谈论深层技术。

 

下一步，就是建立结构化的政策和流程，同时保持一定的灵活性。

 

OSPO 的结构  OSPO应该在工程部门，还是在法律部门、CTO 办公室或其他特定业务部门？这同样取决于公司的主要业务和开源战略。这里有一些常见的位置供参考：

• 对于拥有大量知识产权组合的公司，前期会选择在法律部门设置 OSPO 来解决合规问题

• 工程驱动的公司通常选择在工程部门建立 OSPO，report to CTO 或 CIO

• 有些公司选择营销组，作为开发者关系/营销的一部分

 

OSPO 的人员  对应的，OSPO 的角色由开源项目经理，法律团队，合规团队（核心团队为开源审查委员会 - OSRB），开发者关系、宣传和布道者组成，还有一些其他工作角色，如工具管理员，培训经理，工具和系统集成开发人员，部署支持人员和实施项目负责人。

OSPO 的流程  配备了角色之后，下一步就是明确政策和流程。政策应该列出公司范围内使用开源的要求和规则，并记录可执行的流程，来确保规则得到了遵守。流程需要确保最少的开销，并不断质疑和更新规则以简化程序。公司要准备好随着时间的推移，业务的变化以及开源项目的成熟和发展，修改规则和程序。

 

四、开源开发实践

开源软件开发和传统软件开发中的 “Waterfall” 模型有很大不同。拿需求收集来举例，开源开发中需求通常是来自用户或开发者的“功能请求”，并且由于开发的迭代/敏捷性更强，不存在长期的需求阶段。这种方法需要应对不断变化的需求并对项目运营所在的技术和业务环境做出快速响应。

 

 

成功的开源开发工作的一个标志就是能够根据可用的参与量有效地扩展项目（可扩展的开发模型），随着小型项目发展成中型到大型项目，它们会执行更严格的发布周期，增加维护者，并对子系统进行进一步划分。可以参考世界上最成功的开源项目之一——Linux Kernel，它有一个严格执行的发布级别，和专门的维护集（LTE分支）。这种开发模型的一个关键要素是，通过将不同项目子系统的责任委托给“维护者”来发挥作用，“维护者”对子系统中的代码负有最终责任。这允许一定程度的专业化和监督，使整个项目维护者能够专注于项目的更大战略和架构图。

 

 

公司参与开源时，其实是要去和大型分布式开发团队进行协作，而这种协作方式和公司内部严格的开发活动略有不用。没有两个社区是完全相同的，社区也不适用于个别公司。所以一定要了解社区，了解它是如何治理和沟通的，然后去沟通、参与、回馈，并计划好适当的退出策略。（如果需要的话）

 

内源   内源是指“使用开源软件开发最佳实践，并在组织内建立类似开源的文化。该组织可能仍然开发闭源软件，但在内部开放开发”。内源实施非常强调开源的文化部分，除了简单采用开源开发实践以外，在组织内部建立更开放和透明的文化才能发挥内源的全部好处。

 

五、开源许可与合规

许可证是开源分发的关键概念。公司在使用开源项目时，许可证合规是一个非常关键的避免风险的策略。开源许可证如下图展示的，主要分为宽松许可证，如 MIT、BSD ，和互惠许可证，如GPL、AGPL。公司必须了解自己使用到的开源组件涉及到哪些许可证，并且在发布产品时履行许可证义务，所以开源合规计划整体分为两块：了解义务，履行义务。

 

可能会触发许可证义务的场景是对一个开源组件的修改和分发。

 

下图是公司进行合规管理时的典型实践，对于入站的开源组件（可能是自己开发的软件，第三方软件或专有软件）：

• 首先需要识别他们

• 识别之后，对源代码进行审计，得到审计报告

• 审查小组对审计报告进行审查，解决报告中的问题

• 批准使用

• 一旦某个开源组件被批准在产品中使用后，需要被登记到产品清单中，并在跟踪系统中注册

• 准备一份声明（Notice）

• 验证和分发，提供随附的（需要开源的）源代码，对应的版本

 

 

这个过程不可避免的需要依赖工具，例如源代码扫描，许可证扫描，二进制包扫描，集成工具，组件管理工具等。这里有两个行业优质项目：

• SPDX，提供了标准交换数据格式的工具，spdx文档的内容是标准格式的软件包、包级别、文件级别和版权信息等内容，这种更加通用的格式可以帮助降低扫描合规性时的复杂度。

• OpenChain，提供了一个规范和认证计划，涉及源代码、构建脚本、许可证副本、归属通知、修改通知、SPDX 数据和其他管理软件可交付成果的开源许可证可能需要的材料的供应链交换。

 

公司在进行并购交易时通常需要进行审计，对于特别是软件公司，开源审计流程和传统审计有一定不同。进行开源审计是为了了解目标公司对开源软件的使用深度和依赖程度。同样，输入是一些可能的开源组件，输出是一份物料清单（BoM），包含完整的开源组件来源，许可证，以及声明。

 

审计可以分为传统审计和DIY审计，传统审计是第三方审计公司的人员通过远程访问或现场访问源代码执行审计，并给出审计报告；DIY审计是收购方或目标公司自己运行扫描工具，这种方式更加灵活，但一般需要企业内部有经验丰富的员工能够解释扫描结果和提出修补建议。

 

 

 

六、了解上游开源项目

上游作为名词，是指衍生品所基于的原始开源软件项目；上游作为动词，是“将更改推送到上游项目”的简写方式，即对源代码所做的更改贡献回原始项目。

如果在供应链的背景下考虑上游，它会是这样的：

为什么公司要对上游项目做贡献？只消费而不回馈似乎看起来更容易，但是贡献回上游可以让其他人知道所做的变更，并且围绕变更进行规划，同时降低自己的代码意外损坏的风险，减少构建成品的工作量，甚至有机会影响你所使用的开源项目的未来方向。

 

那么什么时候应该贡献上游？

• 当保持代码与上游项目同步的成本（时间或金钱）超过单独工作的便利性时

• 当你希望其他人（包括客户）使用你的代码时

• 当你希望你的代码成为事实上的标准，或推动主线项目时

• 如果你预计在即将推出的产品中重复依赖某个代码库来补充上游项目

 

上游开源项目使用的治理模型有多种，因集权程度、组织实体的影响程度以及民主式决策机制和领导力选择而存在差异。没有一刀切的模型，不同的项目可能适应于某种特定的模式。我们可以看几种例子：

• 公司主导的治理，如Google Android，RHEL

• 仁慈的独裁者，最典型为Linux内核

• 理事会，如FreeBSD，Debian

• 基金会/财团，如Open Stack，Kubernetes，Academy Software Foundation

 

与上游进行合作时，我们一般采用“上游优先”的理念，然后制定有效的贡献政策，这些政策应该更多是帮助人们成功地为开源项目作出贡献，特别是对于新贡献者。贡献政策还应预定义上游项目使用的已批准的开源许可证列表。

 

上游社区可能还需要其他类型的与代码无关的支持，这时可以参考上述治理模型，可以选择以公司会员的形式赞助项目或者负责该项目的基金会。这些资金可以帮助项目取得成功，并且在某些情况下，还能帮助公司本身更多地参与咨询角色或对项目产生一些影响。

 

七、创建开源项目

公司要创建开源项目，第一步需要了解这样做的价值主张是什么——有成千上万个开源项目，你的代码是否提供差异化的价值，还是能让一个成熟且成功的项目变得更好？其次是衡量在开源中的投入，不是简单的将代码扔出来，却不考虑内部财务和工程投资。

 

下图列举了创建开源项目的适当理由和不好的理由：

 

 

 

你需要为你的新项目做好准备，确定相关的执行负责人，适当的给他分配资金。还有很重要的一点是，需要对员工进行培训，不只局限于对宏观开源的培训，还需要让工程师和产品经理意识到一些可能与他们日常构建产品或评估方式的不同之处。

 

下一步是对要开源的项目进行审查，包括法律审查，技术审查，这两块我们在合规工程中讲过；此外还有营销审查，为项目品牌建立指导方针；然后就是建立合适的治理模式和流程，包括社区架构，领导力，基金会的选择等等。

 

项目成功启动之后需要持续的维护，这就需要借鉴典型的成功的开源项目的运作模式了。你需要建立起一个社区，维护多元化的贡献者群体，这也意味着企业需要有更多资金投入，以及内部开发者的投入，这些投入可以依靠项目的重要性来决定。

 

一般来说，可以聘请社区倡导者（有时也称为社区经理）来帮助新的开源项目取得成功，这是个非常有挑战性的角色，此外，也不要忽视技术作家、项目经理，甚至社会学、心理学等非传统研究领域的人。

 

以上就是第四周课程的总结。自此，我们暑期为期一个月的开源软件通识基础课程到此结束，希望能够和大家继续保持互动，一起来聊开源。

 

我们接下来会进行短暂的休整与总结，开始新一轮的迭代。从新学期 9 月份开始，我们将继续推出新的一期开源通识课程，目的性也会更加明确，我们这里可以简单剧透一下。

 

 

为了保证课程质量与大家的专注度，新一期的课程准备采取定向邀请的形式进行招生（互联网企业、开源初创公司、开源基金会、高校、开源投资机构等），规模预计 60 人左右。

 

根据目前的反馈来看，开源运营的视角是大家需求最为迫切的地方，我们也考虑从这个角度来切入，小伙伴们不要错过，有兴趣的可以给我们留言，欢迎加入我们～

本文为  X-lab开放实验室  原创文章，遵循CC-BY 4.0协议，转载请附上原文出处链接及本声明。

文中部分图片源自：https://nythesis.com