萬事開頭難，我們經過長期的策劃和籌備，終於推出了 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 公眾號 第一時間收到更新。
還有更多開源專案的介紹和寶藏專案等待你的發現。