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

2022-12-30 13:12

文 | 谭中意

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

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

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

企业开源战略定义

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

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

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

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

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

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

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

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

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

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

2.1 开源究竟是什么？

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

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

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

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

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

符合 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、腾讯、阿里）

2.4 企业开源的底层逻辑

利他 + 利己

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

竞争 + 合作

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

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

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

驱动力 3.0

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

3. 下面我们先看看企业开源战略中第一部分，如何管理企业内部的开源软件供应链？

（1）企业开源战略之一：开源软件供应链管理

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

合规方面的例子：

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 分钟内定位漏洞所影响的业务线并精确发送安全工单到直接负责人来告知情况和修复办法，三天内可以做到全部修复。

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

（2）企业开源战略之二：内部开源

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

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

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

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

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

下图是 InnerSource 和 DevOps 的关系图。

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

（3）第三部分我们来看看企业对外开源相关的战略。

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

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

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

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

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

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