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

嘉宾 | 谭中意

整理 | 涂承烨

策划 | 徐杰承

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

在日前由51CTO主办的​​WOT全球技术创新大会​​中，第四范式公司架构师、开放原子基金会TOC副主席谭中意老师为广大参会者带来了主题演讲——《大中型科技企业如何制定和落地开源战略》。重点介绍了什么是企业开源战略；企业为什么需要开源战略；企业开源战略包含的内容，以及企业开源战略制定和落地的实践经验。现将演讲内容整理如下，希望对诸君有所启发。

本文分为两部分：

第一部分为企业开源战略是什么，为什么需要，都包含哪些内容。

第二部分为企业开源战略如何制定和落地。

1. 企业开源战略定义

企业开源战略是企业技术战略的一部分。

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

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

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

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

• 海量开源组件如何使用才能安全、合规、高效？
• 每个企业都会用到大量开源项目，重点投入的项目是哪些？为什么？怎么投？如何衡量？
• 如何利用开源建设内部的研发文化？

2.为什么需要企业开源战略

企业已经离不开开源软件，所以需要一个整体、一致、长期、清晰的策略。

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

在展开阐述企业开源战略之前，我们先看看开源的一些基本知识和底层逻辑。

开源究竟是什么

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

现在认为，开源是一种开放式协作模式，产出物符合开源许可证的要求。

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

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

常见的开源商业模式

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

（1）羊毛出在猪身上

这是互联网从业人员非常熟悉的模式，A产品免费、B产品收费。例如Google的安卓手机系统是免费的，但安装在上面的Google GMS是收费的，这就是一类典型的商业模式。

（2）基于开源软件进行企业服务

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

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

企业开源的底层逻辑

• 利他+利己

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

• 竞争+合作

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

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

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

• 驱动力3.0

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

3.如何管理企业内部的开源软件供应链

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

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

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

开源软件社区的安全漏洞修复是非常快的，一般来说今天爆出漏洞，三天内就会出对应的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的问题。

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

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

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

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

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

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

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

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

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

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

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

4.企业开源战略如何制定和落地

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

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

开源战略如何落地

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

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

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

设立OSPO的常见模式

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

目前国内各大企业中，也有不少OSPO落地的案例，华为在其集团标准与产业发展部集团战略研究院；腾讯在其研发管理部；阿里的OSPO隶属于CTO office；百度则设立于技术管理部等等。

嘉宾介绍：

谭中意，第四范式架构师、企业智能化转型开源社区—-星策社区发起人、中国开源推进联盟副秘书长、开放原子基金会TOC副主席。在Sun、Baidu、腾讯工作超过20年，曾任百度开源技术委员会负责人。在企业开源治理方面有大量规划与落地经验。也是多个开源基金会包括Apache、Mozilla、Gnome、InnerSourceCommons、OpenChain的Committer/Member。