實錄 | 黃東旭：開源與基礎軟件創業在中國

10 月 23 日，EGO 北京分會會員、PingCAP 聯合創始人兼 CTO 黃東旭做爲 EGO 線上分享第二季嘉賓，與超過 400 位 EGO 會員交流了本身在開源軟件和創業方面的感悟。本文爲根據口述內容整理的實錄。

口述｜黃東旭

整理｜趙新龍

爲何要作開源和基礎軟件

我是黃東旭，PingCAP 聯合創始人和 CTO 。今天恰好回想起來，我擁有第一臺電腦是在 1997 年的，到今年 2017 年，我編程恰好 20 年。並且今天也是 TiDB 1.0 正式版發佈的日子，在這個日子分享，我以爲蠻有記念意義的。

我是一個基礎軟件工程師，一直在作分佈式系統和數據庫相關的研發，以前我在豌豆莢期間完成了一個使用比較廣的開源分佈式緩存方案 Codis ，不少朋友以前也是經過 Codis 認識個人。

緣起

我最先是在豌豆莢基礎軟件團隊維護 MySQL 集羣時有了這個想法。當時豌豆莢的總體技術架構比較樸素，上層用 Codis 支撐分佈式緩存，底層數據庫是 MySQL 和一部分 HBase 。當時 MySQL 大概有 16 個分片，就是最傳統的分庫分表。當時豌豆莢尚未全職 MySQL DBA ，維護 MySQL 就由咱們基礎架構團隊負責。

當時咱們很是痛苦，每一次數據庫擴容和調整都感受要掉一層皮。主生產庫不能容忍停機，同時每個分片有本身的儲備，擴容一次不只要把主節點拆分，還同時要在業務層上作拆分；並且在業務層有不少的工做，好比說語句的全部請求必須帶着 Sharding Key ，不能作 Cross-shard 的事務或者稍微複雜的查詢。當時你們很但願有辦法解決這些問題。

我跟另外一個合夥人劉奇，如今是 PingCAP CEO ，都在豌豆莢的基礎架構團隊，當時就想作一個 MySQL 中間件解決這個問題。這有點像 MySQL Proxy 了。咱們作了一段時間，發現作出來既沒有太多的創新，也不會完全解決問題，當時幹得還挺不開心。

那段時間咱們看到了 Google Spanner 的論文，以爲將來的數據庫應該是這樣的。咱們但願可以有這樣的東西，解放後端程序員，解決關係型數據庫在面對海量數據高併發時的擴展性問題。

而後咱們就開始作這個數據庫。

蹣跚學步

咱們從第一天就堅決地要走開源路線。咱們研究了國外有名的開源項目是如何發展起來的，包括 MongoDB 、Kafka 、Spark ，同時咱們在 Codis 項目上也積累了一些國內社區運營經驗。

公司頭三個月都是三五我的的狀態，早期員工都是咱們三個創始人的前同事和朋友，沒有依賴獵頭，也沒有依賴第三方的中介。早期咱們的目標很是簡單，就是寫代碼。整個階段大概持續半年，咱們開源了第一個 TiDB 版本。

提及來很是好玩，第一個 TiDB 的版本是不能存數據的，只開源了 MySQL 協議處理層跟一個簡單的 SQL 優化器，數據只能存儲在本地，並非一個真正的分佈式的數據庫。固然了，如今咱們已是完整的分佈式數據庫。

我以爲作開源就是這樣，不是一會兒把全部東西作好，而是一步一步讓開發者社區看到進展，這一點很是重要。因此當時咱們就決定在第一個能夠 run 的版本就把整個代碼開源，看看社區有什麼反饋，在社區發發聲音，同時開始組織線下的一些技術 meetup 彙集人氣。

經過持續的分享，咱們逐漸在社區積累了外部貢獻者，也有了幾個試用的客戶，好比當時華爲的一個團隊對項目很是感興趣，也投入工程師參與開發。咱們慢慢積累了社區影響力，2016 年末完成 500 萬美金 A 輪融資。這時候，距離公司成立一年多，公司逐漸變得比較正規，再也不是「軟件做坊」。

小步快跑

1. 輪完成以後，咱們加快人員結構調整，開始擴大工程師團隊。開源有個好處就是，好的項目會讓不少人快速知道，在社區有影響力，不少能力不錯也一直在貢獻代碼的工程師對項目很是感興趣，他們自己是咱們公司很好的人才儲備。

咱們從社區裏「招安」了一些優秀工程師，吸納到 PingCAP 開發團隊。最開始的 10 我的持續了一年左右，從 10 個工程師到 50 個工程師也用了差很少一年，這段時間正好是項目從比較粗糙變得完整精緻的轉折點。到如今，每一個核心組件有 10 到 15 人團隊負責，他們自己是社區貢獻者，同時是 PingCAP 員工，全職工做就是提交代碼、在社區討論、跟社區協做制定將來的開發計劃。另外有大概差很少 20 人的工程師團隊主要作商業產品、商業化周邊工具等。

咱們在 2016 年 12 月發佈了 RC1 版本，今天（ 2017 年 10 月 16 日）正式發佈了 TiDB 1.0 版。如今也基本完成了美國的分公司的事情。

爲何要出海？

在中國，你們會遇到 MySQL 的擴展性問題，在美國也會遇到。因此這兩個市場對於基礎軟件公司來講，不會像 C 端產品公司那樣難以複製或者難以進軍海外。基礎軟件領域是沒有國界限制的，這是咱們的優點。

開源項目怎麼運營

在過去很長一段時間理，中國都沒有在世界範圍內的特別成功的開源項目。

我以爲這是有緣由的。不少早期知名的開源項目，好比 Linux 、MySQL ，都是國外草根開發者出於我的興趣而投入大量時間和精力作出來的；運轉過程當中，開發者重度參與開源項目，也都是自發和出於興趣。我稱之爲開源 1.0 。

這種模式不適合中國國情。在國外，整個社會是相似於 community 爲主的文化，開源社區裏的協做模式跟現實生活很是像。而中國是沒有相似的文化背景的。另外一方面比較實際，國外工程師的時間挺多挺寬鬆，國內工程師和開發者很難憑興趣愛好在業餘時間重度參與很是龐大的項目。另外一方面，技術能力和語言可能也是一個問題。

最近幾年，開源社區構成有了很是大的變化。不少主流開源項目背後都有商業公司支持，甚至項目自己就是商業公司發起，好比 Spark 背後的 Databricks 、Hadoop 背後的 Hortonworks 和 Cloudera ，以及最近上市的 MongoDB 背後的 MongoDB 公司。這一類開源項目，我稱爲開源 2.0 。這時候，開源軟件的發起不是純粹的開發者我的興趣，而是有商業公司把開源做爲很好的開發模式和市場手段。

回到開源社區的運營，我以爲 OpenSource 並非簡簡單單的 Source Open ，把代碼開源出來、把代碼放到 GitHub 上就好了。

介紹一下咱們早期是怎麼作的：

• 在項目開始階段，咱們的文檔比代碼還要多。這個階段須要把項目的理念和設計詳細的展現給社區。- Day 1 開始國際化，最先的 TiDB 沒有中文文檔，全部的註釋和每個 commit 提交記錄必須是英文，全部的設計文檔都要放到 GitHub 上。早期使用者有問題會直接微信或者郵件聯繫我，我也建議他們把問題放到 GitHub。我甚至會幫早期提出 issue 的人，把中文翻譯成英文。
• 珍惜每個 contributor 。即便提交很是小的 Pull request ，可能就是改一行文檔、改一個標點符號，我都會親筆爲他寫一個明信片，還有贈送水杯或者T恤。沒多少成本投入，貢獻代碼的朋友會有榮譽感。
• 嚴格的 Code Review 流程，擺在社區面前，經過 CI 和代碼測試覆蓋率量化代碼質量。

開源項目怎麼掙錢

這個問題是我被問過無數遍的。

每個開源項目的掙錢路徑是不同的。代碼自己一毛錢都不值。一個開源項目掙不掙錢，不取決因而否開源，而是取決於項目自己面向的市場是什麼樣的、面向的人是什麼樣的、背後的商業價值是什麼樣的。舉個例子，好比 Docker 的掙錢路徑必定是跟 MongoDB 、MySQL 和 PingCAP 不同的。這很好理解，容器跟數據庫是兩個不一樣的類別，它自己的商業價值跟開源不要緊。

有了這個前提，講一下咱們認爲數據庫或者存儲資領域的商業模式是個怎麼樣的。如今主流的盈利模式大體有兩種，一種是內核開源，企業版和周邊商業工具收費，好比 Dashboard 、數據導入導出遷移工具、安全、審計、自動化部署的套件。

開源的數據庫自己是能夠隨意使用的，若是在覈心生產系統裏面用到關鍵數據庫，業務數據很是重要而你用的是社區版數據庫，這時候不少公司要不成立 DBA 團隊，要不就找商業公司購買服務。這種模式是比較傳統的賣 license ，或者賣服務的模式。這種模式的大的問題在於，基本上是一錘子買賣。我賣一批 license ，後續就只能收維護費，維護費可能跟 license 不太對等。

另一種我比較推崇的商業模式相似於訂閱。好比和雲廠商合做或者私有部署，你在雲上能夠無限制地使用個人數據庫或者開源軟件，你要爲佔用的資源付費，有點像訂閱模式 —— 我每月或者說每半年有一個 subscription 。乍看之下跟賣 license 差很少，對於創業公司來講，subscription 能保持比較健康的現金流。

咱們的相似 subscription 的模式目前不限制用戶環境下的使用規模。我已經訂閱了，那我用 1 G 和 100 T 都是同樣的價格，我能夠把盡多的數據放到你的平臺裏面。這種模式對大的用戶更加友好若是咱們的維護和支持自動化程度越高，1 G 部署和 100 T 部署區別不大，並且對咱們來講更能鍛鍊產品，對用戶來講更放心的使用，不用擔憂用超了。若是是 license 模式，業務縮減了，購買了 10 個license 卻只用着三個，對用戶來講是浪費。訂閱模式是更符合時代的、新的商業的模式。

代碼自己並不值錢，只有用戶在使用、用它解決問題的時候，你提供的服務、你提供的價值能被用戶長期承認，你的開源項目提供了什麼東西能讓用戶有黏性，這是值錢的。

中美企業服務市場的差別

你們都基本上去默認中國的企業服務市場是並不掙錢的，可是我卻是以爲這個假設可能快過期了。

我先分析一下爲何你們以爲過去中國的企業服務市場不掙錢，或者說不是一個特別好的生意。過去，中國作企業服務的廠商基本都是軟件集成商，這樣的大型 IT 經銷商的競爭力是作產品的整合和周邊開發。簡單來講，他們的商業模式是賣人，招一些工程師，快速把產品作出來知足用戶需求，算是外包模式。外包模式的問題是他難以複製，或者說很難擴展。由於每一家的需求都不太同樣。

中國沒有 Oracle 這樣的大公司，有幾個緣由。一是過去 20 年中國開發者總體水平不是過高，很難作出有核心技術競爭力的產品，另外就是過去中國不夠尊重 IT 知識產權，盜版是一個長期問題，還有就是過去你們都喜歡本身造輪子，由於中國工程師在過去很是便宜，對於公司來講，我養一個團隊、我本身去作，整個成本反而是更低的；我在外面找到軟件供應商，產品質量也良莠不齊，還可能涉及到跨公司跨項目協做的各類扯皮。

這就致使過去中國軟件行業基本上是渠道導向、銷售導向甚相當系導向的市場，並非產品導向。這樣活生生把毛利特別高的企業軟件行業變成了毛利特別低的行業。

美國商業環境比中國好，法律制度很是健全，公司都比較具備契約精神，這是第一。第二就是，銷售自己雖然重要，但核心仍是產品。在美國，多是一個很小的公司，若是你的產品確實知足客戶需求 —— POC 階段可能在客戶那邊作，測試持續時間可能會比較長，可是一旦測試經過的話，基本上事情就成了。

並且在美國，軟件預算不會跟硬件綁定，爲軟件付費的概念是在國外是比較根深蒂固的。

不過咱們觀察到在，中國在發生一些變化。第一個變化是互聯網公司有錢了。過去不少人都奉勸我，不要作互聯網公司的生意。可是我發現，如今不少 CTO 和 CIO 都會算帳，產品質量和服務都不錯的狀況下，本身造輪子的成本跟購買技術軟件提供商的成本對比一下，很明顯的購買服務是更划算的。

另外一方面，也不是一會兒能招到合適人選，況且工程師薪水也是水漲船高。第二個是，中國的人力成本慢慢向美國靠攏，這就給企業服務帶來巨大機會。美國的企業服務市場是中國的 20 倍，中間存在巨大利差。過去中國不太接受企業服務是由於人太便宜，當人力成本上升到企業主不能忽視的級別時，購買軟件服務會成爲主流。這是中國的優秀企業服務公司的好機會。

並且，PingCAP 目前的付費用戶大多數是互聯網相關行業的公司。

如何看待雲的崛起

如今中小型公司徹底上雲是大勢所趨，稱得上是「標準答案」。技術軟件公司必須順應雲的時代，雲化本身的產品。不少開源軟件做者一直認爲，公有云是開源軟件最大敵人。舉個例子，Oracle 從 MySQL 掙的錢，根本連亞馬遜從 MySQL 上掙的錢的零頭都不到。那麼 AWS 給 MySQL 貢獻了多少代碼、投入了多少工程師維護？不多不多。有人說公有云有點像吸血鬼，一邊在用開源軟件，一邊大把掙錢。

話雖然如此，可是雲化是不可逆轉的趨勢。我是堅決地相信雲，相信將來一切都是在雲上的 —— 開源也好，閉源也好，公有也好，私有也好，IT 基礎設施必定是在雲上。因此要作的就是，怎麼讓你的開源軟件來適應雲，你不能說個人軟件只能跑在個人專用機房或者個人專有硬件，必定要是雲化的，Cloud Native 的。

眼光再放稍微長遠一點，將來你們必定都把基礎設施網雲上遷移，可是真正有錢的企業和大企業不可能把本身綁定在一個雲提供商上。他必定須要在幾個公有云 Vendor 之上提供一套獨立第三方的統一的數據訪問接口，它不可能被一個雲的私有方案綁定。這就是開源軟件或者說開源公司的比較大的機會。開源軟件的優點，是獨立於雲、獨立於雲提供商的解決方案，好比說我能夠去用 AWS 的數據分析服務，可是我也能夠去用 Spark 來作分析，用 Spark 的話，我能夠平滑的遷移到 Azure 或者 GCP 上。或者，個人數據多是跨雲存儲的，一來提供了更大的靈活性，二來對雲服務提供商有了更大的議價能力。

好比摩根斯坦利沒有選擇 AWS Redshift 而是選擇了 Spark —— 若是他徹底綁定 AWS ，他之後就喪失了不少話語權，好比他想切換到 Google Cloud 就很難。因此跨雲的數據同步和跨雲的需求方面能產生不少的開源軟件，並且這是開源軟件獨有的東西。這上面能夠作不少文章。

個人觀點是，須要想辦法跟雲作好溝通或者說保持合做關係，並非說雲就是你的敵人，或者雲會把你吃掉。我以爲仍是須要合做，這種合做的態度比較重要。

Q&A

Q：你在 PingCAP 創業踩過什麼坑嗎？怎麼解決的？

我能夠分享兩個坑，一個是技術上的，一個是商業上的。

第一個是技術上的坑。咱們當時打算把 SQL 層寫出來之後直接對接 HBase ，對外發布第一個版本，投入了我本人一兩個月的精力一直再去作事情，可是後來沒有什麼效果。後來想一想，在 HBase 上去實現第一個分佈式的存儲引擎，基本是無用功。我獲得的啓示就是，開源項目一切都要維護圍繞主線目標。不少人會告訴你我須要A功能、我須要B功能，個人需求很是急迫……常常會有這樣的誘惑，並且你們很差意思拒絕，這就可能致使錯誤地投入到並無什麼收益的方向上。好在咱們看到問題後及時止損，果斷轉回主線方向。

第二個是商業上的坑。我跟劉奇（ PingCAP CEO ）都是碼農，咱們沒有在國內作商業化的經驗，也沒作過生意。當時國內很多集成商和一些比較傳統的企業來找咱們，說一塊兒合做或者搞些什麼，常常有比較虛的合做。在早期沒有判斷得特別準確，投入了一些精力。在早期階段精力是很是寶貴的。至少到如今爲止，咱們最重要的目標是技術、產品的質量和社區。好比當下能掙快錢的事情 —— 咱們之前可能會妥協，如今不會了。創業公司貴在專一和快。

Q：公司團隊異地協調一直是個難題，想問一下我們開源公司是怎麼解決的？有哪些軟件、工具或者方法？

咱們是特別典型的異地協同公司，差很少一半工程師是分佈在全球各地的。我以爲這個問題會因公司而異，PingCAP 自己的產品形態是數據庫，可能跟其餘公司會有很多區別。

文檔協做所有采用 Google Docs

遠程協做團隊的溝通成本很是高的，不可能沒件事情都 face to face 地溝通，甚至多說幾遍也無所謂。咱們的文檔協做所有采用 Google Docs ，不一樣人能夠 comment ，還能夠你們協同編輯。同時討論結果必須得轉成 Markdown 文檔放到 GitHub 上，要求一切討論都須要落地。

重度依賴 Slack

Slack 是咱們全部消息的中轉平臺，包括項目持續集成、GitHub issue 、跟社區成員的交互信息都會彙總在 Slack 。它既是咱們的聊天工具，也是公司內部的 Dashboard 。同時，咱們也在用 Trello ，用於追蹤客戶進展和作重要的會議記錄，它能夠很好地跟 Slack 作整合。

以自動化和工具化替代人工操做

咱們花了不少時間作持續集成、自動化測試和 code review 等東西。咱們如今基本上作到了，每提交一行代碼，不須要找人 code review ，不須要找人手動測試，一切環節和流程都是自動的。你提交了代碼，立刻就在 GitHub 上看到自動化構建的項目在 run ；測試成功仍是失敗，代碼覆蓋率是多少，一目瞭然。若是代碼審覈沒有經過，那麼代碼合併按鈕是沒法顯示綠色，是沒法點擊提交的。一切須要人工保證的流程，咱們儘量把它變成自動化和用工具實現的。