企业开源的软件协议模型实践技术分析
一、概述
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 项目
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 版权
- 数据库标准化程度高，共识清晰
- 运维专家可开设公司提供商业服务
- 附加价值有限，被云厂商关系数据库服务截取利润
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 作业调度的企业不在同一维度竞争
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）
- 初创公司更容易在细分领域或新兴领域通过开源赢得声誉
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"词义
- 强烈建议不要使用
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（高级功能付费模式）
协议模型六分点
- 文档：CC BY-SA 4.0
- ee 目录：商业协议（测试开发自由，生产需订阅）
- jh 目录：商业协议（极狐公司）
- 客户端 JavaScript：MIT Expat
- 第三方软件：原协议
- 其他代码：MIT Expat
成功原因
- 对企业需求有完整解决方案
- 代码安全审计、开发流水线、研发效能等痛点支持
- 高级功能能打到痛点
- 社群开发与企业功能代码分离
C. 国内效仿者
Bytebase
- 将高级功能以密钥上锁
- 禁止破解
Logto
- 将云上部署功能上锁
4. 协议切换风险
诱导转向（Bait and Switch）问题
切换软件协议后的负面影响：
- 企业与产品品牌受到打击
- 社群反噬和衰退
- 用户客户逃离
- 生态集成出现问题不再繁荣
红帽 RHEL 案例
- RHEL 以 GPLv2 发布
- CentOS 利用相同代码提供发行版和服务
- CentOS 成为中国企业环境部署量最大的 Linux 发行版
- 2014 年红帽收购 CentOS 公司
- 2021 年 CentOS 作者再次复刻代码开发 Rocky Linux
初创公司困境
- 通过开源赢得第一批客户
- 其他公司复刻代码直接竞争
- 切换到禁止商业竞争协议是有效手段
- 但面临品牌打击和社群衰退风险
四、策略选择建议
1. 决策树
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. 潜在风险
- 协议碎片化导致集成困难
- 社群分裂和生态割裂
- 企业信任危机
- 开源定义的稀释
六、总结
企业开源的软件协议选择是一个复杂的战略决策，需要综合考虑：
- 软件定位：是盈利核心还是市场敲门砖
- 行业环境：标准化程度、竞争格局
- 团队能力：技术创新、品牌建设、生态运营
- 发展阶段：初创期、成长期、成熟期
- 社群期望：开发者期望、用户需求
没有万能的解决方案，企业需要根据自身情况灵活选择和调整。完全开放源码和禁止商业竞争各有优劣，关键是找到平衡点，在建立生态的同时保护商业利益。
未来，随着云原生、AI 等技术的发展，企业开源的协议模型还将继续演进，需要持续关注行业实践和社群反馈。
参考资料
- 企业开源的软件协议模型实践 - 夜天之书 - 原文链接
- 企业开源该选什么软件许可证？ - 夜天之书 - 前置文章
- 黑客与顾客：开源软件能商业化吗？ - 夜天之书 - 用户类型分析
- Business Source License 1.1 - MariaDB - BSL 协议官方说明
- Elastic License 2.0 - Elastic - ELv2 协议官方说明
- Server Side Public License - MongoDB - SSPL 协议官方说明
- The SSPL is not an open source license - OSI - OSI 对 SSPL 的立场
- Bait and Switch: Fauxpen Source Strategy - tisonkun - 协议切换风险分析