前几天，一篇名为《开源商业模式是个伪命题》的文章横空出世，看似犀利的观点却没有引起激烈的反驳。无论是开发专有软件的企业，还是重度投入到开源软件开发的企业，都认同开源本身并不是企业作为软件及服务提供商的商业模式。
行业当中有这样的共识并不奇怪。如果你在国际互联网上搜索『开源商业模式』关键字，其结果从 2016 年起就几乎被『开源不是商业模式』所统治。本文老调重弹，从开源为什么不是商业模式，不是商业模式的开源在企业运作中扮演什么角色，以及围绕开源软件存在哪些商业模式做出讨论。
开源为什么不是商业模式
我们从那些宣称或者暗示开源是商业模式的企业来反证这个观点。
通常，此类企业一上来不提供收费的商业软件，而是投入巨大的人力开发一款开源软件。其创始人往往期待以此打开名声，用户纷至沓来，随着用户量的增长，应该自然产生商业诉求，由此转换为企业的客户，企业从而增长营收。在这样的一个假设当中，软件开源是用户能够*使用，从而自发宣传病毒式传播的基础，因此只要软件做得好，一经开源赢得足够大的用户群，后面的营收就是 autowin 了。
显然，这个逻辑存在两个巨大的漏洞。
第一个是用户不等于客户，开心使用你提供的开源软件的企业，不见得在你提供商业支持和服务以后就会采购。
对于绝大多数中小企业来说，一个能从今天的开源软件市场里杀出来的软件，几乎都是可以直接上手使用的。例如关系型数据库领域，PostgreSQL 和 MySQL 的成熟方案足以支持一家中型企业的数据存储和事务操作需求。如果你的开源软件不比它们好，那么用户没理由使用;如果你的开源软件比它们更好，用户只需要用开源版本就可以满足需求。
第二个漏洞是开源协议给予接收者的*度，使得公司投入巨大的人力开发出来的软件，没有在竞争对手的商业竞争中形成有效的技术壁垒。
潜在甲方企业规模越大，其关键任务路径上的软件选择和运维就更加谨慎。如果一款开源软件在行业内对解决这个问题有比较优势，这些甲方企业是会存在采购商业支持、软件订阅或云服务的需求的。
然而，由于开源软件给予接收者*修改、*集成和*分发修改或集成后软件系统的权力，一旦这样的需求出现，市场上的竞争者直接拿来原厂开发的开源软件，投入人力完善企业级需求，完全能够提供极具竞争力的产品。例如，在 MongoDB 和 ElasticSearch 修改软件协议之前，云厂商拿来它们的代码，与自己的云平台进行集成。在边际投入递减的平台团队和强大的销售团队的支持下，云厂商提供的服务并不比原厂差。甚至对于用户来说，云厂商提供的与云平台深度集成的服务更加方便，大厂完善的售前售后体系更加可靠。在这样的竞争态势下，原厂投入在软件内核研发的产出都被竞争对手免费获取，无法形成有效的技术壁垒，从而在商业竞争中没有优势。
可以说，在销售软件及服务的赛道里，把自己的核心软件开源，是一件『苦恨年年压金线，为他人作嫁衣裳』的事情。开源不仅不是商业模式，还主动放弃了往研发中心投入成本本应形成的技术壁垒。
近年来，相关企业修改软件协议，也是为了应对上面介绍的这两个开源模式漏洞。
Elastic 公司选择 Elastic License 2.0[1] 重新许可核心的 ELK 套件，禁止任何人或组织破解其高级功能或提供同类服务，CockroachLabs 公司选择 Business Source License 1.1[2] 重新许可数据库系统内核，并在可选限制上同样要求任何人不得提供同类(数据库)服务。值得一提的是，这一类型的新许可并不禁止企业内部*使用和修改原厂开发的软件，而是旨在垄断软件及服务提供商的地位，即这是对上述第二个漏洞的亡羊补牢。
Lightbend 公司和 MariaDB 公司更进一步。它们不仅仅希望通过协议垄断软件及服务提供商的地位，还希望在生产环境使用其软件的企业都必须取得商业许可。MariaDB 公司的核心产品 MaxScale 的软件协议禁止用户部署多节点集群，而该产品的主要功能就是管理集群和对外提供代理访问;Lightbend 公司禁止 Akka 框架部署在任何生产环境上，但是在公司层面为年收入在一千万美元以下的公司开放申请企业内免费使用的通道。同样采取禁止生产环境使用的还有 Materialize 等公司。禁止生产环境使用，自然也就消灭了潜在竞争对手提供服务的可能性，这种做法一次性解决了上述两个漏洞。
当然，这些协议不仅和典型开源协议的条款大相径庭，也不符合开源定义[3]和其他开源组织的理念。今天，这些协议自己或其采用者会强调这只是公开源码的软件协议，而不是开源协议，将其商用是受限的。
开源在企业运作中扮演什么角色
开源不是商业模式，企业自研的核心软件开源将面临严峻的商业竞争，那么开源在企业运作中就没有价值了吗?
显然不是的。无论是企业主动使用开源软件、参与开源软件开发，还是开源共同体自发的创造，都会对企业运作形成可见的影响。
企业虽然缺少将核心软件完全开放的理由，但是使用其他开源软件却是不可避免的。
今天的任何复杂软件，或多或少都会有开源组件的成分。合规使用开源软件，排查、跟进乃至修复开源软件存在的安全风险，是企业作为使用者必须应对的问题。除此以外，当企业产品的质量与某个开源软件产生密不可分的联系的时候，企业参与开源软件开发的动机就出现了。
成熟的开源软件定义了领域内的关键抽象，提供了历经打磨和沉淀的实现。但是对于特定企业具体的场景，开源软件未必能够提供完美的支持。对于有研发能力的企业来说，内部维护或临时做一个二次开发的版本非常常见，而如何处理下游版本和上游的关系，就是一个需要评估的问题。
滴滴、腾讯和华为云都对 Apache Pulsar 有深入的使用的内部定制，Pulsar 上游社群活跃且开放，这些企业要想让减少升级跟进上游版本的开销，推动内部修改合入上游就是最佳策略。如果上游选择另一种方式实现相同需求，内部集成和业务可以响应适配。即使上游不认同提出的更改，至少再做其他设计决策时，能够考虑到用户存在这样的需求，不至于无意间把打补丁的路给堵死了。
如果企业对开源软件的依赖更深，而且内部开发极其活跃，且无法与上游达成一致，那么可能 hard fork 就是唯一的出路。PingCAP 的 TiFlash 和字节跳动的 ByConity 对 ClickHouse 的 hard fork 就是这样的案例，它们随后成为了公司产品的一部分。Firebolt 更加彻底，hard fork ClickHouse 作为其云数仓的执行引擎，并且从未有过再像 TiFlash 或 ByConity 一样开源出来哪怕部分的想法。这也再次应证了前文提到的开源软件本身要商业化，容易遇到拿来就用的竞争对手的强力挑战。
除了使用开源软件的场景，企业开源不是核心产品的基础软件或周边组件，或是把核心软件裁剪成一个基础版本再做开源也不罕见。对于这些场景，在做软件及其生态的开发者体验工作时，开源的属性和开源社群的存在，能够提供一些优势和额外的切入点。
典型的是由于开发者能够接触到源代码，所以他可以深入理解软件的原理，成为高级用户，并将自己的经验带给其他人，提高软件的影响力。当然，对于源码公开的专有软件来说，这一点也能做到;对于闭源软件例如 Oracle 来说，通过完善用户手册、提供培训和撰文解释原理，也能达到不错的效果。
开源独特的地方，在于开发者能够*地修改源代码，使得适应他的运行环境和使用场景，且修改后的版本可以*的使用，从而使得开源软件能够跑在许多创始团队想不到的场合下。这就是开源合作创新理想的样子。
最后，开源共同体自发的创造本身会影响商业环境。这个世界今天有 PostgreSQL 这样的软件，它几乎做任何工作都有成熟的生态支持。这就意味着你做一个商业数据库管理系统，必须比开源软件做的更专业。也就是说，开源虽然不是商业模式，但是商业面临的开源软件挑战是真实存在的。开源软件因为种种原因存在，实际上提升了商业软件的基准线，最终是对用户有利的。
围绕开源软件的商业模式
这个话题我在过往的多篇文章里都做过详细论述，这里只做一个简单的罗列。
第一种是专有核心，开源周边工具的模式。
例如 Airbyte 修改软件协议之后，其内核和 UI 是不允许商业竞争的，而 CLI 和 Connectors 则是开放的，鼓励开发者进行生态集成。这种模式走到极端，就是 GitHub 的服务端完全闭源，但是 API/SDK 开放，甚至有全开源的 GitHub Actions 生态，当然这个生态是绑定在 GitHub 平台的。
第二种是核心开源，高级功能付费。
例如 GitLab 的开源版和企业版的差异化就做的不错。通常来说，团队协同功能、安全加密功能、合规审计功能、云上的运维和特殊场景的集成，都是高级功能的良好候选。这一模型往往要求企业对软件有完整的自主产权，或者在中立社群中极强的话语权，否则研发的高级功能有被上游或其他深度参与者釜底抽薪的风险。
第三种是做开源软件的发行版。
Ubuntu 是 Linux 的发行版，以订阅模式响应企业用户的定制和支持请求。Cloudera 的 CDH 是大数据套件的发行版，帮助企业快速启动一个版本相互兼容的大数据平台，屏蔽大量运维细节。Percona 和 PlanetScale 基于 MySQL 提供的数据库服务，还有云厂商对一众开源软件简易封装后提供的服务，其实也可以算是某种发行版。
第四种是基于开源软件做解决方案。
Databricks 基于 Apache Spark 研发定义了 AI Infra 和 Lakehouse 等产品线，Decoable 基于 Apache Flink 开发了一个实时数据处理平台，Firebolt 拿几个开源软件缝合了自己的云数仓，还发了篇论文[4]。
这些案例当中，往往企业不是开源软件的第一作者。哪怕大家都觉得 Databricks 是所谓 Spark 背后的公司，Spark 的核心逻辑其实是在高校实验室了开发出来的，项目捐赠给中立的 Apache 软件基金会也发生在公司成立之前。所以这不是 open-source from scratch 的模式，而是普通的有个好的开源软件拿来用。话语权足够强的，不需要 fork 开发，否则可以像 Trino 一样 hard fork PrestoDB 上游。核心商业价值在软件之外的，不需要 fork 后闭源，否则只要协议允许，可以像 Firebolt 和太多没有明说的企业一样，拿到企业内部魔改，而无需公开修改后的软件。
最后，我想说，目前仍然存在原创核心软件开源的商业公司。例如，
•Alluxio (Alluxio)•Chef (Chef)•HashiCorp (Terraform)•JuiceData (JuiceFS)•PingCAP (TiDB)•ScyllaDB (ScyllaDB)
这些企业要么是专注于特定行业场景，细分门槛极高，不是抄个软件就能抢过客户的情况;要么是软件本身知名度和市场占有率还不高，竞争对手抄了还要自己帮忙吆喝。前者发展下去，可以通过把握标准和垄断专门人才来维持市场地位;后者发展下去，则需要和其他供应商形成联盟，建立合作，否则还会走 MongoDB 和 Elastic 的老路。实际上，MongoDB 和 Elastic 就是通过改变软件协议，强迫供应商坐下来谈合作。
往期文章阅读
•企业开源的软件协议模型实践•黑客与顾客：开源软件能商业化吗?•企业实践开源的动机•免费增值的商业模式
全文最后，看一个 ChatGPT 对“开源是商业模式吗”的回答：
开源不是一种商业模式，而是一种软件开发的方法。
开源意味着软件的源代码可以公开获取和使用。这使得更多的开发者可以对软件进行改进和优化，从而提高软件的质量和稳定性。
虽然开源软件本身免费使用，但许多开源软件的维护、支持及其他附带服务是可以进行商业化的。例如，Red Hat 公司就以 Linux 发行版为基础提供商业化的支持、培训和咨询服务，同时也开发了自己的商业软件产品。
因此，开源可以为商业模式提供一些有利条件，但它本身并不是一种商业模式。
原文标题《开源不是商业模式》
参考材料
•There is NO Open Source Business Model[5]
•There is Still NO Open Source Business Model[6]
•Open Source Isn't A Business Model, It's A Market Strategy[7]
•Open source is not a business model[8]
•Entrepreneurship for Engineers: Open Source Business Models[9]
•Business models for open-source software[10]
References
[1] Elastic License 2.0:
[2] Business Source License 1.1:
[3] 开源定义:
[4] 论文:
[5] There is NO Open Source Business Model:
[6] There is Still NO Open Source Business Model:
[7] Open Source Isn't A Business Model, It's A Market Strategy:
[8] Open source is not a business model:
[9] Entrepreneurship for Engineers: Open Source Business Models:
[10] Business models for open-source software: