企业与开源的分析和思考

导语：近年来，开源软件对企业数字化转型的促进作用愈发明显。国家更是把建设和完善开源生态写入了“十四五规划”。与此同时，围绕开源治理、安全供应链等话题成为业界一大热点。作为开源用户或者作为开源主体，我们应该如何理解开源，如何理解社区，如何更好更安全地参与开源。本文将与您一起从开源的意义、商业模式、风险与挑战、选择与治理等几个方面进行探讨。

开源对企业的意义

让我们首先站在一个小我的角度思考开源与个体的意义，可以用一句话来概括“利己与利他”。使用开源项目或产品可以帮助个人快速解决工作中的问题与挑战，个人还可从开源项目或产品中获得创新思想与经验。这些都是利己。当个体不满足于只是作为开源的使用者，而开始参与到开源项目的贡献时，乃至自己设立开源项目时，就变成了利他，其他用户将从他的贡献或项目中获得收益。

对企业来说也一样。当企业注重自身的数字化转型时，就意味着企业将会追求更加开放的组织精神。数字化转型的核心是利用数字技术和能力实现企业流程再造，进而驱动商业模式创新、提升企业竞争力，甚至改变一个行业，就像“滴滴”一样。这就要求企业的 IT 基础设施、技术不但要能支撑业务的快速变化与发展，更要能够驱动业务创新。企业要快速建立业务，快速迭代业务，快速获取业务反馈。因而具有可灵活支持短期与长期业务发展的 IT 架构与技术是关键，企业必须采用开放的可协作的新技术来持续改进和提升技术架构迭代能力。这些都意味着要足够“快”，要足够“创新”。开源技术恰好呼应了企业这样的需求，因为开源技术追求开放、协作、贡献的精神。企业采用开源技术，可以获得来自全世界优秀人才的贡献，更可以通过借助全世界人才的贡献来快速改进和提升企业的竞争实力。开源所造就的开放生态系统为所有相关方带来了这样的价值。

以智能汽车行业为例。传统上，汽车生产企业需要依赖大量第三方供应商与技术。但当企业进入智能汽车新赛道后，车企需不断地创新车辆功能，提升用户体验，快速占领市场。如果车企依然采用传统供应商模式，将受制于那些封闭的供应商而无法创新产品，无法快速占领市场。通过采用开源技术，比如 AGL（Automotive Grade Linux），可以无需再去开发车载的基本操作系统，而将宝贵的研发技术投入在更多的具有竞争性的创新上。

具有开放性精神的企业，并不会仅仅止步于采用开源技术，更会贡献到开源中来。大型企业可以通过开源自身的产品或技术，帮助企业实现市场战略，占领市场或改变市场游戏规则，例如 Google 的安卓系统。而创新型小企业通过开源可以积累庞大的社区用户，增加影响力，扩大自身估值。

可以看出开源对企业数字化转型的意义是显而易见的。一方面，开源有利于激发企业技术创新，相对于使用闭源软件，开源技术让使用者更具创造力和创新精神；另一方面，使用开源技术能够帮助企业节约成本，从而可以让更多的 IT 投资用于部署新技术，加快数字化转型。在一项针对全球 IT 领导者 2020 企业开源状况的调查中同样反映了这一结果，95% 的受访者表示开源对他们的整体软件战略具有战略重要性。在国内，一些头部互联网企业也成立了专门的企业开源委员会来帮助企业实现更好的开源战略。国家更是把建设和完善开源生态写入了“十四五规划”。

开源有时还会被赋予“可信、可控”的概念。诚然，开源并不能和“可信、可控”直接画上等号，只有当企业有能力并有资源来通过学习彻底吃透并掌握时才具备真正的可信、可控。但开源，确实通过源代码开放的形式，让用户可以吃上定心丸，并在企业必要的时候通过研究开源代码来解决运维中的问题。

F5 在中国运营开源 NGINX，深刻理解中国用户的诉求。NGINX 技术的可靠性与易开发性保证了企业能够具有更好更可靠的 IT 基础架构，这是它对企业数字化转型的重要意义。无论是在分布式还是在微服务架构里， NGINX 技术都已经被全世界用户验证，其可靠性确保了 IT 基础架构的稳定。在中国，我们可以看到无论是互联网公司，还是金融企业，都有大量的用户在生产中使用 NGINX 技术，比如农业银行的开放银行，新网银行的业务访问调度等等。NGINX 的易开发性让这些技术创新成为可能。可以说很多客户借助 NGINX 实现了软负载的自主可控。更进一步，通过对开源 NGINX 进行本地化，在中国提供开源订阅服务，意味着中国用户可以通过本地服务实现更可靠的产品使用，这个服务包含了基本的技术支持，还包含高级专家服务，联合共创、开发等。

开源的商业模式

开源的商业模式有很多。根据项目的起源、背景、诉求、主体的不同，一般可以分为：

• 广告模式

通过在网站、安装过程、文档等地方放入赞助商广告获得一定收益。游戏、搜索类项目，一般容易采取此类方式。

• 售卖服务

这是比较典型的开源商业模式。服务商本身并不提供代码的售卖，而是出售服务，用户为更好更专业的技术支持服务付费。服务的售卖可以是开源项目的原主体，也可能是其他主体。当然一般来说单纯售卖服务很难支撑一个公司的发展，一般来说企业会采取混合的商业模式，例如 Redhat 公司。

• 软件再分发

企业通过自身的开发，扩展、丰富上游开源项目，并形成商业化的产品进行再分发与销售。这是一种比较常见的方法，例如围绕 kubernetes 存在大量的商业发行或企业产品的再整合。

• 直接代码售卖

开源的定义容许你直接销售源码。在互联网早期，通过收集、分发代码或二进制软件并灌制为光盘等形式来获取收益。依靠直接销售代码在如今显然不太容易成功。

• 双重许可/核心开放

开源项目的主体在公开源代码的同时拥有商业 License 版本的软件，一般来说两者会存在一些功能性差异。开源产品会拥有主要的核心功能，但是一些对企业生产级部署时需要的额外功能会通过商业版本进行销售。这类企业往往也会同时附加售卖服务。NGINX 开源与 NGINX Plus 便是一种双重许可。NGINX Plus 完全基于开源 OSS，但增加了诸多企业级的特性，使得用户可以更好地在生产环境下部署运行。

• SaaS

将开源软件部署为云上的 SaaS 服务模型，也是当前比较流行的方式。也是云时代下，开源类产品更易获得商业成功的模式。MangoDB 的 SaaS 服务即为这种模式。当然也因为云上服务引发了一些开源的争议，在后文的风险与挑战部分再做探讨。

• 生态伙伴

以生态伙伴的方式进行商业化属于一种混合的商业方式。一些企业通过员工全职参与到一些非常知名及流行的开源项目中，类如 Istio，Kubernetes 等。对这些上游项目进行贡献，并进入到这些上游项目的技术委员会，SIG 等，在社区与领域上形成较高的影响力。公司本身则会进行相关专业服务支持、增值产品等的售卖。这是一种较为高级的商业形式，一般来说多存在于大型公司或极具创新的初创公司。如 Solo，Tetrate 这类公司。F5 NGINX 对社区 k8s Ingress Controller 的贡献也是这样的模式。

开源的商业模式还有很多，例如捐助、众筹、周边品牌等。无论哪种方式，从用户角度来说，产品必须具备价值才能够被买单。对依赖开源进行商业化服务的公司来说，则必须提供有价值的产品、有良好体验的服务，回归到产品本源才能更容易实现开源商业化。仅依赖市场营销难以持久实现开源商业化。

开源的风险与挑战

开源对企业或用户拥有诸多的好处。但在实际使用过程中，依然会存在一定的风险与挑战。从风险角度来说，有以下四个方面：

• License 风险

这可能是在使用开源中首要进行考虑的方面。一般来说自由软件 License 是 copyleft 模式的，这类 License 一般较为严格，会强制下游用户继续保持开源。因此要小心在修改代码后是否会违反 License 的要求，比如 HAproxy 的 GPL License 就要小心应对，这是典型的 copyleft 型许可，在分发修改并编译的二进制时，必须要附上修改后的源码，利用 HAproxy 实现的具有交付式能力的封装产品，在交付提示符下还需要有相关简短版权声明等。尽管如今的一些开源软件 License 已不再要求用户必须再开源修改后的代码，但是仍然需要小心 License 的许可场景以及限制性要求。比如，是否将开源代码用在了被禁止的使用场景里，Redis 的 RSAL 就对使用的场景如搜索引擎、流处理引擎等进行了限制。在使用开源软件构建云上服务能力时，对于使用 Affero GPL 或 SSPL 协议的开源产品则必须小心，他要求必须公开相关源码，这对很多类似公有云的企业非常不友好，因此 Google 在内部严格拒绝在公有云上使用 AGPL 的软件。

• 项目持续性风险

由于开源的主体参差不齐，有些项目是一些企业 KPI 导向的结果，有些则是个人基于兴趣爱好或者工作阶段的成果(可以称之为：顺手开源)。这些项目可能无法具有持久性，其生命周期也较短。如果企业选择了这类项目，则必须要充分理解此类风险，企业需要自己能够持续性开发和维护。持续性风险，还可能表现在一些地缘问题上。尽管开源倡议组织（OSI）在开源的 10 项定义里提到“不歧视个人或群体”，但是在一定的情况下依然会遇到这样的担忧。有时候这类担忧是因为个人情感或基于个人认知而做出的。如前段时间 F5 关于停止 F5 俄罗斯办公室职员工作的声明，让少部分人从情感上无法接受，误解为 NGINX 源自俄罗斯而 F5 却停止了俄罗斯人对 NGINX 的贡献。实际上这仅仅是 F5 基于地域战争对 F5 内部职员安全考虑而做出的决定。NGINX 的源代码一直托管在 github 以及 mercurial 多个服务系统上，来自全世界互联网用户的贡献、访问、下载均未被影响。

• 项目质量风险

开源项目由于追求开放性，以及开发者经验水平并不完全一致，这可能导致代码测试不充分、代码存在安全隐患，以及不全面的使用用例等。一些大型、热门的开源项目往往会通过规范开发者贡献、设置专门测试人员、文档人员、安全小组等方式来提升软件质量。但并不是所有项目都能具有这样的资源和能力。企业在做开源项目引入时候应做充分的调研与测试。

• 开源嵌套风险

此类风险需从两个角度考虑。一是 License，当在自身的项目中引用其它开源项目时候要注意引用方法与 License 的关系，注意自身项目 License 与引用项目 License 是否存在兼容风险。二是注意连环嵌套带来的质量失控，当 A 项目引用 B，B 又引用 C 等这类多层引用时，要综合判断上述提到的所有风险情况。

从挑战角度来说，其涵盖要宽广得多。一般来说，企业的数字化转型会涉及文化、技术、流程这三个方面。同样的，企业使用开源的挑战也可以从这三个方面来思考。

• 文化方面

企业建立开源文化动力不足是个挑战。企业往往会强调运行的稳定，无论是流程还是 KPI 考核对于 IT 系统往往追求的是稳定性。从项目的招标、测试、上线、运维无一不以稳定为第一。在这样的文化下，技术系统、人员思想容易僵化：近乎静态稳定的 IT 系统限制了 IT 系统对业务创新的支持，导致业务上线速度缓慢；技术人员则会依赖商业产品的技术支持，导致缺乏创新精神。开源文化动力不足，还表现在另一方面，就是企业缺乏开源贡献精神，只是一味索取使用，不对开源上游进行贡献，更害怕把自己的创新共享到社区。

• 技术方面

涉及两个相互关联的挑战：开源技术掌握的能力，以及掌握技术的人才。开源产品，往往不是开箱即用，需要企业根据自身情况进行再开发，同时为了实现业务能力，往往还需要采用多种开源技术。这就需要企业需要具有更多的开发人才，更多的具有创新能力的人才，需要这些才来分析研究这些开源产品，吃透并掌握核心技术。这对于采用外包模式的企业，往往挑战很大，这类企业缺少足够的人才来掌握这些技术。即便是对于具有一定开发规模的企业来说，如何转型人才，建立良好的人才上升通道，留住掌握关键开源技术、吃透开源技术的高端人才，其实也是非常大的挑战。

• 流程方面

企业需要将已有流程与开源相适应，这往往比较困难。使用开源技术意味着面向闭源软件的流程需要改造并适应开源技术带来的变化，无论是商务流程、资产管理、技术配套、治理流程等等。我们见到有一些企业，当使用开源后，如何购买与开源相关的技术支持服务时，在流程上仍会遇到一些问题。

开源的选择与治理

开源主体和开源用户对开源的选择与治理的思考会在两个不同的范畴。因为这是两个方向的问题，尽管两者角色有时候会交叉。

开源选择，对于开源主体来说，首先要对自己的项目是否开源做出决定。项目的负责人或公司需要基于对开源的认知理解，结合所在行业的特点、领域竞争分析，自身实际情况去思考，综合分析开源或不开源将会产生的影响。当决定开源后，还需决定是企业内部开源还是对外开源。企业内部开源是一些头部互联网或技术领先的大型企业的一种做法，其本质是利用开源的好处促进企业内部创新，打破企业部门壁垒，提高企业生产力和协作效率。一般来说，企业的内部开源会经历个人或小组自发阶段，进而到企业设立内部开源管理部门进行企业全局层面的统一开源管理与协调阶段。

当正式决定开源后，随后就需转入对开源治理的思考。对开源主体来说，开源治理包含了两个方面，一是项目工程的治理，二是社区治理。

1. 项目工程治理,无论如何，开源项目最终还是一个软件工程，只是它是建立在更大范围内的协作、信任与贡献的基础上。因此对于项目工程质量、代码方面的管理一样适用于开源项目。需要考虑项目的范围管理、进度管理、质量管理、变更控制等，通过这些管理保证代码的质量、进度、安全等。我们可以看到一些开源项目会给出开发者指导、Code of conduct 等，这些都是用来保证代码质量。同时，还需要构建良好的 DevOps 自动化流水线，以便让开发者的贡献过程更加顺畅，确保提交的代码经过相关 review、自动化检查、自动化测试等并及时反馈结果给贡献者。此外，还需要做好风险管理，我们可以看到很多成熟的开源项目都会要求开发者签订开发者贡献协议（CLA）之后才可以提交PR，这些都是为了防范版权、非原创等方面的风险。风险管理还包含对项目中所用到的其它开源组件的 License 合规性管理，避免引入风险，类似 FOSSA 类工具往往会被用于此方面的管理。

2. 项目社区治理，开源项目最大的特点是去中心化，人员多样化，他们来自世界各地，背景不同、文化不同。因此社区的治理本质上是对“干系人”的管理，人的管理是开源项目中最大的挑战。可以说社区治理的好不好是项目能否成功的一个非常关键的因素，因而 Apache 基金会特别强调 “Community over code” 理念。社区从一开始就应该定下明确的规则与基调，这样可确保社区始终聚拢那些具有相同认知的人。社区的治理会涉及到选择哪种治理模式，比如基金会托管还是自我管理。一般来说，加入基金会有利于项目的运作，因为这些专业的开源基金会可以帮助指导项目的运作，也可以帮助项目快速走向全球化，帮助构建项目生态，通过基金会的力量形成不同项目之间的交叉支持。当然，基金会还会运作很多活动，这些都可以帮助项目提高知名度，吸引更多开发者成为用户，并最终成为贡献者。自我管理则需要项目所有者或背后所属的组织具有较强的社区管理能力。比如 NGINX 就属于自我管理，F5 公司通过专业的社区运营团队来治理社区。无论哪种治理方式，其核心都是要帮助项目走在正确的轨道和方向上，保证项目的可持续发展，解决项目进行过程中的各类干系人问题。社区治理需要进行的工作可包含产品布道、活动运营、开发者关系维护、Issues/PR 管理，许可证管理，社区契约与规则管理、文档管理、生态构建、法律事务等。

开源选择，对开源用户来说，特别是对企业用户，开源选择的第一条就是应建立准入控制，企业可以考虑建立开源软件资产白名单，避免开发者随意引入开源软件或项目，同时对采购的服务商所提供的软件也要执行相关白名单检查。尽管这在一定程度上增大了成本，但是对于企业的安全风险控制却是非常必要的。企业应对开源项目进行充分的调研与分析，了解项目的状态、活跃度、背后的支撑力量、运作模式、用户基数、贡献者热度、License 限制、技术路演、软件架构、代码质量等，并做好充分的引入前测试。还应客观引入开源项目，避免少部分人的技术情怀或倾向而导致引入“关系型开源项目”。

再来看开源治理，如同上文关于使用开源的挑战，企业可以从文化、技术、流程方面进行开源治理。

1. 文化方面，企业应建立崇尚开源、敬畏开源的文化。在积极鼓励采用开源技术的同时，加强员工对开源的认知。如尊重版权，避免法律风险。认识开源并不等于免费，使用开源不等于取巧。认识开源并不意味着就可以自主可控。开源不等于定制化，任何有利于产品的修改与增强都应回馈到上游。企业应根据自身实际情况客观评价当前对开源的把控能力，不宜冒进。比如企业可能是需要一步一步塑造开源文化基因，这时企业更适宜采用有专业支持服务的开源软件使用模式，通过引入第三方或开源服务商的支持来帮助企业避免技术风险，实现务实的自主可控。以软负载类产品为例，企业可通过引入 NGINX 支持服务来尝试开源实践。对于刚进行开源实践转型的部门，如运维部门，可考虑采用商业产品 + 厂商开源扩展的解决方案，确保在风险可控的前提下，逐步进入开源运维。

2. 技术方面，在开发环节建立良好的开发构建与测试平台以及安全测试平台，对相关开源代码展开代码扫描检查。识别相关库的依赖关系，发现代码本身以及关联依赖的潜在漏洞。通过开源 License 管理软件检查可能存在的 License 合规性问题以及交叉问题。在交付运行环节，使用额外的安全设备或策略对运行开源组件的环境进行安全加强，比如相关开源软件在历史上是否曾暴露过漏洞，其所依赖的组件是否暴露过漏洞，有针对性地进行加固。加强技术团队对开源技术的学习与技能提升，建立专业的开源技术组件支持团队等。

3. 流程方面，企业可以考虑建立从引入、开发、交付、运维到退出的全流程机制来进行开源管理。从组织机制、管理制度等方面来形成开源软件引入规范、开发规范、部署规范、运维规范、退出管理等规范。引入规范可以结合上述提到的开源选择部分识别开源准入，建立准入条件，把好入口第一道关。开发规范则可以考虑定义开源软件代码的使用语言、范式、边界、修改流程、文档流程等。部署规范可围绕交付、依赖管理、安全加固、标准化环境等方面进行考虑。运维规范可考虑开源软件的运维工具、排错流程、最佳实践等方面。此外，企业还应形成闭环的管理体系，针对开源的使用与运行，建立识别与检查机制。例如识别已经在运行的开源软件及相关项目，并对其进行评价，针对发现的问题进行相关文化、流程、技术方面的修正，也要及时退出运行不佳的开源软件，确保对开源的治理始终处在有效的轨道上，避免开源的蔓延与失控。

总结

可以看出，无论是开源主体，还是开源用户，围绕开源的理解、选择、风险、挑战、治理都是一个系统化的工程与能力。近些年，在国家大力推进开源的战略背景下，国内又提出了“可信开源”的理念，其主要目标依然是如何更好地发挥开源的作用，避免开源中可能遇到的风险。不管怎样，如果一个开源项目能够始终坚持初心，坚持以用户为中心，那么在很多方面可以消除用户在开源方面的担忧与风险。正如 F5 中国总经理张毅强在 “2022 F5 多云应用服务科技峰会” 上所说：以用户需求为中心，围绕产品特性与社区平台构建开源生态。这是保证 NGINX 在中国可以走的更长远的核心，是 F5 为用户提供价值的核心，是用户信赖 F5 的核心。我想，这同样也适用于我们对其他开源的理解。