Loading... # 企业开源的软件协议模型实践技术分析 # 一、概述 ## 1. 文档背景 本文基于夜天之书博客发布的技术分析文章《企业开源的软件协议模型实践》，深入探讨企业开源场景下软件许可证的选择策略、风险管控和商业模式设计。 发布时间：2023 年 2 月 15 日 作者：tison ## 2. 核心问题 企业在决定将自研软件开源时，面临的首要问题是选择什么样的软件协议。这个决策直接影响企业的商业竞争能力、团队稳定性和长期发展策略。 ## 3. 分析维度 本文从企业开源的不同诉求和风险出发，结合实际企业案例，分析两大主流策略： - 完全开放源码策略 - 源码公开但禁止商业竞争策略 # 二、完全开放源码策略 ## 1. 策略定义 完全开放源码是指以符合开源定义（Open Source Definition）的软件协议发布企业自研软件。这既包括宽容协议（如 Apache License 2.0、MIT），也包括 Copyleft 式协议（如 GPL、AGPL）。 ## 2. 主要风险分析 ### A. 竞争对手的商业竞争 #### 风险描述 开源软件的用户分为两类： - 黑客用户：有能力使用和修改软件 - 顾客用户：无力或不愿承担开发和维护任务 完全开放源码后，竞争对手可以免费获取软件代码，直接提供同类服务展开商业竞争。 #### 典型案例 **Kafka 托管服务竞争** - Confluent 聚拢了 Kafka 核心开发者 - Upstash、Aiven 提供 Kafka 托管服务 - AWS MSK、阿里云 Kafka、红帽 OpenShift Streams 提供平台服务 - Confluent 被迫寻求新的增长点（多租户功能、流计算集成） **ElasticSearch 和 MongoDB 协议变更** - ElasticSearch 初期使用 Apache License 2.0 - MongoDB 使用 AGPLv3 - AWS 等云厂商低技术成本、高平台优势竞争 - 最终被迫变更为禁止商业竞争的协议 ### B. 团队分裂并参与竞争 #### 风险描述 在软件可自由演绎和商用的情形下，企业内部开发者可能分裂出去单独进行商业运作。 #### 典型案例 **Apache Hadoop** - 雅虎孵化，但未下场商业化 - Cloudera、Hortonworks、MapR 激烈竞争 - 结局：Hortonworks 和 MapR 被收购，Cloudera 私有化退市 **Apache Flink** - 德国大学开发，捐赠至 Apache 软件基金会 - 创始成员成立 Ververica，2019 年被阿里巴巴收购 - 核心团队分几次出走 - Immerok 公司被 Confluent 收购，狙击阿里巴巴流计算业务 **Apache Doris 案例分析** - 百度研发团队开发并捐赠 - 部分核心开发者出走，fork 创建 StarRocks - 另一研发团队出走，成立 SelectDB - StarRocks 与 Doris 硬分支，"大路朝天，各走一边" **其他硬分支案例** - Trino 基于 Facebook Presto 硬分支，团队成立 Starburst - Lightbend 将 Akka 切换商用协议后，社群 fork 创建 Pekko - AWS 在 Elastic 切换协议后，发起 OpenSearch 项目 ```mermaid graph LR A[Apache Doris] -->|团队出走| B[StarRocks] A -->|团队出走| C[SelectDB] D[Facebook Presto] -->|硬分支| E[Trino/Starburst] F[Akka] -->|社群 fork| G[Pekko] H[ElasticSearch] -->|AWS fork| I[OpenSearch] ```   ## 3. 应对策略 ### A. 运维和高级功能策略 #### 策略描述 提供比开源版本功能更丰富的企业版本，包含闭源高级功能或运维支持。 #### 局限性 - 无法提供明显竞争优势，竞争对手处于同一起跑线 - 企业工程师投入开源上游开发，成本由企业承担，竞争对手无偿获取 - 难以做出合适代差说服客户 - 纯运维支持营收难以支持公司增长 #### 结论 这是保护性策略，必须提供，但很少成为决定性优胜策略。 ### B. 独特品牌建设策略 #### 策略原理 通过基于软件建设公司独特品牌，将软件与公司品牌关联，赢得用户心智竞争。 #### 成功案例 **HashiCorp（Terraform、Nomad）** - 使用 MPLv2 协议发布 - 定义基础设施即代码的工作方式 - 用户采购的是整套方法论，而非单一工具 - 竞争对手难以超越原创厂商 **Cube.js 和 Streamlit** - 商业智能数据分析服务内核 - 定制化和方法论依赖程度高 - 技术品牌与开源软件绑定 **Starburst（Trino）** - 推出 Data Mesh（数据网格）概念 - 联邦查询引擎支持不同来源数据统一分析 - 概念传播性强，Confluent 也跟进捆绑营销 #### 失败案例 **MySQL AB 公司** - 拥有 MySQL 版权 - 数据库标准化程度高，共识清晰 - 运维专家可开设公司提供商业服务 - 附加价值有限，被云厂商关系数据库服务截取利润 ```mermaid graph TD A[独特品牌建设] --> B{标准化程度} B -->|低| C[成功案例] B -->|高| D[失败案例] C --> E[HashiCorp IaC] C --> F[Starburst Data Mesh] D --> G[MySQL 云厂商竞争] ```   ### C. 赛道维度升级策略 #### 策略描述 当开源软件成为行业标准后，单纯部署运维服务陷入价格战，需要升级赛道维度，提出新的解决方案。 #### 典型案例：Databricks **第一阶段：Spark 简单包装** - 与微软 Azure 合作 - 捆绑销售 Apache Spark 性能优化发行版 **第二阶段：AI 切入点** - 推出 SparkR 和 PySpark 集成支持 - 与 edX 合作推出 Spark 系列课程 - 强化 Databricks 品牌在 Spark 生态中的地位 - 针对 AI 提供标准化算力资源和解决方案 **第三阶段：湖仓一体** - 发现 Spark 计算能力加存储的巨大需求 - 自研 Delta Lake 软件 - 提出 Lakehouse 概念 - 完善 Delta Live Table 等周边产品 **第四阶段：Data + AI 平台** - 不是简单 Spark 提供商 - 成为 Data + AI 领域企业级方案和云服务提供商 - 与简单提供 Spark 作业调度的企业不在同一维度竞争 ```mermaid graph LR A[Spark 包装] --> B[AI 切入] B --> C[湖仓一体] C --> D[Data + AI 平台] A -.竞争对手.-> A1[Spark 托管] B -.竞争对手.-> B1[AI 平台] C -.竞争对手.-> C1[数据平台] D -.无同类竞争.-> D1[市场空白] ```   ### D. 市场占有率与开放标准策略 #### 策略原理 将开源软件作为打开市场和建立开放标准的敲门砖，而非企业盈利核心软件。 #### 应用场景分类 **场景 1：开源编程语言** **Erlang/OTP 案例** - 瑞典电信公司 Ericsson 支持 Joe Armstrong 开发 - 将整个 Erlang/OTP 平台完全开放 - 目标：保证劳动力市场有人熟练掌握，维护内部系统 - 结果：在电信行业推广，游戏行业广泛应用，BEAM 虚拟机借 Elixir 再次发展 **Elixir 案例** - José Valim 在 Plataformatec 开发 - 开发 ecto 工具和 Phoenix 框架 - 使用率增长后，创办 Dashbit 提供支持和咨询 - José 头衔：Chief Adoption Officer（首席采用官） - 策略：用户使用量增长是基本盘，不杀鸡取卵 **场景 2：竞争型开放标准** **Google 开源矩阵** - Chromium：浏览器内核半壁江山 - Android：与 iOS 二分天下 - Kubernetes 和 Istio：容器战争胜利者 **Facebook 案例** - React 成为无可置疑的前端标准 - Google Angular 势弱，投资企业和开发者损失惨重 **国内企业案例** - 腾讯 Apache InLong（数据集成） - 阿里巴巴 Apache Dubbo 和 Nacos（微服务） - 字节跳动 CloudWeGo（中间件） - Bilibili Go Kratos（微服务框架） **场景 3：初创公司实践** - DatafuseLabs 捐赠 OpenDAL - CockroachDB Pebble 存储引擎（BSD-3-Clause） - 初创公司更容易在细分领域或新兴领域通过开源赢得声誉 ```mermaid mindmap root((市场占有率策略)) 编程语言 Erlang/OTP Ericsson 内部使用 保证劳动力市场 Elixir Dashbit 支持 Chief Adoption Officer 竞争标准 Google Chromium 浏览器 Android 移动端 Kubernetes 容器 Facebook React 前端框架 国内企业 腾讯 InLong 阿里 Dubbo/Nacos 字节 CloudWeGo Bilibili Kratos 初创公司 DatafuseLabs OpenDAL CockroachDB Pebble ```   # 三、源码公开但禁止商业竞争策略 ## 1. 策略定义 源码公开但禁止商业竞争是指软件源代码公开，允许使用、修改和分发，但限制提供同类商业服务。 ## 2. 主要协议类型 ### A. Server Side Public License (SSPL) #### 协议特点 - 不直接禁止商业竞争 - 要求向企业提供同类服务时，必须将服务所有相关软件源代码以 SSPL 公开 - 对"服务所有相关软件"定义非常模糊 - 没有判例，企业不敢测试是否"传染"到核心代码 #### 行业认可度 - Fedora 社群明确否认 SSPL 是自由软件协议 - 违反开源定义第九条"不得限制其他软件" - 不被开放源码阵营认可 - 企业往往选择完全不使用 MongoDB 软件 ### B. Elastic License 2.0 (ELv2) #### 协议特点 - 文本量相对较少 - 意图和范围描述清晰 - 允许使用、复制、修改和分发 - 限制条件： - 不允许改变软件协议 - 不允许破解密钥保护的功能 - 禁止提供与软件功能相似的商业服务 #### 使用场景 - 企业内部使用允许 - 作为业务逻辑支撑系统允许 - 禁止直接提供相同或相似接口的服务 ### C. Business Source License 1.1 (BSLv1) #### 协议特点 - MariaDB 公司创造（MySQL 团队成员创业） - 限制条款留白，属于协议框架 - 独特机制：不超过四年的约定期限后，自动以 GPLv2 or later 兼容协议发布 - 实践中多选择四年后以 ALv2 重新发布 #### 使用模式分类 **第一类：禁止提供同类服务** - CockroachDB - Outline - 与 ELv2 模式大体相同 **第二类：免费增值策略** - MariaDB MaxScale：不得链接超过三个节点的集群 - Materialize：禁止提供同类服务 + 单集群单并发 - Lightbend Akka：只能用于与 Play Framework 下的应用进程通信 #### 商业价值 - 长时间轴允许后来人自由使用 - 足够拉开技术代差，劝退模仿企业 - 平衡社群需求和商业利益 ### D. Common Clause（已废弃） #### 协议内容 - Redis Labs 在 BSD 3-Clause License 上添加 - 禁止接收者"售卖"软件 - 对"售卖"定义模糊 #### 失败原因 - Redis Labs 在社群反弹下切换回纯 BSD 3-Clause - 几乎没有其他采用案例 - 自由软件基金会抨击污染"Common"和"Sell"词义 - 强烈建议不要使用 ```mermaid graph TD A[禁止商业竞争协议] --> B[SSPL] A --> C[ELv2] A --> D[BSLv1] A --> E[Common Clause] B --> B1[模糊定义<br>行业不认可] C --> C1[清晰禁止<br>范围明确] D --> D1[协议框架<br>四年后开放] E --> E1[定义模糊<br>已废弃] D --> D2[第一类<br>禁止同类服务] D --> D3[第二类<br>免费增值] D2 --> D21[CockroachDB] D2 --> D22[Outline] D3 --> D31[MariaDB 三节点] D3 --> D32[Materialize 单并发] D3 --> D33[Akka Play 集成] ```   ## 3. 实践案例分析 ### A. Airbyte（ELv2 + MIT） #### 初始策略 - 完全使用 MIT 许可发布 - 数据集成核心研发投入大 - 细分领域有行业共识 - 打的是集成多寡的体力仗 #### 变更原因 - 很快出现模仿者打价格战 - 核心优化投入被下游无偿获取 - 独特品牌策略提供不了壁垒 - 人力不足以完成赛道维度升级 #### 变更时机 - 大型云厂商尚未关注 - 用户要么自己部署，要么使用 Airbyte 服务 - 使用竞品服务用户初现趋势 - ELv2 不禁止用户自己部署 #### 变更结果 - 没有引起巨大反弹 - 命令行工具、连接器代码、开发套件仍为 MIT - 不影响社群开发的集成继续以开源协议发布 - 核心模块开发者规模主要是 Airbyte 员工，未受太大影响 ### B. GitLab（高级功能付费模式） #### 协议模型六分点 1. 文档：CC BY-SA 4.0 2. ee 目录：商业协议（测试开发自由，生产需订阅） 3. jh 目录：商业协议（极狐公司） 4. 客户端 JavaScript：MIT Expat 5. 第三方软件：原协议 6. 其他代码：MIT Expat #### 成功原因 - 对企业需求有完整解决方案 - 代码安全审计、开发流水线、研发效能等痛点支持 - 高级功能能打到痛点 - 社群开发与企业功能代码分离 ### C. 国内效仿者 **Bytebase** - 将高级功能以密钥上锁 - 禁止破解 **Logto** - 将云上部署功能上锁 ## 4. 协议切换风险 ### 诱导转向（Bait and Switch）问题 切换软件协议后的负面影响： - 企业与产品品牌受到打击 - 社群反噬和衰退 - 用户客户逃离 - 生态集成出现问题不再繁荣 ### 红帽 RHEL 案例 - RHEL 以 GPLv2 发布 - CentOS 利用相同代码提供发行版和服务 - CentOS 成为中国企业环境部署量最大的 Linux 发行版 - 2014 年红帽收购 CentOS 公司 - 2021 年 CentOS 作者再次复刻代码开发 Rocky Linux ### 初创公司困境 - 通过开源赢得第一批客户 - 其他公司复刻代码直接竞争 - 切换到禁止商业竞争协议是有效手段 - 但面临品牌打击和社群衰退风险 # 四、策略选择建议 ## 1. 决策树 ```mermaid graph TD A[企业开源决策] --> B{软件是否为<br>盈利核心} B -->|是| C{行业标准化程度} B -->|否| D[市场占有率策略] C -->|低| E{团队能力} C -->|高| F[禁止商业竞争] E -->|强| G[品牌建设 + 赛道升级] E -->|弱| F D --> H[开放标准策略] F --> I{协议选择} I -->|清晰禁止| J[ELv2] I -->|灵活配置| K[BSLv1] I -->|高级功能| L[功能上锁模式] ```   ## 2. 策略组合建议 ### 完全开放源码适用场景 - 企业拥有独特方法论和品牌 - 团队有持续创新能力，可升级赛道维度 - 软件不是企业盈利核心，而是市场敲门砖 - 细分领域或新兴领域，需要建立生态 ### 禁止商业竞争适用场景 - 行业标准化程度高，品牌建设困难 - 团队资源有限，无法持续赛道升级 - 需要保护核心商业利益 - 面临云厂商或大型企业直接竞争 ### 混合模式适用场景 - 核心功能开源，高级功能付费 - 基础工具开源，企业解决方案闭源 - 社群版本和企业版本并行维护 ## 3. 实施要点 ### 协议选择前评估 - 明确软件在商业模型中的定位 - 评估行业竞争格局和标准化程度 - 分析团队能力和资源 - 预判可能的竞争者和竞争方式 ### 协议变更时机 - 在云厂商大规模介入前 - 在社群规模较小时 - 在用户依赖较深后 - 提供充足的过渡期和解释 ### 社群管理 - 保持透明沟通 - 尊重社群贡献 - 提供明确的迁移路径 - 平衡商业需求和社群期望 # 五、技术趋势观察 ## 1. 协议发展趋势 - SSPL、ELv2、BSLv1 等新型协议增多 - 传统开源协议（MIT、Apache 2.0）仍占主流 - 企业更注重商业保护和开源平衡 - 社群对协议变更更加敏感 ## 2. 商业模式演进 - 从开源软件销售转向服务订阅 - 从单一产品转向解决方案平台 - 从技术竞争转向生态竞争 - 从代码开源转向标准开源 ## 3. 行业格局变化 - 云厂商成为开源主要使用者 - 初创公司更难通过完全开源建立壁垒 - 生态集成成为关键竞争因素 - 开源基金会在企业开源中角色增强 ## 4. 潜在风险 - 协议碎片化导致集成困难 - 社群分裂和生态割裂 - 企业信任危机 - 开源定义的稀释 # 六、总结 企业开源的软件协议选择是一个复杂的战略决策，需要综合考虑： 1. **软件定位**：是盈利核心还是市场敲门砖 2. **行业环境**：标准化程度、竞争格局 3. **团队能力**：技术创新、品牌建设、生态运营 4. **发展阶段**：初创期、成长期、成熟期 5. **社群期望**：开发者期望、用户需求 没有万能的解决方案，企业需要根据自身情况灵活选择和调整。完全开放源码和禁止商业竞争各有优劣，关键是找到平衡点，在建立生态的同时保护商业利益。 未来，随着云原生、AI 等技术的发展，企业开源的协议模型还将继续演进，需要持续关注行业实践和社群反馈。 *** ## 参考资料 1. [企业开源的软件协议模型实践 - 夜天之书](https://www.tisonkun.org/2023/02/15/business-source-license/) - 原文链接 2. [企业开源该选什么软件许可证？ - 夜天之书](https://www.tisonkun.org/2022/12/17/enterprise-choose-a-software-license/) - 前置文章 3. [黑客与顾客：开源软件能商业化吗？ - 夜天之书](https://www.tisonkun.org/2023/02/05/hackers-and-customers/) - 用户类型分析 4. [Business Source License 1.1 - MariaDB](https://mariadb.com/bsl11/) - BSL 协议官方说明 5. [Elastic License 2.0 - Elastic](https://www.elastic.co/licensing/elastic-license) - ELv2 协议官方说明 6. [Server Side Public License - MongoDB](https://www.mongodb.com/licensing/server-side-public-license) - SSPL 协议官方说明 7. [The SSPL is not an open source license - OSI](https://blog.opensource.org/the-sspl-is-not-an-open-source-license/) - OSI 对 SSPL 的立场 8. [Bait and Switch: Fauxpen Source Strategy - tisonkun](https://www.tisonkun.org/2022/10/04/bait-and-switch-fauxpen-source-strategy/) - 协议切换风险分析 最后修改：2026 年 01 月 19 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏