近 20k Star的项目说不做就不做了，但总结的内容值得借鉴
关注并将「趣谈前端」设为星标
每天定时分享技术干货/优秀开源/技术思维
最近在社区看到一个让人惊讶的消息，近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实现方案之一了！
回到正题！一起来了解、学习一下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模块文件
据说在 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夸赞~ 给尤大点个赞！
更多推荐
创作不易，加个点赞、在看 支持一下哦！