談談開源（一）

做者 申礫

源碼面前，了無祕密
---- 侯捷

前言

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

目前咱們在國內沒看到什麼特別好的文章講如何運營一個開源項目，或者是如何作一個頂級的開源項目。TiDB 這個項目從建立到如今已經有兩年多，從開發之初咱們就堅決地走開源路線，陸續開源了 TiDB、TiKV、PD 這三個核心組件，得到了普遍的關注，項目在 GitHub 的 Trending 上面也屢次登上首頁。在這兩年中，咱們在這方面積累了一些經驗和教訓，這裏和你們交流一下咱們作開源過程當中的一些感覺，以及參與開源項目（至少是指 TiDB 相關項目）的正確姿式。

什麼是開源

Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose.
---- From Wikipedia

本文討論的開源是指開源軟件，簡而言之，開源就是擁有源代碼版權的人，容許其餘人在必定許可證所述範圍內，訪問源代碼，並用於一些本身的目的。
最基本的要求就是其餘人能夠訪問源代碼，另外獲取代碼後能作什麼，就須要一個專門的許可證來規範（能夠是本身寫的，也能夠用一個別人寫好的）。裏面通常會規定諸如對修改代碼、新增代碼、後續工做是否須要開源以及專利相關的事項。
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、使用範例、接口文檔、安裝部署以及最佳實踐等等。這點也是大多數項目所忽略的。

如何參與開源項目

試用

最簡單的參與方式是試用開源項目，這也是開源最大的一個好處，全部人均可以隨時試用，至關於有不少人幫助項目做者作測試。畢竟若是隻有做者本身作測試，遇到的環境、場景、應用方式會比較單一，總有一些你想像不到的地方會出問題。因此每個測試出來的問題都很寶貴，咱們都會盡量快的評估和回覆。

報 Issue

試用過程當中你們可能會遇到各類問題，特別是文檔中沒有說起的問題，反饋問題的最佳方式是在 Github 上新建 Issue，這樣全部的人均可以看到，並且經過 Issue 來反饋咱們也會更重視一些，有人會按期掃一遍未處理的 Issue。固然，創建 Issue 以前先搜索是否和已有的 Issue 重複是個好習慣。

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

提出建議

若是對項目有什麼建議，也能夠經過新建 Issue 來反饋， 咱們通常會給出是否會支持，若是要支持的話，大概會在何時支持。

提 PR

當你使用 TiDB 遇到問題或者須要新的 Feature，而以爲本身有能力 Fix 或者是當前官方尚未精力 Fix 時，能夠嘗試本身修改代碼，解決問題。

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

若是是小的功能或者是簡單的 Bug Fix，能夠在相關的 Issue 下面吼一聲，讓你們知道你在作這個事情便可，這樣不會有人作重複的工做。若是作的過程當中遇到了什麼問題，也能夠在相關的 Issue 中和 Maintainer 討論。

若是要作的是比較大的功能，那麼最好先和官方作一輪討論，而後寫一個儘量詳細的 Design，討論 OK 後，開始開發。

講一點好玩的事情

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

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