近 20k Star的項目說不做就不做了，但總結的內容值得借鑒

最近在社區(qū)看到一個讓人驚訝的消息，近20k Star的構建工具庫 Snowpack的作者 Fred K.Schott^[1] （文中簡稱Fred）表示已經(jīng)沒有精力去維護snowpack了，其使用量和下載量都開始呈現(xiàn)下降的趨勢。Fred也借此回顧了Snowpack的一生，反思、總結，并且借助這些經(jīng)驗投身到另外一個新項目Astro^[2]中，而Sonwpack打算交給社區(qū)維護。這 ... 作者是說不做就不做了嗎？

翻譯：講真的，我不確定Snowpack之后會怎么樣。去年年底，維護snowpack勞累過度，現(xiàn)在已經(jīng)沒有精力去維護了。Snowpack的使用量和下載量開始呈下降趨勢，社區(qū)也已經(jīng)變得平靜。

所以可能把事情放慢一點是有意義的。我們想問一下我們的社區(qū)是否有人愿意參與長期維護。但是新的貢獻者上手維護還需要一些時間，而且我們似乎還找不到....

說真的，有點可惜，但也沒辦法，開源本身就不容易。不過Snowpack也做的不錯了，想想在基于webpack構建的大型項目下，項目啟動時間夸張點甚至能過100s，更新的速度也不及時，而當瀏覽器支持了 ESM import 模塊加載后，我們就不需要在構建時處理模塊（包括node_modules）之間的關系了，所有的模塊化加載都交給瀏覽器，實現(xiàn)了原生的tree-shaking，同時項目中單文件的修改也可以做到單文件的reload，這開發(fā)構建的效率肉眼可見的up up up！Snowpack算是比較優(yōu)秀的bundleless實現(xiàn)方案之一了！

回到正題！一起來了解、學習一下Fred做Snowpack開源庫的經(jīng)驗總結吧！

做開源的成功經(jīng)驗

Snowpack也算是一個比較成功的開源庫了，從用戶量、下載量、Star三個維度都能體現(xiàn)出來，畢竟100w+的下載量和近20k的Star也不是隨隨便便就能做到的，F(xiàn)red也總結了他做到這種地步的成功經(jīng)驗，希望能幫助到大家！

1. 痛點驅動，明確方向

Snowpack最初是Fred在Google 的 Polymer 團隊工作中做出來一個用于替代 HTML imports^[3] 規(guī)范的構建工具，后來引申出 「為什么npm包在瀏覽器運行都需要借助webpack打包，而不能單獨運行在瀏覽器呢？」 的問題，于是Fred就針對 「npm包單獨運行在瀏覽器」 的可行性開始不斷的嘗試，這就有了之后的Snowpack

所以這個庫就是始于Fred對于現(xiàn)狀的質疑、思考，這個可以讓他明確庫的方向，也能知道后續(xù)需要做什么！如果一個開源作者莫名其妙就創(chuàng)建了個庫，對于這個庫也沒有明確的作用方向，那長期下來，及時開源了，使用者或者開發(fā)者都是懵逼的，這個庫注定也走不遠！

2. 快速行動，做事果斷

在明確了一個庫的大方向后，就要開始不斷完善大大小小的功能，在這過程中你根本不知道哪些代碼、哪些功能是重要的，它們會不會在以后被廢棄。基于這一點，在項目初期就沒必要顧慮太多，有想法直接做就完事了，即使你寫的功能在之后會被刪掉，即使你寫的代碼結構有些混亂，這都沒問題，大不了后續(xù)完善！（據(jù)說Snowpack最初根本沒啥代碼結構，全程都是一個index.js梭哈）

而且Snowpack的最初的核心目標并不是打包業(yè)務代碼，而是直接使用瀏覽器原生的 ES Module 能力，因此Fred就基于rollup進行了一層封裝，將用到庫生成對應的ESM模塊的文件，并將import路徑替換成生成的ESM模塊文件

據(jù)說在 Sonwpack里會用Rollup 這一舉動為Fred節(jié)省了很多個星期，甚至很多個月的時間！

當然了，為了相應 快速行動 的口號，F(xiàn)red在Snowpack初期連單元測試都沒有寫，不是因為他不知道要寫單測，而是他覺得當時只處于項目的初期階段，還不確定這個項目是否有用，是否會被大家接納，再加上寫單測本身就是個很耗時的事情，要是前期在拼命完成各個功能之余還努力把單測寫好，如果到最后自己的項目沒有什么用、無法落地或者沒被大家所采納，那前期浪費的時間就很多很多了，F(xiàn)red認為這種情況是非常頭疼的，他寧愿等項目被眾多用戶使用后，再補上他所欠下的技術債！

總結一下：

• 代碼寫的爛沒事，先行動，把功能實現(xiàn)最重要，后續(xù)可以優(yōu)化代碼
• 要確定并且專注自己要做的事情
• 可以借助比較優(yōu)秀的開源庫或者工具，提升開發(fā)效率
• 前期可以先調過單測這一階段，等后期真的需要了再補寫單測

3. 快速修復bug

每個開源庫在最初期的使用階段應該多多少少都會有bug，尤其是當有人嘗試使用你發(fā)布的庫時，遇到bug后一定會給你提一個大大的issues，此時作為開源庫的作者，就應該以最快的速度去解決這個issues，畢竟人家是你項目初期為數(shù)不多的使用者啊，更何況還幫你找到了bug，如果連這一個用戶的都服務不好，更別說之后有成千上萬的開發(fā)者使用你的庫了

所以你做開源就想再做生意，最初使用你的開源庫（還未完全成熟）那批用戶就是你冷啟動時的資源，只有把它們服務好了，才有機會冷啟動成功，做到廣為人知

Babel 成功的原因之一就是夠快速修復 bug 并發(fā)布新版本。通常會在 bug 上報后的幾分鐘內就修復并發(fā)布。在早期用戶不多的時候，做到這一點至關重要。使用者會覺得這個庫的維護者效率非常高，及時他們遇到了bug，也不會抱怨這個庫bug真多而放棄使用

4. 推廣宣傳

推廣宣傳 換成一個"令人頭疼"的詞叫做 營銷，可能大家就會聯(lián)想到營銷號，其實不是讓大家去為了宣傳自己的開源庫而做一些"卑鄙"的推廣，甚至是拉踩別的庫從而抬高自己的庫哈，這種惡意的營銷會讓人很反感，及時你的庫再好，那口碑也好不到哪里去

害，真頭疼，辛辛苦苦寫了個庫，還要努力推廣，不推廣就沒人使用，甚至沒人知道！

那我們該怎么做呢？

可以先跟與身邊的朋友和同事分享，也可以讓他們給你點建議。如果你很幸運，早早的就有了試用你庫的用戶，那么他們也能給你提不少建議，甚至幫你宣傳！

如果后續(xù)你有機會跟更多的用戶分享你的項目，那么你可以通過一些很有意思的方式去向他們介紹，跟他們交流。例如給你的項目做幾個生動有趣的介紹宣傳視頻、講述一些簡短的小故事關于你和你的項目、寫一些技術博客直接或間接地介紹你的項目 等等

Fred在Snowpack有一定的用戶基礎后，花費了大量的時間寫了一篇博客，里面介紹了Snowpack誕生的原因以及他與該項目的任何東西，當時僅靠這一篇文章就爆火了，并且在后續(xù)的一年內被許多用戶分享、引用，總之就是用戶增長很快很快！！我想應該是Fred文章寫的比較走心， 能讓大家感同身受吧~

其實在國內有一個開源庫的作者在推廣上就做的比較好，他就是H5-dooring的作者徐小夕，他這幾年在推廣自己LowCode上沉淀下來的開源庫時，一直在很多社區(qū)通過寫技術文章的方式來推廣宣傳，大家看完文章既學到了LowCode平臺的技術實現(xiàn)，又知道了有這樣一個優(yōu)秀的開源庫。在另一方面，大家應該對他的信任也會更多吧，畢竟能輸出技術文章展現(xiàn)給大家，一起交流討論 ~ 這也是個良性循環(huán)

5. 傾聽用戶心聲

現(xiàn)在都支持言論自由，那你在推廣自己開源庫的過程中，一定會遇到大量的評論，例如：

• 你這個功能，xxx庫不是早就實現(xiàn)了嗎？重復造輪子有意思嗎？
• 給作者提個建議，感覺xxx功能的實現(xiàn)可以換成xxx方案，這樣比較好
• 這個庫bug真多，還不如用xxxx
• 這個功能真棒啊！希望能一直維護下去
• ....

你們看到了，好的壞的評論都有。你也有區(qū)分辨別不同反饋的能力，不要被大量的稱贊沖昏頭腦而滿足當下，也不要因一些帶有批評性質的話語而一蹶不振。被夸贊時，應該要更加激勵你把開源庫做得更好，在收到善意的建議時，也要保持謙虛的心態(tài)去接受；被批評時，你首先要反思是不是你對于自己的開源庫宣傳沒到位從而導致用戶對你的庫有誤解，是否需要重寫README.md 或 在社區(qū)再介紹一下？其次你再考慮批評你的人是否就是閑著沒事用絕對的口吻去踩你的項目（俗稱鍵盤俠），那你大可不必理會，嘗試去忽略它，花費更多精力去發(fā)現(xiàn)更具有建設性意義的評價！

總之就是要傾聽用戶的心聲，畢竟他們才是真真正正在實踐落地你開源庫的人！

做開源的錯誤總結

當然Snowpack也有做得不好的地方，不然Fred也不會沒有精力去維護它了。那么在維護這樣一個大型的開源項目時，F(xiàn)red在總結反思中又得出了什么結論呢？

1. 采用 Dogfooding 方法

Dogfooding： 用維基百科的解釋來講，Dogfooding^[4]是一種使用自己的產(chǎn)品或服務以支持內部測試的做法，其可以對產(chǎn)品的質量進行提前把控，并做到有充分的信心正式上線

簡單舉個例子，F(xiàn)acebook（文中簡稱FB）開源了React，并且其內部很多應用也是基于React開發(fā)的，如果React新增了某個特性或修復了某個bug，除了用單測進行檢驗，F(xiàn)B也可以把改動后的React應用到自己內部應用中，在真實的線上項目中驗證React功能的穩(wěn)定性，一定比只在開發(fā)環(huán)境下檢驗更全面。等到改動后的React在自己的項目應用一段時間且基本沒有任何問題后，F(xiàn)B就可以很自信地認為React的質量有很高的保障，并且開放給其它開發(fā)者使用。

Fred其實在Snowpack的維護中并沒有像FB一樣很好地把自己的開源庫大面積應用到自己內部的項目中，因此也沒辦法很好地在公開Snowpack新特性前做完善的質量保障，F(xiàn)red取而代之的做法就是在開發(fā)Snowpack新特性之前，與用戶們進行交流討論。

Fred現(xiàn)在回想起來，當初真的應該要采取 Dogfooding 方法，為自己的開源庫換取更多的全面公開前的線上功能測試與質量保障。

2. 保質保量，了解用戶

在前文Fred的成功經(jīng)驗中提到，他在項目初期時盡可能服務好最初一批Snowpack的使用者，在當時實現(xiàn)的某個功能是得到初期用戶的認同的，但隨著使用的人越來越多，大部分覺得這個功能是不好的，甚至覺得應該廢棄掉。這里就有一個用戶需求的轉變過程，所以在整個項目維護的任何一條鏈路中，你都要去了解用戶的反饋，這樣才能更好地推動項目的發(fā)展

在一個開源庫最初期，可能會有很多大大小小的bug，這都是情有可原的，畢竟剛開始，而且使用的人也不是很多，所以更不會引起成百上千的bug反饋或用戶吐槽。而隨著項目走上正軌并且越來越成熟，使用的人也就越來越多，使用者最期望的就是該庫bug更少，功能更穩(wěn)定，所以作為開源者要做到的就是提高開源庫的質量，保障最基本的用戶使用體驗！

3. 收集反饋，積極解決

不是每個人都會向你反饋問題的。設身處地想一下，假如你在用某些開源庫時遇到了問題，此時你會去百度搜索問題的解決方案，沒搜到你又會去看這個庫的官方文檔或者Github的issues有沒有類似的解答，再沒有的話，你多半就不想用這個庫了，心里可能還會默默地說一句：這庫真LJ，這么多問題，如果你稍微有點耐心，你會給他提個issue，渴望作者的回復，渴望問題得到解答，但如果遲遲得不到回應，最終的結果就是你轉頭就去找另一個能平替甚至超越它的成熟的開源庫。

據(jù)Fred所說，Svelte^[5]團隊曾在一篇博客中提到，他們對Snowpack很感興趣，這就意味著Snowpack有可能被他們團隊所使用（用戶+1），F(xiàn)red也感到很開心，但是后來Fred發(fā)現(xiàn)在SvelteKit^[6]正式發(fā)布之前，他們已經(jīng)把Snowpack換成了能實現(xiàn)同樣功能的Vite^[7]，后來了解過后得知，Svelte團隊對于Snowpack并不是很滿意，也跟我剛才舉的例子說的一樣，他們也沒有向Fred進行反饋，因為他們可能因為種種原因而沒有空沒有耐心去走這條「反饋 -> 等待解決 -> 問題被解決」完整的鏈路，此時正好有一個別的庫能滿足他們需求，而且基本也沒什么問題，那豈不是美哉？

Fred后來反思，他覺得Snowpack初期在跟用戶的交流互動上做的還是比較好的，但隨著用戶群體越來越龐大了后，跟用戶沒有很強的互動感了，自然而然會流失掉一部分用戶。Fred后來才知道，Svelte團隊在使用Snowpack時，經(jīng)常會遇到問題，但Fred收到他們的反饋時已經(jīng)為時已晚了，因為他們已經(jīng)放棄使用Snowpack了。

對此，F(xiàn)red自己也總結了一個心得：作為開源庫的創(chuàng)建者，一定要把反饋渠道做好，與用戶保持較強的交流互動。不要只等著用戶來給你反饋問題，一定還要積極主動地去收集用戶反饋并且積極快速地解決問題

4. 持續(xù)輸出，不斷完善

一個開源庫的誕生肯定都是為了解決某個問題，但問題是解決不完的，而且初版的功能一般都會比較簡單，所以開源庫要一直被維護著。而做開源本身就不是件很容易的事情，因為一旦用戶群體大了，你每天會收到無數(shù)的issues，有很多問題和bug等著你來解決，好在社區(qū)還是很友好很活躍的，經(jīng)常會有同學愿意發(fā)現(xiàn)問題并反饋提交，甚至能力不錯的同學還會提個pr貢獻一些代碼，這是開源最美好的樣子

而作為開源項目創(chuàng)建者，更應該做的就是積極主動去解決這些用戶反饋的問題，認真審核別人提交的代碼，同時自己也要思考自己項目還有哪些可以優(yōu)化提升的地方，簡而言之就是要持續(xù)地去完善開源項目，你的用戶也能從你做事的效率上看出你是個很優(yōu)秀、很負責任的人（哇！這個作者一天提交了十幾次代碼！我2個小時前提的bug這么快就修復了！效率真高！），那么對你產(chǎn)生的信任也能映射到你所做的開源項目上

聽到這里似乎開源很費時間呀！難道要放棄現(xiàn)在的工作全職做開源嗎？倒也不是！因為真正能全職做開源養(yǎng)活自己的人還是少的，大多都是兼職甚至業(yè)余去做的，兼職做開源當然也沒問題，你可以嘗試每周花幾個小時或者每月花幾天去維護一下你的開源項目，這都比你撒手不管來的要好

其實，社區(qū)的小伙伴也是能感受到你對開源項目的投入程度的（這個庫上一次提交還是半年前，而且積攢了500多個issues沒解決！不知道靠不靠譜！），你沒有嘗試持續(xù)維護，那么整個社區(qū)也會趨于平靜，這對開源來說是最大的問題，F(xiàn)red說他見過很多大型的開源項目中經(jīng)常會犯這種錯誤。你總不能只依靠社區(qū)的小伙伴給你提pr來維護開源項目吧？

5. 建立社區(qū)

這一點應該不用多說，大家都能體會到。給自己的開源項目建一個交流社區(qū)就跟商家創(chuàng)建顧客VX群一樣，它將 "商家" 與 "用戶" 交流的鏈路縮短，同時也能提供一個擁有功能目的的用戶交流討論的平臺，他們可以積極發(fā)表想法，也可以互幫互助，你也能從社區(qū)中獲得有價值的反饋

6. 人多力量大

最后這一點可能也是導致Fred沒有精力去繼續(xù)維護Snowpack最大原因之一

Snowpack的Contributors有很多，在寫這篇文章時總共有 402 位，能看得出社區(qū)的小伙伴非常活躍，都愿意幫忙一起維護這個項目，看這趨勢，Snowpack應該會做得越來越好吧？

然而Fred卻不這么認為！ 他一直想獨自來全權維護Snowpack，也不接受Larger Contributions，因為他的短期思維告訴他：他一個人做，可能效率更高（畢竟不需要多人合作，避免了很多合作上的問題）。確實！在那段時間里，F(xiàn)red輸出了非常多的東西，效率確實很高！但從長遠來看，問題只會逐漸暴露。Fred輸出大量內容是建立在 匆忙完成功能、跳過代碼檢查 的前提下的，出來混總是要還的，按照這種做法一直做下去，遲早會因為代碼質量不高、結構混亂等問題而維護成本變大的

我趕緊去看了一眼Snowpack的Larger Contributions，確實不多，算上Fred自己總共就2個！

總結一下，開源項目做大了以后，不能只靠單打獨斗，找到有興趣有能力的伙伴組成個團隊一起共建是很明智的，畢竟開源不僅僅只是寫代碼，要做的事情很多，例如：新增功能、修復bug、收集并解決用戶問題、宣傳推廣、寫官方文檔等等，最后加上團隊以及社區(qū)熱心小伙伴的幫助，一定能順利推動開源項目的進展的，如果后續(xù)開源項目盈利了，作為創(chuàng)建者你還可以定期給團隊內的小伙伴一些Money，畢竟誰都不是為愛發(fā)電~

閑談

文中提到了SvelteKit放棄使用Snowpack而選擇使用Vite，會不會有人覺得是Vite干掉了Snowpack呢？其實也不是誰干掉了誰，F(xiàn)red也在回顧Snowpack的一生中看到了自己做開源時的很多問題，只能說對于做開源這件事沒有其它大佬有經(jīng)驗吧~

再來具體聊聊Vite，可以從Vite的官方文檔^[8]中了解到，Vite借鑒了Snowpack v1的依賴預構建功能，所以從這一點來說，這兩個庫非常相似，因此社區(qū)的很多大佬們也經(jīng)常會寫這兩個庫的對比文章。Vite又是出于什么原因誕生的呢？據(jù)說尤大在使用Snowpack v1的時候發(fā)現(xiàn)這個庫對HMR沒有很好的支持，所以才搞了個Vite，并提供了基于原生ESM的HMR，同樣的，后來Snowpack v2也借鑒了Vite的這個特性進行了實現(xiàn)

Fred也非常大方地夸贊Vite做得非常好，并表示之后也會將自己的項目Astro從Snowpack遷移到Vite上

翻譯：與此同時，Vite正在飛速發(fā)展。值得稱贊的是，他們很多事情做得都非常好。比較好的是，這兩個工具非常相似，而且容易切換使用。甚至之后Astro也會嘗試從Snowpack遷移到Vite。

確實！站在Vite的角度上去回顧本文剛才提到的所有章節(jié)，Vite做得確實很不錯，開發(fā)效率、問題及bug的修復速度、推廣宣傳、完善文檔（中英都有）、持續(xù)輸出、保質保量、擴大生態(tài)等等，怪不得會被Fred夸贊~ 給尤大點個贊！

總結

看了Fred大佬的開源總結（大佬很謙虛），受益匪淺，也希望能給以后或者現(xiàn)在做開源的你們一點啟發(fā)~

文中我摻雜了很多的個人想法，把Fred總結的東西一點點融入到本文中了，想看純原文的話，我把鏈接放這了~

• https://dev.to/fredkschott/5-more-things-i-learned-building-snowpack-to-20-000-stars-5dc9

參考資料