诱导转向的伪开源战略

发表于 更新于 分类于 本文字数： 5.7k 阅读时长 ≈ 21 分钟

本文已整理到【开源小镇】网站【企业沙盘】文档，最新更新请前往对应页面阅读。

本文是我继《企业实践开源的动机》、《开源世界当中到底存不存在“白嫖”？》和《免费增值的商业模式》之后再一次讨论免费增值相关的软件商业模式。主要受到 Percona 发布的 Open Source Bait and Switch: Licensing and Beyond 一文的启发，让我意识到 MongoDB Inc. 在很长一段时间里采用 AGPL 的免费增值战略仍然在开源的范畴之内，直到这些公司陆续切换到专有软件许可证，才真正走上了伪开源战略的道路。

什么是诱导转向？

诱导转向（bait-and-switch）是描述从 MongoDB Inc. 到 Lightbend 这一系列公司改变许可证的行为最为贴切的词汇。

它们首先告诉你这个软件是开源软件，所以你可以愉快地将这个软件用在任何你喜欢的地方。等到上游聚拢了足够多的用户，并在大量开发者和用户的参与以及反馈下逐渐完善和建立生态以后，往往是因为其他供应商的竞争，具有软件著作权并且此前强制所有参与者签署 CLA (Contributor License Agreement) 的公司于是使用新的专有软件许可证替换原先的开源软件许可证。

这种替换虽然只对新版本起作用（原先的版本既然已经按照开源软件许可证发布，就无法再阻止具有拷贝的人自由分发），但是用户的选择其实不只是一个二进制，而是一个软件生态和设计哲学。举个例子，如今相当部分的 Java 应用都强依赖开源的 Spring 框架及其生态。如果 Spring 的后续版本变成专有软件不再可以自由使用，在不考虑社群 fork 继续走开源道路的前提下，这些庞大基数的应用就将锁死在一个版本上限，不得不自己修复框架缺陷尤其是安全问题。此外，由于社群的倒塌，生态连接项目和工具的缺陷修复和更新会快速垮掉，大量工程师不再选择死技术而转向其他技术，决策人不得不倾向于选择另一个框架迁移现有代码，这都是庞大的开销。

这个过程和销售当中的诱导转向手段别无二致：通过虚假宣传吸引用户和开发者参与共建，繁荣生态甚至成为类别杀手，随后切换软件许可证，迫使用户在离开、独自维护和支付提供商商业支持费用上选择其一。

常见的开源软件许可证：

常见的专有软件许可证：

诱导转向犯了什么错？

商业公司及其拥趸并不认为诱导转向是错的，即使这种策略在销售领域当中也为人所不齿。它们的辩白书越积累越多：

总的来说，商业公司及其拥趸的发言可以分成三个派别。

  • 合法合规派“我们所做的一切都是符合协议规定的，我们是作者并且和每一名参与者都签署了 CLA 文件！”
  • 自欺欺人派“我们相信改变许可证能够可持续地发展开源软件！”
  • 气急败坏派“如果看不惯上游的做法，你 fork 一份开发就好了！”

一些历史文章：

相比于源代码不可得，任何人在绝大多数场景的使用都需要付费的传统专有软件商业模型，免费增值的模型至少通过公开源代码促进了行业技术共享，并且通常允许部分用户在限制条件下（往往模糊地表述成不进行商业竞争）免费使用。这些不同之处有它进步的方面，以及对行业和社会带来的价值。

然而，诱导转向的问题在于“诱导”环节的虚假宣传，以及随后的“转向”确实地收割了其他社群成员的声誉。

开源项目、围绕开源项目形成的社群，以及社群成员之间的通力合作，一开始并没有明显的企业参与痕迹。企业主动参与到开源软件的建设要追溯到 VA Linux 和红帽的年代，也就是 1999 年左右，而 Linux 是 1991 年发布并在此后开放开发的，自由软件运动则要追溯到上世纪七十年代。企业主动生产开源软件并尝试建立商业模式，则要追溯到 MySQL AB 公司成立的年代，也就是 1995 年左右。

不同于商业交易，开源协同不是基于一系列合同和协议运作的，而是基于人与人之间的关系建立起来的。你不欠其他社群成员任何东西，他们也不欠你任何东西。久负盛名的 Apache 软件基金会就总是强调 community is about people 和所有社群成员都是志愿者。在这样的背景下，为什么社群成员会愿意无偿付出自己的劳动呢？

社群成员的动力来自两点，其之一是成员自身的利益，其之二是支持社群获得更大的成功。社群成员会自发地推广项目、报告缺陷、提交补丁和改进文档，为的是能够自由地使用和改进开源软件，并在项目的开源许可证的约束下分享包含改进的新版本。换句话说，社群成员为社群工作，而不是为商业公司工作。这使得坚持“公司的成功将使社群受益”的企业受挫，尤其是将公司的成功解释为社群成功的必要条件的企业。公司的成功不是大部分社群成员关心的内容，也不是开源社群这样一个基于社会资本的组织运作的方式。

Apache 软件基金会与开发者签订 CLA 文件，主要是为了两点。其一是在演进 Apache 协议的场景下，能够合规地以新版本协议替换原来的协议；其二是和雇主签订 CCLA 文件保证开发者的参与能够规避法律风险。公司凭借 CLA 文件的内容玩文字游戏，从根本上改变软件所采用的协议的性质，无论找什么理由，这都是对开源社群的背叛，破坏了开源共同体一直以来对合作的对等和软件使用不会有非有意后果的共识。

应该说，在改变许可证以后，企业基于开源软件的商业模型更像是《大教堂与集市》里《魔法锅》一章当中提到的“硬件糖霜”模式。略不同于书中描述的硬件专有、驱动开源的模式，Elastic 和 GitHub 等企业本质上都是采用核心专有、工具开源的模式。可以看到，GitHub 在保持其核心服务逻辑专有且不公开的情况下，仍然建立起了强大的社群和围绕工具开发的繁荣社群。但是，开发者们很清楚这个模型，一开始并没有对开源许可证的期望，这跟中途改变许可证非常不同。

诱导转向的做法，错就错在欺骗和故意误导。

自诩“开源商业公司”的企业一开始不提供商业收费的版本，投入巨大的人力开发唯一的开源软件。根据开源许可证的定义，这样的软件能够自由地使用在任何地方，并且可以随意更改。所有人都对美好的未来感到兴奋。他们推广软件、报告缺陷、提交补丁和改进文档，帮助软件取得成功和广泛采用。

然而，一旦超越了临界线，商业公司就改变软件的许可证，收割其他社群成员的声誉和凭借共建才能达到的软件生态。这种欺骗，换句话说，与其认为软件项目是出于善意才以开源的形式开发和发布，不如说它只是在开发的早期阶段才伪装成开源软件，一旦打出名声并进入到残酷的商业竞争当中，就立即寻求改变为完全或部分专有的软件。

对于复刻（fork）一份就好的说法，且不论因为开源趋于协同合作而不是四分五裂相互攻讦，开源社群的开发者天生就反感分支，单论复刻分支这个行为，也不是轻飘飘的一句话就能实现的。

社群的共识难以复刻，声誉也难以复刻，项目设置和一系列资源材料难以复刻，背景各不相同的开发者以另一个名字重新组织起来更是不容易。从参与到社群的开源开发者的角度来说，更合理的做法是修改协议的人去复刻分支，而不是上游修改协议，其他想要继续以开源方式运行项目的开发者尝试自组织和复刻。

为什么选择诱导转向？

既然诱导转向的伪开源战略会伤害开源社群，劝退相当部分的开发者和用户，为什么企业还要采取这样的行动呢？

其实，这些企业的辩白书并非全无道理。

它们确实面临严峻的商业挑战，或者是投资人对十倍、百倍利润的索取。同时，开源许可证赋予软件用户的权利确实使得继续传统软件专利垄断收费的模式难以为继。双重压力下，这些企业突然发现原来自己能够修改协议，把已经打出名声形成生态的软件转换为公司的专有软件，杜绝一切商业竞争，并且逼迫部分难以转型的用户成为客户。

还有这种好事？从企业立竿见影的商业利益和对投资人的解释说明角度来看，改变许可证也就可以理解了。

当然，不是说企业都是邪恶的，企业主导的开源都是伪开源，实际上，上面的心路历程想要成立，需要三个前提条件。

第一点，从情感和法理的角度上看，需要开源软件是公司项目而不是第三方项目。这就是说，开源软件的诞生是公司立项并组织雇员开发的，因此公司自然获得了项目的所有权。毫无疑问，只有项目是公司的，公司才有可能改变软件的许可证。这一点虽然非常浅显，但是点破以后却能帮助开源开发者和用户快速识别大部分“开源软件”的风险。

不同于 MongoDB Inc. 拥有 MongoDB 的所有权，Elastic 拥有 ELK Stack 所包含项目的所有权，Bytebase.com 拥有 Bytebase 的所有权，PingCAP 拥有 TiDB 的所有权，StreamNative 基于 Apache Pulsar 提供消息平台云服务，但是 Pulsar 本身是 Apache 软件基金会的项目，StreamNative 一家公司没有能力改变上游软件的协议。同样，基于 Apache DolphinScheduler 和 Apache SeaTunnel (Incubating) 开展数据整合业务的白鲸开源，基于 Apache Cassandra 提供云上数据库服务的 Datastax 公司，都没有改变上游软件协议的能力。

这一模式往上要追溯到 Sun 和 RedHat 的年代。Sun 拥有 Java 的所有权，被 Oracle 收购以后转移到 Oracle 公司。因此，Oracle 公司才能在前几年尝试用商业许可协议来发布 Oracle JDK 版本，即使 OpenJDK 是 GPLv2 许可的。反观 RedHat 并不是 Linux Kernel 的作者，因此即使他们做出了 RHEL 发行版并提供订阅服务来盈利，也无法动摇 Linux 上游 GPLv2 许可的现状。

当然，GPL 系列协议属于开源协议簇里的 Copyleft 类协议，除了作者以外不能重新许可。如果是 Apache 一类的宽容开源许可，就有可能被其他供应商重新打包商业化发行。例如，尽管无法改变上游 Apache Doris 的性质，StarRocks 仍然能够复刻 Doris 代码，开启自己的魔改之路，并使用 ELv2 这样的专有协议来许可自己的软件。

从情感上说，自诩“开源商业公司”的企业一开始不提供商业收费的版本，投入巨大的人力开发唯一的开源软件，这可能是一种不成熟的行为。尤其是如果公司创始人没有想好此后如何盈利，只是觉得自己写好一个软件，以开源的方式打开名声，就能坐地收钱，那日后破防也是不可避免的。

对于这些企业来说，初心就是“写个软件好卖钱”，而且确实也是创始人辛辛苦苦拿到融资，组织起来一帮兄弟姐妹领工资夜以继日的开发软件。到头来用户只是使用而不付费，甚至因为太好用找不到付费的理由。这个时候，又冒出来几家供应商把代码拿过去改改做出自己的解决方案，甚至由于上游使用宽容开源许可，这些供应商源代码一藏，随口就说碾压上游版本。

这实在是大大超出了企业创始人的预料，于是修改软件许可，让这些用户和供应商搞清楚状况就会被加紧提上日程。尽管，这有违当初无论是有心还是无意与开源参与者和用户的开源协议：不止是一纸文件，更是人与人之间的承诺和共识。

第二点，从商业利益的角度上看，需要企业依赖或说重度依赖软件所有权甚至专有属性盈利。商业活动依托于开源软件的模式有很多，并不是每一种都可以从软件的专有属性当中获利。

例如，Google 开源 Android 系统、Chromium 浏览器内核、Kubernetes 系统、Bazel 构建工具、Protobuf 软件库和工具链等等，主要的目的都是抢占领域标准，而不是直接销售对应软件盈利。对于 Google 来说，能够带来盈利的业务实在是太多了，不需要靠这几个软件的专有经营盈利。从企业的主营业务来说，这些软件的研发和维护都是必然成本的一部分，闭源开发维护也是成本，开源开发维护也是成本，并且以开源的方式运行，由于有更广泛的用例和同行评审反馈，成本只会更低。此外，保持一个开源的好名声，以及公司软件在行业内的广泛采用，对招聘到高水平人才和懂得公司内部技术栈的人才都有很大的帮助。对于这些企业来说，这部分软件完全遵守开源促进组织的开源定义并不会影响主营业务的收入，只有好处没什么坏处。

例如，Databricks 虽然总被人认为是 Apache Spark 的商业化公司，但是它早年的商业化产品是 AI 场景数据流水线，近年来打的是 LakeHouse 湖仓一体的名号，商业产品矩阵并不只是简简单单地做一层 Spark 作业编写、发布和管理的封装，而是包含大量商业代码的系统解决方案，只不过其计算处理核心是 Spark 而已。当然，Databricks 这么淡定的原因，很大一部分是 Spark 的主体代码和名声早在 AMPLab 时期就已经打响，严格来说 Databricks 也只是继承和发扬。这种心态跟从创业融资开始从无到有写作一个软件，自然大不相同。

Upstash 公司是一个更加典型的例子。它的团队既没有 Redis 的创始人，也没有 Apache Kafka 的创始人，甚至不需要招聘项目维护者，就能够提供全球化的 Redis 和 Kafka 的无服务器软件即服务（Serverless SaaS）。这是因为他们的商业价值就是在全球各个区域都可用的 Redis 和 Kafka 服务。只要付钱，你就能为自己的全球业务在美东、美西、欧洲、巴西或新加坡快速起起来一个服务，而 Upstash 会提供相应的 SLA 商业支持。Upstash 也会赞助 Redis 生态的项目，例如 Redis 的 Golang 客户端 go-redis 项目，也会自己编写一些周边的开源工具。但是其核心组成部分，是开源软件上游代码，加上提供一整套云服务的商业代码。

Firebolt 公司也是此中高手，甚至写了一篇论文 Assembling a Query Engine From Spare Parts 讨论如何基于开源软件快速缝合一个商业软件。

反观改变软件协议的“开源商业公司”，往往商业模式都建立在用了开源软件的人总有一部分会付费这样一个虚无缥缈的假设之上。最终能改协议的往往就改了协议，不能改协议的只能痛苦的转型，而转型的大半都坚持不过低谷。

不过，其实正常销售线索铺开来，也确实总有部分用户愿意付费，无论是类似信念相同打赏性质的，还是企业采购要求的原因等等。但是这部分付费人群不会太多，如果公司的目标就到这里，做到收支平衡小有盈余，倒也不是不行。只是大部分公司创始人总有或者总被忽悠做着星辰大海的梦想，不甘于此。

第三点，从社群成长和生态发展的角度上看，需要公司在社群当中一家独大。这与第一点不同，不是强调所有权，而是强调社群生态的多样性及其产生的张力。社群生态的多样性产生的张力能够产生威慑，直接提高公司改变软件协议的成本，从而使得改变软件协议是不划算的。

绝大多数成功改变协议的商业公司，基本在对应的开源社群当中是一言堂的状态，说改也就改了，很难遇到像样的抵抗。即使用户骂声连连，也很难构成实际的威胁。反正该买的总是要买的，不会买的也永远不会买。

反观 Oracle 虽然尝试过 JDK 收费，但是很快就在其他发行版声明坚持提供开源版本的压力下放弃。Java 17 开始，Oracle JDK 以 Oracle No-Fee Terms and Conditions 允许所有用户自由使用。

又例如，Pivotal 曾经试图推行商业版本的 Spring 全家桶，但是很快就被社群强大的生产力所击败，最终放弃商业版本的计划，只是提供商业支持和实施指导。

又例如，Lightbend 在接连放弃维护 Lagom 和 Play 以后，以修改 Akka 软件许可的方式转向专有软件收费。新的许可允许个人使用和规模小于一定数字的企业使用，这或许能满足部分用户的需求。但是，由于软件协议性质的变化，开源共同体当中大量的软件将不再提供生态整合支持，因为相信开源的理念和做法而来的开发者的离开也会导致生态的凋敝。这将最终导致用户不得不选择使用新的软件或者支付一大笔费用。

目前，一部分 Akka 的用户和开发者团结起来，试图借助 Apache 孵化器的凝聚力孵化 Akka 的 fork 版本 Pekko 项目。复刻是难的，这一次能否成功，如果成功 Lightbend 将如何应对，或可拭目以待。

应该怎么做？

诱导转向的核心问题在于欺骗。因此，只要商业公司以诚实的原则做市场营销和承诺，用户和开发者以诚实为准线来衡量公司行为，以软件所有权为底线衡量可能的后果，双方在不欺骗的前提下搞清楚自己的权益和责任，就可以让诱导消弭于无形，自然也会不会承担转向带来的伤害。

这两篇文章都提到，开源协同的开发方式不一定适合商业公司里所有软件的开发，尤其是依赖其带来盈利的软件。OSI 的博文强调，商业公司不应该声称或暗示不是开源协议许可的软件是开源软件。因为“开源”这个品牌所代表的优点、权益和承诺，其专有软件并不具备：这是简单直接的欺骗。Percona 的博文强调，让开源就是开源。开源提供了自由，同时也会妨碍某些类型的商业活动的开展。如果你没想好一个依托于开源软件的商业模式，退化到专有软件的开发售卖模式并不丢人。但是，就按照它原本是什么来阐述，而不是扭曲“开源”的定义来获得市场声量和迷惑用户。