---
# Why the Fedora Sandbox Would Have Helped Podman Survive Its Early Days

**URL:** https://crunchtools.com/fedora-sandbox-podman-early-days/
Date: 2026-03-11
Author: fatherlinux
Post Type: post
Summary: I’ve been following the conversation around Jef Spaleta’s Fedora Sandbox proposal with a lot of interest, and I think it’s worth sharing some perspective from someone who lived through exactly the kind of situation this framework is designed for. When Podman was getting started, we didn’t have anything like a structured lifecycle process in Fedora,Continue Reading "Why the Fedora Sandbox Would Have Helped Podman Survive Its Early Days" →
Categories: Articles
Tags: Community, Container Engines, Container Tools, Fedora, Open Source, Product Management, Red Hat
Featured Image: https://crunchtools.com/wp-content/uploads/2026/03/gemini_gen_20260311_203447_9d86f15a.png
---

I've been following the conversation around Jef Spaleta's [Fedora Sandbox proposal](https://discussion.fedoraproject.org/t/a-modest-proposal-a-technology-innovation-lifecycle-process-for-fedora/182435) with a lot of interest, and I think it's worth sharing some perspective from someone who lived through exactly the kind of situation this framework is designed for. When Podman was getting started, we didn't have anything like a structured lifecycle process in Fedora, and looking back, I think having one would have made a real difference in how the project matured, how we communicated about it, and how we justified the investment during the years when its survival was genuinely uncertain. None of what I'm about to describe is unique to Podman, and that's kind of the point. Every new open source project, every startup, every internal side bet at a big company faces the same set of pressures. The question is whether you have infrastructure to help you navigate them, or whether you're just making it up as you go.

Before I get into the details, I should say that I'm not trying to relitigate old battles or point fingers at anyone. The Podman story had a good outcome. But I think there's a tendency in the open source world to look at successful projects and assume that the success was inevitable, that some combination of technical merit and community goodwill carried it through. The truth is that we came pretty close to not having enough resources to keep going at several points, and I think the Podman journey illustrates exactly why a framework like the Fedora Sandbox matters, not just for corporate-backed projects, but for any new technology trying to find its footing inside the Fedora ecosystem.

## It Started with Skopeo

Most people think the container-tools story starts with Podman, but it actually starts with [Skopeo](https://developers.redhat.com/articles/2025/09/24/skopeo-unsung-hero-linux-container-tools). Back in 2016, Antonio Murdaca wanted a way to inspect container image metadata on a remote registry without having to pull the entire image down to your machine. He opened a pull request upstream with Docker to add a `docker inspect --remote` capability, and the Docker maintainers rejected it. Their response was basically, "container registries are just web servers, go build your own tool." So in classic fashion, Antonio just went off and built it himself, and the tool he ended up with was Skopeo, which is Greek for "remote viewing," and at the time it was just this tiny binary that could talk to registries directly.

Once Antonio had a tool that could inspect images, he figured he might as well pull them too. Once he could pull them, he figured he could push them. The `containers/image` library got extracted from Skopeo's internals, and before long there was a reusable foundation for building container tools that didn't depend on the Docker daemon at all. One rejected pull request kicked off a whole alternative set of tools, though I don't think any of us were thinking about it in those grand terms at the time, we were just solving problems as they came up.

When I look back on that period, I think that's where a formal process like the Sandbox could have first started to help us. Skopeo was a side project, a useful tool born out of frustration with an upstream that wouldn't accept a patch. It didn't have a team behind it, it didn't have a roadmap, and nobody was making decisions about whether to invest more resources in it, it was just a thing that existed and worked. In a Sandbox model, a project like Skopeo could have entered at the experimental stage with low requirements, gotten some visibility, and started building the kind of community engagement metrics that help justify further investment.

## From Skopeo to Podman: The Expanding Vision

By 2017, Dan Walsh's team was working on [CRI-O](https://medium.com/cri-o/introducing-kpod-f06109b96374), and they realized that when administrators set up Kubernetes clusters, they needed a way to debug containers on the host without depending on the Docker daemon. If Docker's daemon hung, you couldn't inspect images, couldn't see which containers were running, couldn't diagnose anything. So they built kpod inside the CRI-O project, then separated it out and renamed it Podman, for Pod Manager. Dan had been working on container security and SELinux policy for years, and he had strong opinions about the daemon-based architecture. Ben Breard and I were the technical product managers, and we had an intern helping write code, if I remember right, so that was the whole team we had to work with.

Meanwhile, Buildah was taking shape as the build tool, and all of these tools shared the same underlying libraries, `containers/image` and `containers/storage`, which meant they could work together seamlessly without any of them requiring a central daemon. We were, maybe without fully realizing it at first, applying the old [Unix philosophy](https://www.redhat.com/en/blog/say-hello-buildah-podman-and-skopeo) of small tools that each do one thing well to the whole container management problem.

To put this in context, you have to remember where Docker was at this point. By 2017-2018, Docker was still the dominant name in containers, but the cracks were starting to widen in ways that mattered. Docker Swarm was losing the orchestration war to Kubernetes, and the company was struggling to figure out how to turn a wildly popular open source project into a sustainable business. There was an opening, but it wasn't obvious to most people yet. If you were paying close attention to the architecture, you could see that the centralized daemon model had real limitations for security and systems management. But "paying close attention to the architecture" describes maybe a few hundred people in the world, and the rest of the market just saw Docker as the standard.

I think people who don't work inside large technology companies have this idea that projects at places like Red Hat get started with executive sponsorship, dedicated budgets, and a clear path to productization. In my experience, that's not how it works at all. Most projects start as side bets, passion projects that a small group of engineers believe in strongly enough to invest their own time and political capital in. The company doesn't commit real resources until the project proves it has legs, and proving it has legs means demonstrating community traction, technical viability, and some evidence of market fit, all at the same time, often with minimal support. This is no different from what a two-person startup faces, or what an independent open source maintainer faces when they're trying to get their project noticed. The scale is different, but the dynamic is the same.

## The Constant Pressure to Justify

It's not like there was ever some big dramatic moment where an executive tried to kill Podman, because that's not really how these things play out inside a big company, or anywhere else for that matter. What you get instead is this constant, grinding pressure to justify expansion of the team every single planning cycle. You start with a handful of engineers writing code, and that's fine as a proof of concept, but to become a real project you need QE, you need documentation writers, you need dedicated engineering resources, you need someone thinking about the user experience, and every one of those resources has to be justified against other priorities over and over and over again.

I think it's important for people in the Fedora community to understand this dynamic, because it applies to pretty much every new project, whether it's backed by a company or not. Large companies are for-profit entities with budgets and quarterly planning cycles, and they don't fund things indefinitely out of goodwill. Open source community traction is one of the most important metrics that companies use to decide whether to keep investing, because community adoption is a leading indicator of market demand. If nobody's using it, nobody's going to pay for support. That math is the same whether you're at a startup trying to close your next round of funding or an engineer at a big company trying to get headcount for your project.

The Sandbox framework's time-boxed gates would have helped here in a concrete way. Instead of having to make the case from scratch every quarter, we could have pointed to a defined set of criteria and said, "here's where we are on the maturity curve, here's what we've achieved since the last review, and here's what we need to hit the next gate." That's a much more productive conversation than the vague, recurring "is this project worth it?" that most new initiatives end up having.

## The Perception Problem

You'd think all the hard work would be in the code, and a lot of it was, but looking back, I think the real fight we were having for years was with perception. When Fedora started including Podman, you might expect that would have been a clear signal that the project was maturing. And it was, to some extent. But the community reaction was often, "well, of course Fedora includes Podman, Fedora is a Red Hat project." That framing, whether fair or not, meant that Fedora inclusion didn't carry the independent validation signal that we needed to demonstrate real community buy-in.

When I think about how the Sandbox would have changed that, it comes down to transparency. The proposal asks projects to show that they're technically sound, that people outside the original team are actually using and contributing to them, and that they solve real problems for real users. If Fedora had a formal Sandbox process with well-governed metrics, Podman's progress wouldn't have been perceived as a corporate rubber stamp. It would have been the outcome of a transparent evaluation process that any project, corporate-backed or not, had to pass through. The metrics would have spoken for themselves instead of being filtered through assumptions about who controls what.

The real milestones that started to shift external perception were inclusion in Ubuntu and Debian. When independent distributions with no corporate relationship to Red Hat started packaging Podman, that was a signal even the skeptics had to take seriously. It meant that people outside our bubble were looking at the technical merits and deciding, on their own, that this was worth including. Maybe those kinds of cross-distribution adoption signals should be the type of community engagement metric that factors into an incubation review?

Meanwhile, Docker's own trajectory kept shifting. By the time Podman was gaining real traction, Docker as a company was in the middle of a painful transformation. Docker Desktop moved to a paid licensing model for enterprises, and Mirantis acquired Docker Enterprise. The competitive landscape was reshaping itself underneath everyone, and I think having a structured way to evaluate where emerging technologies actually stand would have given the whole community better tools for making sense of what was happening.

## Graduation: RHEL Default and CNCF

Two milestones stand out as the moments when Podman clearly "made it." The first was shipping as part of the [container-tools module in RHEL 8](https://www.redhat.com/en/blog/rhel-8-enables-containers-tools-software-craftsmanship-0), with Podman, Buildah, and Skopeo all tested and delivered together in fast and stable streams. That coincided with Podman becoming the default container runtime in RHEL, which was pretty much the clearest possible signal that the project had moved from experimental to strategic. The second was getting the container tools into the CNCF, which felt like a permanence guarantee, like the project would be around for the rest of my career.

But neither of those milestones happened inside Fedora. There was no formal Fedora mechanism that said, "hey, this technology has matured and we're confident in its future." It just sort of happened gradually, and external observers had to piece it together for themselves by watching conference talks and reading mailing list threads. A graduation path from Sandbox to Incubating to Integrated within Fedora would have given partners and customers a clear, trustworthy signal about where the project stood, especially for the people who watch Fedora as a leading indicator of RHEL direction.

## Making Fedora the Place Where Projects Come to Grow

Everything I've described about Podman's journey applies to any new project trying to establish itself in the open source world, and this is where I think the Sandbox proposal gets really interesting. It's not just about managing risk for Fedora's existing ecosystem, I think it could make Fedora a genuinely more attractive place for small projects that are looking for a structured path to maturity.

Right now, if you're a small open source project and you want to grow, your options are pretty limited. You can apply to the CNCF, but that's focused on cloud-native infrastructure and comes with its own politics and resource requirements. You can try to get your project packaged in a major distribution, but that's a binary decision with no graduation path, you're either in or you're not. There's no established framework that says, "bring your project here, we'll give you a structured environment to experiment, clear criteria to meet, and a path to broader adoption if you succeed."

The Sandbox could be that framework for Fedora, and I think it would be genuinely differentiated in the Linux distribution space. Most distributions compete on stability, package count, release cadence, or desktop experience, and those are all important, but they're also increasingly commoditized. What's harder to replicate is a culture and a process that actively nurtures new projects with real guardrails, a place that welcomes experimental work, gives it structure and visibility, and provides a credible graduation path that the broader industry recognizes.

I've been describing Fedora internally as something like a research university for open source technology. The analogy isn't perfect, but I think the core of it holds up. Universities don't just teach established knowledge, they provide an environment where new ideas get explored, tested, and either developed into something real or set aside without anyone treating it like a failure. The Sandbox proposal, with its explicit off-ramps and sunset provisions, captures that same spirit. Not every experiment succeeds, and that's actually how it's supposed to work. The important thing is having a process that makes visible, to everyone watching, whether a technology is still finding its footing or has graduated to something sustainable.

## Making It Real

Before people start arguing in the comments, I know the Sandbox proposal has real issues, and I've been watching the discussions about whether it adds too much bureaucracy or whether we even have the infrastructure for it, and those are all things that have to be figured out. But the core idea is sound: Fedora needs a structured way to introduce, evaluate, and either graduate or retire experimental technologies. I lived through what it looks like without that structure, and while Podman survived and thrived, I think it would have been a smoother and more transparent journey if something like the Sandbox had existed back then.

More importantly, I think the Sandbox could make Fedora something more than a proving ground for RHEL. It could make it the place where the next Podman comes to grow up. Projects like [RamaLama](https://github.com/containers/ramalama) or the [Command Line Assistant](https://github.com/fedora-llm-project/command-line-assistant) based on Goose are exactly the kind of technologies that would benefit from a structured incubation path, a way to experiment in the open, demonstrate community traction with real metrics, and either graduate to broader adoption or sunset gracefully. I think that's a pretty good deal for smaller projects or even just a couple of folks with a new idea, and it's probably useful for other companies too who want a real-world place to get something off the ground without all the ceremony of something like the CNCF. The Linux distribution landscape is tough to differentiate in, but building the infrastructure for structured innovation is something that nobody else is really doing right now, and I think Fedora is in a good position to pull it off.

---

## Categories

- Articles

---

## Navigation

- [Home](https://crunchtools.com/)
- [Articles](https://crunchtools.com/category/articles/)
- [Events](https://crunchtools.com/category/events/)
- [News](https://crunchtools.com/category/news/)
- [Presentations](https://crunchtools.com/category/presentations/)
- [Software](https://crunchtools.com/software/)
- [Beaver Backup](https://crunchtools.com/software/beaver-backup/)
- [Check BGP Neighbors](https://crunchtools.com/software/check-bgp-neighbors-nagios/)
- [Chev](https://crunchtools.com/software/chev-check-vulnerabilities-script/)
- [Graph BGP Neighbors](https://crunchtools.com/software/grpah-bgp-neighbors/)
- [Graph MySQL Stats](https://crunchtools.com/software/graph-mysql-stats/)
- [Graph Sockets Pipes Files](https://crunchtools.com/software/graph-sockets-pipes-files/)
- [MCP Servers](https://crunchtools.com/software/mcp-servers/)
- [Petit](https://crunchtools.com/software/petit/)
- [Racecar](https://crunchtools.com/software/racecar/)
- [Shiva](https://crunchtools.com/software/shiva/)
- [About](https://crunchtools.com/about/)
- [Home](https://crunchtools.com)

## Tags

- Community
- Container Engines
- Container Tools
- Fedora
- Open Source
- Product Management
- Red Hat