在工作学习之余，你可能会萌生做一个开源项目的想法。一方面将自己的好代码分享出去帮助更多开发者，另一方面也希望在开源社区中得到反馈和成长。如果项目能获得很多的关注那更是锦上添花，高 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)，即版本号为 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] ，饿了么大前端有你更精彩。