Remember when Yarn burst onto the scene, claiming to be the savior of JavaScript package management? Built by Facebook for Facebook, Yarn was marketed as the “npm killer” that would revolutionize the way developers manage their dependencies. At the time of writing, there are plenty of other “npm killers” emerging like… 
and… 
Both bun and pnpm run rings around npm and yarn (obviously) in terms of performance and developer experience. Hell, even Yarn’s Lead Maintainer acknowledged bun is better.
Data don’t lie - the 2024 Stack Overflow Developer survey reported a 3% drop in yarn usage from 2023 (bun is +3%, draw your own conclusions).
But this article isn’t about package managers or specific tools.
Back to Yarn - it was never really about being the best tool for the community. It was built for internal needs and just happened to be released to the public. Yarn is public source — a tool that was thrown over the wall for others to use, but never truly designed to grow beyond Facebook’s control.
Back in 2016, npm was painfully slow. Installing packages felt like pulling teeth, and anyone who’s dealt with a huge node_modules folder knows the pain of waiting. Facebook, dealing with its own scaling issues, needed something better. Enter Yarn, a blazing fast, deterministic package manager that promised to solve all of npm’s performance woes. It quickly gained traction because it was fast — faster than npm at the time — and introduced lockfiles that actually worked.
Yarn was built to solve Facebook’s problems, not yours.
It was a project born from internal struggles, slapped with a permissive license, and left out in the wild. And now? Yarn is basically collecting dust, and its major selling point (speed) has been eclipsed by npm’s improvements. Yarn lost the package manager war against npm. npm won because it’s a true open source project with community-driven improvements and widespread adoption, not because it was birthed from a giant tech company’s internal needs.
Public v Open
It’s not just semantics — it’s a mindset that can dramatically impact your workflow, project sustainability, and community engagement. When you choose a tool, you’re not just picking code; you’re picking the ethos behind it, the community that supports it, and the roadmap that drives it forward.
Public source software is code that’s available to the public but isn’t necessarily developed with the public in mind. It’s often created to solve a specific problem for the company that built it and then released, sometimes as a goodwill gesture, sometimes as a PR move. Public source projects tend to have limited or sporadic community involvement, little transparency about future development, and often lack clear paths for contribution. Yarn is a textbook example: it was fast, it was shiny, but it was never truly “ours.”
Open Source on the other hand, is built by the community, for the community. Open source projects thrive on contributions, discussions, and collaborative improvements. They have roadmaps driven by the needs of their users, not just the original developers. The code isn’t just accessible; it’s alive with the input, creativity, and feedback of a diverse group of developers. npm (for all its flaws) is a great example of this philosophy: it evolved through the active participation of its community, incorporating countless improvements that benefited everyone, not just a single company.
When you integrate a tool into your workflow, you’re also adopting its future.
Open source projects often have large, active communities that ensure the tool evolves, adapts, and stays up-to-date with the latest standards. Public source tools, however, can be abandoned when the original creator loses interest or no longer needs it. Yarn’s slow decline is a parable for what happens when the community isn’t involved from the start. Open source projects typically have many eyes on the code, catching bugs, vulnerabilities, and performance issues quickly. This transparency means you’re more likely to get a secure, robust tool. Public source tools may have a similar license, but if the community isn’t engaged, security patches and updates can lag behind, creating hidden risks in your workflow.