Fedora ponders a "sandbox" technology lifecycle

Fedora Project Leader (FPL) Jef Spaleta has issued a "modest proposal" for a technology-innovation-lifecycle process that would provide more formal structure for adopting technologies in Fedora. The idea is to spur innovation in the project without having an adverse impact on stability or the release process. Spaleta's proposal is somewhat light on details, particularly as far as specific examples of which projects would benefit; however, the reception so far is mostly positive and some think that it could make Fedora more "competitive" by being the place where open-source projects come to grow.

Spaleta said some people may have already heard about his idea, which he has been calling the "Fedora Sandbox". It would be used to test, refine, and validate "experimental features, components, output, process or services" without a commitment to integrate any of the experiments into Fedora. The technologies that would be appropriate for the sandbox are those that need to mature or prove themselves in some way. For example, a technology may need time to become stable enough to rely on, or it may be stable but need to demonstrate that there is enough community interest to sustain the technology long term.

He has outlined several objectives for the sandbox. The first is to foster innovation in Fedora by encouraging contributors to bring new ideas forward that might not be mature enough for direct inclusion in Fedora. Another is to isolate risk; by sandboxing a project, it can be worked on as an experiment that won't affect other Fedora components or negatively impact its users. He positioned the sandbox idea as a way to provide a clearer path for inclusion as an official Fedora feature, service, etc. As it stands now, there is a bit of a murky land between a project being a brand new idea and its readiness to be included in Fedora. Spaleta also hopes to use the process as a more formal way of gathering feedback on technologies and to promote transparency in the project.

Fedora already has a mechanism for proposing innovations in the form of its change process. The Fedora Sandbox proposal does not supplant that; projects that make it through the integration stage are then expected to be proposed as a change. So, even if an experiment makes it all the way through the sandbox, it is not guaranteed to be adopted—though it would seem highly probable at that stage. The sandbox process would not be needed for changes that are already well-covered by Fedora's existing process. So, for example, it would not be necessary to put a new release of GCC through this process in order to include it in Fedora.

The proposal

Spaleta suggested a few potential stages for a project going through this process: sandbox, curation, and integration. If an experiment is unsuccessful in moving through the incubator, then it is moved to a fourth stage: retirement.

To enter the sandbox stage, maintainers of an experiment would need to demonstrate that it might be a fit for Fedora and specify the exit criteria as well as the timeline. Applications to enter the sandbox would be reviewed either by the Fedora Engineering Steering Committee (FESCo) or a designated working group.

Maintainers would have to provide quarterly updates on the sandbox project and any packages or features that go with it would need to be clearly labeled as "Fedora Sandbox" components. The maintainers would also be responsible for active participation in some dedicated communication channel, such as a mailing list or Matrix room, to get feedback from the larger community.

When the maintainers feel that the project is ready to exit the sandbox, the team would submit a request to FESCo to decide its fate. The council could allow the project to fully graduate and move to the integration stage, extend its time in the sandbox if the graduation criteria has not been fully met, or decide that the project should be wrapped up and retired altogether.

FESCo could also decide to send the project on to curation if the project has met its stated exit criteria, but the council feels there are other deficiencies that need addressing or refinements that need to be made. For example, FESCo might find that a project met its initial release criteria but decide that it does not yet have sufficient community interest and engagement. In that case, it would be sent to curation and have a fixed amount of time to drum up sufficient community interest to satisfy FESCo that it should graduate. Curation is meant to have a firm exit date; 12 months is the current suggestion. FESCo would conduct a mandatory review when the time is up. Again, FESCo could decide to let the project graduate and attempt to integrate into Fedora, extend its time in curation, or retire it.

If a project makes it to the integration stage, then it would need to submit a "symbolic" change proposal according to Fedora's usual process that FESCo could approve. Projects may also be subject to maintenance reviews even after they graduate the sandbox, and could be kicked back to the curation stage if they are found to be struggling.

Handwavy

The proposal is a bit handwavy; this is not surprising or unreasonable. There is little point in putting a great deal of detail into a proposal at this stage when the community may balk at the very idea. It is something of a rookie mistake to flesh out every detail of a proposal when it has not been established whether there is an appetite for it or not; the finer points can be worked out if the community doesn't shoot down the basic idea. It is a bit surprising, though, that Spaleta hasn't provided any concrete examples of projects or technologies to help illustrate the need for an incubator. Previous Fedora discussions may provide a clue, though.

When Fedora discussed its AI-assisted contributions policy in October 2025, the conversation exposed some unhappiness by Red Hat leadership with Fedora as an "innovation engine" for RHEL. There was more than a little pushback from the Fedora community on accepting AI-assisted contributions, but Red Hat and IBM are investing heavily in AI. Mike McGrath, Red Hat vice president of core platforms, complained about objections to doing experiments with AI, including letting AI determine if a contribution is accepted:

At a bare minimum I'd like to see Fedora get in front of RHEL again with a more aggressive approach to AI. Not just in how we build Fedora but formally opening the doors to AI contributors and data scientist so that Fedora is their first stop shop. I'd hate to see a scenario where Fedora's policies make it a less attractive innovation engine than even CentOS Stream.

In another comment, McGrath said that the point he wanted to make is that it wasn't possible to improve a technology if it was banned before getting started. "We can't even reasonably see how Fedora would make such a system if its not allowed".

The Fedora Council report on its recent strategy summit pointed to another project that Red Hat has been trying to interest the Fedora community in testing and adopting, but with little traction so far. The Konflux project is an Apache-licensed, continuous integration and delivery (CI/CD) platform for building, testing, and releasing software artifacts—including bootc images and RPMs. Fedora already has, and many contributors are already comfortable with, the venerable Koji build system—but Red Hat has moved to or is moving to using Konflux internally for its own products. Koji is getting a bit long in the tooth, and Red Hat probably has little use for it outside of Fedora at this point. It is not entirely unreasonable that the company might want to move things along with moving Fedora to Konflux, but volunteer contributors may not see any direct benefit in learning yet another system.

The thinking within Red Hat may be that a sandbox process with more lightweight approvals would help with some of the corporate-led initiatives that have few supporters in the larger Fedora community. One thing that is not entirely clear in the sandbox proposal is where community feedback comes into the picture: Fedora's change process requires an announcement and opportunity for the larger community to provide feedback. It is unclear whether Spaleta envisions such an announcement and community engagement for experiments proposed for the incubator.

Spaleta noted that the proposal "had a genesis" in the Red Hat Enterprise Linux (RHEL) 11 planning discussion he had sat in on as FPL. Fedora's role in RHEL development, and corporate dissatisfaction with it, may well have been on the agenda. Going directly to FESCo, without the more stringent requirements of a change proposal, could allow Red Hat to conduct some experiments more quickly without significant pushback. The change proposal prior to integration would then provide the community with a chance to object even if FESCo, which is typically made up entirely or almost entirely of Red Hat employees, favors a technology. But, at that stage, it may be much harder for the community to block a change if it has been proven to be technically feasible.

Reactions

Spaleta asked for the initial discussion to focus on the high-level structure of the proposal: would it help Fedora in cultivating sustainable ideas and in weeding out unsustainable ones? If there was consensus on the bones of the proposal, then it would make sense to drill down into more of the details and nail down how everything would work.

Julia Bley wondered if the "increased bureaucracy" would turn FESCo into a bottleneck or waste people's time on crafting proposals. Spaleta said that he did not see it as an increase in bureaucracy; technology entering Fedora has to go through FESCo somehow anyway. The proposal also makes it possible for FESCo to delegate the work to a working group. His concern, "having had a lot of quiet conversations", is that there is a bias against experimenting within the Fedora project.

There were several concerns about how a sandbox process would fit with existing Fedora processes and infrastructure. FESCo member Fabio Valentini said that the proposal sounded worthwhile, but asked for details about how it would work. For instance, where would sandboxed experiments host alternative versions of packages that are already in Fedora? He also imagined that a sandboxed project might have alternative kernel packages or ship kernel modules that are not in Fedora's kernel; either of those scenarios would violate Fedora's current packaging guidelines.

Spaleta said that he fully expected projects would break "non legally binding" Fedora policy in the sandbox and curation stages. "For policy violations that survive from sandbox to curated, we have to have a reasonable path forward towards resolution in time for integration". How a project could solve those problems during the curation period would be part of the sandbox exit review discussion. Projects would seem to be expected to comply with any Fedora policies around licensing or that prohibit shipping certain technologies for legal reasons, but other policy would be, effectively, optional.

Fedora Infrastructure lead and FESCo member Kevin Fenzi also worried that it might be a burden for FESCo, but said it might be acceptable depending on how many projects were active at one time. He also asked how the infrastructure for the sandboxed projects would be handled. He did not want to throw projects to the wolves and tell teams to build things on their own dime, but he also did not want to provide fully staffed and resourced infrastructure; he suggested a middle ground that used AWS or the Fedora community's OpenShift instance, Communishift. Spaleta said that any requirements would be part of a sandbox proposal; the infrastructure team could say no if it didn't have the capacity. "I'm also hoping that if we do this correctly, the infra team is able to mentor a group through the curation stage if there are special infrastructure needs to get to fully integrated."

Fenzi had also asked if Spaleta had any examples of good candidates for the process. That was a chicken-and-egg problem, Spaleta said. "The best question that could be asked right now is what would have gone better in the past if this were a process available?" He seemed reluctant to provide any actual examples of current or past projects that needed a sandbox process.

Michel Lind felt that discussions about adopting Konflux would have been easier with the sandbox framework in place. Spaleta said that experience was reasonable to think through in the context of the sandbox proposal:

My view is, how Konflux has been introduced is effectively a very loosely defined sandbox, with a false start or two. It's on a path towards integration now because it's started to get some traction from contributors interested in using the technology. But there is less clarity on the expectations on what a sustainable konflux implementation for Fedora looks like, and as a result there is more anxiety about it than there really needs to be. A lifecycle process with clear stage exit expectations and review points may have helped get clarity around what is expected from a sustainable Konflux integration.

Justify your existence

Scott McCarty, who is a product manager for Red Hat, said that a Fedora sandbox would have been helpful when teams at the company were trying justify resources to develop the Podman project. Fedora's adoption of Podman was seen as a "rubber stamp", and not a validation of the market interest in the project. "Real validation came from Ubuntu and Debian picking up Podman independently". He reasoned that a sandbox process might change that for future projects and make Fedora's stamp of approval carry more weight.

He also wrote a blog post that went into more detail about Podman's history and the need for Fedora to become a place for projects to incubate. The post provides more detail about the need to justify Podman's existence and resources inside Red Hat, and how the sandbox might have helped in that regard:

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 [quality engineering], 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.

McCarty made the case that a sandbox would be useful to help differentiate Fedora from other Linux distributions. Distributions today "compete on stability, package count, release cadence, or desktop experience", all of which are important but are effectively commodities. What would be harder to replicate, he said, is a culture and process that nurtures projects, welcomes experimental work, and provides it with visibility. He also acknowledged the concerns about adding too much bureaucracy and stressing Fedora's infrastructure, but argued that the core idea of the sandbox is sound.

Somewhat ironically, Spaleta's proposal for a structured process to incubate technologies with time-boxed stages does not, itself, have a specific timeline for feedback or next steps. It has attracted modest interest and no strong opposition so far; presumably, at some point, he will gather up the feedback and revise the proposal for additional feedback or move it along to the Fedora Council.