打造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 )，Commit的格式包含Header、Body、Footer三個部分：
<type>(<scope>): <subject> <body> <footer>但如果每次提交代碼的Commit Message 都需要我們按照上述格式來錄入的話還是一件又累又容易忘記的苦差事。推薦兩個工具來輔助我們的操作：
- 使用commitizen進行交互式的Commit填寫，如下圖所示，只需要按照提示選擇更新的type和填寫必要的訊息，就能自動生成符合規範的提交記錄；
- 使用@semantic-release/changelog來根據Commit中type自動增量生成CHANGELOG；
語義化版本號
每個社區都有自己的版本號規範，千萬不能因為是自己的開源項目就隨心所欲地填寫版本號，不然可能會給使用者帶來不必要的麻(彩)煩(蛋)。在NPM生態圈中絕大部分包都是使用語義化版本號( Semantic Versioning )，即版本號為abc的形式，其中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 數量的多少已經不是那麼重要了，我們豐富了開源社區的內容，幫助了更多的開發者，也從開源的經歷中得到了視野的拓展，能力的提升，這才更有價值的收穫。
PS 如果你熱愛前端，熱愛開源，歡迎加入我們團隊，這裡有網紅開源UI 庫Element，承接了公司98% 前端項目的發布系統，比jsdelivr 更好用的靜態資源管理平台和更多有意思的項目等著你。請聯繫[email protected] ，大前端有你更精彩。
