共计 7683 个字符，预计需要花费 20 分钟才能阅读完成。
以下文章来源于前端印象，作者零一
最近在社区看到一个让人诧异的音讯，近 20k Star 的构建工具库 Snowpack 的作者 Fred K.Schott[1]（文中简称 Fred）示意曾经没有精力去保护 snowpack 了，其使用量和下载量都开始出现降落的趋势。Fred 也借此回顾了 Snowpack 的毕生，反思、总结，并且借助这些教训投身到另外一个新我的项目 Astro[2] 中，而 Sonwpack 打算交给社区保护。这 … 作者是说不做就不做了吗？
翻译：讲真的，我不确定 Snowpack 之后会怎么样。去年年底，保护 snowpack 劳累过度，当初曾经没有精力去保护了。Snowpack 的使用量和下载量开始呈降落趋势，社区也曾经变得平静。
所以可能把事件加快一点是有意义的。咱们想问一下咱们的社区是否有人违心参加长期保护。然而新的贡献者上手保护还须要一些工夫，而且咱们仿佛还找不到 ….
说真的，有点惋惜，但也没方法，开源自身就不容易。不过 Snowpack 也做的不错了，想想在基于 webpack 构建的大型项目下，我的项目启动工夫夸大点甚至能过 100s，更新的速度也不及时，而当浏览器反对了 ESM import 模块加载后，咱们就不须要在构建时解决模块（包含node_modules）之间的关系了，所有的模块化加载都交给浏览器，实现了原生的 tree-shaking，同时我的项目中单文件的批改也能够做到单文件的 reload，这开发构建的效率肉眼可见的 up up up！Snowpack 算是比拟优良的 bundleless 实现计划之一了！
bundle 与 bundleless 比照图（图源：ES2049 Studio）
回到正题！一起来理解、学习一下 Fred 做 Snowpack 开源库的经验总结吧！
做开源的成功经验
Snowpack 也算是一个比拟胜利的开源库了，从用户量、下载量、Star 三个维度都能体现进去，毕竟 100w+ 的下载量和近 20k 的 Star 也不是随随便便就能做到的，Fred 也总结了他做到这种境地的成功经验，心愿能帮忙到大家！
1. 痛点驱动，明确方向
Snowpack 最后是 Fred 在 Google 的 Polymer 团队工作中做进去一个用于代替 HTML imports[3] 标准的构建工具，起初引申出「为什么 npm 包在浏览器运行都须要借助 webpack 打包，而不能独自运行在浏览器呢？」的问题，于是 Fred 就针对「npm 包独自运行在浏览器」的可行性开始一直的尝试，这就有了之后的 Snowpack
所以这个库就是始于 Fred 对于现状的质疑、思考，这个能够让他明确库的方向，也能晓得后续须要做什么！如果一个开源作者莫名其妙就创立了个库，对于这个库也没有明确的作用方向，那长期下来，及时开源了，使用者或者开发者都是懵逼的，这个库注定也走不远！
2. 疾速口头，做事果决
在明确了一个库的大方向后，就要开始不断完善大大小小的性能，在这过程中你基本不晓得哪些代码、哪些性能是重要的，它们会不会在当前被废除。基于这一点，在我的项目初期就没必要顾虑太多，有想法间接做就完事了，即便你写的性能在之后会被删掉，即便你写的代码构造有些凌乱，这都没问题，大不了后续欠缺！（据说 Snowpack 最后基本没啥代码构造，全程都是一个 index.js 梭哈）
而且 Snowpack 的最后的外围指标并不是打包业务代码，而是间接应用浏览器原生的 ES Module 能力，因而 Fred 就基于 rollup 进行了一层封装，将用到库生成对应的 ESM 模块的文件，并将 import 门路替换成生成的 ESM 模块文件
图源：alienzhou
据说在 Sonwpack 里会用 Rollup 这一行动为 Fred 节俭了很多个星期，甚至很多个月的工夫！
当然了，为了相应 疾速口头 的口号，Fred 在 Snowpack 初期连单元测试都没有写，不是因为他不晓得要写单测，而是他感觉过后只处于我的项目的初期阶段，还不确定这个我的项目是否有用，是否会被大家接收，再加上写单测自身就是个很耗时的事件，要是后期在拼命实现各个性能之余还致力把单测写好，如果到最初本人的我的项目没有什么用、无奈落地或者没被大家所驳回，那后期节约的工夫就很多很多了，Fred 认为这种状况是十分头疼的，他宁愿等我的项目被泛滥用户应用后，再补上他所欠下的技术债！
总结一下：
- 代码写的烂没事，先口头，把性能实现最重要，后续能够优化代码
- 要确定并且专一本人要做的事件
- 能够借助比拟优良的开源库或者工具，晋升开发效率
- 后期能够先调过单测这一阶段，等前期真的须要了再补写单测
3. 疾速修复 bug
每个开源库在最初期的应用阶段应该多多少少都会有 bug，尤其是当有人尝试应用你公布的库时，遇到 bug 后肯定会给你提一个大大的 issues，此时作为开源库的作者，就应该以最快的速度去解决这个 issues，毕竟人家是你我的项目初期为数不多的使用者啊，更何况还帮你找到了 bug，如果连这一个用户的都服务不好，更别说之后有成千上万的开发者应用你的库了
所以你做开源就想再做生意，最后应用你的开源库（还未齐全成熟）那批用户就是你冷启动时的资源，只有把它们服务好了，才有机会冷启动胜利，做到广为人知
Babel 胜利的起因之一就是够疾速修复 bug 并公布新版本。通常会在 bug 上报后的几分钟内就修复并公布。在晚期用户不多的时候，做到这一点至关重要。使用者会感觉这个库的维护者效率十分高，及时他们遇到了 bug，也不会埋怨这个库 bug 真多而放弃应用
4. 推广宣传
推广宣传 换成一个 ” 令人头疼 ” 的词叫做 营销，可能大家就会联想到营销号，其实不是让大家去为了宣传本人的开源库而做一些 ” 卑劣 ” 的推广，甚至是拉踩别的库从而抬高自己的库哈，这种歹意的营销会让人很恶感，及时你的库再好，那口碑也好不到哪里去
害，真头疼，辛辛苦苦写了个库，还要致力推广，不推广就没人应用，甚至没人晓得！
那咱们该怎么做呢？
能够先跟与身边的敌人和共事分享，也能够让他们给你点倡议。如果你很侥幸，早早的就有了试用你库的用户，那么他们也能给你提不少倡议，甚至帮你宣传！
如果后续你有机会跟更多的用户分享你的我的项目，那么你能够通过一些很有意思的形式去向他们介绍，跟他们交换。例如给你的我的项目做几个生动有趣的介绍宣传视频、讲述一些简短的小故事对于你和你的我的项目、写一些技术博客间接或间接地介绍你的我的项目 等等
Fred 在 Snowpack 有肯定的用户根底后，破费了大量的工夫写了一篇博客，外面介绍了 Snowpack 诞生的起因以及他与该项目标任何货色，过后仅靠这一篇文章就爆火了，并且在后续的一年内被许多用户分享、援用，总之就是用户增长很快很快！！我想应该是 Fred 文章写的比拟走心，能让大家感同身受吧~
其实在国内有一个开源库的作者在推广上就做的比拟好，他就是 H5-dooring 的作者徐小夕，他这几年在推广本人 LowCode 上积淀下来的开源库时，始终在很多社区通过写技术文章的形式来推广宣传，大家看完文章既学到了 LowCode 平台的技术实现，又晓得了有这样一个优良的开源库。在另一方面，大家应该对他的信赖也会更多吧，毕竟能输入技术文章展示给大家，一起交换探讨 ~ 这也是个良性循环
5. 聆听用户心声
当初都反对言论自由，那你在推广本人开源库的过程中，肯定会遇到大量的评论，例如：
- 你这个性能，xxx 库不是早就实现了吗？反复造轮子有意思吗？
- 给作者提个倡议，感觉 xxx 性能的实现能够换成 xxx 计划，这样比拟好
- 这个库 bug 真多，还不如用 xxxx
- 这个性能真棒啊！心愿能始终保护上来
- ….
你们看到了，好的坏的评论都有。你也有辨别分别不同反馈的能力，不要被大量的称誉冲昏头脑而满足当下，也不要因一些带有批评性质的话语而一败涂地。被夸赞时，应该要更加激励你把开源库做得更好，在收到善意的倡议时，也要放弃虚心的心态去承受；被批评时，你首先要反思是不是你对于本人的开源库宣传没到位从而导致用户对你的库有误会，是否须要重写README.md 或 在社区再介绍一下？其次你再思考批评你的人是否就是闲着没事用相对的口气去踩你的我的项目（俗称键盘侠），那你大可不必理睬，尝试去疏忽它，破费更多精力去发现更具备建设性意义的评估！
总之就是要聆听用户的心声，毕竟他们才是真真正正在实际落地你开源库的人！
做开源的谬误总结
当然 Snowpack 也有做得不好的中央，不然 Fred 也不会没有精力去保护它了。那么在保护这样一个大型的开源我的项目时，Fred 在总结反思中又得出了什么论断呢？
1. 采纳 Dogfooding 办法
Dogfooding：用维基百科的解释来讲，Dogfooding[4]是一种应用本人的产品或服务以反对内部测试的做法，其能够对产品的品质进行提前把控，并做到有充沛的信念正式上线
简略举个例子，Facebook（文中简称 FB）开源了 React，并且其外部很多利用也是基于 React 开发的，如果 React 新增了某个个性或修复了某个 bug，除了用单测进行测验，FB 也能够把改变后的 React 利用到本人外部利用中，在实在的线上我的项目中验证 React 性能的稳定性，肯定比只在开发环境下测验更全面。等到改变后的 React 在本人的我的项目利用一段时间且根本没有任何问题后，FB 就能够很自信地认为 React 的品质有很高的保障，并且凋谢给其它开发者应用。
Fred 其实在 Snowpack 的保护中并没有像 FB 一样很好地把本人的开源库大面积利用到本人外部的我的项目中，因而也没方法很好地在公开 Snowpack 新个性前做欠缺的品质保障，Fred 取而代之的做法就是在开发 Snowpack 新个性之前，与用户们进行交换探讨。
Fred 当初回想起来，当初真的应该要采取 Dogfooding 办法，为本人的开源库换取更多的全面公开前的线上功能测试与品质保障。
2. 保质保量，理解用户
在前文 Fred 的成功经验中提到，他在我的项目初期时尽可能服务好最后一批 Snowpack 的使用者，在过后实现的某个性能是失去初期用户的认同的，但随着应用的人越来越多，大部分感觉这个性能是不好的，甚至感觉应该废除掉。这里就有一个用户需要的转变过程，所以在整个我的项目保护的任何一条链路中，你都要去理解用户的反馈，这样能力更好地推动我的项目的倒退
在一个开源库最初期，可能会有很多大大小小的 bug，这都是情有可原的，毕竟刚开始，而且应用的人也不是很多，所以更不会引起成千盈百的 bug 反馈或用户吐槽。而随着我的项目走上正轨并且越来越成熟，应用的人也就越来越多，使用者最冀望的就是该库 bug 更少，性能更稳固，所以作为开源者要做到的就是进步开源库的品质，保障最根本的用户应用体验！
3. 收集反馈，踊跃解决
不是每个人都会向你反馈问题的。将心比心想一下，如果你在用某些开源库时遇到了问题，此时你会去百度搜寻问题的解决方案，没搜到你又会去看这个库的官网文档或者 Github 的 issues 有没有相似的解答，再没有的话，你多半就不想用这个库了，心里可能还会默默地说一句：这库真 LJ，这么多问题，如果你略微有点急躁，你会给他提个 issue，渴望作者的回复，渴望问题失去解答，但如果迟迟得不到回应，最终的后果就是你转头就去找另一个能平替甚至超过它的成熟的开源库。
据 Fred 所说，Svelte[5]团队曾在一篇博客中提到，他们对 Snowpack 很感兴趣，这就意味着 Snowpack 有可能被他们团队所应用（用户 +1），Fred 也感到很开心，然而起初 Fred 发现在 SvelteKit[6] 正式公布之前，他们曾经把 Snowpack 换成了能实现同样性能的Vite[7]，起初理解过后得悉，Svelte 团队对于 Snowpack 并不是很称心，也跟我方才举的例子说的一样，他们也没有向 Fred 进行反馈，因为他们可能因为种种原因而没有空没有急躁去走这条「反馈 -> 期待解决 -> 问题被解决」残缺的链路，此时正好有一个别的库能满足他们需要，而且根本也没什么问题，那岂不是美哉？
Fred 起初反思，他感觉 Snowpack 初期在跟用户的交换互动上做的还是比拟好的，但随着用户群体越来越宏大了后，跟用户没有很强的互动感了，自然而然会散失掉一部分用户。Fred 起初才晓得，Svelte 团队在应用 Snowpack 时，常常会遇到问题，但 Fred 收到他们的反馈时曾经为时已晚了，因为他们曾经放弃应用 Snowpack 了。
对此，Fred 本人也总结了一个心得：作为开源库的创建者，肯定要把反馈渠道做好，与用户放弃较强的交换互动。不要只等着用户来给你反馈问题，肯定还要积极主动地去收集用户反馈并且踊跃疾速地解决问题
4. 继续输入，不断完善
一个开源库的诞生必定都是为了解决某个问题，但问题是解决不完的，而且初版的性能个别都会比较简单，所以开源库要始终被保护着。而做开源自身就不是件很容易的事件，因为一旦用户群体大了，你每天会收到有数的 issues，有很多问题和 bug 等着你来解决，好在社区还是很敌对很沉闷的，常常会有同学违心发现问题并反馈提交，甚至能力不错的同学还会提个 pr 奉献一些代码，这是开源最美妙的样子
而作为开源我的项目创建者，更应该做的就是积极主动去解决这些用户反馈的问题，认真审核他人提交的代码，同时本人也要思考本人我的项目还有哪些能够优化晋升的中央，简而言之就是要继续地去欠缺开源我的项目，你的用户也能从你做事的效率上看出你是个很优良、很负责任的人（哇！这个作者一天提交了十几次代码！我 2 个小时前提的 bug 这么快就修复了！效率真高！），那么对你产生的信赖也能映射到你所做的开源我的项目上
听到这里仿佛开源很费时间呀！难道要放弃当初的工作全职做开源吗？倒也不是！因为真正能全职做开源养活本人的人还是少的，大多都是兼职甚至业余去做的，兼职做开源当然也没问题，你能够尝试每周花几个小时或者每月花几天去保护一下你的开源我的项目，这都比你撒手不管来的要好
其实，社区的小伙伴也是能感触到你对开源我的项目的投入水平的（这个库上一次提交还是半年前，而且积攒了 500 多个 issues 没解决！不晓得靠不靠谱！），你没有尝试继续保护，那么整个社区也会趋于平静，这对开源来说是最大的问题，Fred 说他见过很多大型的开源我的项目中常常会犯这种谬误。你总不能只依附社区的小伙伴给你提 pr 来保护开源我的项目吧？
5. 建设社区
这一点应该不必多说，大家都能领会到。给本人的开源我的项目建一个交换社区就跟商家创立顾客 VX 群一样，它将 “ 商家 ” 与 “ 用户 ” 交换的链路缩短，同时也能提供一个领有性能目标的用户交换探讨的平台，他们能够踊跃发表想法，也能够互帮互助，你也能从社区中取得有价值的反馈
6. 人多力量大
最初这一点可能也是导致 Fred 没有精力去持续保护 Snowpack 最大起因之一
Snowpack 的 Contributors 有很多，在写这篇文章时总共有 402 位，能看得出社区的小伙伴十分沉闷，都违心帮忙一起保护这个我的项目，看这趋势，Snowpack 应该会做得越来越好吧？
然而 Fred 却不这么认为！他始终想单独来全权保护 Snowpack，也不承受 Larger Contributions，因为他的短期思维通知他：他一个人做，可能效率更高（毕竟不须要多人单干，防止了很多单干上的问题）。的确！在那段时间里，Fred 输入了十分多的货色，效率的确很高！但从久远来看，问题只会逐步裸露。Fred 输入大量内容是建设在 匆忙实现性能、跳过代码查看 的前提下的，进去混总是要还的，依照这种做法始终做上来，迟早会因为代码品质不高、构造凌乱等问题而保护老本变大的
我连忙去看了一眼 Snowpack 的 Larger Contributions，的确不多，算上 Fred 本人总共就 2 个！
总结一下，开源我的项目做大了当前，不能只靠单打独斗，找到有趣味有能力的搭档组成个团队一起共建是很理智的，毕竟开源不仅仅只是写代码，要做的事件很多，例如：新增性能、修复 bug、收集并解决用户问题、宣传推广、写官网文档等等，最初加上团队以及社区热心小伙伴的帮忙，肯定能顺利推动开源我的项目的停顿的，如果后续开源我的项目盈利了，作为创建者你还能够定期给团队内的小伙伴一些 Money，毕竟谁都不是为爱发电~
闲聊
文中提到了 SvelteKit 放弃应用 Snowpack 而抉择应用 Vite，会不会有人感觉是 Vite 干掉了 Snowpack 呢？其实也不是谁干掉了谁，Fred 也在回顾 Snowpack 的毕生中看到了本人做开源时的很多问题，只能说对于做开源这件事没有其它大佬有教训吧~
再来具体聊聊 Vite，能够从 Vite 的官网文档[8] 中理解到，Vite 借鉴了 Snowpack v1 的依赖预构建性能，所以从这一点来说，这两个库十分类似，因而社区的很多大佬们也常常会写这两个库的比照文章。Vite 又是出于什么起因诞生的呢？据说尤大在应用 Snowpack v1 的时候发现这个库对 HMR 没有很好的反对，所以才搞了个 Vite，并提供了基于原生 ESM 的 HMR，同样的，起初 Snowpack v2 也借鉴了 Vite 的这个个性进行了实现
Fred 也十分慷慨地夸赞 Vite 做得十分好，并示意之后也会将本人的我的项目 Astro 从 Snowpack 迁徙到 Vite 上
翻译：与此同时，Vite 正在飞速发展。值得称赞的是，他们很多事件做得都十分好。比拟好的是，这两个工具十分类似，而且容易切换应用。甚至之后 Astro 也会尝试从 Snowpack 迁徙到 Vite。
的确！站在 Vite 的角度下来回顾本文方才提到的所有章节，Vite 做得的确很不错，开发效率、问题及 bug 的修复速度、推广宣传、欠缺文档（中英都有）、继续输入、保质保量、扩充生态等等，怪不得会被 Fred 夸赞~ 给尤大点个赞！
总结
看了 Fred 大佬的开源总结（大佬很虚心），受益匪浅，也心愿能给当前或者当初做开源的你们一点启发~
文中我掺杂了很多的集体想法，把 Fred 总结的货色一点点融入到本文中了，想看纯原文的话，我把链接放这了~
- https://dev.to/fredkschott/5-…
参考资料
[1]Fred K.Schott: https://twitter.com/FredKSchott[2]Astro: https://astro.build/[3]HTML imports: https://developer.mozilla.org…[4]Dogfooding: https://en.wikipedia.org/wiki…[5]Svelte: https://svelte.dev/[6]SvelteKit: https://kit.svelte.dev/docs#i…[7]Vite: https://vitejs.dev/[8]Vite 的官网文档: https://vitejs.dev/guide/comp…
开源前哨日常分享热门、乏味和实用的开源我的项目。参加保护 10 万 + Star 的开源技术资源库，包含：Python、Java、C/C++、Go、JS、CSS、Node.js、PHP、.NET 等。
