本文首发于「HelloGitHub」公众号，搜索「HelloGitHub」点击关注解锁更多宝藏！
万事开头难，我们经过长期的策划和筹备，终于推出了 HelloGitHub 采访系列「开源项目作者的访谈」。这是一个采访个人开源项目作者的栏目，内容侧重于开源项目作者与开源的故事。
我们深知想要做好一个开源项目不是一件简单的事，同时也不止一次遇到过想做一个开源项目却不知道从何下手，那么「HelloGitHub 采访」希望通过分享优秀的个人开源项目作者的经历以及故事， 让读者了解更多开源项目背后的故事，做开源项目的乐趣、困难、挫折以及收获。
最后，也希望通过这个系列让大家认识：
优秀的开源项目背后，那个对开源充满热爱而且特别可爱的人。
HelloGitHub 访谈，第一期的嘉宾：iamkun（朱昆）
在 GitHub 上学习、成长为自己想要的样子——iamkun
iamkun
故事开始之前，我们先来认识下我们的嘉宾：
姓名：朱昆
常用 ID：iamkun（不是蔡徐坤的坤哟~)
GitHub：https://github.com/iamkun
开源项目：
- https://github.com/iamkun/dayjs
- 语言：JavaScript
- Star：34.8k
- 收录于 HelloGitHub 第 26 期
目前是阿里 Element UI（49.9k star）社区负责人
iamkun & 开源项目
Day.js
🎙️ ：说到 Day.js 我们一定会想到 Moment.js，而 Day.js 的特性之一便是 Moment.js 没有的极简和轻量，这当中是有什么故事吗？为什么在 Moment.js 盛行的 2018 年，选择开源 Day.js 呢？
昆哥：其实一开始我并没有想要做一个开源项目之类的想法，纯粹是一次公司业务需求，想把项目优化下让加载速度更快一点，然后发现整个项目中用了 Moment.js，但是我们并没有使用它的全部功能，而只是用了部分功能，所以想着能不能搞一个精简版的 Moment.js，就这样我们优化了项目之余也有了 Day.js 雏形。这里要说下 Day.js 的命名了，一个项目的名字首先要好记，本来想叫 Date.js（前端嘛命名总是带个 js，常见的就是 Node.js 了），不过有点遗憾被人抢占了，想着这个项目要和日期有关最后就叫了 Day.js。
回到上面提到的那次优化，我们业务用上“初代” Day.js 之后 js 压缩之后是原来的 1/30，也算是达成了优化的目标。
就是这样仅仅是公司的优化需求，产生了 Day.js。至于为什么是 2018 年，都只是个时机罢了，刚好业务优化需求，加上当时网上也没有好的优化方式，网上大多数的解决方案都是基于 Moment.js 去进行优化，而没有人想到去写个简化版的 Day.js（笑：大概是没有人想到重新“造个轮子”吧）。正好，公司那段时间也在鼓励开源，然后我们就想着反正都写了，对吧，那不如索性发到网上去大家一起用好了，毕竟我们在项目中用了 Day.js 确实挺好用。
当然，在完全没有推广仅开源的情况下，不出所料，Day.js 起初一个 star 都没有 :) 开源不易。
Element UI
🎙️ ：除了 Day.js 这个身份之外，iamkun（昆哥）的另外一重身份是 Element UI 社区负责人。而一提到 Element UI，一般前端同学都会问：它还在开发吗？还在维护？这里方便透露下 Element UI 目前的开发进度和版本规划吗？
昆哥：Element UI 其实一直在维护的，只是它作为进入成熟期的开源项目，不会像初期那样频繁迭代，主要是以性能优化和 bugfix 为主，毕竟 Element UI 有非常多用户在生产环境上使用它，还是以稳定为主。
在保证用户生产环境稳定之余，我们也有同步在做基于 Vue3 的 Element Plus 版本，重大的不兼容升级和新组件，新 UI 都会在 Vue3 里更新，毕竟按照现在的社区趋势，Vue3 也是大势所趋。所以，未来我们的主要开发精力会随着 Vue3 的普及，慢慢地转移到 Element Plus，当然用 Element UI 的小伙伴也不用担心，Element UI 会一直处于一个维护的状态，会有 bugfix 的 pr 合并进来，直到慢慢地所有的 Vue2 的生态迁移到 Vue3。这里我们也欢迎其他小伙伴一起来做 Element UI，简历这边有请：kunhello@outlook.com。
iamkun & 开源之路
🎙️ ：我看到你在 GitHub 上还有几个有意思的前端项目，比如：盖楼游戏等。而时间节点都很凑巧，是三年之前开始的？所以 iamkun（昆哥）你是怎么走上开源条路的呢？以及，在你看来「开源」到底是什么呢？
昆哥：为什么开源时间点都是 3 年前呢？因为在那个时候，我刚刚入门前端，有了自己的 GitHub，就想着把自己写的好玩的一些东西就会放在 GitHub 上面。
其实我开源出来的东西主要都是个人兴趣，换句话说，开源是我的一种学习方法。举个例子，我要实现一个需求，相比用现成的库，我会更喜欢自己造轮子，把里面每一个东西用最纯的 JS 写出来，这样子去更好地了解它里面的原理。当然，纯粹地去造一个干巴巴的轮子，其实是一件非常枯燥的事情，所以我一般会给它找一个场景，像上面盖楼游戏就是我开始学 Canvas 的时候写的。通过试着写一个游戏来理解 Canvas 当中的原生 API，盖楼游戏 GitHub 地址：github.com/iamkun/towe…。
一开始走上开源这条路，正如上面说的有了 GitHub 之后就想让贡献墙好看点，所有有什么稀奇古怪好玩的东西都会往 GitHub 上面放。但后来为什么越来越喜欢做开源呢？因为我发现如果你真是很用心地把你的项目推到社区，是真的会吸引来很多志同道合的人，他们会很乐意帮你把项目做得更好，也非常乐意去帮你 review 代码，去帮你完善你之前可能做的不是很好的地方。
所以说，开源其实更重要的是一个 idea，就是你想做什么，你完全不用担心自己的代码写得好不好，或者说自己的能力能不能把这样的一个东西做起来，只要你有这个 idea，只要你愿意去做，开源社区的力量就是这么的强大。
🎙️ ：做过开源项目的小伙伴都了解，一个项目获得成功，姑且以 star 数和 commit 数为衡量标准，是一件不容易的事情。搜遍全网，Day.js 在开源之后，iamkun 你并没有大张旗鼓，花很多精力在推广上面，但三年之后它成长为了一个 30k+ star，1.3k+ commit 的项目，当中是有什么黑魔法吗？
昆哥：Day.js 缘起于一次业务优化，开源之后其实很长时间里没有做推广，就只是内部在使用。我们一直觉得酒香不怕巷子深，就那样开源放在 GitHub 上，结果一个 star 增长都没有。后来我们觉得酒香也怕巷子深，就是开源项目你光做出来其实只是它的第一步，后期的推广还是非常重要的。
当然，我个人觉得 Day.js 能火起来主要是因为两点，第一点就是天下苦 Moment.js 久矣，就想上面提到的，其实在网上搜一搜，很多的人都在说 Moment.js 体积很大，而且它这种可变对象对于调试和开发非常的不友好。但是，社区的各个方案基本上都是在考虑怎么对 Moment.js 本身进行优化，比如：把这些 locale 文件都去掉，或者基于一些 Webpack 的插件去优化 Moment 本身。也可能没有人想着说我再写一个精简版的 Moment，因为这样听起来就是一个没有意义的重复造轮子的行为。
但是，社区上对于优化 Moment 也是一个很经典的话题了，大家有各种各样的尝试方案，所以我觉得 Day.js 能火起来，第一点还是因为大家都觉得 Moment 很好用，但是 Moment 也有它非常不友好的地方。
另外一点可能就是有一点点机缘巧合了， Node.js 社区有一个大神叫 TJ(github.com/tj)，这个人非常的厉害，就是我们用的 KOA、Express 这些知名框架都是他写的。在我也不知道为什么的情况下，TJ 大神给 Day.js 点了个赞，就在 Day.js 完全没有推广，完全没有什么 star 的时候，他给点了一个 star。然后，TJ 大神的这一次点赞给 Day.js 带来了几千 star，然后 Day.js 就开张了。
说个小花絮，后来我在推特上问 TJ 大神为什么那时候给我们点了个 star，他说：只是觉得 Day.js 有意思。
但是，真要说 Day.js 它能变成今天这样一个 30k 多 star 的项目，它一方面和前期的努力迭代、推广有关系，另外一方面其实我觉得更重要的是要坚持去做它、维护它。
Day.js 其实刚开源的第一年也没有那么的火，也没有特别多的关注，我真的就只是想把它开源出去、把它做得更好，当做自己的一个产品去运营、维护以及迭代它，所以慢慢坚持下来。而社区上的人，用过 Day.js 之后觉得挺好用，就会自发地帮你去推广、安利，慢慢地 Day.js 就被大家知道并且接受了。
- 机缘巧合 node 社区大神 tj 点了个 star 为项目带来了几千 star
- 天下苦 moment 久已
- 只要坚持，star 就会一天天变多，但这里涉及到一个反馈的问题
🎙️ ：无论是 Day.js 还是 Element UI 都可以说是一个前端明星项目，且用户体量不小，在维护大型的开源项目上你有什么经验可以分享吗？
昆哥：前面也提到，一个项目被人用在生产环境，第一点要保证的是产品的稳定。尤其是 Day.js 和 Element UI 这种用户体量巨大的开源项目，其实功能什么的都是次要的，最重要的是每次发版的稳定性，因为可能一个很小的失误，就会导致别人线上的项目直接就挂掉，这样就很尴尬。所以，比较重要的一点就是 semantic version，就是 Node 社区大家比较推崇的 a.b.c 这样的版本号。有不兼容的版本一定要通过版本号去区分，而不要你明明是一个不兼容的更新，但只是发了一个非常小的 patch 更新，这样对于你的用户是非常不负责任的，而且也很容易引发社区的舆情。
其次就是说，当用户量大起来了，开源项目其实就不只是你自己的项目，而是一个社区大家的项目了。所以，当你想加新功能、改功能或者移除功能的时候，最好不要直接就改代码发版本，而是去开一个 issue，和社区的同学一起好好去聊一聊、讨论一下这个东西。这样子的话，接受社区的意见可以让你的项目在社区走得更远，而不是成为你自己一个人的玩具。举个例子，像 Day.js 中各个国家本地化的模块，比如语言翻译、国家的大小年，大部分是依赖于社区中身处当地的同学，他们对这块的了解肯定比我要深。
当然，最后一点也是我觉得最重要的一点，不要想着这么大的项目可以完全靠你自己一个人做完，首先每个人的力量是有限的。其次，大家都是有本职工作的，都是利用自己的业余时间做开源。而像我 Element UI 加 Day.js 每天有超过三、四十个 issue 和 pr 需要处理，如果光靠我自己一个人，我是没有能力完全处理完的。这就要讲到开源社区的好处了，真的会有很多热心的小伙伴，他们非常乐意去帮你一起维护社区、做周边生态，去把整个项目做好。所以说，要相信社区的力量去多多发展和壮大你的社区。
再补充一条，其实不管是 Day.js 还是 Moment.js 都有一个很重要的经验，一定要靠各种各样的自动化工具，比如自动化测试、自动化的 lint，以及其他自动化流程，去尽可能过筛掉一些低质量、不合格的 pr，这样子就可以保证需要你人肉来 review 的 pr 它不会出现代码运行不起来、把你之前的逻辑改坏掉，或者说 pr 质量非常差、代码写得非常乱，诸如此类问题。一方面可以提高你整个 pr 的质量，另外一方面也可以大大地减少维护者在这个项目维护上面的时间。
- semantic version
- 重大改变先开 issue 讨论，可能自己的想法是错的
- 发展社区力量，一个人是忙不过来的
🎙️ ：一个开源项目的持续发展，除了仰仗维护者自身的努力之外，项目的 Contributor（贡献者）也是一个不可小觑的力量。Day.js 和 Element UI 都拥有过百的 Contributor，当中也不乏一些国际友人。在和 Contributor 的沟通中，有什么有意思的故事发生吗？和国内外的 Contributor 日常交流中，除了语言的不同，有什么编程、设计思维上的不同吗？
昆哥：我这里也是个小样本，根据和 Day.js 海外开发者的接触，我觉得国外的程序员比较熟悉开源的游戏规则，或者说是玩法、流程，比如，他们提个大 pr 之前会先开 issue 问问这个东西可不可以做，会 at 项目负责人或者是 maintainer：他可不可以去提这个 pr。我觉得这样做其实还挺重要的，因为如果你上来一个 pr 哗啦啦地把项目改了一大半，但又不是社区期望的方向，自然是很可惜但只能抱歉地关掉 pr，此外，也白白消耗了贡献者的开发精力和热情。
而，我接触到这些国外的程序员，感觉他们更倾向这样的一套玩法：先去跟你交流，然后再去做。
还有一个个人的感觉，也许是我的错觉，我总觉得国际友人他们的空闲时间比较多，反映出来就是他们在开源项目的不管是参与度，还是参与的深度或是频率都感觉会比我们这边（国内程序员）要多一些。简单来说，不管是贡献者，还是他们贡献的代码量，包括和你一起讨论问题、code review 的参与度，国外的程序员都比较多。一方面可能是他们的兴趣，还有一方面海外的程序员也可能确实比较闲，我觉得。
- 一部分人很熟悉开源的游戏规则，提 pr 之前会先开 issue 问问可不可以做
- 感觉上他们空闲时间更多，更愿意贡献
🎙️ ：那有统计过 Day.js 国内和海外的一个 contributor 比例吗？以及，Day.js 是如何吸引那么多海外的 contributor 呢？
昆哥：大概是 9:1，国内的不到 1/10 的这样一个比例。其实，吸引海外 contributor 算是国际化的一部分。一开始，我在做 Day.js 的时候，整个社区 issue 或者 pr 我都是要求用英文来书写，如果是中文的 issue 我一定会关掉，或者让他们改成英文的标题。因为，我期待的是既然做开源项目，大家都用英文这种 GitHub 上更通用的语言会更友好。另外一点，其实也是我觉得比较遗憾的事情，就是 Day.js 从一开始的开发到推广，其实我自己这边的渠道全都是国内的渠道，即便这样一个国内的项目又在国内的渠道推广，但目前看来，Day.js 真正参与进来开发的人大部分 9/10，或者是 8/10 都是国际友人，可能还是两边的想法不太一样。
iamkun & 前端学习和提高
🎙️ ：在进行采访之前，HG 向小伙伴们收集了下想问 iamkun（昆哥）的几个问题。由于时间问题下面只问其中的一个问题：前端技术日新月异，你在平时的工作、生活中，主要会从哪几个方面来提升自己的技术水平呢？
昆哥：我是从刚入行就注册的 GitHub 账户，并且开始对开源社区感兴趣。一直到现在，自己挺多的业余时间都是在开源社区里学习和成长。我个人是很喜欢在社区造轮子，并且分享自己的轮子来提升技术。
首先通过造轮子，一方面你可以了解一些你不熟悉的技术细节，它的底层原理是什么？另外当你把造出来的轮子分享出来，并且有人来看的时候，就形成了一个非常好的互相学习氛围。
通常社区上的同学的水平都是比你高的，所以不管他是从架构对你提出的建议，还是对于你一些不太优雅写法的纠正，包括他们给你贡献的 pr 其实都是非常好的契机让你去学习和提高自己技术。
这也就是一种比较良性的正向反馈，换句话说，既然说做开源，如果你东西做出来了，然后没有人去看，自然而然你也不会有什么动力去坚持维护下去，对吧？但是如果说，你做出来的东西，有人在用，有人给你反馈，你就会觉得我做这个东西原来还是有一点点价值，这样你就得到了一个正向反馈，你就更愿意去花精力把它做得更好。
在这样的一个过程中，其实你就学习和成长了，而且这里的学习和成长还不仅仅只限于题目中说的前端成长，更多的是让你从一个完整的产品角度去看待、规划产品。
比如说，你的产品怎么帮用户更好地解决问题。这可能就回归到了技术的本质，就是技术本质并不是说比较谁的技术好，谁的技术不好，技术它也只是一种手段去解决一个问题，让这个产品被更多的用户所接受。
最后
以上就是本次 HelloGitHub 的访谈的全部内容了，首先感谢 iamkun（昆哥）接受 HelloGitHub 的访谈，分享自己和开源的故事、经验。
在 GitHub 上造轮子分享自己的作品，坚持不断地迭代维护。然后通过开源社区的力量让它越来越好，同时你也会越来越强而且不单单是技术上的成长！
这里是 HelloGitHub 的访谈节目，每期和个人开源项目作者聊聊他们与开源的故事。如果你也想和更多的小伙伴分享你和开源的故事，那就联系我们吧。
关注 HelloGitHub 公众号 第一时间收到更新。
还有更多开源项目的介绍和宝藏项目等待你的发现。
