打造 10000 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 ,饿了么大前端有你更精彩。

相关文章
相关标签/搜索