【CSDN 编者按】2018 年 8 月，Redis 模块开源许可证变更，多个项目不再开源遭多方质疑；10 月，MongoDB 更换开源协议至 SSPL，希望从软件即服务上获取收入；12 月，Kafka 团队修改 KSQL 开源许可，矛头直指云厂商……再加之“开源中年危机”等论调不绝，关于开源商业模式的探讨再度受到关注。

此前，中国开源软件推进联盟名誉主席陆首群教授在评《云会杀死开源吗？》一文时曾表示：开源不会消失；关键要建立合适、有效的商业模式；商业开源是促进开源发展之道，开源软件+商业模式才能形成商业开源。

而关于这个问题，John Mark 也提出了自己的观点，他认为开源商业模式之殇在于因小失大，对“利用某项技术赚钱”的过于执着导致了运营策略上的极大失误，强调了“为用户创造价值”的重要意义。

以下为译文：

作者 | John Mark

译者 | 弯月

责编 | 仲培艺

出品 | CSDN（ID：CSDNNews）

切勿本末倒置

免费软件！免费领取！超级便宜！

最近几个月里，由于 Mongo、Redis Labs 和 Confluent 近来的举动，所谓“开源商业模式”的话题又火了。单独来看，每个案例都有独特的情况，值得进一步分析，却又无法依据个别情况得出结论。然而，总体来看这些单独的行为却又呈现出一个明显的趋势——以开源为基础构建产品的各大公司纷纷转向更为专有的路径。虽然各个公司的情况各异，但实际上他们都宣称：开源方法不足以产生足够的收入来获取投资者所寻求的投资回报。我认为这是因为开源商业模式这个独特的类型将这些公司推向了一个狭隘的决策矩阵，从而限制了他们在未来进行方向调整的可能性。

需要明确的一点是，在商业环境中利用开源软件的方法有很多种，但并没有独立的开源商业模式，而对这种模式的追求极有可能限制未来的发展。

Open Core 1.0

为了研究专有解决方案的动向，我们先来看看其发展的历史轨迹。回溯二十一世纪初期，开源异军突起，出现了一种社区认可的建立开源公司的方式，我们称其为 Open Core 1.0：

1. 建立一个成功的开源项目；

2. 聘请其核心开发人员；

3. 在其上创建一个产品（通常是专有的）；

4. 说服那些顽固且习惯占便宜的客户购买更好的专有产品；

5. 创造利润！

然而，很多原因导致这种方法具有缺陷。对于创业公司来说，这种方法相当于将所有免费软件使用者都预设为“潜在客户”，同时假设免费的东西都没有内在价值，无法满足潜在客户的“胃口”。为了实现这一目标，这些公司通常都会保持对代码的完全控制，强制公司独占版权分配，如此他们才能向付费客户发布开源和专有代码的商业许可。众所周知的是，这种方法最后走向了失败，只有 MySQL 一个例外——Sun Microsystems 将其从绝望中解救了出来，并转向了盈利。

证明这种模式并不可靠的原因如下：

• 软件社区被永久地限制在第二梯队，其地位显然不如商业产品重要；
• 社区的范围仅限于母公司画下的圈内，无法开发独立于母公司之外的创新方法；
• 永远不允许社区以独立于母公司之外的身份发展。

Open Core 1.0 压制了开发者社区的发展，阻滞了创新。这些创业公司为了从软件的商业化中获利，放弃了更开放的方法。但有意思的事情发生了：当社区沦落为将“爱占便宜”的用户转化成付费用户的手段之后，也相继迎来了凋零。此外，由于这些公司往往基于蓬勃发展的社区建立他们的整个商业模式，所以社区的凋零导致他们无法达成期望的销量和收入。如果能够在几年内打造良好的品牌，并出售公司，投资者就能收获丰厚的回报。如果做不到这一点，前进的道路将布满荆棘。那些期望获取十倍回报的投资人常常会对他们的开源产品感到失望，部分原因是因为开源公司面临着更为严苛的审判，而且开源方法似乎局限于投资人们苦苦追求的“曲棍球棒曲线”式的增长（指经历某个转折点后呈指数型增长）。但我认为，曲棍球棒曲线只是昙花一现，而且无论软件许可如何，其在任何情况下都几乎无法实现，但是这些人都听不进我的话，所以……

我需要在这里对 MySQL 这个例外做个特别说明：他们在开源之前就建立了一个伟大的免费增值产品，而且他们从未失去这个产品——这就是他们的优势。虽然其他创业公司试图利用现有的开源社区，将其转换为免费增值产品，在开源许可发展强劲之时，MySQL 只开放了它的软件，将其作为支持开源许可的手段。MySQL 没有必要将其社区转换为免费增值方式 ，它始终存在，并融入了他们的模型中。尽管如此，他们在转换用户方面也遇到了很大的困难，但无论如何他们的成功仍然是个例外。

值得一提的是，MongoDB 始于 Open Core 1.0 的末期，你可以在其基本业务模型中看到这一点。我们稍后再详细介绍。

Open Core 2.0 的出现

随着 Open Core 1.0 的巨大失败，各种更为现实的新方法纷纷涌现。开源核心方法演变成了所谓的“混合方法”：利用协作开发的开源平台作为构建大型企业专有系统管理框架的基础。 Cloudera 就是一个最好的例子，它利用广泛的 Hadoop 社区作为其软件基础，但还有其他产品。Apache Spark 开发出了 Databricks；Apache Kafka 开发出了 Confluent。这些混合模型的一个问题在于，很难确定是先有软件项目还是先有公司。RedisLabs 是一家密切关注旧式开源内核模型的公司，但是他们也在尝试尽可能独立地运行 Redis 项目，并从先前的反面模式中吸取经验。在一众存活了下来并蓬勃发展的公司中，Mongo 可能是如今最接近 Open Core 1.0 时期统治风格的公司。

但是，许多公司在商业模式方面都遇到了困难，我们从最近诸多试图开源与专有兼得的软件许可策略中就可以看出这一点。MongoDB 更换开源协议至SSPL（Server Side Public License），以期借此抓住其软件用户。Confluent 也正式变更其平台部分开源组件的开源许可协议，从 Apache 2.0 切换到 Confluent 社区许可（Confluent Community License，CCL），允许免费下载、修改和重新发行代码，但不允许将这些软件作为 SaaS 产品提供给用户，防止其他人在未经 Confluent 许可的情况下将 KSQL 作为服务运行。

当然，真正引发这场争议的公司还是 RedisLabs，他们更改了部分 Redis 插件的许可，添加了与 CCL 类似的 Commons Clause，也是为了防止未经授权的公司将其软件用作服务。那么是什么导致这些公司将其部分软件从开源生态系统转移到自己的专有软件中呢？我相信这些决策都是由大家对开源商业模式的错误信念引发的。

没有开源商业模式

如果你的出发点是“我需要一个开源商业模式”，那么你就会走入一个误区，即“我需要通过项目赚钱”，而非“我需要构建一个能够带来价值的产品”。乍一看，这两者似乎并没有什么区别，但这会最终会让你得出“许可变更合乎逻辑”的结论。沿着这条路走下去，会限制你对业务与产品目标的转变能力。我相信，如果你专心构建能够为客户的核心业务带来价值的产品，那么是否选择为软件强加许可就不那么重要了，或者根本就不打紧了。

Cloudera 案例

下面让我们以 Cloudera 为例进行说明。他们曾经一度以“利用 Hadoop 赚钱”为目标。他们很幸运，因为他们将业务委托给了他们之中最聪明的一个人——Mike Olson，很快他们就走上了“我们能为客户提供什么价值”的道路，并创建了这样的产品。当初 Cloudera 是“Hadoop 公司”，但是如今他们已是拥有大量数据分析和数据科学解决方案的“企业数据云”。你再也看不到 cloudera.com 说他们打算“利用 Hadoop 赚钱”，或者“利用 Spark、Kafka 或其他开源项目赚钱”—— Cloudera 是一家提供产品和解决方案的公司，他们向客户销售有价值的东西，他们不关心软件的来源。你可能觉得这是对开源的不敬与冒犯，但是我不这么认为。

假设当初 Cloudera 决定继续做个“Hadoop 公司”。那么我们来想想如今的 Cloudera 会怎样：他们买了一个域名 hadoop.com，并注册了一个公司 Hadoop,Inc.（当然，我知道 Apache Hadoop 由 ASF 管理，绝不允许别人掺和他们的项目，所以这里我们只是做这个假设而已）。Cloudera 一下子就从专注于为客户提供价值，转变为还要同时继续高举 Hadoop 大旗。这在 Hadoop,Inc. 的决策树中又将如何体现？

对于创业公司来说，现在他们的成功已经与 Hadoop 项目的命运联系在一起，他们与 Hadoop 的成败紧密相关，如果 Hadoop 未能成功，那么他们未来的发展也几乎没有回旋余地。而且这也会引发其他令人不安的问题和决定：如果 Hadoop“过于成功”，导致 Hadoop,Inc. 黯然失色，结果会怎样？Hadoop,Inc. 会不会是 Hadoop 项目不易使用的原因？如果其他公司想在 Hadoop 上构建产品怎么办？他们应该付钱给 Hadoop,Inc. 吗？如果他们不想给钱或没有那么多钱，该怎么办？这是否意味着 Hadoop,Inc. 在质疑那些不愿花钱买企业产品“爱占便宜”的人呢？一些刚刚毕业的 MBA 会说：“我知道了！我们应该寻找一些比较流行的 Hadoop 组件，然后做成专有软件！如此一来，那些爱占便宜的人就不得不付钱给我们了！”于是，恶性循环开始了，每项新技术或新项目都开始考虑这项技术是“核心”技术，还是“附加”技术，是应该开源还是专有。这个充斥着变化与悔恨的恶性循环将无休无止。曾经被当作“核心”的东西可能变成“附加”，反之亦然，结果只会导致萧条与本末倒置，而其根本原因就在于“我们必须利用 Hadoop 赚钱”。

对于这一点，你可能会认为： Cloudera 的管理产品不是专有的吗？没错，是专有产品，但我有两点想说：

1. 因为开源项目和 Cloudera 产品领域之间有明显的分离，所以二者不存在混淆。在创建 Cloudera 解决方案时，还没有关于其是否是开源核心的无休止的争论。Cloudera 开发的所有东西都属于产品，产品经理可以专注于提供价值。

2. Cloudera 选择让开源之上“附加”的管理软件成为专有。我认为底层软件的许可并不重要，而这正是我与 Olson 意见分歧的地方。

上述第 2 点的重要之处在于：这是 Cloudera 的选择，因此与它对 Hadoop 的影响完全无关。他们的管理产品使用专利还是开源对 Hadoop 社区的影响很小，Hadoop 社区仍然是开发人员的庞大生态系统，各个公司依此构建了大量开源项目。我可以理解为什么商业人士可能不愿意公开购买你使用的所有代码，但需要考虑一点：如果你是客户，你需要一个可行可靠的解决方案，你是否真的愿意以你的团队内部开发的解决方案为基础建立你的业务呢？

恰好有一家以销售开源产品为生的公司，他们也在开源软件之上建立了管理解决方案，他们所有产品都是通过开源组件构建的。而且赚了很多钱。这家出类拔萃的公司就是 Red Hat。就像我说的那样，没有人可以逆向解析或重新实现 Red Hat 模型。Cloudera 与其在概念上非常接近，但在很多重要的方面他们的实现各异。与 Cloudera 一样，Red Hat 通过向需要现成解决方案的客户销售许可来赚钱。但与 Cloudera 不同，Red Hat 的所有软件都是开源的，因为他们希望通过软件协作获得加速创新带来的价值，而这并没有成为他们的绊脚石。为什么？因为 Red Hat 很早就抢在众人之前明白了一个道理：客户的价值与底层软件的许可无关，而与整体解决方案的固有价值有关，即它是否实现了自己的承诺。

亚马逊“问题”

在利用开源软件无需任何费用构建产品的公司之中，亚马逊和 Google 最具有代表性，让我们认真分析一下：亚马逊和 Google 并不会原封不动地使用你的软件，特别是你的管理软件，不管你的软件是否专有。他们构建了自己的管理用户体验和用户界面，因为他们有自己的特殊需求需要满足，他们使用现有的平台 API 来构建产品。

与普通的企业客户相比，他们的可扩展性要求太过于庞大，绝大多数供应商甚至无法想象如何满足他们的要求。这就是为什么引入许可的“把戏”来解决“AWS 问题”的不是一个创业公司，而是问题的解决方案。这就是为什么引入许可“把戏”来解决“AWS 问题”是行不通的，这是一个“寻找问题”的解决方案。你不可能通过对本质针对业务模型问题的许可解决方案进行反向工程，来解决自己的业务错误。你真的相信 Amazon 在引入内存数据库服务时会使用 RedisLabs 的管理实现吗?

事实是，无论你使用了 Mongo、RedisLabs、Confluent 还是其他任何产品，你都可以使用 IaaS 平台（包括亚马逊或 Google）向客户出售你的解决方案。事实上，Mongo 已经做到了这一点，并且大多数人都认为他们在这方面做得非常成功。

如果你想创办一家公司，那么就不要因小失大。以“我如何才能为客户创造价值”为出发点，然后倒推回来。接下来，将你需要的开源组件组合在一起，为你的终极解决方案提供价值，并构建你的软件供应链。届时，你可以像 Red Hat 一样，决定利用协作开发的好处，或者你也可以像 Cloudera 一样，决定让其中一些完全在你的掌控之下。关键是你可以做出这样的选择，而不用为“利用某某技术赚钱”所累。如此你才会为自己的选择而感到高兴。

推荐阅读：

https://medium.com/@stephenrwalli/there-is-still-no-open-source-business-model-8748738faa43

https://www.linux.com/blog/why-your-open-source-project-not-product

https://www.linux.com/news/how-make-money-open-source-platforms

https://www.linux.com/news/how-make-money-open-source-platforms-part-2-open-core-vs-hybrid-business-models

原文：https://medium.com/@johnmark/open-source-business-models-considered-harmful-2e697256b1e3

本文为 CSDN 翻译，如需转载，请注明来源出处。