作者簡介：黃東旭，PingCAP 聯合創始人兼 CTO
前些天在與友人喝咖啡的時候，正好聊到關於 PingCAP 和 TiDB 的一些歷史以及對於開源軟件公司核心競爭力的理解，回顧這幾年的創業生涯和 TiDB 社區的生長壯大，就像是一場巨大且正在進行中的社會學實驗，原本零散的一些想法隨着一條主線變得逐漸清晰，就想着寫成文章總結一下關於社區對於開源軟件以及開源公司到底意味着什麼。
無處不在的網絡效應
兩種網絡效應
很多人聽說過網絡效應（梅特卡夫效應：網絡的價值與聯網用戶的平方數成正比），許多偉大的產品和公司通過網絡效應構建起了強大的護城河。提到網絡效應，經典例子在通信領域，例如手機，每多一個用戶，對於所有用戶的價值就越大，雖然大家也無意爲他人創造價值，但是一旦開始使用，該行爲就會幫助這個網絡創造價值。很多我們熟知的 to C公司，尤其是社交網絡和IM（即時通信軟件） ，通過這個效應構建了極高的壁壘。NfX Venture 在他們的一篇博客(https://www.nfx.com/post/network-effects-manual/）中詳細描述了很多種網絡效應，在介紹社區之前，我想着重介紹下其中和開源軟件相關的兩種網絡效應。
- 基於從衆心理的網絡效應
這類網絡效應通常是從一些意見領袖開始，可能是行業大咖，可能是社交潮人，常常出現在一個新產品要去進攻一個老產品的市場時。儘管這個新產品相比市場的統治者來說不一定成熟，但它通常會帶着一些鮮明的特色或者更加前沿的理念，吸引那些對「主流」不滿或者希望突顯自身前沿視野的意見領袖的支持，造成一種「很酷的人都在用，你不用你就要被淘汰了」的感覺。
這種感覺會在新用戶紛紛加入時，形成從衆心理的網絡效應，但是這類網絡效應的持續時間不會太長。細想一下就能知道：如果早期意見領袖只是因爲突顯「不同」而加入，那麼在這個社區成爲主流後，這些意見領袖就沒有理由留下，追隨這些人的粉絲可能會隨之而去。另外，對於這個新產品來說，完善程度通常不如老產品，美譽和差評會在早期同時到來。此時，如果不快速通過網絡效應打磨產品，獲得更好的迭代速度，那麼，這個網絡效應是根基不牢的。一個好處在於，該效應在早期是事半功倍的。
回想 TiDB 早期的社區建設，也是因爲幾個創始人在 Codis 的工作以及在國內基礎軟件圈中積累的名聲，和一些互聯網技術圈中朋友的支持，形成最早的背書。
- 基於信仰的網絡效應
所謂「信仰」，就是基於對一個理念的認可而加入，從而形成網絡效應。這點在軟件領域也不少見，自由軟件運動和開源運動都是很好的例子。人嘛，總是要相信點什麼。這類網絡效應的護城河是極深的，而且對於產品缺陷的容忍度極高。因爲信念是一個長期的念想，對於 TiDB 來說，這個念想形如：相信分佈式是未來，相信雲時代的業務需要像 TiDB 這樣的數據庫。但是這個目標又是足夠有挑戰的，值得長期爲之努力。
基於信仰的網絡效應可能在最早期和從衆心理網絡效應有點類似，其中的關鍵是社區核心人羣對於產品背後的理念是否有堅定信仰。反之，如果只是簡單地秀優越感，是不會長久的，隨着興趣衰減，網絡效應也會崩塌。
網絡效應對於基礎軟件的意義
對於基礎軟件來說，我一直堅持兩個觀點：
- 基礎軟件是被“用”出來的，不是“寫”出來的。
- 迭代和進化速度是這類軟件的核心競爭力。
這兩點恰恰是網絡效應能帶來的，雖然價值鏈條不像IM那樣明顯，但是，網絡效應存在的基礎是新用戶給老用戶帶來的額外價值。而基礎軟件的價值，體現爲以下幾點：
- 可控的風險（穩定性）
- 更多的場景適應性（發現新的適用場景和持續提升性能）
- 良好的易用性
對於風險控制來說，越多人用意味着風險被越多人均攤，其中的一個假設是：我不特別，我遇到的問題別人應該也遇到過，一定有人能比我早發現並修復它。這個假設在一個成熟且活躍的基礎軟件社區是成立的，因爲基礎軟件的場景邊界相對清晰，在適用範圍內的路徑大致相同，同一條路徑走多了，坑自然就少了。只要有一個人踩到坑，反饋回社區，不管最後是誰修好的，這個行爲對於其他用戶都是受益的。
同樣的邏輯，對於場景適應性來說也成立。個體的認知總是帶有侷限性，即使是項目的創始團隊，也不見得對於某個具體的應用場景有深刻理解。社區用戶的創造力是無窮的，一些設計外的使用路徑可能會出奇地好用，從而發展出新的優勢場景。同樣地，只要有一個成功案例，那麼對於其他具有相似場景的用戶來說，軟件的價值就增加了， TiDB 和 Flink 組合成的實時 HTAP 數據處理方案，就是一個很好的例子。
對於易用性改進的邏輯和穩定性類似，我就不贅述了。利用網絡效應帶來的飛輪效應改進軟件，這個思路我在《大教堂終將倒下，但集市永存》一文中也提到過。
社區的成熟度曲線和必經階段
社區的誕生
在 GitHub 上開放你的源代碼，甚至使用公開的 Git 工作流，都不是社區誕生的時刻。一個社區真正誕生，是在你和你的代碼之外，開始有第三者介入併產生連接的時刻，可能是收到第一個外部 PR，可能是收到第一個外部 issue，這些纔是社區的開端。社區始於連接，也成就於連接。開放源代碼並不等同於開源，很多團隊和項目在開放源代碼方面花費了很多時間，卻忽略了代碼及背後團隊的社區化，這是很可惜的。
死亡鴻溝和希望之坡
就像《跨越鴻溝》這本書中提到的，開源軟件也有自己的生命週期曲線，這是和社區息息相關的。
圖中斷層出現的原因是產品成熟度遲遲沒有跟上，用戶過來以後發現都是坑，隨之而來的各種差評會讓早期支持者和創始人疲於奔命甚至而失去興趣。
對於一個開源軟件，斷層的體現可能是經歷早期快速增長後，來到長達 1~2 年的靜默期，增長几乎停滯。對於社區來說，幾乎所有的精力都用在給早期用戶填坑，期間會有用戶自然增長但流失率也非常高。這個階段對於資源的消耗非常大，社區的核心貢獻者也會非常累，如果熬不過去就死了，所以說是“死亡鴻溝”。
好消息是，這個階段終將會過去，bug 這種東西嘛，改掉一個就少一個，產品也會在這個階段逐漸摸索到自己的定位和最佳實踐，而在最佳實踐這個路徑上，產品會變得越來越穩定和聚焦。如果定位是市場剛需，那麼就會迎來一個高速增長階段（成熟期），而社區的生態也會隨着產品的普及開始加速度發展。這個從上圖的 Kubernetes 和 TiDB 的搜索指數裏面能看到這個鴻溝的一個側寫。
社區的終局
一個好的開源軟件社區的終局會是什麼樣子？對於這個問題，其實我們有很多能參考的例子，例如 GNU Linux、Hadoop、Spark、MySQL 等等。我認爲，不管一個開源軟件及社區是由商業公司發起還是其他方式發起、壯大，到最後一定會出現獨立於某公司之外的中立組織來接管這個社區，這也是最自然合理的方式。
尤其是公司主導的開源項目，在後期會面臨中立性的問題。因爲對於公司而言，最重要的是客戶成功，對商業化的訴求一定會影響開源軟件功能設置和開發優先級。而且優先級往往是會變的（可能更緊急且更具體），變化也許會和社區的開發節奏衝突，但我不認爲這兩者的矛盾不可調和，我會在下文展開來講。
中後期的開源軟件已經支撐着太多用戶的場景成功和商業利益，由一箇中立的委員會來平衡各方的利益及監督各方的責任是目前看來比較成功的實踐，而且開始有這樣的組織，也從側面說明這個項目已經成熟，已經有良好的生態。還沒有到達這個階段的開源軟件大多是由項目背後的公司主導社區，在項目成熟階段，重點是不斷地通過優化客戶和場景的成功讓整個飛輪轉動起來，當主導公司之外有越來越多的成員在思考和實踐 governance rule，這就是一個積極的信號。
社區和商業化如何共存
種地和做菜 & 河與岸上的人
前文留下一個問題，就是開源與商業化的矛盾，不管我如何解釋，本質上開源和傳統的軟件售賣模式一定是衝突的。
我舉一個比較好理解的例子：如果將開源比作種菜，開源軟件源代碼相當於種子，業務成功相當於長出來的菜，傳統的軟件商業模式類似於賣種子，但是種地施肥（hosting）都是客戶自己的工作。開源軟件的種子是免費的，地是客戶的，種地的人也是客戶的人，所以開源廠商大概只能提供種地指導服務，尤其在一些種子不是太好種的情況下，指導服務是有意義的。但仔細想想，隨着種子不斷改良（性能、穩定性、易用性等），隨便撒到地裏就能開花結果，那麼專業的種菜服務就沒什麼必要性了。於是廠商只好賣一些額外的價值，比如保險服務，萬一種子生長遇到極端天氣，至少有專家團在背後幫忙解決。但是這種商業模式仍然比較彆扭，因爲價值鏈條大部分都在客戶自己這邊。所以，如果廠商看待社區只停留在潛在客戶視角，很難做出好產品，因爲沒有內在動力去持續優化軟件。
一個更好的視角是往後退一步，我再舉個好理解的例子：將社區當成一條河流，不屬於任何人，大家共同保持河水的清澈和流動性，誰都不要過度撈魚，不同的組織和個人都可以在河流周邊構建自己的生態，至於岸上的人靠什麼掙錢，那是另外一個問題，後文再講。
客戶成功和用戶體驗：內在的一致性
雖然開源軟件商業公司的第一目標是客戶成功，但這和做好社區並不矛盾。一個常見的誤區是在開源軟件公司內部，這兩個團隊形成對立關係。商業團隊認爲社區就是給商業化養魚的，養肥了就要收割，極端點就動不動要閉源；社區團隊認爲商業化會減慢生態傳播的速度，使用門檻上升，極端做法是產生反商業化的傾向。如果都只在自己的位置上思考問題，當然雙方都沒錯，那到底是哪裏有問題呢？
問題出在了“階段”和“客戶選擇”，社區用戶和商業用戶使用開源軟件的生命週期可能完全不同，一般的開源軟件公司會有兩個漏斗，我稱之爲社區漏斗和商業漏斗。有些說法認爲社區漏斗是商業漏斗的上層，我之前也深以爲然，但經過幾年的實踐，我漸漸發現其實並不是那樣。這兩者是獨立的，如果只是簡單地作爲一個漏斗，那麼就會有很多問題，比如經典問題：不會流到商業漏斗的社區用戶，其價值到底是什麼？所以，肯定不是一個漏斗，而是有很深的內部聯繫。
什麼聯繫？爲方便理解，還是用種菜舉例說明。開源社區孵化出來的東西，例如用戶成功案例、社區貢獻對產品的打磨、探索出來的適用場景等，就像一個個生的菜和食材，而客戶想要一盤魚香肉絲，並不關心盤子中的肉和菜是怎麼來的，所以看到關鍵點了嗎？商業化團隊的角色就像是廚師，社區運營團隊就像農民，二者的關注點並不一樣，廚師關注點是如何做好菜，農民的關注點是如何種好地，產生更好的食材。從食材到一道菜，還要經歷很長的過程，但沒有好食材，能力再強的廚師也難做出一盤好菜。
對於開源軟件公司來說，社區和商業這兩個團隊的內部一致性是：好產品和制勝場景。根據我們的實踐經驗，比較好的做法是，社區團隊聚焦於兩個關鍵點：
- 社區用戶對於產品的打磨（在制勝場景下）；
- 發現更多的制勝場景。
這兩個關鍵點會形成閉環，社區團隊持續產生食材（制勝場景以及持續進化的產品），商業團隊聚焦於制勝場景的進一步加工和客戶旅程優化，兩個團隊互相配合拉動整個公司和項目的大循環。例如TiDB商業用戶的場景和解決方案，大多是從社區用戶中誕生並打磨成熟，儘管可能兩個用戶羣體完全不一樣，但是通過 TiDB 形成了一個大的生態——商業化的循環，而PingCAP 就是中間的橋樑。另外，社區和商業化團隊會有一個共同的北極星指標：用戶體驗。
可規模化變現的唯一出路：雲
一個好的生意應該是可以規模化的，傳統開源軟件公司的商業模式，問題在於規模化中需要人的介入，銷售/售前/售後交付等等，而基於人的生意是沒法規模化的。在雲誕生前這個問題是無解的，所以開源軟件公司需要尋找一個和開源無關的軟件商業模式（聽起來有點彆扭，但是仔細想想確實如此），而云本質上是一個資源租賃生意。
還是以種菜的例子來說，過去傳統的商業模式中，因爲土地和種菜人都是客戶自己的，所以開源軟件公司的位置就比較尷尬，但是在雲上，基礎軟件商業模式本質上是一個hosting服務，讓原來價值鏈條中最重要的一部分“土地”（ hosting資源和基礎設施）掌握在了廠商手上，這對於用戶來說也是好的，畢竟管理“土地”也是一件費心費力的事情，而且很難做到按需購買。問題在於用戶想要的只是一道好菜而已，注意這和開源（種菜）並沒有什麼關係，因爲不管開不開源，用戶支付的都是管理和租賃費用，相當於即使種子和食材免費，顧客去飯店喫飯，也需要爲菜品買單，因爲顧客購買的是好菜和服務體驗。
另外，很多人認爲開源社區是競爭壁壘，其實並不是，真正的壁壘是生態，而開源社區是構建生態的一種高效方式，如果一個產品不用開源也構建起了生態，那麼效果是一樣的。一個很好的例子就是 Snowflake，儘管 Snowflake 沒有開源，但是2012年誕生伊始，它在雲數據倉庫這個市場內幾乎沒有任何競爭對手，留給 Snowflake 足夠的時間通過差異化定位和極佳的用戶體驗構建自己的生態，依託雲的崛起和規模化效應取得了巨大成功。
如何做好社區
上文形而上地討論了很多關於哲學的內容，接下來聊聊落地實踐。想要做好開源社區其實是有方法論的，但前提是有正確的思考方式和思考角度，否則在實踐環節你就會發現有無數事情可以做，卻不知道哪件或哪些事情是更重要的，更難受的是你發現沒法衡量對與錯。以下是我的一些思考角度以及思考時考慮的重點指標，可作爲社區運營者的參考。
你是誰？你解決了什麼問題？爲什麼是你？
好社區的根基一定是好產品，要回答“你是誰”這個問題，一定是通過回答“你解決了什麼問題”而得出的，這點和 to C 產品的運營很不一樣。一些社區運營者會將注意力轉移到各種活動或者宣傳拉新，同時誇大產品能力，導致與現實不符，這是最常見的誤區。
很多做社區運營的朋友經常來找我：我也做了很多活動，寫了很多文章，爲什麼看起來沒有效果？通常這個時候我會問他：你能一句話說明白你的產品是做什麼的嗎？到底解決了什麼問題？這個問題是普遍問題嗎？非你這個產品不可嗎？這個時候他就明白：完美的產品是不存在的，好的產品一定是跟隨它的優勢場景出現的，比如 Redis 顯然不能用來做核心金融交易場景，但誰都不會否認Redis在緩存場景下是當之無愧的事實標準。同樣的例子還有很多，例如 Spark、ClickHouse 等等。所以對於運營團隊，在做任何動作之前要想清楚上面的四個問題。
好用決定了漏斗的轉化率
找到制勝場景就夠了嗎？當然不是，如果把整個用戶旅程當成一個漏斗，找到制勝場景充其量是找到正確的入口而已，進入漏斗以後，重要的事情就變成了提升各階段的轉化率，決定轉化率的一個關鍵指標是產品的易用性，這點和做 to C 產品很像，很多做 to B 的團隊會下意識忽略這一點，通常可能是兩種原因：
- 不太重視社區用戶 Self-service ，項目官方甚至鼓勵用戶聯繫官方團隊，因爲早期知道有人在用這個信息是很重要的，而商業客戶基本服務和支持都是官方的，客戶無感，對公司而言沒有動力優化。
- 很多產品在誕生初期是救命型的產品，用戶沒有別的選擇。例如早期的 TiDB ，在 MySQL 擴展需求迫在眉睫的時候，用戶更關心如何立即把問題解決掉，內核能力更重要，其他的可以先緩緩，忍着就好。
這兩種原因導致的結果就是，對易用性和用戶體驗關注不足，這個錯誤在市場競爭初期是很隱蔽的。一方面因爲流進漏斗的 leads 數量不夠大，人肉支持尚可，且市場的競爭還不激烈，用戶沒有其他選擇。試想一下，當這個市場終有一天變得成熟，大量客戶被充分教育後流入漏斗，團隊的支持帶寬肯定是不足的；另一方面，因爲市場已經被教育成熟，一定會有競爭對手能做類似的事情，這時，當你不是市場中唯一的救命選擇，用戶一定會選擇用着順手且省心的一方，這不難理解。這就是爲什麼在開源軟件競爭的中後期，易用性和用戶體驗要放在至高位置的原因。對於“用着省心”，假設已經通過成熟的生態和案例背書解決了，而在“用着順手”這一點上，中國誕生的開源軟件團隊相比世界先進水平而言，差距很大，畢竟海外的開源軟件競爭比國內更加激烈，因爲國外開源市場誕生時間長，而且業務場景對於基礎軟件的需求也沒有國內極端，通常好幾個產品都能搞定同一個場景，那麼這時當然就要比拼易用性（省心）和生態（放心）。
有幾個問題，作爲開源項目的產品負責人可以問問自己，在你的產品領域裏，如何定義好用？最佳實踐是什麼？世界上最好用的同類水平是怎麼樣的？我相信思考這些問題對產品發展會有幫助。一個反映易用性的好視角是：用戶能夠 Self-servicing 的程度，其指標體系較多：比如在雲上自助完整整個產品生命週期的比例，在開源社區從接觸到使用過程中不用提問的比例，開源社區活躍貢獻者數量等等。
二次傳播是達成網絡效應的關鍵
上文提到過，網絡效應產生的前提是，任何一個新用戶的使用對於老用戶是有價值加成的，所以試想：如果一個社區用戶默默地使用了軟件，默默地看了文檔和最佳實踐文章，甚至出了 bug 自己默默地修好（不貢獻回來），這對這個社區和產品是有價值的嗎？
我認爲是沒有的。
儘管我知道一定會有這樣的用戶存在，就像沉默的大多數人一樣。對於社區運營者來說，最關鍵的任務不是讓沉默者更多或更深度地使用，而是讓他們和網絡中的其他用戶建立更多的連接，例如分享經驗（寫案例文章）、培養貢獻者、積極向社區反饋使用中的問題等等，而且一定要將這些內容傳遞到網絡的其他節點，確保產生價值。例如：一個用戶的使用場景幫到了另一個用戶選型，一個用戶反饋幫助產品發現了一個 bug 並修復，這些都是產生價值的例子。切忌讓用戶變成一個個孤島，社區運營者如果看不清這個關鍵點，可能會陷入爲了數字（使用量）而追求數字的情況，做了很多工作，但從全局看不到進步。
網絡效應的轉移
社區運營的最高境界是將網絡效應從使用者的網絡效應轉移到基於信仰的網絡效應，將社區中心從開源公司內部轉移到外部以獲得更大的勢能。這兩者都不容易，對於前者可能更多的是抽象和總結提煉理念以及持續保持長遠而正確的 insight（洞察），加之尋找合適的佈道者羣體，這點並不容易。對於後者來說，只要在以公司爲中心的階段積累足夠多的成功案例和優勢場景，並且投入資源教育市場，剩下的交給時間就好，這個階段關注的指標是品牌力。開源軟件社區運營是一個指數曲線的遊戲，要抱着長期主義的心態去耕耘。
最後作爲結尾，我想談談，一個偉大的開源基礎軟件產品應該是什麼樣的？
我眼中一個偉大的基礎軟件產品不僅僅是解決眼下的具體問題，而是開啓一片新的天地，一個新的視角，創造新的可能性。就像智能手機的發明，它作爲平臺催生出了微信這樣的偉大應用，開啓了一個全新的世界。就像雲、S3 和 EBS 的發明，給開發者提供了新的設計方式，催生出了Snowflake這類的新物種，徹底改變了人們使用分析數據的方式。而開源社區正是這類偉大基礎軟件誕生的最合適的土壤，就像魚和水一樣。
我不知道社區會帶來什麼，我也不敢高估自己能力，畢竟在羣體智慧面前，個人的力量永遠是渺小的。