萬事開頭難，我們經過長期的策划和籌備，終於推出了 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 地址：https://github.com/iamkun/tower_game。
一開始走上開源這條路，正如上面說的有了 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(https://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 公眾號 第一時間收到更新。
還有更多開源項目的介紹和寶藏項目等待你的發現。