去年,我花了很大一部分时间与一些开源项目的创始人会面。这些项目包括网络基础设施、数据库、桌面应用程序和浏览器扩展插件。 尽管项目类型不尽相同,但我发现这些创始人都提出了一个同样的问题:

我该如何围绕自己的开源项目建立商业模型?

因为有了在开源世界摸爬滚打的经历,所以我可以回答这个问题。我在 Blossom Capital 和 Index Ventures(都是为开源初创公司提供资金的投资公司)工作过,还是一名开源贡献者,参与过小型独立的项目以及在 FSF 和 Apache 基金会管理下的大型项目。 我也很幸运地共同主持过 Wikimedia 基金会的第一届理事会选举。

ÉãͼÍø_500452700_banner_´úÂë¼üÅÌ£¨ÆóÒµÉÌÓã© (1)_wps图片.jpg

选择正确的模型不仅对项目的商业可行性来说至关重要,对于是否能够获得社区的支持来说也同样重要。在最糟糕的情况下,社区和项目会因为商业决策和由此引发的监管问题而分道扬镳。

有很多模型适合小型的团队,不过,项目创始人通常希望能够建立强大的公司,帮助开源项目不断发展,成为所在领域的领导者。因此,在这篇文章里,我将重点介绍一些可以让公司达到相当规模(年收入超过 1 亿美元)并成为独立上市公司的模型。

几十年来,开源世界的业务模型已经融合成这四种可以实现上述目标的模型:开放核心、专业服务、托管和市场(Marketplace)。

什么样的业务模型能保证开源项目的成功?

开放核心

在 90 年代末和 2000 年代初,人们用怀疑的眼光看待开放核心模型。开发人员担心基于开源核心构建商业产品的公司会为了让商业产品更具吸引力而试图削弱开源产品。

不过,在过去十年中,情况发生了很大变化。我们看到了无数商业开源公司被证明是开源项目的好管家,他们选择构建扩展其开放核心的产品,但又不与开放核心冲突,有时候还将开源项目交给非营利性基金会(例如 Apache 基金会)管理。

我们开始看到开放核心公司的模式出现了,它们的商业产品与开放核心是互补的,而不是冲突的,包括:

  • 易用模式:SaaS、UX、协作工具;

  • 企业模式:可伸缩性、安全性、管理和集成;

  • 解决方案模式:特定用例。

影响这些选择的因素有两个:(1) 对企业用户来说有价值的功能;(2) 不太可能由社区提供也不在开放核心路线图中的功能。

最重要的是不要让社区感到核心产品的重要功能有所保留。对于大多数成功的开放核心公司来说,他们的客户仅占总体用户的一小部分。确保开源产品的成功是商业产品取得成功的关键。

近来成功的开源案例,包括 Confluent、Elastic 和 Github,开放核心就是其主要模型。

专业服务

早期的开源模型通常是建立在专业服务之上,企业需要支付支持和咨询费用。尽管有很多公司已经采用了这种模型并达到了一定规模,但并非没有遇到重大挑战。

服务收入通常是高度不可预测的,需要大量的人力资源,一旦收入出现变动,公司就有可能面临很大风险。提供专业服务的公司的利润也比提供产品的公司的利润要少得多。

去年,红帽公司在服务方面的利润为 31%,而产品订阅方面的利润为 93%。也就是说,要招聘一个核心开发人员,红帽公司从咨询方面获得的利润必须是产品的 3 倍。利润方面的巨大差异意味着以咨询为基础的开源企业通常只有有限的资源用于开发核心开源产品。

值得注意的是,红帽公司的产品订阅业务起初主要是“支持订阅”,随着时间的流逝,一些公司(如 IBM,收购了红帽之后)开始削弱其支持服务,订阅业务进而逐渐发展成为一种产品。

虽然少数像 Hortonworks(被 Cloudera 收购之前)这样的公司仍然通过纯支持订阅模式获得可观的收入,但由于缺乏可防御性,现在通常将支持与其他产品捆绑在一起。

公众市场对提供服务的公司持负面看法。提供服务的公司的收入通常是 1 到 3 倍,而产品类公司的收入通常可以达到 10 倍以上。

托管服务

在过去的十年中,托管服务已经成为开源公司的一种常见产品,特别是在数据领域。终端用户能够以类似 SaaS 产品的方式使用基础设施组件,而不需要管理基础设施。

虽然开源公司通常都不会公开其托管服务的利润,但根据粗略的计算,MongoDB 的云业务在 65% 左右,Elastic 在 40% 左右。相比之下,高于服务利润率,但低于产品利润率。

托管服务的收益是由付费意愿决定的,如果价格远远高于基础设施的成本,那么公司就会选择自己托管,特别是对于那些已经拥有成熟的内部 DevOps 团队的大客户来说。

近年来,云托管提供商(最著名的是 AWS)已经开始为常见的开源软件提供托管解决方案,这进一步挤压了开源公司的利润空间,导致很多开源产品(如 Redis 和 MongoDB)改变了他们的许可,以便抵御来自云供应商的竞争。

一些公司(如 Confluent 和 Elastic)选择了另一种策略,他们在托管服务中提供开放核心无法提供的功能,催生了一种托管与开放核心的混合模型。

虽然我们还没有看到这种策略的最终结果,但对于那些已经建立了开放核心的公司来说,这一种策略很可能是一种自然的延伸,尤其是在许可变更可能会在用户中引起争议的情况下。

值得注意的是,托管服务对于这些企业而言通常是一个重要的收入来源(超过 1 亿美元),但通常是次要的,而不是主要的。

那些以托管服务为主要产品的开源企业通常将托管服务与重要的 SaaS 或基础设施产品(远远超出了其开源核心)相结合,例如 GitHub 和 WPEngine。

市场

Android 是开源领域最大的一个商业成功案例,尽管人们常常忽略了这一点。尽管谷歌的年度财务报告显示,他们并没有从 Play Store 获得大量收入和利润,但很可能仍然比之前的红帽公司要高。

同样,Mozilla 每年 5 亿美元的收入中有很大一部分来自为搜索引擎引流。

虽然这仍然是一种相对少见的模式,但是越来越多的开源初创公司在探索这种“媒介”模式。在未来十年,我们可能会看到更多建立在这种模式基础之上的开源公司。

如何选择正确的模型

在实际当中,公司往往会混合多种模式。

如今,对于成功的开源公司来说,最常见的模式是将开放核心产品与托管和服务相结合,作为第二和第三收入来源。如果这种组合对你的产品来说是有效的,那么它可能是一个不错的选择,不过它需要你考虑如何在商业产品和开源产品之间做出明确区分。

在某些情况下,这些模型可能都不适用,你可能需要为自己产品找到独特的商业模式。

除了找到一个能够让公司规模发展的模式外,关键在于所选择的模式要与产品的特性相吻合。同样,创业者和整个社区的目标和愿景也很重要。

原文链接:
https://medium.com/blossom-capital/successful-open-source-business-models-2709e831e38a