大中型科技企业开源战略制定与落地

“开源” 是近几年是非常火的一个词，但目前很多企业对于开源是什么，怎么用开源，如何参与开源，企业在开源方面如何做决策，如何进行开源治理，如何利用开源强化竞争力等方面的问题，仍存在着一些难点。

其实现实是，Open Source Has Won，企业已离不开开源软件，但是企业使用开源软件有各种风险，企业可以利用开源来获得商业利益，企业可借鉴开源模式进行各种协作，这些风险和收益都是企业需要考虑的东西，所以需要一个整体、一致、长期、清晰的公司级别的策略，称之为企业开源战略。

本文重点介绍了什么是企业开源战略；企业为什么需要开源战略；企业开源战略包含的内容，以及企业开源战略制定和落地的实践经验。本文又分为两部分：第一部分为企业开源战略是什么，为什么需要，都包含哪些内容；第二部分为企业开源战略如何制定和落地。因为这些内容对大中型科技企业更适用，所以本文的标题为大中型科技企业如何制定和落地企业开源战略。

企业开源战略定义

企业开源战略是企业技术战略的一部分，它主要与企业所使用的开源软件和企业内外部协作相关，包括如何选择和使用、如何管理和维护、如何与外部企业和社区合作、是否创建自己的开源项目来获取利益，还包括学习开源社区的协作模式来提升内部的效率和质量等。

关键的关键是需要跟企业的商业战略对齐。

空谈开源对于企而言没有任何意义，企业是一个盈利性组织，做任何事情都要考虑 ROI（投资回报率）。因此，企业开源战略一定要与企业的商业战略对齐。

企业开源战略主要解决哪些问题？

• 海量开源组件如何使用才能安全、合规、高效？
• 如何利用开源建设内部的研发文化，让内部协同更流畅，减少重复造轮子，加速创新？
• 每个企业都会用到大量开源项目，重点投入的项目是哪些？为什么？怎么投？如何衡量？
• 是否要对外开源自己的项目，为什么要开？怎么开？持续运营方向是什么？

为什么需要企业开源战略？

企业已经离不开开源软件，而且需要利用开源来增强企业竞争力，所以一个整体、一致、长期、清晰的公司级的策略是非常有必要的。

• 一个统一的、连贯的企业开源战略有助于明确企业内的优先级
• 企业开源战略可以指导企业内开源运营，并向员工提供清晰一致的导向
• 开源软件管理的流程和政策需要更高层的上位法

在展开阐述企业开源战略包含哪些内容以及如何做之前，我们先看看企业开源的一些基本知识和底层逻辑。

开源的基础知识和底层逻辑

“开源” 一词现在已经有很多种解释，开源软件、开源商业、开源协作、开源社区等等，开源的核心理念是以公开的方式产生知识产权。开源软件 = 源码公开 + OSI 认证的 License。而开源的商业模式则是建立在开源软件之上的商业模式。

现在认为，开源是一种开放式协作模式，协作的产出物符合开源许可证的要求。这种协作用在软件上，产出物即软件符合开源软件许可证的要求，就是开源软件。

企业使用开源软件不等于免费

企业使用开源软件不是免费的，是有各种成本的，例如引入的成本、学习的成本、维护的成本等，而在这其中，维护的成本一般是最高的。开源软件的许可证不管是哪种，都包含一个免责条款，即该开源软件的用户在使用该开源软件的过程中出现任何问题，都与原作者无关，原作者没有任何义务修复企业在生产环境中碰到的实际问题。因此，企业在使用开源软件碰到问题时，要么需要商业公司的支持，要么自行招聘工程师负责这方面的工作。而这都是需要成本的。

开源软件相关的常见开源商业模式

符合 OSI 定义的开源许可证的软件，本身是没有销售价值的，任何人都可以对其进行下载、修改、分发，软件本身不会收取任何费用。而关于开源的商业模式，则主要有如下 2 类：

(1) 羊毛出在猪身上

这是互联网从业人员非常熟悉的模式，A 产品免费、B 产品收费。通过开源软件产品免费提供，而从另外的产品上收费而获得营收。例如 Google 的安卓手机系统是免费的，但安装在上面的 Google GMS 是必须的，Google 通过 GMS 上的服务来获取收益。例如 Mozilla 的 Firefox 浏览器是开源的，它通过内置的搜索引擎默认为 Google 从而向 Google 收取费用。这都是典型的盈利模式。

(2) 基于开源软件进行企业服务

这类总结起来主要有以下四个模式：

• 双 License（代表：MySQL、X264）
• Open—Core（代表：Kafka，Elastic）
• Service（代表：RedHat，IBM）
• SaaS（代表：AWS、腾讯、阿里）

企业开源的底层逻辑

• 利他 + 利己

首先，企业将软件免费开放，将自己的知识产权暴露出去，这本身就是一种利他的行为。但企业又要从开源上获取收益，这又是利己的。因此，利己和利他必须要很好地结合，既吸取开源带来的便利，同时避免过度商业化给开源社区及企业长期利益带来损害。所以需要很好的设计商业模式，把握这个度。

• 竞争 + 合作

开源界有一个词是 Coopetition，是 Competition 和 Cooperation 两个词的混合体，开源世界既有竞争也有合作。两个厂商有可能在开源项目 A 方面是竞争关系，而在开源项目 B 方面又是合作关系。开源不是一个零和游戏，更多是做大蛋糕，大家分享利益的过程。例如，同一个商业赛道上的两家开源软件企业，可能只有在面对同一个客户时才是刺刀见红的竞争，而在其他方面，例如面对投资者、媒体、上下游或用户时，他们其实是一荣俱荣的合作关系。

• 开放 + 透明 + 协作的价值观

开源的运作建立在 “开放 + 透明 + 协作” 的价值观上，这也是 Apache 项目所推崇的 Apache 开源软件基金会最基本的理念。开源中的协作是要建立信任的，社区的运作也是以信任为基础的，而信任的建立必须要遵守这种价值观。

• 驱动力 3.0

对于从事软件研发的知识工作者而言，参与开源社区做贡献，更多的是源于他们的自驱力，他们希望自己的软件能够被更多人所使用并获得更好的价值。传统的 “胡萝卜 + 大棒” 的方式，做了多少事就拿多少钱的这种传统的激励方式是非常短期和低级的，对于开源相关的长期健康运作是不适合的。开源需要利用驱动力 3.0 的激励模型。

第一部分：如何管理企业内部的

开源软件供应链

企业开源战略之一：

开源软件供应链管理

开源软件的供给非常多，企业要确保开源软件供应链的可信。企业引入开源并在内部进行编译、再开发、再部署，这是一个链条的过程，在这个过程中，最重要的是要保证链条是安全的、合规的、高效的。否则会给企业带来直接的商业损失。以下是几个实际案例，因为企业不正确使用开源软件导致的商业损失。

合规方面的例子：

• FSF 起诉思科 关于 Linksys WRT54G
• X264 向某大厂索赔数千万美金
• VirtualApp 判例：GPL 是合同

CVE 方面的例子：

• Heartbleed
• Log4Shell

Bugs 方面：

• 不同 OpenSSL 版本导致集成后 Core dump
• Fastjson hang 导致多个业务受损

挑战主要在于 开源软件海量供给和海量需求，而且供给和消费数量递增的趋势还在增加。

据知名软件仓库软件提供商 Sonatype 的报告《 2021 State of the Software Supply Chain》统计，以 Java 为例 (据 maven 中心仓统计）,maven 中心仓库内有 430 万软件项目共计 730 万个软件版本，平均每个工程师每年下载 3 万 + 个软件包；以 JavaScript 为例（以 npmjs 中心仓库统计），npm 中心仓库有 1800 万软件包共计 2100 万个版本，平均每个工程师每年下载 10 万 + 个软件包。这些软件包绝大部分是开源软件。

衡量软件企业供应链管理能力

主要看两点：

• 当一个常用开源软件发现高危 CVE bug 和 fix 之后，多长时间内能在该企业内部定位和修复？
• 当该企业对外输出软件时候，是否快速输出高质量的 SBOM（软件组件清单）和 Notes，满足合规要求？

开源软件社区的安全漏洞修复是非常快的，一般来说今天爆出漏洞，三天内就会出对应的 patch，最迟一周也会出一个新版本。对于引入开源的企业而言，关键问题首先是漏洞的定位，其次是修复所带来的影响，这是企业需要考虑的一个典型问题。而对于向外输出开源的企业来说，一些比较严格的供应商会要求提供合规的软件组件清单，这对于企业而言会是一个考验。引入与输出都能够做得很好才会被认为是靠谱的、高效的供应链管理。

构建供应链需要政策、流程、工具、法务、安全团队的共同支撑，这是一个公司级别的行为。以国内外开源软件治理的案例来说，一定要将这个流程变成公司级的行为才能够节省成本。

实际操作案例：

• 组建跨部门多功能小团队，包括法务、安全、工具团队
• 使用工具尽可能自动化
• 需要大规模多层次的培训和宣导

对于同样 Fastjson 的一个高危的 CVE bug。在构建软件供应链管理能力前，其处理方式为：安全管理部向全员发邮件声明某个软件的版本有高危漏洞需要尽快修复，但是半年后这个 Bug 影响多少业务，这些业务是否已经修复都无从知晓。而在具备开源软件供应链管理能力后，企业能够在 30 分钟内定位漏洞所影响的业务线并精确发送安全工单到直接负责人来告知情况和修复办法，三天内可以做到全部修复。

我们接下来看企业开源战略中内部开源相关的内容。

企业开源战略之二：内部开源

当企业规模较大时，很容易出现各部门间壁垒严重的问题，俗称 Silos 即 “部门墙”，也很容易在多个部门内出现重复造轮子的情况。笔者曾在某大厂中发现机器学习平台有 15 个，某大厂中 Kubernetes 云部署平台超过 10 个，而其中大部分的轮子是低水平、重复、比较 low 的轮子。在集团范围内存在这些情况是对人力资源巨大的浪费。此外，工程师对技术的追求比较低，只想着快点把产品做出来、快点上线、快点拿收益、快点去升职，最后好跳槽。这会使得企业的技术升级速度放缓，留下大量技术债与极差的基础设施，部署环境、监控等都比较差。线上服务经常出问题，开发和运维人员经常处于救火中。

对于以上问题，内部开源是一个有效的解决方案。内部开源（InnerSource）是从开源社区的软件研发中吸取经验，并将其应用在公司内部的一种软件开发模式，其主要拥有以下优点：

• 提升代码质量
• 提升人员的能力
• 提高员工的满意度
• 打破部门墙
• 减少重复造轮子
• 激励创新

由于在实行企业内部开源后，参与其中的项目的代码会在内部公开，工程师在工作过程中自然而然会考虑代码的可读性，而且开源社区的运作方式是代码提交一定要经过代码 review，拥有严格的代码 review 过程，代码质量自然会得到提升。

InnerSource 和最近十年企业内推行的 DevOps 有非常深的联系。二者都以提升效率为目标。而提升效率最重要的两个方法，一个是重用，一个是自动化。InnerSource 更关注重复用，DevOps 则更关注自动化。其两者是互相促进的，一个 DevOps 做得好的项目，采用内部开源的方式来运作是更有利的。而 InnerSource 的基础设施做得好，也能够帮助 DevOps 的工具更快地落地。只有基于开放、透明、协作的价值观，建立起内部信任的文化，才可以将 DevOps 正向推动。对 DevOps 而言，并不是企业上了 CI/CD 平台，流程跑起来就算是做好了。

下图是 InnerSource 和 DevOps 的关系图。

目前采用内部开源的国际大厂包括微软、谷歌、Bosch，国内大厂包括华为、腾讯、百度等，都在进行相关的内源建设。

企业对外开源相关的战略

Linux 基金会曾提出，企业对外开源包括四个阶段：消费者阶段、参与者阶段、贡献者阶段、领导者阶段。企业对外开源的两种形态，一种是 Upstream，对已有项目做贡献，另一种则是自主创建开源项目。自主创建开源项目一定是带有强烈的商业目的，是 Business Driven 的问题。

企业 Upstream 的目的或者说收益主要有以下三点：首先，降低内部版本的维护成本。如果内部用到的开源软件需要与外部开源软件的版本长期保持同步，则需要减少本地的补丁数量，做法是将一部分补丁贡献回去，本地的补丁数量自然而然就会下降，从而减少持续版本升级维护的成本

其次，希望复用开源社区成熟的分发渠道。例如微软在 Linux 内核的贡献是不小的，但其贡献只聚焦于内核跟微软 Hypervisor 相关部分。使用这些补丁才能让微软的操作系统上安装 Linux 发行版的虚机运行状态良好。因此，微软将这些补丁直接贡献到上游社区即 Linux 内核，这样各个发行版出新版本的时候就会直接包含这些补丁。不贡献在上游 Linux 内核社区的话，微软需要跟各个 Linux 商业发行版本厂商一个个沟通技术合作，这将花费巨大的成本

最后，希望对一些关键软件保持控制力。一些大厂选择在对其业务非常关键的开源项目上投入人力，就是希望能保证这个项目的迭代符合它的利益目标。

近几年很多企业尤其大厂都在不断对外开源自己内部的技术。但是在对外开源之前先需要回答三个灵魂拷问：首先是为什么要做；其次是如何证明是否成功；最后是如何进行衡量。如果这几个问题都没有答案，那对外开源只能被认为是工程师自发的行为，对外开源的项目也大概率会成为一个烂尾的项目。

为什么对外开源，有一些比较好的理由如下：

• 构建事实标准，提供开源实现能更快推进标准
• 打击竞争对手，例如企业与某厂商是竞争对手，业务侧重点不同，将对手企业的侧重点实现并开源，就是对竞争对手的打击
• 竞争差异性，例如 Mozilla 与 IE 的竞争，IE 选择预装，而 Mozilla 则直接选择开源，实现竞争的差异性
• 建立生态系统推广，例如 Android
• 雇主品牌和技术口碑，例如 LinkedIn 开源 Kafka
• 降低支持成本，客户自行维护，例如各种云厂商的云 SDK

当然也有一些不好的理由如下：

• 甩包袱，不想维护的项目交给社区
• 内部不想增加人员，想找免费劳动力
• 内部工程师或部门的 KPI
• 纯 PR 无后续支持计划

在对外开源之前，需要对该项目进行很好的评估。

要评估一个项目的潜力，需要明确其所处的赛道、分类、市场潜力、与竞争对手的差异性，以及上下游都有哪些项目，这些更多的其实是产品设计、产品战略的问题。此外，企业在做对外开源时一定要做如下几个 Review：

• 法务 Review：项目采用什么样的 License、采用什么样的条款、是否存在法律风险
• 技术 Review：项目有没有安全漏洞，有没有合录一些不需要的代码
• 市场 Review：项目使用什么 branding，市场竞争的策略是什么
• 治理模式 review：采用独立发展模式还是托管到基金会，亦或是成为基金会的孵化项目

第二部分：企业开源战略

如何制定和落地

如何制定

企业的开源战略一定要结合企业的自身情况分阶段进行制定。例如拥有海外业务的企业，海外业务可以先从合规做起；内部重复造轮子现象严重的企业，可以先进行企业内部开源；而对于主营云，希望拓展智能云 toB 业务的企业，对外开源会是一个很好的手段。

制定过程可以参考使用 BLM（Business Leadership Model）方法来进行规划和制定。

开源战略如何落地

关于开源战略的落地有一个简单的方法，就是组建开源管理办公室（OSPO）。其作用是帮助企业创建和执行开源项目的战略，保障开源领导者、开发者、营销人员和其他员工成功运营开源项目。而 OSPO 的主要职责则涉及以下几个方面：

• 清晰向内外沟通公司的开源策略
• 贯彻并监督开源战略执行
• 促进企业内有效和安全的使用开源软件
• 维护开源许可合规的审查和监督
• 确保代码向开源社区的高质高频发布
• 与开发者社区合作，促进公司对其他项目的有效贡献
• 在组织内部形成开源文化

业内第一家创建 OSPO 的公司是 Sun Microsystems，Sun 公司于 1999 年成立首个开源办公室，其所做的第一件事就是推动 Java 的开源，也是由于开源所带来的正向影响，Java 一直活到现在并且非常有生命力。

设立 OSPO 的常见模式

业内设计 OSPO 的常见模式包含三种。

• 第一种，将 OSPO 设立在在法务部门之下，侧重解决知识产权问题，例如硬件的公司都会把 OSPO 挂在法务部门。
• 第二种则是将 OSPO 设立在研发部门，主要支持工程师使用开源软件，适合软件公司。
• 第三种，将 OSPO 设立在市场 / 开发者关系团队，偏重 PR 去影响销售。

目前国内各大企业中，也有不少 OSPO 落地的案例，

• 腾讯：研发管理部
• 阿里：隶属于 CTO office
• 百度：技术管理部
• 蚂蚁：隶属于 CTO office
• 微众：属于公司项目管理部
• 滴滴：属于开源委员会（虚拟）

通过组建 OSPO，来促进企业开源战略的制定和落地，是一个行之有效的办法。

作者丨谭中意

编辑丨唐凌波

设计丨宋传琪

开源社简介

开源社成立于 2014 年，是由志愿贡献于开源事业的个人成员，依 “贡献、共识、共治” 原则所组成，始终维持厂商中立、公益、非营利的特点，是最早以 “开源治理、国际接轨、社区发展、开源项目” 为使命的开源社区联合体。开源社积极与支持开源的社区、企业以及政府相关单位紧密合作，以 “立足中国、贡献全球” 为愿景，旨在共创健康可持续发展的开源生态，推动中国开源社区成为全球开源体系的积极参与及贡献者。

2017 年，开源社转型为完全由个人成员组成，参照 ASF 等国际顶级开源基金会的治理模式运作。近八年来，链接了数万名开源人，集聚了上千名社区成员及志愿者、海内外数百位讲师，合作了近百家赞助、媒体、社区伙伴。