I’ve spent a lot of my free time the last few years building and maintaining open source projects. Usually a few friends use them, or they’ll tap out at a ~100 stars or so, until a few weeks ago when I built what one would call a “viral demo.” zerobrew is a 5-20x faster, Rust-based Homebrew alternative.
As I write this, the repo is at ~6.8k stars, my tweet got ~380k impressions, friends at Notion and Duolingo sent me screenshots of it floating around their Slack, someone made an unauthorized memecoin, and a lot of people called me an idiot on Reddit.
As software becomes easier and faster to build, building the “right” things that have positive feedback loops (more users, more maintainers, better product) is an increasingly core skill of software engineering. That said, I basically had no reason to explain why this worked, or got 40x more of the attention than anything else I’d built. I talked through it with some friends, and end up with a few hypotheses:
I made the demo look fast
Yes, the first zerobrew version was much faster (~5-20x), than Homebrew, but I think the presentation of speed was perhaps just as important. In his “Animations on the Web” series, design engineer Emil Kowalski writes that “a faster-spinning spinner makes the app seem to load faster, even though the load time is the same.”
Here’s the demo gif:
Rather than having one loading spinner, I made sure every single dependency had its own loading state, to (hopefully) impress the user with the quantity of packages downloading in parallel underneath the hood. I fiddled with this screen a bunch. The full-width loading bars, I think, also convey completed work in ways in-place spinners wouldn’t. In essence: regardless of what actually happened under the hood, the loading design made it look like a ton of work was being done very quickly.
Many people already wanted it to exist
There were large, pre-existing holes to be plugged in Mac package managers. I realized how frustrated people were after a thread went viral noting that Homebrew had only added concurrent downloads in November 2025. I came pretty staunchly to their defense!
I was surprised but how annoyed people were, but I think this was animated by recent excitement of full rewrites of slow package managers, particularly bun and uv. For the uninitiated, Python dependency management has historically been extremely unpleasant and fragmented across many bad providers (pip, poetry, mamba, conda, etc). A company called Astral, seemingly out of nowhere, released uv1 a few years ago, which “just works,” is written in Rust, and lands enormous performance speedups.
Bun, a high performance JavaScript runtime2, did the same:
This is to say: zerobrew bootstrapped onto a set of latent beliefs, mobilized by uv and bun. Cartoonishly, these beliefs read something like:
Homebrew devs are dumb; there was no competition to spur better work
everything rewritten in Rust is automatically faster
there are basic performance optimizations everywhere, things are made by people, our world is malleable
The key here is that people wanted to believe these things before the package was released. This reminded me of a recent favorite book, Bruno Latour’s The Pasteurization of France3. The book argues that Pasteur’s work was not accepted purely due to its truth4, but by leveraging a “hygenist” community of physicians, public health reformers, and other administrators. The hygienists, before Pasteur, used random cleaning tactics that didn’t stop people from getting sick. Pasteur’s theory a) gave them means to actually improve health outcomes and (b) armed them with reasons to command more money, power, influence, and control5. In Latour’s words:
[An opponent of Pasteur] imagined that he was fighting against a scientist, whereas he was fighting against someone who was already the spokesman, the figurehead, and the amplifier of an immense social movement that passionately wanted Pasteur to be right
In essence, one can harness latent frustrations into interest and enthusiasm about a better solution. The best place to see these gaps is in developer communities or building software with existing tools. It was quite clear to me zerobrew was a lightning rod for existing frustration or beliefs in some of the quote tweets:
Addressing these frustrations with solutions, even if partial or flawed, is a closer step to fixing the problem than tweeting more. More succinctly, in ffmpeg’s words: “talk is cheap, send patches.” That said, I think I needed to work in a new codebase, and citing simple concrete speedups in the launch tweet made it clear that this was better solved in a “greenfield” project vs. through patches to Homebrew.
I scoped the MVP to be immediately adoptable
One of my largest initial fears was that nobody would entertain swapping out battle-tested—Homebrew first released in 2009—software for a new package. Feature-completeness would also be impossible; the codebase supports tons of edge cases, environments, and functionality that would take months to replicate.
I’ve tended to try new products when they do “just enough” to improve on an initial experience and don’t otherwise disrupt me. The most classic here would be Cursor: no learning curve from VS Code, and tab complete itself was enough to push me over the edge.
Rather than try to go for completeness, I figured it was better to make 80 percent of cases 10x faster, to “fail fast” on long tail issues and let users easily fall back to Homebrew for whatever doesn’t work. It’s not even obvious that Homebrew’s handling of such edge cases, on set of features is the correct one; with some initial adoption and sufficient traction, we could get initially buggy packages to support native zerobrew setup too, rather than being forced to hew to their spec. Anyone could try zerobrew without a big migration or trusting it fully on the first try.
Ultimately, you have no idea how your work will be received
zerobrew was one of my first views into the full spectrum of internet feedback. Many people slammed me for edge case functionality that was missing, claiming it wasn’t useful, etc. To stay sane I think you have to ignore some of these, in a “critics sound smart, optimists get things done” vein6. That said, a lot of the critical feedback was extremely useful and correct; I got a ton out of people flaming various architectural choices, many in actionable (and since-fixed!) ways. I think it made me a much better engineer; I’m working on another project right now that I’ve spent much more time fuzzing, testing, and polishing before release. Outrage also made it clear the project “mattered,” versus the code sitting in my head or in a repo unused.
The coolest part of this response was seeing the communal spirit of open source up close. I’ve contributed to a few projects myself, but it was pretty nuts to be flooded with pull requests and issues. I reviewed the first batch myself, reached out to the two best contributors, and asked them if they wanted to help me maintain. cachebag and maria-rcks are true superheroes, and while I step in from time to time, they review / triage basically all of the inbound PRs and issues. They and an amazing set of contributors have built a ton of additional features on top of the initial version, like:
Linux support
building packages from source
additional large speedups (another 3x cold!)
tons of bug fixes and edge cases
I found it quite inspiring to see this come together — to see volunteer maintainers excited about the project, contributing purely out of interest in seeing it get better. This is another beautiful thing about releasing work publicly: your projects can take on a life of their own. Pretty quickly, I was eclipsed as the #1 zerobrew contributor!
My ultimate conclusion is that I don’t really know why zerobrew did better than many of my other projects. I could make an equally compelling argument for why many other projects that didn’t go viral, should have, for similar reasons.
Generally I think it is worth paying attention to what you can control—building something people (particularly: you already!) want, 80/20ing your prototype correctly, making a clear demo, etc. Beyond that, it’s a heavy tail situation and you have to take many shots on goal, build things you think are great7 for yourself and let external perception shake out how it will. A famous Mr. Beast quote goes something like: ‘if you want to understand virality, first upload 100 videos8.” In essence, I come to: find what’s wrong and fix it, don’t get too demoralized by trolls, and release high quality things often. There’s so much more useful software to build!
Thanks to Jaclyn Chan, Matthew Jordan, Celine Nguyen, Brie Wolfson, Omar Rizwan, Daniel Coffield, Alana Goyal, and Owen Fahey for discussing / reviewing drafts of this. Of course, all errors are my own.
Since I started writing this, acquired by OpenAI! Speedups are valuable, but it does seem quite difficult to independently monetize these faster, high performance open source projects.
Recently acquired by Anthropic to speed up Claude Code!
Recommended to me by my former roommate Tian Fang. We hosted a book club for it in SF!
After release, I learned that another developer built wax, another fast, Rust-based Homebrew-compatible package manager. This is a great setup: why did zerobrew blow up where wax did not?
This is very “social construction of science” which is quite controversial; when I read this book, I kept finding myself going “pasteurization actually worked!” My current roommate, Matthew Jordan has an excellent essay in Asterisk Magazine on the disciplinary history of History of Science, which is well worth your read. I also love Alyssa Battistoni’s essay about Latour and the broader history of the Sokal Hoax in Lingua Franca, if this is of interest.
I think you have to remember truisms like this, or examples like everyone dunking on the first Dropbox version, in order to stay sane and actually produce work (beyond just commentary!)
This also reminds me of an excellent, canonical Ira Glass quote, which I’ll quote in full because I like it so much and always find myself revisiting: “Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.”
The software example of this would be Peter Steinberger, who’d released ~40 open source projects before OpenClaw.
The factory is the product and the bts is the growth strategy
Enjoyed reading the yr thinking on this!