前言

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

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

[[205052]]

什么是開源

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

為什么要開源

很多人覺得代碼是一個(gè)軟件公司最寶貴的資產(chǎn)，把這些最寶貴的資產(chǎn)讓別人免費(fèi)獲取，對(duì)你們有什么好處?如果對(duì)手拿走了你們的代碼，另起爐灶和你們競(jìng)爭(zhēng)怎么辦?或者是用戶直接獲取源代碼，用于自己的環(huán)境中，那你們?nèi)绾问斟X呢? 對(duì)一個(gè)技術(shù)型公司來說，最寶貴的資產(chǎn)其實(shí)是人，對(duì)一個(gè)開源項(xiàng)目來說，最核心的資產(chǎn)是一個(gè)活躍的開源社區(qū)以及他人對(duì)這個(gè)項(xiàng)目的認(rèn)可。 我們從這兩方面來看一下開源在這兩方面的影響。

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

所以我們認(rèn)為開源是基礎(chǔ)軟件的大趨勢(shì)，無論是 Hadoop、MySQL、Spark 這樣的知名產(chǎn)品，或者是 Linux 基金會(huì)、Apache 基金會(huì)、CNCF 基金會(huì)這樣的巨頭，都證明了這個(gè)觀點(diǎn)。國內(nèi)目前大公司比較熱門的開源項(xiàng)目，也都集中在基礎(chǔ)軟件領(lǐng)域，比如百度的 Brpc、Palo、Tera，以及騰訊的 PaxosStore。

PingCAP 開源了哪些項(xiàng)目

這里簡(jiǎn)單講一下我們開源的幾個(gè) Repo 都是做什么：

• TiDB：數(shù)據(jù)庫的 SQL 層
• TiKV：數(shù)據(jù)庫的分布式存儲(chǔ)引擎
• PD：集群的管理節(jié)點(diǎn)
• Docs：項(xiàng)目的英文文檔
• Docs-cn：項(xiàng)目的中文文檔

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

開源模式下的開發(fā)流程

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

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

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

9:30 到達(dá)公司，開始干活。

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

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

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

13:30 小睡一會(huì)

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

15:30 參與同事的設(shè)計(jì)評(píng)審會(huì)議，通過視頻會(huì)議系統(tǒng)和遠(yuǎn)程的同事一起討論設(shè)計(jì)方案，拍板后開干

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

18:00 大部分同事已經(jīng)去吃飯了，我準(zhǔn)備開車回家吃飯去

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

22:30 休息一會(huì)，準(zhǔn)備洗澡睡覺

如何做一個(gè)開源項(xiàng)目

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

協(xié)議選定之后，再選擇一個(gè)代碼托管平臺(tái)，目前的標(biāo)準(zhǔn)選擇是 GitHub，注冊(cè)一個(gè) GitHub 賬號(hào)，申請(qǐng)一個(gè) Orgnization 之后，就可以開始用了，如果不需要私有 Repo 的話，那么不需要交任何費(fèi)用。

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

后續(xù)的開發(fā)都需要通過 Pull Request 進(jìn)行，***不要直接 Push Master。一個(gè)嚴(yán)肅的項(xiàng)目需要把 Master 加入 Protected Branch，禁止直接 Push。

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

如果有人試用項(xiàng)目時(shí)發(fā)現(xiàn)一些問題，會(huì)通過 Issue 反饋，所以需要關(guān)注 Issue ，盡快給予回復(fù)。另外將 Issue 通過 Label 分門別類是一個(gè)好的實(shí)踐，便于大家快速搜索、分類 Issue。比如我們會(huì)將一部分簡(jiǎn)單些的 Issue 標(biāo)記為 Help Wanted，如果有新加入社區(qū)的同學(xué)想要開始貢獻(xiàn)代碼，那么這些 Issue 就是不錯(cuò)的起點(diǎn)。

當(dāng)參與的人越來越多，那么會(huì)有一部分人開始貢獻(xiàn)代碼，Maintainer 需要 Review 其他人的 PR，保證能項(xiàng)目自身的代碼質(zhì)量要求、編碼風(fēng)格一致。

***一點(diǎn)，一個(gè)好的項(xiàng)目需要配備完善的文檔，幫助大家使用項(xiàng)目。包括架構(gòu)、簡(jiǎn)要介紹、詳細(xì)介紹、FAQ、使用范例、接口文檔、安裝部署以及***實(shí)踐等等。這點(diǎn)也是大多數(shù)項(xiàng)目所忽略的。

如何參與開源項(xiàng)目

1. 試用

最簡(jiǎn)單的參與方式是試用開源項(xiàng)目，這也是開源***的一個(gè)好處，所有人都可以隨時(shí)試用，相當(dāng)于有很多人幫助項(xiàng)目作者做測(cè)試。畢竟如果只有作者自己做測(cè)試，遇到的環(huán)境、場(chǎng)景、應(yīng)用方式會(huì)比較單一，總有一些你想像不到的地方會(huì)出問題。所以每一個(gè)測(cè)試出來的問題都很寶貴，我們都會(huì)盡可能快的評(píng)估和回復(fù)。

2. 報(bào) Issue

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

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

3. 提出建議

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

4. 提 PR

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

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

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

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

講一點(diǎn)好玩的事情

在開源項(xiàng)目中總能或多或少的發(fā)現(xiàn)奇葩的 Issue，比如這個(gè)

看到這個(gè) Issue 真的是震驚了。

【本文是51CTO專欄作者“PingCAP”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)聯(lián)系作者本人獲取授權(quán)】

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