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

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

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

1.             基於開源專案（開源核心）建立商業產品，提升開發和佈署效率。
2.             為組織布署Solr提供企業級支援和SLA。

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

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

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

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

1. 我們有一個工程師團隊，他們只在負責在我們產品的開源社群做開源專案開發。
2. 我們把與第三方的整合商業化，如頂層的UI。
3. 我們提供資料分析技術的盒子實現。

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

第二課：支援還是諮詢，還是客戶成功

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

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

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

第三課：管理人員的部分

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

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

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

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

我們還在嗎？

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