世界上不会出现第二个红帽

会员服务 ·

世界上不会出现第二个红帽

2021 年 12 月 31 日 AI前线

作者 | Matt Asay

译者丨屠灵

策划丨冬梅

整个行业浪费了十余年时间在模仿红帽公司的开源模式上。

我们真的不要再发那种探究开源成功奥秘的文章了。事实证明，是市场决定了一家开源公司采用怎样的模式才能取得成功。整个行业浪费了十余年时间在模仿红帽公司的开源模式上。正如 2014 年风投公司 Andreessen Horowitz 合伙人 Peter Levine 在一篇文章中所写的那样，这个世界上不会出现第二家红帽公司。如果这篇文章放到现在写，他可能会说这个世界上不会出现第二家 Confluent。

Confluent 公司是前 LinkedIn 员工出来后联合创办的，而创业的基础是一款叫作 Apache Kafka 的开源软件。在整个 Hadoop 的生态圈里，Kafka 是一款非常特殊的软件。它由 LinkedIn 于 2011 年开源，并在 2012 年底从 Apache 孵化器里面毕业，正式成为 Apache 的顶级项目。

并不是说那种十亿级规模的开源公司不会再出现，事实上，现在这类独角兽公司（Databricks、Redis、GitLab 等等）似乎正处在“增值繁衍”的模式之下。问题的关键在于，一家开源公司的业务模式是由多种因素决定的，围绕开源建立业务模式并不只有一条路。

你只看到了红帽公司的表象

即使是在今天，人们仍在怀念红帽公司的高光时刻。这家完全在开源模式下运作的公司，向它所依赖的社区做着贡献。说实话，我喜欢红帽公司。但是，它的业务模式并不适合其他公司或项目。你会发现，很少有红帽支持者能够成功地运营一家开源公司。这是有原因的，并不是因为他们不够聪明，而是因为红帽的业务模式在红帽产品线之外就失去了魔力。

可能说到这里你会有些之意，来听听前红帽公司 CTO 在 2006 年是怎么说的：“红帽的模式之所以有效，与我们的技术复杂性有关系。一个平台由很多移动的部件组成，为了避开这些复杂性，用户愿意为之掏钱。我不认为你可以在同样的模型之下只依赖其中一个部件（比如 Apache）就能取得成功。你的产品需要具备复杂性”。

很多公司花了数年时间尝试变成某种“红帽公司”，但它们无一不是以失败告终。这些公司（比如我曾工作过的 Alfresco）在一开始大半是开源的，也就是所谓的“开源核心”。就是说，它们 90% 以上的代码采用了开源许可，留下足够的一小部分，比如安全、管理等方面的内容，用来促使项目使用者成为付费用户。

这种模式饱受诟病，但它产生了数十亿美元的市场回报，帮助推动了更多的开源创新。开源是一项艰苦的工作，没有人愿意免费赠送。如果一个开发者或一家公司在开源上投入，那是因为他们希望从投资中获得回报。毕竟我们所拥有的资源很有限，而这就是生活 (和开源) 本来的样子。

这也是为什么我不喜欢那些无脑谴责那些为我们所喜欢的开源项目提供了大量资金的风险投资家的人 (例如 Tim Bray 就曾说：“我认为由现代风投驱动的商业模式不值得同情”)。这些观点一般来自那些在大公司工作的人，他们不需要从开源中得到什么，也不需要从开源中获得回报用来偿还贷款。

真正的开源业务模型

那些将开源作为职业的人可能已经发现，根本不存在一种简单的方法可以将免费的软件变成一种有利可图的业务。以 Confluent 为例，初始团队在 LinkedIn 的资助下开发了 Kafka，然后出去自立门户，在已有的市场之上建立起了一种可行的业务模式。Confluent 通过专有的代码和运营来实现他们的业务模式。其他一些公司也效仿了类似的模式，取得了积极的成效，尽管有时候需要修改许可，正如 Battery Ventures 的一份报告所显示的那样：

你可能会得出这样的结论：云是解决开源资金问题的解药。尽管这一结论在很大程度上是正确的，但有时候一些特定的项目并不适合使用云交付模型。例如，EDB 公司已经围绕 PostgreSQL 建立了一个庞大的业务，但他们的客户很大程度上仍然喜欢在本地运行 PostgreSQL。

即使是在托管型服务提供商之间也存在明显的差异。以 Kubernetes 为例，红帽公司遵循其传统模式，提供了 OpenShift 服务，这是 Kubernetes 的一种发行版。而且，红帽就是红帽，所有的代码都是开源的。Kubernetes 的先驱谷歌和后来者 AWS 都提供了自己的托管 Kubernetes 服务和自己的发行版，这样企业就可以在自己的数据中心运行大致相当于 Amazon Elastic Kubernetes Service (EKS) 的服务。

为什么是“大致相当于”？因为如果你想以 AWS 的方式运行 EKS，需要有 AWS 的基础设施、专业的运营知识，等等。

你可能不是 AWS，或者谷歌，或者 Confluent，但你可以遵循一些原则，这些原则可以帮你围绕成功的开源项目构建成功的业务模型，从而吸引更多的投资和开发者。适合你的开源模型取决于你的项目情况和潜在客户。无论如何，向 Confluent 学习，就像我们当初膜拜红帽公司那样。但不要被其他公司的成功所蒙蔽，你的开源之路可能跟它们不一样。

参考链接：https://www.infoworld.com/article/3641218/stop-saying-open-source-nonsense.html