打造 10000 Star 的前端開源項目 ⭐

時間 2019-11-06

標籤打造 star 前端開源項目简体版

原文原文鏈接

在工做學習之餘，你可能會萌生作一個開源項目的想法。一方面將本身的好代碼分享出去幫助更多開發者，另外一方面也但願在開源社區中獲得反饋和成長。若是項目能得到不少的關注那更是錦上添花，高 Star 不只是衡量開源項目可靠程度的一個重要依據，這樣項目維護者的 Github 也能在招聘中讓公司提早了解候選人的開源貢獻、技術熱情和編程習慣等，得到面試官的加分。前端

那麼，開源項目怎麼才能得到更多的 Star 數呢？這裏經過總結我這段時間維護 Day.js 項目的過程當中的一些經驗教訓，來講說如何改進和推廣你的開源項目。git

瞄準用戶痛點

開源社區的內容一應俱全，整理收藏的 Markdown 筆記、框架全家桶的搭建、炫酷的動畫效果以及各類工具庫、框架等都是很好的開源方向，可是考慮到項目的功能、受衆、開發語言等等因素，不一樣類型的項目實現起來的難度和被社區接受的程度也千差萬別。但若是項目能瞄準開發者的痛點，提供優秀的解決方案，就有得到更多關注的可能。一我的的精力始終是有限的，只有更多的人加入進來，使用、反饋、迭代和推廣，才能造成開源項目的良性循環。github

好比我在工做中發現 Moment.js 雖然能很方便地處理日期和時間但這個庫打包體積太大了，而要想遷移到社區其餘幾個輕量的時間庫又會增長新的學習成本和遷移工做量。因此開發 Day.js 的目標就是作一個和 Moment.js 同樣 API 設計，同樣功能，更加輕量的時間日期庫。面試

選擇開源協議

相較與項目自己的代碼和文檔等，開源協議多是一個容易被忽視的細節。開源協議是軟件的受權許可，表述了用戶得到你開源的代碼後擁有的權利和義務。npm

我在初期推廣時就犯了個錯誤，沒意識到開源協議的重要性，也沒有給項目添加任何協議。在版權意識相對更強的英文社區宣傳時就遇到了很大的阻力和各類質疑，他們以爲這樣的項目是不專業的，也不敢去輕易嘗試，就這樣白白錯失了一部分初始用戶。編程

關於怎麼去選擇一個適合項目的開源協議，能夠參考這個網站 Choose License。若是你但願項目能夠儘量被普遍地推廣、使用和傳播，就能夠考慮選擇一個分發自由度比較高的開源協議。bash

規範提交記錄

使用一個規範的 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)，即版本號爲 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 更好用的靜態資源管理平臺和更多有意思的項目等着你。請聯繫 kun.zhu@ele.me ，餓了麼大前端有你更精彩。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。