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

[[135395]]

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

1.             基于開源項目（開源內(nèi)核）創(chuàng)建商業(yè)產(chǎn)品，提升開發(fā)和布署效率。

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

兩種產(chǎn)品都以年度訂閱的方式銷售。

***課：何為貢獻，何為營銷？

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

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

1. 我們有一個工程師團隊，他們只在負責在我們產(chǎn)品的開源社區(qū)做開源項目開發(fā)。

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

3. 我們提供數(shù)據(jù)分析技術(shù)的盒子實現(xiàn)。

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

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

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

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

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

第三課：管理人員的部分

和許多其他公司一樣，你不可能僅基于一個產(chǎn)品自身獲得成功或?qū)е率。酥膺€決定于你身邊的人。在開源世界，雇傭員工的一個關(guān)鍵問題是找到能平 衡公司的開源屬性和你支付薪水的商業(yè)事務(wù)的人。假如你是完全開源的，這很容易做到兩方面的***平衡（假設(shè)將人實際支付的單獨支持）。如果你免費中伴有付 費，這可能更有挑戰(zhàn)性，因為有時來自于閉源世界的人不太了解開源這邊的事（今天已經(jīng)很少見了，源于開源的普遍性）同時那些開源工作和可能不會理解或者不想 從事任何非開源的工作。

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

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

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

我們還在嗎？

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