经营分析系统开源代码_我从经营一家开源公司中学到的三大教训

经营分析系统开源代码

听起来很简单：将代码放到GitHub上或在Apache Software Foundation （ASF）上启动/加入一个项目，建立一个志同道合的个人社区，创建一个公司，获得一些资金，然后进行IPO。 或者可能不是。 可以肯定的是：经营一家开源公司具有独特的挑战和机遇。 尽管在开放源代码和社区建设方面写了很多文章，但我想分享作为一家风险投资开放源代码公司的联合创始人和首席技术官在旅行中学到的三个重要教训。

首先介绍一下背景： 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多年中没有学到其他东西，那就是：您永远不知道下一个好主意将来自何处，所以请敞开心it，继续前进。

阿帕奇
鹅毛笔

本文是Rikki Endsley协调的Apache Quill专栏的一部分。 通过open@opensource.com与我们联系，在Apache Software Foundation的项目内分享您的成功案例和开源更新 。

翻译自: https://opensource.com/business/15/5/3-lessons-running-open-source-company

经营分析系统开源代码