從運營一個開源公司所學到的三大教訓

這一切聽起來是那么簡單：把你的代碼上傳到GitHub或者在Apache軟件基金會 (ASF) 上開始或加入一個工程，建立一個志趣相投的社區，開始一個公司，投入一些資金，然后IPO。或者未必。但有一點是肯定的：運營一家開源公司有著獨特的挑戰和機會。盡管已經有很多關于開源和社區建立的主題，我還是希望分享我在一個由風投支持下的開源公司里，作為一個共同合伙人和CTO所學習到的三個的重要的經驗。

先簡介一下背景：Lucidworks 是做搜索和信息訪問業務。我們的目標很簡單，就是提高信息的可訪問性。我們通過搜索，機器學習，自然語言處理和一些其他新技術來實現我們的目標。在實現過程中我們大量使用開源技術，在很多大的項目中我們既是貢獻者也是使用者。我們主要基于 Apache Lucene 和 Solr，當然也有其他項目如 Apache Spark，Hadoop和Tika。我有兩個商業模式：

1. 基于開源項目（開源內核）創建商業產品，提升開發和布署效率。

2. 為組織布署Solr提供企業級支持和SLA。

兩種產品都以年度訂閱的方式銷售。

第一課：何為貢獻，何為營銷？

我們組織 Lucidworks 建立在一個現有的，完善的社區在 ASF上。不像一些開源但不開放的項目（例如由一個仁慈的“獨裁者“運營），我們必須和一些比我們更有興趣的人工作。對于不習慣這種模式的人來說，這可能會是一份挑戰在開發，市場運營和銷售等方面。例如，社區可能會開發出不同的實現，這些實現作為一個分支可能超過你所開發的，甚至貢獻的特性可能是你長期研發沒能加入到你的商業產品中的。此外，你甚至可能會不能擁有真正的的表明你是商業化的權利。解決方法的關鍵是全身擁抱這種混亂：盡早和開源貢獻者交流你的意圖，通過線上線下的活動努力使社區團結，和他人緊密工作確保你的需求被加入其中。最重要的是，這使我們只要幾次嘗試就得到正確的結果——尋找做貢獻讓你能夠做更高等級的功能，代替在你的產品中做一個離線的實現。例如，我們可以貢獻核心分析功能讓我們的產品擁有強力的推薦機制。

我可能會問，“為什么開源所有源代碼，只做技術支持？”，好問題，我想每個開源公司都很難回答這個問題，除非他們是一家數據公司（如 linkedIn，非死book)，咨詢公司，或者是可以獨立生存，對每個人都很重要的基礎服務（如操作系統）。很多公司初始階段靠開源獲取資源，然后再附件付費功能（被指責出賣），然而也有一些行走商業化道路，再開源。在公司內部，銷售部門總是想附加一些東西來完成業績，但工程師往往頃向于全面開源，因那他們知道這樣可以綁定他們的工作在上面。在一個完美世界里，你可以把兩種方式都實驗一遍，一旦一種實驗失敗也可以控制，但現在，我們決定采用多層次的方式：

1. 我們有一個工程師團隊，他們只在負責在我們產品的開源社區做開源項目開發。

2. 我們把與第三方的集成商業化，如頂層的UI。

3. 我們提供數據分析技術的盒子實現。

特別是第三項已經被證實是成功的，因為大多數公司沒有技術團隊可以做數據分析看板，以建立推薦引擎，搜索分析等等。第三種方式全們我可以專注如何完成和擴大我們的開源成果，保證我們努力建議的社區不被破壞。這也有助于明確什么得到了什么還沒有。

第二課：支持還是咨詢，還是客戶成功

在 Lucidworks 的初期，我們的主要產品是知識，在咨詢時間使用“一包到底“的保險制度做開源。當然我們有一個商業產品，但主要贏利點是獲得知識底層代碼的聰明人。我們銷出很多咨詢和訂閱支持，這些通過我們的技術布署非常有利于豐富的知識獲取，但不利團隊的長期發展，因為問題一旦解決，我們就失去了價值。即便長達一年之久，因為 Solr 只是一時工作之需，客戶們認識到他們不需要中斷或修復保險。

在那段時間發生一件有意思的事情，盡管我們認識到 Solr 沒有崩潰（很多方面，它畢竟只是一個軟件），我們的客戶不斷的問怎么處理更難的事情。比如，他們把基礎搜索運行起來，他們就想知道怎么把自然處理語言或者其他客戶反饋的東西集成進來以提高相關性。這些問題往往需要一到兩個小時的時間在電話里指導他們，另外他們向產品管理團隊反饋了大量用戶最關注的信息。基于這樣的知識基礎，我們成功解決了我們的支持模式，我們稱之為客戶成功模式。

過去，我們把收到的任何困難問題傾向于變成咨詢服務。現在，我們對待這些問題就好像是普通的技術支持一樣并且一直和用戶交流確保問題得到解決。（但任何超過一天的服務仍可能變成咨詢）類似的問題或建議更多地被反饋到我們的產品中讓它變得更好。此外，我們對于用戶需要的支持功能變得更具有預見性，不再需要等待電話來催我們了。雖然明顯，但是我看到很多建立在支持服務層面的開源公司在對待這類問題的方法是轉移話題或“自助服務”，這樣造成的結果差別大家都很明白。更好的結果應該是你仔細專注于客戶的需求服務，這樣你的產品才能變得更好。因為只要你真正用心于客戶關心什么，大家才能真的好，包括你的銷售團隊。

第三課：管理人員的部分

和許多其他公司一樣，你不可能僅基于一個產品自身獲得成功或導致失敗，除此之外還決定于你身邊的人。在開源世界，雇傭員工的一個關鍵問題是找到能平衡公司的開源屬性和你支付薪水的商業事務的人。假如你是完全開源的，這很容易做到兩方面的完美平衡（假設將人實際支付的單獨支持）。如果你免費中伴有付費，這可能更有挑戰性，因為有時來自于閉源世界的人不太了解開源這邊的事（今天已經很少見了，源于開源的普遍性）同時那些開源工作和可能不會理解或者不想從事任何非開源的工作。

社區中很多你想要聘用的工程師往往天各一方，這是做開源的人所要面對的挑戰也是機遇——需要你建立一個能很好支持分布式遠距離辦公環境的公司。我們遇到了一個有趣的挑戰，特別是剛開始的兩年。它來自于過去在辦公室工作的工程師，但他們并不是因為這種“眼不見心不煩”的理由被那些在家辦公的員工困擾。而是因為我們的大部分員工在過去時間是分散的并且也習慣于了異步，分散式的交流方式，他們有許多根深蒂固地開源開發傳統，還沒有習慣集體辦公和各種開發工作流程。

當然，交流和文檔是很關鍵的，但是你可能不會認識到重要事件的發生，直到你認識到一些重要的連接斷裂事件。幸運地是，有許多很不錯的工具可以使用，讓協作間時減少任何潛在的摩擦，但是面對面的聚會一定要保證其充足的預算，這樣的聚會我們一年要做好幾次，要是團隊更小聚會還可以更頻繁。

最后，你必須意識到并不是所有人都具有遠程工作的能力。比如，那些需要高度協作或者視覺導向的工作，最好面對面來做。對于我們來說，服務器端團隊多數人員都是遠程工作的，而我們的產品管理團隊和 UI 團隊中的絕大部分都是集中辦公的。后者能夠從“嗨，過來看看”這種快速的溝通中獲益良多，因為大家都在同一間屋子里辦公，而前者通常得益于擁有大段不被打擾的時間。

我們還在嗎？

就像任何未充分了解創業就去做的人一樣，在你去尋找一種可復制和擴展的商業模式的過程中總會經歷多次的起伏。對我們來說，得到的教訓是難于抗爭和嚴峻的挑戰不僅僅是建立一個能夠銷售的產品，還有如何雇傭優秀的人才以及怎樣建立一個廣泛的用戶社區。除了那些，如果我從過去10年的開源社區貢獻學到了什么的話，那就是：你永遠不會知道下一個好點子來自哪，因此去擁抱它并且像騎馬一樣牢牢抓緊它的韁繩吧。