打造 10000 Star 的前端開源專案 ⭐
在工作學習之餘，你可能會萌生做一個開源專案的想法。一方面將自己的好程式碼分享出去幫助更多開發者，另一方面也希望在開源社群中得到反饋和成長。如果專案能獲得很多的關注那更是錦上添花，高 Star 不僅是衡量開源專案可靠程度的一個重要依據，這樣專案維護者的 Github 也能在招聘中讓公司提前瞭解候選人的開源貢獻、技術熱情和程式設計習慣等，獲得面試官的加分。
那麼，開源專案怎麼才能獲得更多的 Star 數呢？這裡通過總結我這段時間維護 Day.js 專案的過程中的一些經驗教訓，來說說如何改進和推廣你的開源專案。
瞄準使用者痛點
開源社群的內容包羅永珍，整理收藏的 Markdown 筆記、 框架全家桶的搭建、炫酷的動畫效果以及各種工具庫、框架等都是很好的開源方向，但是考慮到專案的功能、受眾、開發語言等等因素，不同型別的專案實現起來的難度和被社群接受的程度也千差萬別。但如果專案能瞄準開發者的痛點，提供優秀的解決方案，就有獲得更多關注的可能。一個人的精力始終是有限的，只有更多的人加入進來，使用、反饋、迭代和推廣，才能形成開源專案的良性迴圈。
比如我在工作中發現 Moment.js 雖然能很方便地處理日期和時間但這個庫打包體積太大了，而要想遷移到社群其他幾個輕量的時間庫又會增加新的學習成本和遷移工作量。所以開發 Day.js 的目標就是做一個和 Moment.js 一樣 API 設計，一樣功能，更加輕量的時間日期庫。
選擇開源協議
相較與專案本身的程式碼和文件等，開源協議可能是一個容易被忽視的細節。開源協議是軟體的授權許可，表述了使用者獲得你開源的程式碼後擁有的權利和義務。
我在初期推廣時就犯了個錯誤，沒意識到開源協議的重要性，也沒有給專案新增任何協議。在版權意識相對更強的英文社群宣傳時就遇到了很大的阻力和各種質疑，他們覺得這樣的專案是不專業的，也不敢去輕易嘗試，就這樣白白錯失了一部分初始使用者。
關於怎麼去選擇一個適合專案的開源協議，可以參考這個網站 Choose License。如果你希望專案可以儘可能被廣泛地推廣、使用和傳播，就可以考慮選擇一個分發自由度比較高的開源協議。
規範提交記錄
使用一個規範的 Git 提交記錄是很有必要的，這不僅讓多人開發中的參與者能更好地瞭解專案的迭代歷史和程序，也能在出現問題時快速定位，找到問題程式碼的提交記錄。同時我們還可以使用工具根據提交記錄自動生成更新說明 (CHANGELOG)，方便使用者瞭解每次更新的具體內容，也免去了專案維護者手動更新的痛苦。 目前前端社群中使用較多的 Git Commit 提交規範是 Angular 規範 (Git Commit Message Conventions
<type>(<scope>): <subject>
<body>
<footer>
複製程式碼但如果每次提交程式碼的 Commit Message 都需要我們按照上述格式來錄入的話還是一件又累又容易忘記的苦差事。推薦兩個工具來輔助我們的操作：
- 使用 commitizen 進行互動式的 Commit 填寫，如下圖所示，只需要按照提示選擇更新的 type 和填寫必要的資訊，就能自動生成符合規範的提交記錄；
- 使用 @semantic-release/changelog 來根據 Commit 中 type 自動增量生成 CHANGELOG；
語義化版本號
每個社群都有自己的版本號規範，千萬不能因為是自己的開源專案就隨心所欲地填寫版本號，不然可能會給使用者帶來不必要的麻(彩)煩(蛋)。在 NPM 生態圈中絕大部分包都是使用語義化版本號 (Semantic Versioning)，即版本號為 a.b.c 的形式，其中 a 是大版本號，b 是次版本號，c 是修訂號。
如果開源專案有按上文所述規範地提交 Commit ，就可以使用 semantic-release 來實現全自動更新版本號和釋出，這個工具會判斷 Commit Message 的不同，fix 增加修訂號，feat 增加次版本號，而包含 BREAKING CHANGE 的提交增加大版本號。
推廣和分析
酒香也怕巷子深，再精美的專案，如果作者自身沒什麼知名度，又沒有太多推廣的話，這個專案很有可能就被淹沒在眾多開源專案之中了。除了在眾所周知的國內開發社群推廣之外，希望大家也不要忽視了國外的社群和論壇。要知道雖然中文開發者數量越來越多，但也只佔到全球開發者的一部分，為了獲得更多關注，我們有必要把開源專案國際化，來幫助更多的開發者。而英語是軟體開發者們的通用語言，翻譯一份英文版的 README 就是走向國際化的第一步。
在推廣 Day.js 的過程中，我會在 Twitter 大佬們吐槽 Date 函式、 Moment.js 庫的推文下，介紹我的專案的特點，希望他們可以嘗試一下（但要有禮貌，廣告別太硬）。社群紅人的一個 Star 或一條支援的推文就能依靠社交網路快速傳播，給專案帶來巨大的流量和很高的關注度。
在每次的重大功能更新或集中推廣之後，我們要通過專案的 Pull request, Issue, Star, Download Count 等資料的變化來了解推廣效果和使用者的滿意度。前端工程師都知道，比起一堆數字，視覺化的資料圖表可以幫助我們更好地理解資料。
如 npmjs.com 展示下載量變化的折線圖，可以分析專案被使用和被依賴的情況。bestofjs.org 展示了專案 Star 數變化的日曆色塊圖，格子越深說明增量越快。下圖深色的小塊就是專案幾次比較成功的推廣，而有些推廣並沒有帶來很大的增長就需要總結經驗並改善方法了。
開始做一個開源專案並不難，要勇敢地邁出自己的第一步。但是持續維護開源專案並不是一件很容易堅持下來的事，我們需要找到自己維護專案的動力，給使用者提供必要的支援，收集使用者的反饋，不斷完善專案，進而形成一個完整的產品閉環來推動專案的不斷迭代更新。
當然能做到這些， Star 數量的多少已經不是那麼重要了，我們豐富了開源社群的內容，幫助了更多的開發者，也從開源的經歷中得到了視野的拓展，能力的提升，這才更有價值的收穫。
P.S. 如果你熱愛前端，熱愛開源，歡迎加入我們團隊，這裡有網紅開源 UI 庫 Element，承接了公司 98% 前端專案的釋出系統，比 jsdeliver 更好用的靜態資源管理平臺和更多有意思的專案等著你。請聯絡 [email protected] ，餓了麼大前端有你更精彩。