开源创业的那些事（二）：重构开源的商业模式

俗语云：人永远忘不了他的第一次。以我个人的经历为样本来说的话，这句话可谓是恰到好处。那还是在2008年，Lucidworks 刚刚融完 A 轮，公司也是刚刚雇用了第一位销售人员。我应这位销售人员的要求，接听一名在 Apache Solr上遇到问题需要解决的潜在客户的电话。在整个的电话沟通中，客户问的问题相对来讲还是比较初级的，我尽力的作全面的答复。当谈话结束，挂掉电话之后，我对自己的表现非常的满意，正在暗自窃喜的时侯，我们的销售人员打来了电话，原话我已经记不清楚了，但大致的意思是这样的：

销售人员：“你的表现很棒，但是你搞砸了这次买卖。”

我：“为什么？在这个过程中我尽我所能，而且给出了他们所遇到的问题的最佳解决办法。”

销售人员：“是的，你做到了！现在的情况是，这位仁兄已经能够解决问题，再也不需要我们了。”

果然，我们的销售人员是对的。当那位再打来电话的时候，快速而直奔主题：“非常感谢你的帮助，我们已经解决了问题，而且运行良好。” 我立刻意识到基于开源软件的商业和作为开源社区的一份子有很大的不同之处。不要对我有任何的误会－－我依然非常乐意分享我所了解的知识，以及在社区贡献自己的一份力量。但是，我有很多的账单要付，更何况公司还处于创业阶段，而我唯一所拥有的资产就是我的知识和时间。

很多年以来，类似的情形已是见惯不怪，正如我们从一个主要以支持为主要的业务转变成为聚焦于产品的组织。和天下所有的商业一样，我们最终都得解决如何赚钱的问题。然而，开源的商业面临的不同于其他方面的挑战主要在于产品是免费授权的。最好的情况是，让价格降低；最坏的情况是，所有的都是免费的：免费的软件、免费的文档、免费的支持。

以客户的角度而言，他们通常是这么想的：“我们会雇用少量的开发人员，这些开发人员可以获得源代码，甚至还能够实现一些功能，更何况我们还能从邮件列表中获得一些问题的答案。或许我们在遇到重大问题时，仅针对解决此问题的情况付费即可。”

我将这样的情形称之为“我免费拿你的，你还得为我埋单。”之软件运动！这些公司希望人人都为他们的产品／服务埋单，事实上，现实的情况就是如此。这样的想法正好诠释了为什么那么多的公司非常的乐于使用开源软件，但是从来不会对之做反馈、贡献。这点可能会引起大家的误会，说我吃不到葡萄说葡萄是酸的，可以理解，因为我本身是在经营一家开源的企业。但是我说的是目前很多软件公司的真实现状。我不确定这样的情形能否长期的运转下去，尤其是考虑到开发人员日渐增长的工资。但是一码归一码，如果你打算基于开源项目来构建商业模式的话，你就得去面临这样一个事实，尝试去解决它－－或者干脆就退出了事。还有更为复杂的情况是，如果“你的”代码库并不是你自己的，举例来说，代码库是属于某个开源基金会的，如 Apache 软件基金会，这时还会有一些利益的冲突。

在我们公司，我们尝试着去回答“我们如何才能赚到钱”这个问题，已经迭代了无数次了，最开始的时候，我们主要倾向于咨询和支持，后来逐渐的进化为我们当前的销售构建在开源之上的平台的模式－－或者是大家通常的称呼“开放核心”－－以及为那些意图直接构建在开源（例如，社区版本）之上的提供支持。它们每一种情况都有好处和坏处，以下是我列出的纲要：

咨询

尽管咨询可以为一个团队带来丰厚的收入，但是它很难扩大，而且利润也不够高，公司背后的风险投资商很难看到此类业务能够给他们带来回报。咨询的业务往往会出现要么是人手不够，大家都忙碌着精疲力尽；要么就是无人问津，团队无所事事，尤其是在一个公司的早期阶段，这样的情况会特别的明显。客户所做的软件咨询给不了你任何的深刻洞见。就拿我们来说吧，在早期的咨询项目中，都是诸如数据连接器、管理特性等。现在，我们对于咨询是有限定的，当然是故意这么做的，我们仅为两类客户提供咨询，一类是订阅了我们服务的客户，另外一类是那些直接回馈给上游的开源项目的公司或个人。

支持

通常涉及到认证的开源项目分发，如果你的软件是比较普遍的（想想核心的基础设施，如操作系统、存储、和计算）话，支持确实是一个很好的商业模式，你可以将很大比例的用户转化为签订支持合同的客户。在某些情况下，支持只是在第一年或者是项目的早期阶段才会被购买，对于提供支持的公司来说，一旦客户的项目成熟、技术人员的知识体系普及的话，此公司就面临着商业模式的转变，因为客户已经能够跨越学习的曲线，并可以成功的部署，换句话说，就是不再需要原公司的支持服务了。而在另外一些情形下，比如在高度竞争的Hadoop市场中，那时的转换成本是非常小的，在利润方面有着下行的压力。

对于我们来说，传统意义上的“出问题／修复”的支持模式并不适合，取而代之的是我们转为高度关切“客户成功”的模式，即鼓励客户去问问题，不管是什么问题，而不是传统的支持那样去筛选一些问题。举例来说，在过去，我们使用原来的那一套支持模式的时候，我们仅仅回答软件栈相关以及产品的问题，若是业务和开发的问题，例如如何优化为最佳结果、如何将一个机器学习嵌入到应用程序中等，是不会去管的。现在，我们要帮助用户成功，通常会回答用户所有的问题。在此情况下，答案更多的是参与或者是客户需要详尽的帮助，我们都提供咨询。在更多的情况下，客户在要实现某个功能时仅仅只是需要为其指出一个正确的方向而已，虽然这看起来时显而易见、微不足道的，但是大多数公司的呼叫中心会回避这类问题，不会去参与。但是，我们不一样！我们这样做，非常显著的改善了我们的支持业务。最后，要提醒大家的是，要确保支持的业务费用不要失控，比如，和客户的接触点不要转换为免费的1小时咨询服务。

开放核心，扩展收费

很多公司都走得是这条道路，均是希望用户能够购买他们的增值产品，例如管理工具之类的。此种模式的公司面临的挑战是那些担心厂商锁定的客户（其实不必介意，作出任何的选择都会有所定），又或者是社区的版本拥有相似的特性，这时你就得面临支持和区分不同的版本。如果你找到了其中的卖点，你可以很好的保证社区好管家的身份之余又维持一定的利润。但是这对产品的开发提出了进一步的苛刻的要求，必须目光敏锐、紧跟步伐，当然，在此过程中为了能够更好的理解用户的真实需求，多做一些咨询和支持就难免了。举个例子，我们的产品（Lucidworks 搜索）的第一次迭代中，它的开发主要来自于对市场中上一代的搜索产品的观察所得而来，Lucidworks 是和 Solr 紧密耦合的，防止用户能够使用 Solr 的全部功能集的。

因为产品并非完全是在臆想中完成的设计，反馈通常聚焦于我们是如何将 Solr 隐藏了那么多。在我们团队内部，开发者们在这时总是会觉得无比的纠结，因为和开源项目比起来更多的是竞争，而非补充。在我们新的架构和产品中（Lucidworks Fusion），我们可以做到连接以及和多个我们所支持的不同版本的主要项目（Solr）一起工作，而且我们还集成了其它关键的开源项目，如 Apache Spark。我们所看到的是如何扩展开源项目，而非去替代其中的一些内容。我们也仍然在捕获和智能的使用更多数据方面找寻更多的办法，而不是去撰写稍智能、专有（闭源）的算法。

云／托管

有一些项目是天生就和托管模式结合在一起的，客户可以自行的进行部署和管理，而且还能够访问所有（也有的是部分）工具套件的源代码。但是，若客户想实现一个真正的多租户环境的话，就得来使用托管的平台，此种方式可以产生明显的效益，而且具有可持续的发展。此模式主要的挑战来自于诸如数据保护、正常运行时间、安全、以及如何上传用户的数据（若客户并没有专门为云计算平台而考虑的情况下）等。还有一些特殊的行业是难以接受此种模式的，如受到严格管理的行业（金融服务、医疗保健），相对更为关心安全和个人身份信息。大型的云计算平台提供商（AWS、Google、Azure）很难在此方面找到突破口，但是小众玩家未必没有机会，只要能够精益运营是有可能找到突破口的。

什么是最佳选择？答案是要视实际情况而定，下列所列举的因素都会影响到你最终的决策：开源项目所完成的特定的功能、公司的组织架构、团队的技能、以及当前的竞争格局等。当然采取混合的模式也未尝不可，只要你不是过于的吝惜的传播自己。

在这里我最后再提醒大家一下，作为一家开源软件公司，你必须尽早的去找出如何快速的走出“免费”这样一个陷阱的答案。正如软件开发中的常见情形一样，如果现在的模式或架构行不通，你必须积极的去拥抱重构，否则后果将会不堪设想。

关于作者

Grant是Lucidworks的联合创始人兼首席技术官，是由曼宁出版社发行的《驾驭文本》的联合作者之一，也是 Apache Mahout 的共同创始人，而且还是 Apache Lucene 和 Solr 开源项目的长期贡献者。Grant 过去的工作经验包括各种搜索的引擎、用于各个领域和语言的问答和自然语言处理应用。他拥有阿默斯特学院的数学和计算机科学的学士学位，以及雪城大学的计算机科学的硕士学位。在空闲时间，他享受与家人待在一起，业余爱好由骑自行车、攀岩和徒步旅行。

本文由作者Grant Ingersoll 发表在Opensource.com上：Let's talk about how to build a business with open source。经授权，在InfoQ中文站翻译共享。本文在Creative Commons BY-SA 4.0许可证下发布。