我从运营一家开源公司中学到的 3 个重要教训

这一切听起来都很简单直接：将你的代码上传到 GitHub，或者在 Apache 软件基金会 (ASF) 发起/加入一个项目，建立一个志同道合的社区，创办一家公司，获得一些资金，然后进行首次公开募股 (IPO)。 也可能不是这样。 但有一点是肯定的：运营一家开源公司具有独特的挑战和机遇。 尽管关于开源和社区建设的文章已经有很多，但我还是想分享一下我作为一家风险投资支持的开源公司的联合创始人兼首席技术官 (CTO) 在旅程中学到的三个重要教训。

首先介绍一些背景信息：Lucidworks 从事搜索和信息访问业务。 我们的目标很简单：我们希望让信息更易于访问。 我们通过利用搜索、机器学习、自然语言处理 (NLP) 和其他新兴技术来实现这一目标。 我们通过大量构建开源项目来实现这一愿景，既是各种项目的贡献者，也是消费者。 我们主要构建的项目是 Apache Lucene 和 Solr，但我们也依赖其他开源项目，例如 Apache Spark, Hadoop, 和 Tika。 我们的商业模式是双重的

1. 构建一个扩展开源（又名“开放核心”）模型的商业产品，并加速开发和部署
2. 为部署 Solr 的组织提供企业级支持和 SLA。 这两款产品均以年度订阅形式销售。

教训一：贡献什么，销售什么？

我们成立 Lucidworks 是为了在 ASF 现有的、成熟的社区基础上发展。 与那些开源但不开放开发的项目（即由仁慈的独裁者运营）不同，我们经常需要与那些与我们有不同利益的人合作。 对于不习惯这种模式的人来说，这可能会带来一些开发、营销和销售方面的挑战。 例如，社区可能会采用与你不同的实现方式，甚至贡献你一直在努力添加到你的商业产品中作为差异化优势的功能。 此外，你甚至可能不拥有你正在商业化的实际品牌。 这种方法的关键是真正拥抱混乱：尽早沟通你对开源贡献的意图，努力通过线上和线下活动将社区聚集在一起，并与他人密切合作，确保他们的用例也得到解决。 最重要的是——我们尝试了几次才做对——着眼于做出能够让你实现更高级功能的贡献，而不是在你的产品中进行一次性实现。 例如，我们贡献了核心分析功能，使我们能够在我们的产品中支持推荐功能。

你可能会问：“为什么不全部开源，只提供支持呢？” 这是一个合理的问题，我认为每个开源代码的公司都在努力回答这个问题，除非他们是数据公司（例如 LinkedIn、Facebook）、咨询公司，或者是每个人基础设施的关键组成部分（例如操作系统），并且可以仅靠支持生存。 许多公司一开始通过开源来获得采用，然后添加商业功能（并被指责为出卖），而另一些公司则一开始是商业的，然后才开源。 在公司内部，销售部门几乎总是想要一些“额外的东西”，让他们可以完成销售配额，而工程师通常希望一切都是开源的，因为他们知道他们可以将他们的工作带走。 在一个完美的世界里，你可以尝试这两种实验，如果其中一个失败了，还可以把精灵放回瓶子里。 目前，我们已决定采取多层方法

1. 我们有一个工程师团队，他们只专注于为构成我们产品基础的开源项目做出贡献。
2. 我们将粘合剂、第三方集成以及顶部的 UI 商业化。
3. 我们提供常用数据分析技术的开箱即用实现。

特别是，第三项已被证明是成功的，因为大多数公司没有大量的在职数据科学家来构建推荐引擎、搜索分析等。 这三种方法使我们能够专注于如何补充和扩展开源，而不会破坏我们所有人都努力建立的社区。 它还有助于明确哪些内容被贡献以及哪些内容没有被贡献。

教训二：支持 vs. 咨询 vs. 客户成功

在 Lucidworks 的早期，我们的主要产品是知识，就像咨询时间以及众所周知的“一锤定音”的开源保险政策方法。 当然，我们有商业产品，但我们销售的主要内容是访问了解核心代码库的聪明人。 我们销售了大量的咨询时间和支持订阅，这对于获得我们技术在各种实际部署中的知识非常有用，但对于建立长期价值来说不是很好，因为一旦问题得到解决，你通常就不再被需要了。 即使在当时，我们的支持合同通常也只有一年期限，因为 Solr 几乎可以正常工作，客户会意识到他们不需要故障排除保险。

不过，在那段时间发生了一件有趣的事情：我们开始认识到，尽管 Solr 没有崩溃（在大多数情况下——毕竟它是软件），但我们的客户不断询问我们如何做越来越难的事情。 例如，一旦他们完成了基本搜索，他们就想知道如何集成 NLP 工具或将用户反馈循环纳入考虑以提高相关性。 这些问题通常只需要在电话上花一两个小时来指导他们正确的方向。 此外，它们极大地告知了我们的产品管理团队客户最关心什么。 基于这种知识基础，我们已成功地将我们的支持模式演变为我们所说的客户成功模式。 过去，我们收到的任何来自客户的难题都会以推销咨询时间来回应。 现在，我们将这些问题视为正常的支持问题，并与客户互动以确保他们获得成功。 （超过一天的问题仍然可能是咨询。） 许多这些问题和建议也被反馈到产品中，使其变得更好。 此外，我们从支持方面更积极主动地联系，而不是等待电话响起。 这似乎是显而易见的，但我认为对于许多建立在支持模式心态之上的开源公司来说，其目标是呼叫转移和自助服务，这种差异非常明显。 好处是你与客户的互动更加密切，你的产品变得更好，因为它明确地关注人们关心的事情，每个人都更快乐，包括你的销售团队。

教训三：管理人员部分

与任何公司一样，你的成功或失败不仅仅取决于产品本身，还取决于你周围的人。 在开源领域，招聘的关键之一是找到不仅与公司的开源性质相符，而且与支付他们工资的商业方面相符的人。 如果你完全是开源的，这很容易，因为两者完全一致（假设人们真的会仅仅为了支持而付费）。 如果你将免费和付费混合在一起，这可能会更具挑战性，因为有时来自闭源的人不会理解开源方面的东西（由于开源的普及，这种情况现在不太常见），有时来自开源的人不会理解或不想从事任何非开源的工作。

开源人员方面的另一个挑战/机遇是，你可能想从社区招聘的许多工程师将是远程的，因此你必须建立一家能够成功支持分布式员工的公司。 对我们来说，一个更有趣的挑战，尤其是在早期，来自于在办公室工作的工程师，但这并不是因为大多数在家工作的员工所面临的常见的“眼不见，心不烦”的原因。 因为我们当时的大多数工程师都是分布式的，并且非常习惯分布式、异步通信，他们有很多根深蒂固的开源开发约定，这些约定并不总是能转化为那些习惯于办公室、专有开发工作流程的人所使用的约定。 当然，关键是沟通和文档，但你甚至可能没有意识到它正在发生，直到你意识到有一些事件突出了这种脱节。 值得庆幸的是，有很多很棒的工具可以实现协作并减少任何潜在的摩擦，但也要确保为大量的面对面聚会做好预算，这是我们作为一个团队每年会做几次的事情，而作为小组则更频繁。

最后，你必须认识到并非所有人都能够远程工作。 例如，需要高度协作或以视觉为导向的工作通常最好面对面完成。 对我们来说，我们的大部分服务器端团队是远程的，而我们的大部分产品管理和 UI 团队则在一起工作。 后者从“嘿，快来看这个”这种在同一房间提供的互动类型中获益匪浅，而前者通常从大段不间断的时间中获益。

我们到了吗？

正如任何曾经做过初创公司的人都知道的那样，当你寻找可重复和可扩展的商业模式时，你将经历许多起起落落。 对我们来说，上述教训来之不易，并且对于不仅构建我们可以销售的产品，而且对于雇用优秀人才和建立广泛的用户社区至关重要。 除此之外，如果说我在 10 多年的开源贡献中学到了什么，那就是：你永远不知道下一个好主意会从哪里来，所以要对它保持开放态度，并抓住机会。

本文是 Rikki Endsley 协调的 Apache Quill 专栏的一部分。 通过 open@opensource.com 联系我们，分享你在 Apache 软件基金会项目中取得的成功案例和开源更新.