在工作學(xué)習(xí)之余，你可能會萌生做一個開源項(xiàng)目的想法。一方面將自己的好代碼分享出去幫助更多開發(fā)者，另一方面也希望在開源社區(qū)中得到反饋和成長。如果項(xiàng)目能獲得很多的關(guān)注那更是錦上添花，高 Star 不僅是衡量開源項(xiàng)目可靠程度的一個重要依據(jù)，這樣項(xiàng)目維護(hù)者的 Github 也能在招聘中讓公司提前了解候選人的開源貢獻(xiàn)、技術(shù)熱情和編程習(xí)慣等，獲得面試官的加分。

那么，開源項(xiàng)目怎么才能獲得更多的 Star 數(shù)呢？這里通過總結(jié)我這段時間維護(hù) Day.js 項(xiàng)目的過程中的一些經(jīng)驗(yàn)教訓(xùn)，來說說如何改進(jìn)和推廣你的開源項(xiàng)目。

開源社區(qū)的內(nèi)容包羅萬象，整理收藏的 Markdown 筆記、 框架全家桶的搭建、炫酷的動畫效果以及各種工具庫、框架等都是很好的開源方向，但是考慮到項(xiàng)目的功能、受眾、開發(fā)語言等等因素，不同類型的項(xiàng)目實(shí)現(xiàn)起來的難度和被社區(qū)接受的程度也千差萬別。但如果項(xiàng)目能瞄準(zhǔn)開發(fā)者的痛點(diǎn)，提供優(yōu)秀的解決方案，就有獲得更多關(guān)注的可能。一個人的精力始終是有限的，只有更多的人加入進(jìn)來，使用、反饋、迭代和推廣，才能形成開源項(xiàng)目的良性循環(huán)。

比如我在工作中發(fā)現(xiàn) Moment.js 雖然能很方便地處理日期和時間但這個庫打包體積太大了，而要想遷移到社區(qū)其他幾個輕量的時間庫又會增加新的學(xué)習(xí)成本和遷移工作量。所以開發(fā) Day.js 的目標(biāo)就是做一個和 Moment.js 一樣 API 設(shè)計(jì)，一樣功能，更加輕量的時間日期庫。

相較與項(xiàng)目本身的代碼和文檔等，開源協(xié)議可能是一個容易被忽視的細(xì)節(jié)。開源協(xié)議是軟件的授權(quán)許可，表述了用戶獲得你開源的代碼后擁有的權(quán)利和義務(wù)。

我在初期推廣時就犯了個錯誤，沒意識到開源協(xié)議的重要性，也沒有給項(xiàng)目添加任何協(xié)議。在版權(quán)意識相對更強(qiáng)的英文社區(qū)宣傳時就遇到了很大的阻力和各種質(zhì)疑，他們覺得這樣的項(xiàng)目是不專業(yè)的，也不敢去輕易嘗試，就這樣白白錯失了一部分初始用戶。

關(guān)于怎么去選擇一個適合項(xiàng)目的開源協(xié)議，可以參考這個網(wǎng)站 Choose License。如果你希望項(xiàng)目可以盡可能被廣泛地推廣、使用和傳播，就可以考慮選擇一個分發(fā)自由度比較高的開源協(xié)議。

使用一個規(guī)范的 Git 提交記錄是很有必要的，這不僅讓多人開發(fā)中的參與者能更好地了解項(xiàng)目的迭代歷史和進(jìn)程，也能在出現(xiàn)問題時快速定位，找到問題代碼的提交記錄。同時我們還可以使用工具根據(jù)提交記錄自動生成更新說明 (CHANGELOG)，方便用戶了解每次更新的具體內(nèi)容，也免去了項(xiàng)目維護(hù)者手動更新的痛苦。
目前前端社區(qū)中使用較多的 Git Commit 提交規(guī)范是 Angular 規(guī)范 (Git Commit Message Conventions )，Commit 的格式包含 Header、Body、Footer 三個部分：

(): 

但如果每次提交代碼的 Commit Message 都需要我們按照上述格式來錄入的話還是一件又累又容易忘記的苦差事。推薦兩個工具來輔助我們的操作：

使用 commitizen 進(jìn)行交互式的 Commit 填寫，如下圖所示，只需要按照提示選擇更新的 type 和填寫必要的信息，就能自動生成符合規(guī)范的提交記錄；

使用 @semantic-release/changelog 來根據(jù) Commit 中 type 自動增量生成 CHANGELOG；

每個社區(qū)都有自己的版本號規(guī)范，千萬不能因?yàn)槭亲约旱拈_源項(xiàng)目就隨心所欲地填寫版本號，不然可能會給使用者帶來不必要的麻(彩)煩(蛋)。在 NPM 生態(tài)圈中絕大部分包都是使用語義化版本號 (Semantic Versioning)，即版本號為 a.b.c 的形式，其中 a 是大版本號，b 是次版本號，c 是修訂號。

如果開源項(xiàng)目有按上文所述規(guī)范地提交 Commit ，就可以使用 semantic-release 來實(shí)現(xiàn)全自動更新版本號和發(fā)布，這個工具會判斷 Commit Message 的不同，fix 增加修訂號，feat 增加次版本號，而包含 BREAKING CHANGE 的提交增加大版本號。

酒香也怕巷子深，再精美的項(xiàng)目，如果作者自身沒什么知名度，又沒有太多推廣的話，這個項(xiàng)目很有可能就被淹沒在眾多開源項(xiàng)目之中了。除了在眾所周知的國內(nèi)開發(fā)社區(qū)推廣之外，希望大家也不要忽視了國外的社區(qū)和論壇。要知道雖然中文開發(fā)者數(shù)量越來越多，但也只占到全球開發(fā)者的一部分，為了獲得更多關(guān)注，我們有必要把開源項(xiàng)目國際化，來幫助更多的開發(fā)者。而英語是軟件開發(fā)者們的通用語言，翻譯一份英文版的 README 就是走向國際化的第一步。

在推廣 Day.js 的過程中，我會在 Twitter 大佬們吐槽 Date 函數(shù)、 Moment.js 庫的推文下，介紹我的項(xiàng)目的特點(diǎn)，希望他們可以嘗試一下（但要有禮貌，廣告別太硬）。社區(qū)紅人的一個 Star 或一條支持的推文就能依靠社交網(wǎng)絡(luò)快速傳播，給項(xiàng)目帶來巨大的流量和很高的關(guān)注度。

在每次的重大功能更新或集中推廣之后，我們要通過項(xiàng)目的 Pull request, Issue, Star, Download Count 等數(shù)據(jù)的變化來了解推廣效果和用戶的滿意度。前端工程師都知道，比起一堆數(shù)字，可視化的數(shù)據(jù)圖表可以幫助我們更好地理解數(shù)據(jù)。

如 npmjs.com 展示下載量變化的折線圖，可以分析項(xiàng)目被使用和被依賴的情況。bestofjs.org 展示了項(xiàng)目 Star 數(shù)變化的日歷色塊圖，格子越深說明增量越快。下圖深色的小塊就是項(xiàng)目幾次比較成功的推廣，而有些推廣并沒有帶來很大的增長就需要總結(jié)經(jīng)驗(yàn)并改善方法了。

開始做一個開源項(xiàng)目并不難，要勇敢地邁出自己的第一步。但是持續(xù)維護(hù)開源項(xiàng)目并不是一件很容易堅(jiān)持下來的事，我們需要找到自己維護(hù)項(xiàng)目的動力，給用戶提供必要的支持，收集用戶的反饋，不斷完善項(xiàng)目，進(jìn)而形成一個完整的產(chǎn)品閉環(huán)來推動項(xiàng)目的不斷迭代更新。

當(dāng)然能做到這些， Star 數(shù)量的多少已經(jīng)不是那么重要了，我們豐富了開源社區(qū)的內(nèi)容，幫助了更多的開發(fā)者，也從開源的經(jīng)歷中得到了視野的拓展，能力的提升，這才更有價值的收獲。

P.S. 如果你熱愛前端，熱愛開源，歡迎加入我們團(tuán)隊(duì)，這里有網(wǎng)紅開源 UI 庫 Element，承接了公司 98% 前端項(xiàng)目的發(fā)布系統(tǒng)，比 jsdeliver 更好用的靜態(tài)資源管理平臺和更多有意思的項(xiàng)目等著你。請聯(lián)系 [email protected] ，餓了么大前端有你更精彩。