我从积雪厚度达到 20,000 颗星的过程中学到的另外 6 件事（第二部分）

本文是两篇系列文章的第二篇。在第一篇中，我回顾了 Snowpack 的早期历史，以及我们如何发展一个开源项目并找到第一批用户。在这篇文章中，我想重点讲述接下来发生的事情：如何维护并持续发展一个如此规模的大型项目？

对于任何对开源软件感兴趣的人来说，这都是一本有趣的读物。其中重点介绍的经验教训，适合大型和/或不断发展的开源项目的现有（或有志于成为开源项目的）维护者。

背景

如果本系列的第一篇文章是关于我使用 Snowpack 所做的所有正确的事情，那么这篇文章就是关于所有出错的事情。

我们满怀期待地迎接新的一年：在 OS Awards 评选中荣获“年度最佳生产力助推器” 。在“2020 JavaScript 现状”构建工具调查中，荣获第一和第二名。下载量从 2020 年的 20 万次激增至 2021 年的 130 万次。

第一次做这样的事，你永远不可能做到100%正确。这是我第一次维护如此规模的开源项目。过去我创建过很多新的代码库，其中一些甚至很受欢迎，但没有一个发展到如此规模。我们没有为这次转型制定路线图，我犯了很多现在看来都挺明显的错误。

我想明确表示，我为这个项目以及所有为之做出贡献的人们感到无比自豪。Snowpack 推动了整个 Web 开发行业的发展，这非常了不起。即使您从未直接使用过 Snowpack，我们开创的成果——特别是围绕 ESM 和非捆绑开发中 npm 包处理——正在整个 Web 工具领域中得到构建和改进，例如Vite、Skypack、JSPM CDN等项目。

这篇文章是我尝试为那些有一天发现自己处于类似境地的人创建一份指南。

第 1 课：测试大型真实项目

真实世界的测试至关重要。这听起来可能有些老套，但确实如此。我们有几个可以用来测试 Snowpack 的初始项目，但它们都规模小、内容简单。这导致我们的内部项目和实际用户之间存在巨大的体验差距。

人们往往认为“内部测试”是预防 bug 的一种方法，但我发现它最有效的方式是与用户保持一致。对于你不了解的事情，不可能做出正确的决定。如果没有某种实际的“内部测试”，你往往会优先考虑错误的功能和修复。

不幸的是，大型企业开源项目在这方面做得很好。Facebook 能够在3 万多个组件的代码库中测试 React 的新功能或错误修复。他们可以在内部进行大规模测试，然后再公开分享。

如果你的项目不属于科技巨头，你仍然有选择。如果你在某个地方全职工作，可以尝试在公司内部进行测试。Rich Harris 经常在《纽约时报》上谈论使用 Svelte如何使该框架受益。你的公司可以成为新功能、API 变更，甚至整个预发布项目的真实试验场。

Snowpack 从来没有公司级的游乐场。然而，在开发功能之前，我们本可以更好地与用户沟通，收集反馈。现在回想起来，我本应该邀请他们去实际的代码库，以换取一些测试和支持。

教训：对大型项目进行测试，以防止出现错误和无用的功能工作。

教训 2：轻松的开发者体验至关重要

在项目初期，一些 bug 和一些奇怪的行为是可以原谅的。但随着项目的成熟，这种耐心往往会耗尽。真正的问题不一定是某个大 bug，而是多个“糟糕”用户体验的总和。

例如，当出现问题时，你应该始终提供清晰的错误消息。是的，即使你认为这是用户的错：

随着我们的用户从早期采用者转变为更庞大的“主流”用户群，用户越来越不愿意去追踪那些奇怪的错误（undefined is not a function😱）。相反，他们会放弃这个项目，转而选择更熟悉/稳定的替代方案。

这也与你如何选择新功能息息相关。“打包应该是可选的”是 Snowpack 从一开始就秉持的核心理念。如果你还记得本系列的第一篇文章，你会发现我们的第一批用户正是因为这个理念而爱上它。但随着我们的发展，主流用户对它的兴趣逐渐消退。他们大多感到困惑，为什么这么简单的功能竟然要自己实现。

经验：随着受众群体的增长，要了解用户的变化。投入精力进行测试、清晰的错误提示以及整体稳定性。在投资高级功能之前，务必确保默认用户体验良好。

教训 3：你的用户不会告诉你一切

Snowpack 几乎为SvelteKit 提供了动力。

Rich Harris在 Svelte 峰会上宣布了这一消息，并发表了一篇博客，表达了他对我们项目的兴奋之情。我们欣喜若狂。但就在 SvelteKit 公开发布之前，他们用一个名为Vite的替代工具替换了 Snowpack 。我们很晚才发现这个工具。决定已经做出了。他们的团队对 Snowpack 很不满意，而我们甚至都没有注意到！

在小型项目中，你往往与用户保持着紧密的联系。但随着用户群体的增长，你就会逐渐失去联系。我已经习惯了这种反馈周期，甚至都没想过要去关注一下。我错过了 Svelte 团队每天遇到的棘手问题，而且总是在他们无法改变任何想法的时候才收到他们的反馈。

对于开源领导者来说，投资反馈渠道非常重要。我们意识到这一点太晚了。

经验教训：不要等着用户告诉你哪里出了问题。要主动收集反馈并解决问题。

第四课：保持一致

开源开发最棒的部分在于社区。随着项目的发展，你会看到越来越多的人来这里聊天、评论问题，甚至贡献代码。重复的贡献者可以成为你一生的挚友。

保持一致性是建立社区信任的最佳途径。对于个人项目来说，爆发式的生产力固然好，但随之而来的长期沉寂，对不断发展的社区来说却是毒药。这可能是我看到大型开源项目最常犯的错误。当你离开项目时，贡献者和潜在的未来贡献者都会注意到。没有什么比投入时间在一个 PR 上，然后让它闲置数周甚至数月，无人评论、无人关注更糟糕的了。

我想强调的是，解决方案不是“仅仅投入更多时间”。这必然会导致倦怠。相反，要更好地利用你的时间。每周花一两个小时来学习，比每月花一整天来学习要好得多。

不管怎样，这是我自己仍在努力的事情。

教训：保持一致。不要让你的贡献者一直忙于代码审查和拉取请求。

第五课：出席并使用 Discord（认真地）

我之前提到过，但再次强调非常重要：使用Discord。获得第一批用户后立即创建一个社区服务器。如果你已经有 Slack 社区，那就开始考虑迁移吧。说真的，Slack 真的好太多了。

新的 Discord 服务器的活跃度取决于您的活跃度。如果您从未访问过，就别指望它会带来什么。如果人们从未收到回复，就别指望他们会长期停留。回顾前两节：持续在线是建立社区并从用户那里获得宝贵反馈的最佳方式。

Discord 也非常鼓励用户进行实验。有人推荐了一款适合你服务器的优秀机器人（也就是集成机器人）吗？那就试试吧！让他们帮忙集成、定制，甚至教你如何使用 Discord。如果你的代码库令人望而生畏，Discord 可以成为一个绝佳的中间地带，让你与社区成员合作（甚至互相学习）。

经验：使用 Discord。保持活跃并保持一致。拥抱平台的趣味元素（表情符号、机器人、贴纸等）。

第六课：你不可能独自完成所有事情

重要的是要意识到你的项目何时发展到超出你独自维护的能力。那时你就需要做出选择：是招募更多人手，还是精疲力竭。

“如果我自己做的话会更快”可能是正确的短期想法，但从长远来看这是危险的。

尽管多年来接受了大量贡献，但我在 Snowpack 上仍然落入了这个陷阱。我内心深处想要独自运营整个项目，拒绝鼓励更多贡献。那段时间我交付了一些很棒的东西，但工作也过于仓促。代码质量下降了。我跳过了代码审查，因为我觉得没时间。后来，当我离开去恢复的时候，我离开的时间又会更长，项目也就变得沉寂了。

你有没有过精疲力竭，甚至没有精力去意识到这一点的经历？是的，这很艰难。

教训：你不可能独自完成所有事情。如果你投入精力，构建社区可能是开源最有趣的部分。阅读关于良好开源治理的书籍，了解其他人是如何做的。

结语：Snowpack 的下一步是什么？

如果您目前是开源维护者或贡献者，我希望这份真诚的指南对您有所帮助！过去的一年是一段疯狂的旅程，但我不会放弃其中的每一刻。

痛苦的错误往往会留下深刻的印象。我已经开始将这些经验教训运用到我们最新的项目Astro 中。我们已经投资了活跃的 Discord、健康的治理模式、可靠的测试套件、对稳定性的关注，以及一个由优秀维护者组成的社区。

当你离开并知道你的项目在可靠的人手中时，这是一种很棒的感觉。

说实话，我不确定 Snowpack 下一步会走向何方。去年年底我就对它感到厌倦了，现在也找不到重回它的动力了。它的使用量和下载量开始下降，社区也变得冷清起来。 

与此同时，Vite（Snowpack 的替代品，目前支持 SvelteKit）正在蓬勃发展。值得称赞的是，他们在很多方面都做得非常出色。好消息是，这两个工具非常相似，而且很容易切换。就连 Astro 也在尝试在未来的版本中从 Snowpack 迁移到 Vite。

所以或许应该逐步结束。我们询问过社区是否有人愿意参与长期维护。但是新贡献者的加入需要时间，我们这边似乎找不到合适的人选。这有点像“第22条军规”。

另一个想法是回归本源，让这个故事完整地呈现。我们的第一批用户爱上的 ESM 软件包安装程序仍然以它自己的软件包形式存在。像这样的实用程序的受众会更小。它甚至可能很有趣！

无论发生什么，我知道我们都会继续学习，不断进步。

感谢阅读！关注我的 Twitter以获取更多更新。如果您错过了，请查看本系列的第一篇文章。