这一切听起来是那么简单：把你的代码上传到GitHub或者在Apache软件基金会 (ASF)上开始或加入一个工程，建立一个志趣相投的社区，开始一个公司，投入一些资金，然后IPO。或者未必。但有一点是肯定的：运营一家开源公司有着独特的挑战和机会。尽管已经有很多关于开源和社区建立的主题，我还是希望分享我在一个由风投支持下的开源公司里，作为一个共同合伙人和CTO所学习到的三个的重要的经验。
先简介一下背景：Lucidworks 是做搜索和信息访问业务。我们的目标很简单，就是提高信息的可访问性。我们通过搜索，机器学习，自然语言处理和一些其他新技术来实现我们的目标。在实现过程中我们大量使用开源技术，在很多大的项目中我们既是贡献者也是使用者。我们主要基于 Apache Lucene 和 Solr，当然也有其他项目如 Apache Spark，Hadoop和Tika。我有两个商业模式：
基于开源项目（开源内核）创建商业产品，提升开发和布署效率。 为组织布署Solr提供企业级支持和SLA。两种产品都以年度订阅的方式销售。
第一课：何为贡献，何为营销？
我们组织 Lucidworks 建立在一个现有的，完善的社区在 ASF上。不像一些开源但不开放的项目（例如由一个仁慈的“独裁者“运营），我们必须和一些比我们更有兴趣的人工作。对于不习惯这种模式的人来说，这可能会是一份挑战在开发，市场运营和销售等方面。例如，社区可能会开发出不同的实现，这些实现作为一个分支可能超过你所开发的，甚至贡献的特性可能是你长期研发没能加入到你的商业产品中的。此外，你甚至可能会不能拥有真正的的表明你是商业化的权利。解决方法的关键是全身拥抱这种混乱：尽早和开源贡献者交流你的意图，通过线上线下的活动努力使社区团结，和他人紧密工作确保你的需求被加入其中。最重要的是，这使我们只要几次尝试就得到正确的结果——寻找做贡献让你能够做更高等级的功能，代替在你的产品中做一个离线的实现。例如，我们可以贡献核心分析功能让我们的产品拥有强力的推荐机制。
我可能会问，“为什么开源所有源代码，只做技术支持？”，好问题，我想每个开源公司都很难回答这个问题，除非他们是一家数据公司（如linkedIn，Facebook)，咨询公司，或者是可以独立生存，对每个人都很重要的基础服务（如操作系统）。很多公司初始阶段靠开源获取资源，然后再附件付费功能（被指责出卖），可是也有一些行走商业化道路，再开源。在公司内部，销售部门总是想附加一些东西来完成业绩，但工程师往往顷向于全面开源，因那他们知道这样可以绑定他们的工作在上面。在一个完美世界里，你可以把两种方式都实验一遍，一旦一种实验失败也可以控制，但现在，我们决定采用多层次的方式：
我们有一个工程师团队，他们只在负责在我们产品的开源社区做开源项目开发。 我们把与第三方的集成商业化，如顶层的UI。 我们提供数据分析技术的盒子实现。特别是第三项已经被证实是成功的，因为大多数公司没有技术团队可以做数据分析看板，以建立推荐引擎，搜索分析等等。第三种方式全们我可以专注如何完成和扩大我们的开源成果，保证我们努力建议的社区不被破坏。这也有助于明确什么得到了什么还没有。
第二课：支持还是咨询，还是客户成功
在 Lucidworks 的初期，我们的主要产品是知识，在咨询时间使用“一包到底“的保险制度做开源。当然我们有一个商业产品，但主要赢利点是获得知识底层代码的聪明人。我们销出很多咨询和订阅支持，这些通过我们的技术布署非常有利于丰富的知识获取，但不利团队的长期发展，因为问题一旦解决，我们就失去了价值。即便长达一年之久，因为 Solr 只是一时工作之需，客户们认识到他们不需要中断或修复保险。
在那段时间发生一件有意思的事情，尽管我们认识到 Solr 没有崩溃（很多方面，它毕竟只是一个软件），我们的客户不断的问怎么处理更难的事情。比如，他们把基础搜索运行起来，他们就想知道怎么把自然处理语言或者其他客户反馈的东西集成进来以提高相关性。这些问题往往需要一到两个小时的时间在电话里指导他们，另外他们向产品管理团队反馈了大量用户最关注的信息。基于这样的知识基础，我们成功解决了我们的支持模式，我们称之为客户成功模式。
过去，我们把收到的任何困难问题倾向于变成咨询服务。现在，我们对待这些问题就好像是普通的技术支持一样并且一直和用户交流确保问题得到解决。（但任何超过一天的服务仍可能变成咨询）类似的问题或建议更多地被反馈到我们的产品中让它变得更好。此外，我们对于用户需要的支持功能变得更具有预见性，不再需要等待电话来催我们了。虽然明显，但是我看到很多建立在支持服务层面的开源公司在对待这类问题的方法是转移话题或“自助服务”，这样造成的结果差别大家都很明白。更好的结果应该是你仔细专注于客户的需求服务，这样你的产品才能变得更好。因为只要你真正用心于客户关心什么，大家才能真的好，包括你的销售团队。
第三课：管理人员的部分
和许多其他公司一样，你不可能仅基于一个产品自身获得成功或导致失败，除此之外还决定于你身边的人。在开源世界，雇佣员工的一个关键问题是找到能平衡公司的开源属性和你支付薪水的商业事务的人。要是你是完全开源的，这很容易做到两方面的完美平衡（假设将人实际支付的单独支持）。要是你免费中伴有付费，这可能更有挑战性，因为有时来自于闭源世界的人不太了解开源这边的事（今天已经很少见了，源于开源的普遍性）同时那些开源工作和可能不会理解或者不想从事任何非开源的工作。
社区中很多你想要聘用的工程师往往天各一方，这是做开源的人所要面对的挑战也是机遇——需要你建立一个能很好支持分布式远距离办公环境的公司。我们遇到了一个有趣的挑战，特别是刚开始的两年。它来自于过去在办公室工作的工程师，但他们并不是因为这种“眼不见心不烦”的理由被那些在家办公的员工困扰。而是因为我们的大部分员工在过去时间是分散的并且也习惯于了异步，分散式的交流方式，他们有许多根深蒂固地开源开发传统，还没有习惯集体办公和各种开发工作流程。
当然，交流和文档是很关键的，但是你可能不会认识到重要事件的发生，直到你认识到一些重要的连接断裂事件。幸运地是，有许多很不错的工具可以使用，让协作间时减少任何潜在的摩擦，但是面对面的聚会一定要保证其充足的预算，这样的聚会我们一年要做好几次，要是团队更小聚会还可以更频繁。
最后，你必须意识到并不是所有人都具有远程工作的能力。比如，那些需要高度协作或者视觉导向的工作，最好面对面来做。对于我们来说，服务器端团队多数人员都是远程工作的，而我们的产品管理团队和 UI 团队中的绝大部分都是集中办公的。后者能够从“嗨，过来看看”这种快速的沟通中获益良多，因为大家都在同一间屋子里办公，而前者通常得益于拥有大段不被打扰的时间。
我们还在吗？
就像任何未充分了解创业就去做的人一样，在你去寻找一种可复制和扩展的商业模式的过程中总会经历多次的起伏。对我们来说，得到的教训是难于抗争和严峻的挑战不仅仅是建立一个能够销售的产品，还有如何雇佣优秀的人才以及怎样建立一个广泛的用户社区。除了那些，要是我从过去10年的开源社区贡献学到了什么的话，那就是：你永远不会知道下一个好点子来自哪，因此去拥抱它并且像骑马一样牢牢抓紧它的缰绳吧。