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 輪融資。這時候，距離公司成立一年多，公司逐漸變得比較正規，不再是“軟體作坊”。
小步快跑
A 輪完成之後，我們加快人員結構調整，開始擴大工程師團隊。開源有個好處就是，好的專案會讓很多人快速知道，在社群有影響力，很多能力不錯也一直在貢獻程式碼的工程師對專案非常感興趣，他們本身是我們公司很好的人才儲備。
我們從社群裡“招安”了一些優秀工程師，吸納到 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 ；測試成功還是失敗，程式碼覆蓋率是多少，一目瞭然。如果程式碼稽核沒有通過，那麼程式碼合併按鈕是無法顯示綠色，是無法點選提交的。一切需要人工保證的流程，我們儘可能把它變成自動化和用工具實現的。