作為一個在中國的數據庫軟件從業者，最近被不少朋友在微信上詢問業內某廠商「團隊整合」的新聞，我其實並不想對這個事情發表什麼評論。我始終堅信：基礎軟件，未來只有開源一條路。如果不開源，或者説內核不開源的話，產品的生命力是有限的。所以，在這裏想分享一些我個人有關開源與閉源的看法，希望大家看完這篇文章後能夠有些自己的思考 :）
作為從事開源的創業者，這幾年的實踐讓我們對於 ESR 的這本書的理解更加的深入，我會試着在這篇文章總結一些我們經常被問到的問題，最後一部分我斗膽給 ESR 的理論在當今雲時代的背景下做一些修訂，另外我們討論的軟件範圍僅限於基礎軟件（數據庫，編譯器，操作系統等）。
代碼是核心競爭力嗎？
我和一些閉源軟件項目的作者聊過，大多數選擇閉源的原因不外乎以下幾種：
覺得自己的核心算法非常厲害，不希望競爭對手模仿；
擔心用户拿到代碼，就不給錢了；
沒有找到或者建立自己的護城河；
代碼太醜，不好意思開源；
怕被人找到 Bug。
其中以前三種答案居多，我非常能理解，這些回答也都是非常正當的理由，只是這篇文章我們好好的就事論事的挨個分析一下，對於第四第五個理由，其實我不想過多展開，未來有機會再聊聊，我們聊聊前兩種，先看第一種，我在後邊會聊聊第二種。
對於第一種原因，我們再深入思考一下，一般可能有下面兩種情況：
我的核心代碼很短，可能是一個很巧妙的算法，或者一套很巧妙的參數；
我的工程上的設計和實現得很優秀，系統架構是領先的。
對於第一種情況，我一直以來的觀點是：如果在同一個行業裏面，除非你達到了徹徹底底的人才壟斷，那麼在一個充分競爭的環境，如果這個問題是一個高價值問題，那麼你能想到的短短的 「核心算法」，別人也同樣能想得到。天下沒有銀彈，計算機科學就是在無數種妥協和不完美中尋找平衡的藝術（當然，圖靈獎級別的 idea 或者量子計算機這種現象級的東西另説，但是這種機會是很少見的），即使通過閉源創造出短期的壟斷優勢，但是這個平衡一定會被另一個競爭對手打破，最終也一定會出現一個優質的開源替代品全部吞掉（這個開源事實標準短期看甚至不一定是更好的）。
其實多數的產品優勢是體現在工程實現上，也就是上面的第二種，一羣優秀的工程師，在正確的設計下，構建出優質的軟件。對於這種情況，無論開源還是不開源，競爭對手都沒有辦法很好的模仿，就像一個學霸，考了一個100分的答卷，把這個答卷給一個學渣看，學渣朋友肯定也沒法馬上變成學霸，因為代碼只是結果，是什麼樣的思考和選擇得到了這個結果，這個過程是沒法開放的，所謂知其然不知其所以然，當然，就算你也很厲害，也有一批優秀工程師，短時間也做出了一個不錯的產品，但是沒關係，結局和前面提到那種情況也是一樣的：只要你是閉源的，這個問題又足夠普遍且高價值，那麼長遠來看一定會有一個開源的解決方案吞掉一切。這背後的原因其實和代碼沒有什麼關係，因為代碼在這裏其實並不是核心競爭力。關於前面提到的第三種理由，我認為是和第一種類似，作者可能認識到代碼並不一定是核心競爭力，但是沒有構建好護城河的情況下，只能選擇將代碼作為護城河。
代碼不是核心競爭力，那什麼才是？
在聊真正的核心競爭力之前，我們來聊聊閉源軟件的侷限性。
我們看看一個閉源的軟件的一生：立項的動機可能是某個公司或者個人對於一個市場機會的洞見找到了一個高價值的場景，通過開發一個軟件能夠很好的提高效率或創造價值，甚至可能就是一張來自甲方的合同，總之這個公司招募了一夥程序員，設計師，產品經理，開始項目的開發。一切順利的情況，順利的滿足了甲方的需求，甲方也很開心的付錢了，然後這個公司發現，好像這個軟件改一改（甚至不用改）也就能夠在同行業另一個客户那邊賣出去，這就太好了，感覺找到了一條致富路。可是好境不長，客户這邊的場景和需求在變化，原來的軟件可能不一定能夠滿足新的需求了，但是開發團隊就這幾桿槍，稍有不慎一個方向判斷錯誤，可能時間和機會窗口就錯過了。這就意味着，對於項目領頭人的要求就很高，要求持續能夠引領行業的方向。還有一種方式是挑選一個相對狹窄或迭代不快的領域，存活時間能夠延長一些。對於甲方也很難受，總是感覺需求的滿足慢半拍，甚至對於有些有着研發能力的甲方，因為受限於沒有源碼，就算知道如何改進，也只能乾瞪眼。
其實這個問題的本質在於：閉源軟件開發商雖然可能是技術的專家，但是並不一定是業務或者場景的專家，軟件進化的速度受限於開發團隊和產品經理自己的認知和見識的進化速度，除非開發商強大到能夠持續引領整個行業的進化方向，否則無解。
其實這個問題，教員早就給出了答案：「…凡屬正確的領導，必須是從羣眾中來，到羣眾中去。這就是説，將羣眾的意見（分散的無系統的意見）集中起來（經過研究，化為集中的系統的意見），又到羣眾中去作宣傳解釋，化為羣眾的意見，使羣眾堅持下去，見之於行動，並在羣眾行動中考驗這些意見是否正確。然後再從羣眾中集中起來，再到羣眾中堅持下去，如此無限循環，一次比一次地更正確、更生動、更豐富…」 — 《關於領導方法的若干問題 32》, 1943
要我説教員放在當代，就算是當個程序員，也能是一個大師級別的。教員的這段話，包含兩個關鍵的點，完美的解釋了開源軟件的生命力的來源，我下面的詳細講講。
第一點，開源軟件的生命力來自於場景的壟斷，而背後更本質的壟斷是人才壟斷。
為什麼強調從羣眾中來？回顧剛才我們閉源軟件的那段，其實一個關鍵的點是，軟件的初始動機雖然來自於少數人的洞見，但是持續保持洞見並不是一件容易的事情，這就是為什麼很多技術團隊或者產品團隊容易「自嗨」，一旦脱離用户，極易出現這樣的問題。閉源軟件廠商觸及用户的手段不外乎於傳統的商業宣傳和銷售，用户從感興趣到使用起來的門檻很高，實施的週期也很長，另外通常銷售會站在產品團隊和客户中間，通過一些信息不對稱來獲取超額的利潤，其中最大的信息不對稱就是封閉的源代碼本身或者定製化。這導致的問題是，相比流行的開源軟件，閉源軟件沒有辦法高效的獲取，吸收和理解更多的場景，這對於一個通用的基礎軟件產品來説通常是一個致命的問題，如果見過的場景不夠多，更沒有辦法判斷產品那些需求該做是普遍需求，哪些是偽需求堅決不做，我認為這就是做產品的「觸感」。
對於一個流行的開源軟件，本身不會有上面提到的問題：因為有足夠多的用户，那麼一定能看到足夠多的場景，也能看到足夠多的稀奇古怪的用法，這一個個用户的反饋，修過的一個個 bug，提出的一個個建議，會持續的產生類似「複利」的效果，你的軟件越強壯，見過的場景越廣，會進一步讓你接觸到更大的用户羣，幫助軟件變得更強大，如此循環。實際上開源軟件本質上是通過放棄一部分通過信息不對稱產生的潛在利潤，換取了極其高效的傳播和場景觸及效率，但是有意思的是，實際上犧牲掉的這些潛在利潤大概率也不一定真的犧牲掉，一來可能本身付費能力有限，二來可能實際上這些用户通過宣傳站台二次傳播或者代碼貢獻等方式回饋了項目本身。
在上面那個過程中還會產生一個更加厲害的效應：人才的壟斷。正所謂「事在人為」，上面提到的場景壟斷中種種的技術決策和實踐都是人來操作的。一個流行的開源軟件在變成事實標準的過程中，一定會培養出大量熟悉這個產品的工程師，用户，搖旗吶喊的粉絲，代碼貢獻者，甚至挑刺吐槽的人。傳統意義上，大家理解的開源社區只是狹義上的開發者社區，只有貢獻代碼才算參與，但是我認為只要和這個產品發生關聯的人，都算是社區的一部分，「人盡其材」才是構建開源社區的終極目標。這個優勢是會隨着時間的流逝不斷累積，這個很好理解，舉個例子：A 公司的工程師在 A 公司的工作中學習使用了 TiDB 也很好的解決了問題，然後這個工程師作為數據庫專家跳槽到了 B 公司，遇到同樣的問題時，你猜他會選什麼？
第二點，迭代，迭代，迭代，只有高速迭代才能立於不敗之地。
上面教員的話裏面有個關鍵的點，關於正向循環，也就是迭代。這個道理同樣也適用於軟件開發，軟件從來都不是靜止的，隨着市場和競爭環境的變化，你今天的競爭優勢，很可能明天就不是了。很多人都喜歡用靜態的眼光看待問題，熱衷於各種方案的橫向對比，而忽略了進化速度，在這點上，我可能更看重的是同一個產品的縱向對比，舉個例子：目前有 A, B, C三個方案，可能當下看這三個方案差距不大，也許在百分之五十之內。但是如果其中一個開源方案每次和自己半年前比都是在翻倍的提升（背後開源社區推動），但是閉源的方案的進步受限於團隊規模和資源。這時候的選擇除非是那種火燒眉毛的情況，否則一定應該選擇一個迭代速度更快，增長率更好，更代表未來的方案，這個也很好理解。這是人的思維的一個慣性，人總是傾向用線性思維去看待問題，於是對非線性增長的事物往往會習慣性的低估。
説一個更加震撼的例子，我粗略統計了一下，從 2018 到現在，也就短短一年多時間，整個 TiDB 的 SQL 層這麼一個項目發生了 30000 多次提交（ 如何掙錢？未來在雲端 剛才我們聊了很多產品哲學上的東西，我們接下來聊聊商業，以及在雲時代開源軟件的位置。讓我們回到開篇提到的那個話題：擔心用户拿到代碼，就不給錢了。這個觀點背後的一個暗示是，用户付費買的是代碼，如果有代碼，用户就沒有其他理由付錢。其實這個結論是靠不住的，客户付費買的是解決問題和創造價值，而不是代碼，如果拿到你的代碼自己折騰付出的成本大於給你的錢（如果你能如實交付價值的話），用户沒有任何理由不付錢。而且這裏的成本包括，比較明顯的成本，例如人力成本，機器成本。也包括一些經常被人忽略的成本，例如錯失市場機會的沉沒成本，業務改造遷移成本，學習成本，線上出問題沒人懂修帶來的風險成本，這些隱性的成本往往是比顯性的成本高得多的。 上面我的解釋中暗示了一點：軟件的價值取決於它解決了什麼問題，創造了什麼價值，而不是開源與否。舉個例子：一個分佈式關係性數據庫，一定比一個分佈式緩存更加有商業價值，這是由前者的應用場景，存儲的數據以及提供的能力決定的，而不是開源與否。所以這就是為什麼我們要做通用數據庫的核心原因，因為價值天花板更高。 還有一點需要強調的，開源並不是一個商業模式，而是一種更好的軟件開發和分發模式。另外，我認為商業模式和軟件本身一樣，也是需要設計的，這個設計取決於產品特性和公司的屬性，這就意味着適用於 A 產品的商業模式，不一定適用於 B，甚至同一個產品，不同的公司，可能適合的商業模式都是不一樣的。 用我很崇敬的華為公司舉個例子，華為是一個很厲害的通信設備製造商，很成功的手機終端廠商，很成功的硬件廠商。賣通信設備，賣手機，賣服務器，大家發現共性了嗎？華為很會賣硬件和盒子，巨大的商業成功帶來了很大的慣性，硬件和通訊設備的市場的特點是：各家產品本身能力差不太多（至少沒有代差），比拼的是滿足客户其他需求的能力以及低價（例如：服務，更快的響應，充分的定製化）。所以不難理解，華為軟件的思路會通過低價甚至軟件免費進入客户場景，然後通過硬件獲取利潤的商業模式。這個模式的問題在於，客户不能多，一旦戰線拉得太長，項目的預算和硬件的利潤都沒有辦法的抹平定製化軟件的研發成本和支持成本時，這個模式就會出現問題。 我認為如果想要通過軟件創造可規模化的持續利潤，需要兩個關鍵點： 生態，軟件能形成生態或者和現有生態有機整合，由生態補齊單一產品的能力，從而才能進一步能形成解決方案。 渠道，高效的分發渠道和支持渠道，這確保在用户規模化後，作為廠商的銷售和售後成本不會隨着客户的增長而增長（至少成本增長的斜率需要更緩）。 兩者缺一不可。對於第一點，開源軟件構建生態是很天然的，開發者和解決方案提供商會很自然的通過不同開源軟件的組合做到解決方案的覆蓋，這個效率是閉源定製化軟件很難跟上的，這點不贅述。 第二點，其實理想的渠道就是雲。雲標準化了硬件，標準化了計算力，甚至標準化了計算力的交付方式，尤其是公有云。一切都是標準化的好處就是可以自動化，這個對於軟件供應商來説才是真正的價值。 所以開源 雲的模式，在開源這端，完成了開發者的心智佔領和解決方案的成型，然後在雲這端完成極其高效的分發和價值傳遞。看上去很美不是嗎？理論上確實沒問題，但是一定會有朋友挑戰我説：這個模式裏面沒有你們開源軟件廠商什麼事情啊？云為什麼不自己提供開源軟件服務？這幾年沸沸揚揚的 AWS 吸血事件逼得一堆開源公司和項目改協議，就是一個例子呀。 關於這個問題，我的看法可能和主流觀點有點不一樣： Cloud is eating Open-source? No, Open-source is eating the cloud. 雲廠商就像當年的運營商一樣，佔據着和客户對接的第一位置，當然很自然的在關鍵路徑上放自家的產品。但是移動夢網和飛信的故事後來大家都看到了，拿飛信做一個例子，大家還記得作為移動的飛信，當年是沒有辦法和聯通電信的手機號碼互通的，直到後來微信的出現，終於事實上打通了各個運營商，所以市場格局就出現了很明顯的分水嶺，運營商是誰不重要，只要保證網絡通信號好就行。對於雲也是一樣，AWS 肯定不會為 GCP 提供舒服的遷移和打通方案，反過來也不可能，但是對於客户來説，這個選擇就像逼着用户選移動的飛信還是聯通的沃友一樣（我猜你可能都沒聽説過沃友吧 ），用户肯定説：不好意思，兩個都不要，我選微信。從另一方面來説，對於在雲上提供開源軟件服務這件事情，雲廠商本身的投入其實不一定有這個開源項目背後的公司多，一個很好的例子是 Databricks 是 Spark 創始團隊的公司，也是一個 100% 在 AWS 上提供 Spark 服務的公司，相比起 AWS 的官方 EMR，Databricks 完全不佔下風甚至客户和產品都勝過原生的 EMR。就像飛信的開發團隊的質量肯定沒有微信高，是一樣的。 由於開源軟件的中立性，使得開源軟件成為用户在多個雲廠商之間保持統一體驗和統一服務的幾乎唯一選項。因為開源軟件和開源服務商的存在，市場我相信會進入一個平衡：雲廠商會持續優化它擅長的東西，真正的將雲基礎能力變成水電煤一樣的規模化生意，開源軟件廠商基於雲的標準基礎設施構建服務並交付業務價值，開源軟件項目和社區由於廠商的持續持續，不斷的蓬勃發展，佔領更多用户的心智。三者形成一個價值鏈的閉環。不要着急，讓子彈飛一會兒。 洋洋灑灑寫了幾千字，聊了聊開源，最後我想用一段《大教堂與集市》書裏我很喜歡的一句話作為結尾： …Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong… …通常，那些最有突破性和最有創新力的解決方案來自於你認識到你對問題的基本觀念是錯的…