他们说你永远不会忘记你的第一次。 我的情况发生在 2008 年，当时 Lucidworks 刚刚完成了 A 轮融资，并聘请了我们的第一位销售人员。 我被要求接听一位潜在客户的电话，他们正在寻求帮助，以解决 Apache Solr 的问题。 在通话过程中，这位潜在客户问了我许多“难倒专家”式的问题。 挂断电话后，我为自己出色地回答了他们所有的问题而沾沾自喜，这时我的销售人员打来了电话。 虽然我不记得他的确切措辞，但意思大致是
销售人员：“干得好，但你搞砸了这个机会。”
我：“为什么？ 我向他展示了我们知道自己在说什么，并给了他们他们正在寻找的答案来解决他们的问题。”
销售人员：“是的，你确实做到了，现在他有了所有答案，不再需要我们了。”
果然，他是对的。 后续电话简短而切中要点：“谢谢你的帮助，我们解决了问题，一切都很好。” 我很快意识到，经营开源业务与成为开源社区的一员大不相同。 请别误会——我仍然乐于分享我的知识并帮助建设社区。 但我也必须支付账单，尤其是在公司发展的早期阶段，而我的知识和时间是我的主要资产。
多年来，随着我们从主要以支持为基础的业务发展成为以产品为中心的组织，这个主题的各种变体 регулярно 出现。 和所有企业一样，最终我们必须弄清楚如何赚钱。 然而，开源企业由于主要产品是免费许可的，因此面临着独特的挑战。 在最好的情况下，这会导致显着的价格下行压力，而在最坏的情况下，则会产生对免费的期望：免费软件、免费知识、免费支持。
对于客户来说，他们的想法通常是：“我们只需聘请一些开发人员，他们可以获取源代码并实施它，我们就可以在邮件列表中获得答案。 如果我们陷入困境，也许我们会支付一些顾问费用。”
我喜欢称之为“我想要你的免费，但你为我的付费”软件运动。 这些公司当然希望每个人都为他们的产品/服务付费。 这种想法解释了为什么这么多公司乐于消费开源，但从不回馈。 这不是我的酸葡萄心理，而是在当今许多软件公司的现实。 我不确定这种做法从长远来看是否可持续，尤其是在开发人员的薪资不断上涨的情况下。 但事实就是如此，如果你想在一个开源项目上建立业务，你需要弄清楚如何应对这种现实——或者根本不参与。 如果“你的”代码库实际上并不归你所有，情况会变得更加复杂，例如当软件归开源基金会（例如 Apache 软件基金会）所有时，你通常会有相互竞争的利益在“你的”沙箱中博弈。
在我的公司，我们经历了多次迭代，试图回答“我们如何赚钱”的问题，最初的几次主要是咨询和支持的变体。 这逐渐演变成我们目前的模式，即销售建立在开源之上的平台——或者通常所说的“开放核心”——以及为那些希望直接基于开源（即社区版）构建的用户提供的支持选项。 每种方法都有优点和缺点，我将在下面概述其中一些
咨询
虽然咨询可以为合适的团队带来丰厚的收入，但它很难扩展，利润率很薄，并且很少能看到风险投资公司期望的回报类型。 咨询业务通常是“饥一顿饱一顿”，尤其是在组织生命周期的早期阶段。 从好的方面来说，没有什么能像咨询那样让你直接洞察客户如何使用该软件。 对我们来说，我们早期的咨询项目对于告知我们构建哪些数据连接器和管理功能至关重要。 如今，咨询业务受到有意限制，仅提供给与我们签订订阅协议的客户或直接为我们支持的上游开源项目做出贡献的客户。
支持
通常涉及开源项目的认证发行版，如果你的软件无处不在（想想核心基础设施，如操作系统、存储、计算），并且你可以将一定比例的用户转化为经常性支持合同，那么支持可能是一项非常好的业务。 在某些情况下，支持仅在第一年或软件早期、错误较多的年份需要，一旦客户度过了最初的学习曲线并成功部署，公司就不得不提出另一种销售模式。 在其他情况下，例如竞争激烈的 Hadoop 市场，如今的转换成本非常低，以至于利润率几乎 постоянно 面临下行压力。
对我们来说，传统的“故障排除”支持模式行不通，相反，我们转而采用更高级别的“客户成功”模式，鼓励客户提出问题，无论这些问题是否传统上被归类为支持问题。 例如，在我们旧的传统支持模式中，我们可能只处理与堆栈跟踪和生产问题相关的请求，而不处理业务/开发人员问题，例如如何最好地提高结果质量或如何将机器学习纳入应用程序。 如今，我们经常回答所有类型的问题，因为它们有助于客户取得成功。 对于那些答案更复杂或客户需要详细帮助的情况，我们提供咨询。 在许多情况下，客户只是在实施某项功能时需要正确的方向。 这似乎显而易见，但大多数公司的支持中心都以呼叫转移为导向，而不是以互动为导向。 我们的方法显着提高了我们纯粹支持业务方面的续订率。 但是，必须注意确保支持费用不会失控，并且这些接触点不会变成数小时的免费咨询。
开放核心或商业扩展
许多公司走这条路线，希望他们能让人为增值功能付费，例如更好的管理工具。 该领域的公司面临的挑战通常属于对供应商锁定的恐惧（别介意任何选择都会锁定你）。 或者社区构建类似的功能，你也必须支持和与之区分。 如果你找到了一个最佳点，你可以在保持利润率的同时仍然成为社区的好管家，但这需要对产品开发有敏锐的眼光，并且通常是在做了相当多的咨询和支持以更好地了解用户实际需要什么之后发展起来的。 例如，在我们产品的第一个版本（Lucidworks Search）中，它主要是通过查看市场上上一代搜索产品的功能而开发的，并且它与 Solr 紧密耦合，这阻止了用户利用 Solr 的全部功能集。
虽然该产品并非完全在真空中设计，但反馈通常集中在我们隐藏了太多 Solr 或他们的插件无法与之配合使用。 在内部，即使是我们自己的开发人员也经常感到在它上面工作很矛盾，因为它与开源项目本身竞争太激烈，而不是补充它。 凭借我们新的架构和产品（Lucidworks Fusion），我们可以连接和使用我们支持的主要项目（Solr）的多个不同版本，并且我们还集成了其他关键的开源项目，如 Apache Spark。 我们将其视为开源的扩展，而不是开源的替代品。 我们还在寻找更多方法来智能地捕获和使用更多数据，而不是编写更智能的专有算法。
云/托管
一些项目自然而然地与托管模式保持一致，在这种模式下，开源的部署和管理由客户管理，同时仍然让客户访问开源项目的完整（或部分）工具套件。 如果你能实现真正的多租户解决方案，这种方法可以产生可观的利润率和良好的经常性收入流。 该领域的挑战通常与数据保护、正常运行时间、安全以及如果客户的数据尚未在云中，如何上传客户的数据有关。 受到严格监管的行业（金融服务、医疗保健）由于对安全和个人身份信息的担忧，通常尤其难以渗透。 大型云提供商（AWS、Azure、Google）似乎正在大力追求这种方法，但如果你的运营精简，利基市场参与者也可能获得成功。
哪个选项最好？ 当然，答案取决于多种因素，包括你的开源项目的特定功能、公司的资本构成、团队的技能组合以及竞争格局。 混合模式也可能是可行的，只要你没有把自己摊得太薄。
最后，作为一家开源公司，你必须尽早决定如何相对快速地摆脱“它是免费的”陷阱，同时仍然发展和培育社区。 正如软件的情况一样，如果模型不起作用，你不应该害怕重构模型。
1 条评论