前言

很多人的『開源』是一個比較時髦且有情懷的詞匯，不少公司也把開源當做 KPI 或者是技術宣傳的手段。但是在我們看來，大多數人開源做的并不好，大多數開源項目也沒有被很好的維護。比如前一段時間微博上流傳關于 Tengine 的討論，一個優秀的開源項目不止是公布源代碼就 OK 了，還需要后續大量的精力去維護，包括制定 RoadMap、開發新功能、和社區交流、推動項目在社區中的使用、對使用者提供一定程度的支持，等等。

目前我們在國內沒看到什么特別好的文章講如何運營一個開源項目，或者是如何做一個***的開源項目。TiDB 這個項目從創建到現在已經有兩年多，從開發之初我們就堅定地走開源路線，陸續開源了 TiDB、TiKV、PD 這三個核心組件，獲得了廣泛的關注，項目在 GitHub 的 Trending 上面也多次登上首頁。在這兩年中，我們在這方面積累了一些經驗和教訓，這里和大家交流一下我們做開源過程中的一些感受，以及參與開源項目(至少是指 TiDB 相關項目)的正確姿勢。

[[205052]]

什么是開源

本文討論的開源是指開源軟件，簡而言之，開源就是擁有源代碼版權的人，允許其他人在一定許可證所述范圍內，訪問源代碼，并用于一些自己的目的。 最基本的要求就是其他人可以訪問源代碼，另外獲取代碼后能做什么，就需要一個專門的許可證來規范(可以是自己寫的，也可以用一個別人寫好的)。里面一般會規定諸如對修改代碼、新增代碼、后續工作是否需要開源以及專利相關的事項。 OK，我們寫一個 main.py 里面有一行 print "Hello World!"，再和某個許可證文件一起扔到 GitHub 上，我們就有一個滿足***要求的開源項目了。

為什么要開源

很多人覺得代碼是一個軟件公司最寶貴的資產，把這些最寶貴的資產讓別人免費獲取，對你們有什么好處?如果對手拿走了你們的代碼，另起爐灶和你們競爭怎么辦?或者是用戶直接獲取源代碼，用于自己的環境中，那你們如何收錢呢? 對一個技術型公司來說，最寶貴的資產其實是人，對一個開源項目來說，最核心的資產是一個活躍的開源社區以及他人對這個項目的認可。 我們從這兩方面來看一下開源在這兩方面的影響。

• Branding 很明顯，開源是一種非常好的 PR、Branding 的手段，大多數大公司做開源也是這個目的，可以以一種成本幾乎為零的方式宣傳企業名，樹立技術型企業形象。一個知名且良好的企業形象，對于各個方面都很有好處。比如國外有一個知名的技術媒體叫 HackNews，我司的產品曾經多次登上其首頁，獲得了大量的關注。其實那幾次都不是我們自己發的帖子，而是其他人關注到我們的產品，自行做的傳播。
• 人才獲取 人才招聘***的難處就是如何鑒別這個人的能力，他是否能干活、是否是靠刷題通過了面試。如何能和這個人工作一段時間，看到他是如何完成日常工作，那么對于這個人的能力了解會更進一步。為了實現這個目的，傳統的手段是 Some How 找到和這個人共事過的人，聽取他的意見。這樣做首先要看運氣，有的時候要轉幾層關系才能找到這樣的人，并且不一定得到的是正確、真實的答案。 但是如果這個人已經給你的項目貢獻了一些代碼，并且代碼質量比較高、貢獻過程中和你的溝通很順暢，那么一方面說明這個人軟硬實例都不錯，另一方面說明這個人對你做的事情很有興趣。TiDB 有大量的正式、實習員工都是從 Contributor 中轉化來的，以至于我們擔心別把所有的人都招進來，社區沒了 :) 。
• 社區貢獻 可以這么說，如果沒有開源社區，整個互聯網都不會是現在這樣。想象一下如果沒有 Linux、MySQL、GCC、Hadoop、Lucence 這些東西，那么整個互聯網的基礎技術棧將不復存在(當然，肯定會出現另外一套東西，但是可能不會像開源的這套這么完善)。無數的開源社區貢獻者貢獻自己的力量，共同維持這樣一個互助互利的社區，支撐社會技術進步。 我們也從開源社區中獲得了很多支持，包括大家報的問題、提的建議以及來自全球一百四十多名貢獻者提交的代碼。隨著項目的發展，我相信社區貢獻代碼的比例會持續提升。
• 提升項目質量 當一個項目以開源方式運營時，代碼質量是項目的臉面，大家無論是在提交代碼的時候，還是在 Comment 別人的 PR 的時候，都會非常謹慎，因為你的一舉一動全世界都能看到，畢竟誰也不想人前露怯是吧。
• 對基礎軟件的意義 對于一個數據庫這樣的基礎軟件，最重要的就是正確性、穩定性和性能。前兩點尤其重要，要保證這兩點，一方面需要在開發和測試過程中盡可能提高質量，另一方面廣泛的使用也非常重要。只有當你的產品有足夠多的人試用，甚至用于生產環境，才可能有足夠多的問題反饋以及產品建議。開發人員能做的測試畢竟是有限的，很多場景、環境或者是業務負載是我們想象不到的。來自實際用戶的問題反饋有助于我們提升產品質量，來自用戶的建議有利于我們提升產品易用性。只有長期在生產環境中運行過的基礎軟件的，才算是合格的基礎軟件的。

所以我們認為開源是基礎軟件的大趨勢，無論是 Hadoop、MySQL、Spark 這樣的知名產品，或者是 Linux 基金會、Apache 基金會、CNCF 基金會這樣的巨頭，都證明了這個觀點。國內目前大公司比較熱門的開源項目，也都集中在基礎軟件領域，比如百度的 Brpc、Palo、Tera，以及騰訊的 PaxosStore。

PingCAP 開源了哪些項目

這里簡單講一下我們開源的幾個 Repo 都是做什么：

• TiDB：數據庫的 SQL 層
• TiKV：數據庫的分布式存儲引擎
• PD：集群的管理節點
• Docs：項目的英文文檔
• Docs-cn：項目的中文文檔

大家可以在 GitHub 上瀏覽我們的代碼，看到我們完整的開發過程。

開源模式下的開發流程

PingCAP 攻城獅小申典型的一天：

8:00 起床，先登錄 Slack 看一下昨晚定時跑的測試任務是否結果正常，然后關注一下 Slack 上各種 Channel 以及微信群、郵箱是否有什么重要的消息

9:00 洗漱完+吃完早飯，逗一會可愛的女兒(也可能是被女兒逗)，然后去上班

9:30 到達公司，開始干活。

• 打開電腦看看 GitHub 上面有什么新的 Issue
• 看看自己的 PR 有沒有被別人 Comment，如果有 Comment 的話，盡快解決;如果還沒人看的話，at 一下相關的同學，求 Review
• 看看有沒有別人的 PR 需要自己 Review，特別是 at 自己的那些 PR
• 帶上耳機開始寫點代碼
• Slack 有人 at 我，趕緊回復一下
• Slack 上我關注的 Channel 中有人在討論問題，我很感興趣，加入進去討論一會
• 同事要做一個新的 Feature，寫了設計文檔，我點進去看了一遍提了幾個 Comment

12:00 肚子可恥的餓了，呼朋喚友去吃飯，路上順便討論討論技術以及八卦

13:00 吃飯歸來，看看郵件、Slack、微信留言，處理一下緊急的事情

13:30 小睡一會

14:00 小睡結束，接一杯咖啡，開始下午的工作，鍵盤敲起來。。。。。

15:30 參與同事的設計評審會議，通過視頻會議系統和遠程的同事一起討論設計方案，拍板后開干

16:30 休息一下，然后繼續敲代碼、Review PR

18:00 大部分同事已經去吃飯了，我準備開車回家吃飯去

20:30 吃完飯，收拾完，沒什么事情，打開電腦看一會郵件、Issue、PR

22:30 休息一會，準備洗澡睡覺

如何做一個開源項目

首先你需要根據自己的訴求、商業模式等選擇一個開源協議，常見的有 GPL 、BSD、Apache 和 Mit ，這些開源協議的區別在阮一峰老師的這篇博客中解釋的很清楚了，推薦大家閱讀。

協議選定之后，再選擇一個代碼托管平臺，目前的標準選擇是 GitHub，注冊一個 GitHub 賬號，申請一個 Orgnization 之后，就可以開始用了，如果不需要私有 Repo 的話，那么不需要交任何費用。

開始代碼開發，提交***次 Commit，完成 Readme 的撰寫(一個好的 Readme 真的很重要)。

后續的開發都需要通過 Pull Request 進行，***不要直接 Push Master。一個嚴肅的項目需要把 Master 加入 Protected Branch，禁止直接 Push。

為了保證后續的代碼提交都是 Work 的，***在 GitHub 中集成至少一個 CI 服務，常用的有 TravisCI、CircleCI (最近一段時間 CircelCI 似乎總是出問題)。然后在 PR 的設置頁面上要求 PR 通過了 CI 才能合并。

如果有人試用項目時發現一些問題，會通過 Issue 反饋，所以需要關注 Issue ，盡快給予回復。另外將 Issue 通過 Label 分門別類是一個好的實踐，便于大家快速搜索、分類 Issue。比如我們會將一部分簡單些的 Issue 標記為 Help Wanted，如果有新加入社區的同學想要開始貢獻代碼，那么這些 Issue 就是不錯的起點。

當參與的人越來越多，那么會有一部分人開始貢獻代碼，Maintainer 需要 Review 其他人的 PR，保證能項目自身的代碼質量要求、編碼風格一致。

***一點，一個好的項目需要配備完善的文檔，幫助大家使用項目。包括架構、簡要介紹、詳細介紹、FAQ、使用范例、接口文檔、安裝部署以及***實踐等等。這點也是大多數項目所忽略的。

如何參與開源項目

1. 試用

最簡單的參與方式是試用開源項目，這也是開源***的一個好處，所有人都可以隨時試用，相當于有很多人幫助項目作者做測試。畢竟如果只有作者自己做測試，遇到的環境、場景、應用方式會比較單一，總有一些你想像不到的地方會出問題。所以每一個測試出來的問題都很寶貴，我們都會盡可能快的評估和回復。

2. 報 Issue

試用過程中大家可能會遇到各種問題，特別是文檔中沒有提及的問題，反饋問題的***方式是在 Github 上新建 Issue，這樣所有的人都可以看到，而且通過 Issue 來反饋我們也會更重視一些，有人會定期掃一遍未處理的 Issue。當然，建立 Issue 之前先搜索是否和已有的 Issue 重復是個好習慣。

在 Issue 中盡可能詳細的描述清楚遇到的問題，以及一個可操作的復現步驟，包括所用 Binary 的版本、部署方式、客戶端以及服務的日志、操作系統的日志(如 dmesg 的輸出)。如果不能復現，也盡可能詳細地提供 Log。這些對開發人員追蹤 Bug 會非常有用。

3. 提出建議

如果對項目有什么建議，也可以通過新建 Issue 來反饋， 我們一般會給出是否會支持，如果要支持的話，大概會在什么時候支持。

4. 提 PR

當你使用 TiDB 遇到問題或者需要新的 Feature，而覺得自己有能力 Fix 或者是當前官方還沒有精力 Fix 時，可以嘗試自己修改代碼，解決問題。

目前 TiDB 項目的 Contributor 有 140 多個，分散在全球十幾個國家。其中不乏深度參與的用戶。

如果是小的功能或者是簡單的 Bug Fix，可以在相關的 Issue 下面吼一聲，讓大家知道你在做這個事情即可，這樣不會有人做重復的工作。如果做的過程中遇到了什么問題，也可以在相關的 Issue 中和 Maintainer 討論。

如果要做的是比較大的功能，那么***先和官方做一輪討論，然后寫一個盡可能詳細 Design，討論 OK 后，開始開發。

講一點好玩的事情

在開源項目中總能或多或少的發現奇葩的 Issue，比如這個

看到這個 Issue 真的是震驚了。

【本文是51CTO專欄作者“PingCAP”的原創文章，轉載請聯系作者本人獲取授權】

戳這里，看該作者更多好文