CockroachDB是如何构建业务并进行盈利

原文：How We’re Building a Business to Last

作者： Spencer Kimball

翻译：黑色巧克力

译者注：文章讲述CockroachDB是如何围绕开源软件构建业务，并建立自身的盈利模式。

Cockroach产生于对可用开源数据库和云DBaaS服务的失望，但它从来不被认为是开源软件。

2014年底，在GitHub社区的鼓励和一些有远见的风险投资家的咨询下，我们到了做决定的时候：是否应该成立一家公司来加速CockroachDB的发展？一方面，雇佣一支优秀的团队会让你更快地开发出一款可行的产品。另一方面，我们的目标不再仅仅是构建下一个伟大的开源数据库。

我们面临着如何围绕开源软件构建业务的难题。

围绕开源软件构建业务

自从RedHat开辟了第一条道路以来，开源软件商业模式一直在不断发展。很少有人能成功地借用RedHat以支持和服务为中心的原始模型。事实上，大多数投资者都认为早期的开源商业模式是一个失败的命题。这里有两种常见的OSS商业模式可供选择:

• 核心开放。这通常涉及一个功能强大的核心产品，它是免费和开源的，通常使用APL、MIT或GPL授权。围绕核心部分提供一组专有软件，以添加或扩展其功能。这些专有的附加组件通常与支持和服务捆绑在一起，以商业软件的形式出售。
• 使用开源软件的云托管服务。通常，这也涉及到私有软件(例如多租户、计费、服务指示板)，但是最终产品是作为服务而不是软件销售的。

这两种模式正被许多公司成功地推行。Cloudera、Elastic和Confluent是我喜欢的三个案例，它们都有不同的模型，并且在不同的阶段将开源产品转化为成功的业务。

警示故事

一些OSS公司为付费功能设置的门槛太低，使得核心的OSS产品感觉“举步维艰”。在2017年，任何拥有核心功能的产品在不需要商业许可的情况下无法扩大规模，可能就是门槛设得太低了。也有一些公司在早期未能提供足够的专有价值，而开放核心正迅速成为一种标准的基础设施。那些在核心产品中看到价值的，以及愿意为改进产品而付费的大公司，除了建立自己的自定义扩展外，没有别的选择。

有一些优秀的开源软件公司由于缺乏收入而停止开发它们的产品。最近一些，包括RethinkDB。以前，那些在默认情况下可以进入开放核心产品的公司，逐渐在生存的利益上更有眼光(参考Paul Dix’s InfluxDB 文章)。

这是一种微妙的平衡。为开源软件构建付费的“企业”特性可能会让人感觉肮脏。付费功能削弱了开源的吸引力，并可能导致社区的不安。另一方面，庞大的云服务提供商在不寻找开源生态系统的情况下重新包装开源软件的做法，或者是1000亿美元的跨国公司放弃了陷入困境的OSS公司的支持许可，这些都令人感到沮丧。如果你真的想要围绕开源软件建立一个公司，你必须走一条狭窄的道路，尽早引入付费功能，会有缩短使用的风险。如果引入付费功能太晚，有可能鼓励经济搭便车的人。在任何一个方向上偏离太远，你的努力最终只会持续作为无报酬的开源贡献。

那么，CockroachDB是如何赚钱的呢？

我相信，最终我们将同时拥有云托管模型和核心开放模型。对DBaaS的需求正在迅速发展，我们只写好了第一章(剧透提醒：AWS正在胜出)。但在不久的将来，我们的产品将与那些打算在公共或私有云中运行数据库的公司更好地结合在一起。换句话说，我们追求的是核心开放模式，尽管其中有一些有趣的Cockroach实验室的特点。

首先是许可的问题。许多采用核心开放模型的公司都将其专有特性作为封闭的源扩展来实现。另一些则发布了两个或更多的产品，其中包括包含封闭源代码的企业版本，并作为已编译的二进制文件分发。这些模型存在明显的缺陷。它们很难升级到最新版本，它们经常涉及多个开发分支，这些分支地管理令人沮丧，并且它们消除了新特性所涉及的开源的好处：外部开发人员不能调试或定制产品的专有部分。

CockroachDB社区许可证(CCL)

我们将以不同的方式提供付费的企业特性。目前，我们的GitHub上的所有内容都是按照Apache许可证2(APL)的条款进行授权的。我们所介绍的企业特性将包含在一个新的许可证所包含的源文件中，称为CockroachDB社区许可证(CCL)。源代码仍然是可用的，但是因为它不包括自由的再分配，所以它不是根据定义而开源的。其目的是确保企业特性的商业使用，在评估周期之外，是付费的。这些特性不会在默认情况下出现，将在文档、代码和帮助消息中清晰地标记出来，并且只能通过操作员或开发人员的选择来启用。我们发布的二进制文件将包含这些特性，但不能在FLOSS许可下进行分发。然而，也可以使用“纯”FLOSS分发版，对于那些需要分发版来说企业特性是不存在的。

因为源代码可以用于所有由CCL许可所覆盖的特性，所以我们希望其他人能够从我们构建的东西中学习，并且有一天可以构建更好的产品。我们希望我们的客户能够定制软件以适应他们自己的需求。

我们将如何决定由CCL许可所覆盖的特性？

这是一个很难回答的问题，也是平衡法的关键。我们已经将选择的结果归结为一个石蕊测试:创业成功所需的特性是APL，并且是开放核心的一部分；只对已经成功的公司主要有用的特性是CCL，并且是企业产品的一部分。每一个新特性的许可，我们将根据我们的直觉和社区反馈来决定。

然而，因为这样的决定是主观的，它们会随着时间的推移而发展。将企业功能从CCL迁移到APL是很简单的，我们希望这是对任何特性的一种需求，而这些特性最终都是来自于创业公司的高需求。

为了在2017年取得成功，一家初创公司需要从数据库中获得什么?

这也是激发CockroachDB设计的特点:

• 跨数据中心的部署和一致的复制以克服失败的灾难(例如，停机和丢失或不一致的数据)。
• 水平的可伸缩性和云本地设计，以保证数据架构的未来。
• 具有分布式ACID事务的SQL API，以及用于开发人员生产的查询执行。

虽然上面的一些特性在其他数据库中被认为是企业特性，但是我们相信它们是构建产品和服务的一个通用的基础，并且在APL中仍然是免费的。毕竟，这些特性也代表了CockroachDB这款产品。

我们计划在2017年推出两项此类产品。

第一种是完全分布式的、拥有增量的能力，可以快速、一致地备份和恢复使用可配置存储库(例如S3或GCS)的大型数据库。其中相同的功能，但非分布式的，将免费提供给所有用户。

第二种是地理分区——一种对数据复制方式和位置进行行级控制机制的数据库。地理分区允许一个单一的、逻辑的数据库为地理上不同的客户提供低延迟的访问，并允许遵从数据主权需求。

构建CockroachDB已经两年多了，我们现在已经接近1.0版本。我们认识到使用这些功能构建一个新的数据库所固有的挑战，并且我们正在努力确保能够继续开发CockroachDB数据库，只要有更好的产品可以在下一个版本中发布。