This content originally appeared on DEV Community and was authored by Fred K. Schott
My name is Fred, and I created Snowpack. Snowpack is a next-gen build tool that fundamentally unlocked the "unbundled web development" movement that Snowpack, Vite, SvelteKit, Nuxt v3, and many other modern dev tools leverage today.
This article is the second entry in a two-part series. In the first post, I went over the early history of Snowpack and how we grew an open source project to find our first set of users. In this second post, I want to focus on what happened next: how do you maintain and continue to grow a large project at this scale?
This article is meant to be an entertaining read for anyone who is interested in open source software. The highlighted lessons are directed at current (or aspiring!) open source maintainers of large and/or growing open source projects.
Background
If the first post in this series was about everything that I did right while starting the Snowpack project, then this post is about everything that I did wrong.
We came into the year with high expectations: Voted "Productivity Booster of the Year" in the OS Awards. Voted #1 & #2 placement in the "2020 State of JavaScript" survey on build tools. Exploding from 200,000 downloads in 2020 to 1.3M in 2021.
When you do something like this for the first time, you're never going to get it 100% right. This was personally my first experience maintaining an open source project of this scale and rising popularity. I had started plenty of new repos in the past, and some of them were even well liked, but none had ever grown this big. Snowpack was my first experience seeing exactly what happens when a project grows beyond its original creator. We didn't have a roadmap for this transition, and I made plenty of mistakes that I now see in hindsight.
I really want to make it clear that I'm incredibly proud of this project and the people who have contributed to it. Snowpack meaningfully pushed the entire web development industry forward, and that's pretty cool. Even if you never use Snowpack directly, the work that we pioneered around npm package handling for ESM and unbundled development is already being built on and improved on across the entire web tooling landscape in projects like Vite, Skypack, JSPM CDN and others.
This post is my attempt to create a guide for anyone else who might find themselves in a similar position one day with a popular and growing community project (open source or otherwise). There's no teacher like experience, but hopefully this will help you avoid some of the same mistakes that I made.
Lesson 1: Dogfood large, real-world projects
This may sound like one of those cliche/obvious things, but I cannot stress enough the importance of real-world testing. We had a few starter projects to test with, and the snowpack.dev website was powered by Snowpack, but then there was a pretty huge experience gap between our small projects and our actual users.
People tend to think of "dogfooding" as a way to prevent bugs, but I've found it to be much more important as a way to align yourself with your users in the same reality. It's impossible to make good decisions about something that you don't know. Without some kind of real-world dogfooding, you end up prioritizing the wrong features and missing the actual blockers that your users are facing.
This is unfortunately one thing that large-scale corporate open source is set up to do really well. Facebook is able to test a new React feature or bug fix across a codebase of 30,000+ components before even asking for public feedback, let alone releasing public code.
If your project isn't owned by a tech giant, you still have options. If you work somewhere full-time, try to dogfood within your company. Rich Harris often talks about how using Svelte at The New York Times directly benefits the framework. Your company codebase can acts as a real-world playground for new features, API changes, and even entire pre-release projects.
Snowpack never had a company playground. However, I still think that we could have been better about talking to our largest users and getting first-hand feedback before each release.
If I could do it all again, I would have sought out invites to real-world Snowpack users' codebases in exchange for some extra testing and hands-on support.
Lesson for open source maintainers: Dogfooding large projects and real-world usage is essential to prevent bugs and useless features.
Lesson 2: Painless developer experience is essential
In the early days of a project, you'll be forgiven for a few bugs and odd behaviors. As your project matures, this patience tends to run out. The real problem doesn't have to be a single big bug, but the sum of multiple "poor" user experiences.
For example, you should always have a clear error message when something breaks. Yes, even if you think that it was the user's fault:
As our user-base transitioned from "early adopters" to a larger "mainstream" audience, users became less likely to track down opaque errors (undefined is not a function ?). Instead, they would just abandon the project for more familiar/stable alternatives.
This is also relevant to how you design your project and choose your features. "Bundling should be optional" was a conceptual idea baked into the core of Snowpack. If you remember back to the first post in this series, that was the core idea that our first users fell in love with. As we grew, mainstream users didn't love it so much, and were mostly just confused why they had to implement this "table stakes" feature themselves.
Lesson for open source maintainers: As your audience grows, understand how your users change. Invest in testing, clear error messages, and overall stability. Make sure that the default user experience is good before investing in advanced features.
Lesson 3: Your users won't tell you everything
A personal story: For a while, it looked like Snowpack might power Svelte's new web application framework, SvelteKit. However, right before their public release they switched out Snowpack for Vite (a Snowpack alternative) and only told us after the decision had already been made. They were unhappy with Snowpack, and we hadn't even noticed!
On smaller projects, you tend to have a strong connection to your users. I had gotten so used to this feedback cycle that I hadn't even thought to proactively check in on the team to see what we could be doing better. I had missed the rough edges that the Svelte team was encountering every day, and only got their feedback after it was too late to change minds.
As an open source leader, it's up to you to invest in good feedback channels. If you don't have a Discord server yet, get one (more on that in a bit). Be proactive about asking users for their feedback and frustrations, and find ways to gather honest feedback on a regular basis. Outreach is now your responsibility.
Lesson for open source maintainers: Don't wait for your users to tell you what's wrong. Be proactive about gathering feedback and fixing issues.
Lesson 4: Be consistent
The best part of open source development is the community. As your project grows, you'll start to see people stopping by to chat, comment on issues, and maybe even contribute code. Repeat contributors can quickly become long-term maintainers, partners, and even friends.
The best thing that you can do for your community is to be consistent. Bursts of productivity (followed by long periods of quiet) are fine on personal projects, but they can be poison to a community. This is probably the most common mistake that I see large open source projects make. When you step away from your project, contributors and potential future contributors notice. There's nothing worse than putting time into a PR and then having it sit around, uncommented and unnoticed for weeks or months.
I want to stress that the solution here is not "just spend more time." That's a guaranteed path to burnout (more on that in a second). Instead, just spend your time better. It's better to spend an hour or two every week than it is to spend a full day, once a month.
For what it's worth, this is still something that I'd like to get better at myself.
Lesson for open source maintainers: Be consistent. Don't leave your contributors hanging on code reviews and pull requests.
Lesson 5: Be present and use Discord (seriously.)
Discord is currently hands down, the best way to build a community around an open source project. It turns out, the same moderation tools designed for 12-year-old gamer kids are also pretty good for open source (I kid! ... kind of ?).
Create a server on Discord once your project is at the size where you're getting consistent interactions on Twitter, GitHub, Reddit, etc. If you already have a Slack community, start thinking about moving. Seriously, it's that much better.
In the early days, your Discord will only ever be as active as you are. If you never visit it, don't expect much to happen. If people never get a response, don't expect them to stay for long. Calling back to the previous two sections: Consistent presence is the best way to build a community and get valuable feedback from your users.
Discord also is great at encouraging experimentation. Is someone recommending a great bot (aka integration) for your server? Try it out! Ask them to help integrate, customize, or even teach you how Discord works. If your codebase is daunting, customizing Discord can be a great middle-ground where you can collaborate with and even learn from your community.
We always had a Discord for Snowpack, but I've only recently begun to appreciate just how useful it is when used correctly.
Lesson for open source maintainers: Use Discord, and be present + consistent. Embrace the fun side of the platform (emotes/emojis, bots, stickers, etc).
Lesson 6: You can't do it all on your own
At a certain point, your project will grow beyond the scope of what you can maintain yourself. This is probably the biggest test your project will face: you either grow past yourself, or you burn out.
To make matters worse, this can be a hard problem to fix after-the-fact. Investing in new contributors takes time and energy, the two things that you're probably lacking most. "It will just be faster if I just do it myself" might be true in the short-term, but can be dangerous long-term thinking.
I definitely fell into this trap with Snowpack. We had plenty of contributors over the project's history, but I wanted to run the project all on my own and rarely encouraged someone to keep contributing. I shipped some great stuff during that period, but in retrospect I was rushing work and the overall quality was suffering. I skipped code reviews because I felt I didn't have time for it. And then when I did step away to recover, the project often went quiet.
I was burnt out, and I didn't even have the energy to realize it.
Lesson for open source maintainers: You can't do it all yourself. Building a community of contributors can be the most fun part of open source, if you invest in it. Read up on good open source governance to learn how others have done it.
Epilogue: What's Next for Snowpack?
If you're currently an open source maintainer or contributor, I hope that you have found this honest guide useful! This last year has been a wild journey, but I wouldn't trade a moment of it.
One good thing about painful mistakes is that they really stick with you. I've already started to apply these lessons to our newest project, Astro. Astro is still young, but we invested early in an active Discord, a healthy governance model, a solid test suite, and a community of maintainers with full responsibilities and permissions on the project.
It's an amazing feeling to step away every once-in-a-while and know that a project is in good hands.
To be honest, I'm not sure where Snowpack goes from here. I burnt out on it at the end of last year, and haven't really found the energy to return to the project since. Not surprisingly, usage and downloads began to trend down and the community has gotten quieter. At the same time, Vite (that Snowpack alternative that I mentioned above) has really taken off and I think that they do a lot of things really well. The two tools are mostly interchangeable, and even Astro is experimenting with moving from Snowpack to Vite in a future release.
So maybe it makes sense to start winding things down. We asked our community if anyone wants to step up to get involved in Snowpack's long-term maintenance, but (as mentioned above) new contributor onboarding takes time that we just can't seem to find any on our end. It's a bit of a Catch-22.
One other idea would be to go back to basics, and refocus our effort on the ESM package installer that originally made Snowpack famous. The code for this already lives in its own package: esinstall (no relation to esbuild). It would be fun to speed up esinstall and convert its internal engine from Rollup to something faster like though. But more importantly, this project audience would be smaller, and therefore easier to maintain.
Whatever happens, I know that we'll keep learning and keep improving.
Thanks for reading! Follow me on Twitter for more updates. If you missed it, check out the first post in the series.
This content originally appeared on DEV Community and was authored by Fred K. Schott
Fred K. Schott | Sciencx (2021-09-15T22:58:01+00:00) 6 MORE Things I Learned Building Snowpack to 20,000 Stars. Retrieved from https://www.scien.cx/2021/09/15/6-more-things-i-learned-building-snowpack-to-20000-stars/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.