In Community We Trust

做者簡介：黃東旭，PingCAP 聯合創始人兼 CTO

前些天在與友人喝咖啡的時候，正好聊到關於 PingCAP 和 TiDB 的一些歷史以及對於開源軟件公司核心競爭力的理解，回顧這幾年的創業生涯和 TiDB 社區的生長壯大，就像是一場巨大且正在進行中的社會學實驗，本來零散的一些想法隨着一條主線變得逐漸清晰，就想着寫成文章總結一下關於社區對於開源軟件以及開源公司到底意味着什麼。

無處不在的網絡效應

兩種網絡效應

不少人據說過網絡效應（梅特卡夫效應：網絡的價值與聯網用戶的平方數成正比），許多偉大的產品和公司經過網絡效應構建起了強大的護城河。提到網絡效應，經典例子在通訊領域，例如手機，每多一個用戶，對於全部用戶的價值就越大，雖然你們也無心爲他人創造價值，可是一旦開始使用，該行爲就會幫助這個網絡創造價值。不少咱們熟知的 to C公司，尤爲是社交網絡和IM（即時通訊軟件） ，經過這個效應構建了極高的壁壘。NfX Venture 在他們的一篇博客(https://www.nfx.com/post/network-effects-manual/）中詳細描述了不少種網絡效應，在介紹社區以前，我想着重介紹下其中和開源軟件相關的兩種網絡效應。

1. 基於從衆心理的網絡效應

這類網絡效應一般是從一些意見領袖開始，多是行業大咖，多是社交潮人，經常出如今一個新產品要去進攻一個老產品的市場時。儘管這個新產品相比市場的統治者來講不必定成熟，但它一般會帶着一些鮮明的特點或者更加前沿的理念，吸引那些對「主流」不滿或者但願突顯自身前沿視野的意見領袖的支持，形成一種「很酷的人都在用，你不用你就要被淘汰了」的感受。

這種感受會在新用戶紛紛加入時，造成從衆心理的網絡效應，可是這類網絡效應的持續時間不會太長。細想一下就能知道：若是早期意見領袖只是由於突顯「不一樣」而加入，那麼在這個社區成爲主流後，這些意見領袖就沒有理由留下，追隨這些人的粉絲可能會隨之而去。另外，對於這個新產品來講，完善程度一般不如老產品，美譽和差評會在早期同時到來。此時，若是不快速經過網絡效應打磨產品，得到更好的迭代速度，那麼，這個網絡效應是根基不牢的。一個好處在於，該效應在早期是事半功倍的。

回想 TiDB 早期的社區建設，也是由於幾個創始人在 Codis 的工做以及在國內基礎軟件圈中積累的名聲，和一些互聯網技術圈中朋友的支持，造成最先的背書。

1. 基於信仰的網絡效應

所謂「信仰」，就是基於對一個理念的承認而加入，從而造成網絡效應。這點在軟件領域也很多見，自由軟件運動和開源運動都是很好的例子。人嘛，老是要相信點什麼。這類網絡效應的護城河是極深的，並且對於產品缺陷的容忍度極高。由於信念是一個長期的念想，對於 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這類的新物種，完全改變了人們使用分析數據的方式。而開源社區正是這類偉大基礎軟件誕生的最合適的土壤，就像魚和水同樣。

我不知道社區會帶來什麼，我也不敢高估本身能力，畢竟在羣體智慧面前，我的的力量永遠是眇小的。