5 Lessons Learned After 5 Million Downloads
Wooohooo 🎉
Podman Desktop just crossed 5,000,000 downloads! Less than a year ago we were celebrating 3 million, and now we're humbled to be at 5 million. That kind of growth doesn't happen without a community pushing us, challenging us, and choosing us. Thank you.
Download numbers can easily become vanity metrics. So instead of just announcing one, we wanted to mark this milestone the way developers actually like to celebrate: with a retro. Here's what came out of it.
1. Extensibility works
The container landscape hasn't stood still since Podman Desktop launched: new tooling, AI, and constant churn in integration points, to name a few. Our extension-based architecture made it easier to respond, and that wasn't an accident. Many of us on the founding team came from the IDE space, building tools and extensions on top of VS Code, so making Podman Desktop extensible from day one was a deliberate choice, not an afterthought. We wanted people to be able to shape the tool to their own needs, and we wanted people working with other, related container technologies to be able to build their own extensions too.
Extensions like Apple Container and AI Lab let us adapt to the market without disrupting the core application. AI Lab in particular has been a great example of extensibility opening up entirely new use cases: it's helped developers realize they can run models locally using the container technology they already know, and from there, get inspired to build their own LLM-powered use cases. We're also seeing organizations build their own internal extensions to tailor Podman Desktop to their specific developer workflows or connect it to their own internal systems, which makes the tool easier to adopt at an enterprise scale.
That said, staying this open comes at a cost we keep paying, not one we paid once. Features like our dashboard and onboarding flows are built so extensions can contribute their own views into them, and that constraint makes those areas harder to redesign or refactor than they would be in a closed system. Keeping the UI and styling consistent across a growing ecosystem of third-party extensions, without breaking them every time we ship an upgrade, takes real, ongoing care. It was a commitment we made early on, and one the team has never backed away from.
2. Scaling breaks things
For us, that was telemetry. When usage was low, we could gather the data we needed about product use without paying much attention to volume. That granular data was a great way to track feature adoption and inform the roadmap, and it's also genuinely helped us fix things fast: at one point we caught, directly through telemetry, that a QEMU change was breaking the Podman machine on certain setups, and were able to build and ship a patch before it turned into a wider wave of bug reports. Telemetry gave us patterns and context that users reporting an issue often can't provide on their own, since they don't always have a clean reproducer.
As we grew, though, the cost of collecting all that data grew with it, and our approach hadn't kept pace. We had to sit down and rethink what we actually needed: which events tell us something about how well the application is performing, which ones tell us whether a feature is discovered and used, and which ones we were only collecting out of habit. We deliberately stopped measuring the things that fell into that last bucket. We now collect less, but more deliberately, and it's paying off in both directions: it's cheaper and clearer for us to act on, and it still gives us what we need to evaluate new features and the impact of changes we ship.
3. Building the community we want
More downloads brought more contributions, more issues, and more pull requests. While our progress relies on our excellent contributors, there have been growing pains. Some contributions didn't match our coding practices, or overlapped with work already in progress or planned for a later point on the roadmap. Contribution volume is up and that means real time spent chasing authors for follow-up instead of shipping.
Our response was to make the path clearer before people start, not just react after the fact: we published contributing guides, and added guardrails in the repository, including a bot that automatically checks pull request quality so contributors get that feedback directly, without waiting on a maintainer. It's made contributing easier, and contributions keep growing as a result, so reviewing them takes real time and coordination. That's a good problem to have, and we're happy with the pace of contributions we're getting today. The lesson: maintaining a community of contributors is paramount, and it's on us to build the guardrails that make that the easy path.
4. Adoption doesn't always look the way you expect
It's tempting to assume that if you build a great feature, people will use it. When we launched the Kubernetes Extension, adoption didn't match how useful we thought this feature was.
Kubernetes has actually been part of Podman's DNA since the very beginning; the name "Podman" itself comes from "Pod Manager," a nod to Kubernetes pods. We know most containers built with Podman Desktop eventually land on a Kubernetes environment, and Kubernetes brings its own layer of complexity for developers. So working with the community, and with organizations running containers at scale on Kubernetes, we set out to build what developers actually needed: help shaping containers so they're ready for Kubernetes, and the ability to quickly inspect, test, and debug workloads, down to getting a terminal directly inside a running container. That work shipped as our Kubernetes dashboard, built in the open with the community, and we're genuinely happy with where it landed.
So why didn't adoption immediately follow? We think it comes down to awareness and perception more than the feature itself. Most people know Podman first as the best alternative to Docker, and don't necessarily think of us as a tool that also helps them work with Kubernetes, even though that's been part of the roadmap from day one. Adoption doesn't always happen right away, and shifting how people perceive a tool can take longer than shipping the feature itself. Building a great product is part strategic vision, part user feedback, and part enablement and awareness. We try to stay grounded in how the product is used today, while still leaving room to make strategic bets for the future.
5. Open source travels farther than you can see
This last lesson might be the most encouraging. Building on open-source foundations has compounding value: it lets a community grow around a project in ways a closed, corporate roadmap never could. Adoption of developer tools still runs mostly on word of mouth, so we pay attention to every signal we can get: issues opened on GitHub, who shows up to our community calls, conversations at developer conferences, and Red Hat customers reaching out with questions of their own. Case in point, through those signals we've discovered large-scale corporate adoption of Podman Desktop that had been happening quietly, well before it ever showed up as a direct ask to our team.
Five million downloads isn't really about the number. It shows that people are picking up Podman Desktop and gives us more to learn about where and how they use it.
What's next
We're bringing this retro to our community call on Thursday, August 27, live, with room for questions and anyone who wants to celebrate with us.
From all of us on the Podman Desktop team, thank you for the downloads, the issues, the pull requests, the extensions, and the honest feedback that keeps teaching us these lessons. Here's to the next 5 million. 🚀
