The Fedora project grapples with change

Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN . Thank you for visiting LWN.net! By Joe Brockmeier July 20, 2026 The Fedora Project is known for, among other things, having a well-defined set of processes for just about everything. It has extensive packaging guidelines that deal with the complexities of creating RPMs to install software, as well as processes for managing the legal questions that arise around shipping software. Fedora also has a well-defined change process for dealing with self-contained technical changes as well as major changes to the distribution , and other issues as they arise. At the moment, though, the project seems to be experiencing a sort of midlife crisis as it re-examines several of its change processes at once to determine if they are still effective.

As a vendor-sponsored project, Fedora has always had to walk a difficult path in serving its users, contributor community, and corporate masters; what makes one party the happiest may be a source of angst for another. Red Hat's desire to trial technologies in Fedora does not always spark joy among contributors and users. Volunteer contributors may want to push ideas that are of little interest to Red Hat (at least at the time), or may even conflict with its choices. For example, Fedora's choice of Btrfs as the default filesystem contrasts with Red Hat's decision not to support it in Red Hat Enterprise Linux (RHEL).

Users want easy access to problematic software, such as patent-encumbered games or codecs , but shipping those could create expensive legal headaches for Red Hat. Attempts to make Fedora more user-friendly, say by setting the default for the $EDITOR environment variable to GNU nano , may not please some developers .

Fedora had little in the way of governance or policy when the project launched in 2003 as a kind of replacement for Red Hat Linux . Early on, Red Hat entertained the idea of creating a "Fedora Foundation" that would give the project some independence, and then pulled back from that in 2006. Some of the mechanisms that were put in place in anticipation of the foundation, such as a Fedora Board and Fedora Extras Steering Committee, evolved into the Fedora Council and Fedora Engineering Steering Committee (FESCo) over time.

There have been a number of times when there was friction between corporate and community priorities; but the project has more or less made it work over the years. It has done this by discussing the problems, finding some kind of consensus, documenting the policies that are hammered out along the way, and then using them for new decisions. See, for example, Tom Callaway's overview of how Fedora's legal policies were developed . Over the years, Fedora's governance and policies have become something of a model for other open-source projects.

The project's governance has had one constant: Red Hat has the final say. As former Fedora Project Leader (FPL) Max Spevack noted when Red Hat dumped the idea of an independent foundation:

Red Hat *must* maintain a certain amount of control over Fedora decisions, because Red Hat's business model *depends* upon Fedora. Red Hat contributes millions of dollars in staff and resources to the success of Fedora, and Red Hat also accepts all of the legal risk for Fedora. Therefore, Red Hat will sometimes need to make tough decisions about Fedora. We won't do it often, and when we do, we will discuss the rationale behind such decisions as openly as we can.

Just because Red Hat has power over Fedora does not mean that the company wants to use it, he said. Nor did it want to make all the important decisions about Fedora: effective community-driven decision making would be a direct measure of Fedora's success. " We aim to set the standard for open source innovation. A truly open Fedora Project is what makes that possible. "

In the past year or so, though, the project's processes that have worked until now seem to be coming into question more and more often: usually when they seem to butt up against Red Hat's priorities. For example, last year's deliberation on Fedora's AI-assisted contribution policy that showed a disconnect between Red Hat's desire to experiment with AI in Fedora and contributors who wanted Fedora's policy to be much less friendly to AI.

In March, current FPL Jef Spaleta proposed a technology-innovation-lifecycle process he dubbed the "Fedora Sandbox" for " experimental features, components, output, process, or services ".

The driver for Spaleta's sandbox idea seemed to be related to frustrations that Red Hat leadership had with pushing its experiments into Fedora; the project's existing processes, which involve compliance with Fedora's strict packaging and license policies as well as a need to gain community buy-in, could slow or stymie acceptance of things Red Hat was going to do for RHEL anyway.

Having to maintain those projects outside of Fedora, which ultimately serves as the foundation for a RHEL release, is a likely source of frustration for folks working on both—not to mention their managers and Red Hat leadership who (not unreasonably) just want features to land in RHEL on schedule to make customers happy.

Spaleta's sandbox process would have allowed experiments to be conducted in Fedora even if they broke " non legally binding " policies as long as they had a " reasonable path forward towards resolution " before being fully integrated into the project or distribution. He proposed that the sandbox would be in addition to the existing change processes and community initiatives that can be used to set longer-term goals for Fedora, such as the completed initiative to create the Fedora IoT project, or the current Git Forge initiative to replace the Pagure collaboration platform with the Forgejo -based Fedora Forge service. The sandbox proposal has not been accepted (or rejected) yet.

Red Hat developer Gordon Messmer proposed an AI developer desktop initiative, on March 31, with an aim to " build a thriving community around AI technologies " within Fedora. That proposal met with some opposition from the community, with objections ranging from a dislike of AI to complaints about potentially changing Fedora's policy for out-of-tree kernel modules. Ultimately the proposal was discussed by the Fedora Council, initially approved , and then blocked at the last minute when council member Justin Wheeler changed his vote on May 8. Council member Miro Hrončok, likewise, also changed his vote on May 13 saying that " the Fedora community is not supportive of this initiative as is ".

Another Red Hat idea, an automated approach to building an operating system called Project Hummingbird, was raised on the Fedora development list in April. It was greeted with some interest, as well as some confusion about how it might differ from other Fedora variants, but it didn't seem to face much opposition. It was never formally proposed, though McCarty said he planned to do so through Spaleta's sandbox initiative.

Instead, Red Hat bypassed public processes entirely. It asked the council in private for approval to use the Fedora trademark so that it could announce the project at Red Hat Summit on May 12. Fedora contributors outside of Red Hat were surprised and confused by the announcement. Michael Gruber, for example, wondered whether Hummingbird was legitimately a Fedora project or not. " There might be even some good ideas in there, but given how this started and how it is communicated I can put zero trust in this. "

Red Hat employee and Fedora contributor Adam Williamson said it would have been ideal for Red Hat to make the request more openly, but he was happy that the company was trying to do the Hummingbird project within Fedora rather than doing an end run around the project. The more Red Hat has to do outside Fedora, he reasoned, the greater the risk that the company will question its funding of the project.

From inside Red Hat, especially if you don't work on Fedora, it is possible/tempting to look at Fedora as a source of strife. It's got all these people in it, with opinions, who aren't on the payroll! You can't tell them what to do or think or complain to their manager! They have eternal arguments about everything! You have to write a wiki page and convince some person you've never heard of that your idea is good! Who needs this?

So we're kind of constantly fighting a tendency for RH to just spin stuff up in channels it 100% controls, which tends to seem easiest at first then turn out to be a mess after a few years.

Christopher Klooz, however, worried that the funding justification meant that Fedora could be " step by step transformed into a corporate unit of RH ". He added that it was already unclear " when the Council acts as agent of RH and when as agent of the community ".

Williamson replied that he understood the point, but said that this was a " an ever-present tension " that Fedora has had to manage nearly as long as it's been around:

Red Hat employees who care about Fedora, he said, have to keep selling that vision and making sure that it works. The Hummingbird discussion petered out not long after Williamson's reply, but it appears that Fedora's decision-making bodies have been mulling over how things are done.

On July 1, Aoife Moloney, Fedora's "change wrangler", announced that the Fedora Council was proposing a pause to Fedora's community initiatives process. Existing initiatives would continue as planned, she said, though " the administrative framework around them may evolve ".

The AI developer desktop, she said, had shown that the initiatives process had failed as a framework " where new ideas can surface, receive respectful feedback, and gain Council support for work that fits the project's present and/or future ". The nature of the failure, however, was unspecified. One can imagine that the various participants in that discussion might well agree that something had not gone well, but what that something was would depend entirely on the observer's point of view.

The council, Moloney said, wanted to work out a new method of setting strategic direction " in an open, transparent way that more intentionally includes the community voice ." The council recognized that it needed to be " better at being more open in our discussions and decision making " because much of the work that leads to proposals " happens under the radar before official approval processes kick in ". At the moment the existing " approval pipeline " for initiatives involves the council performing trademark review, and then FESCo reviewing change proposals. That works well, she said, but misses " early and inclusive discussion for everyone across the project ". Therefore, the council would be looking at the sandbox proposal closely as an alternative to initiatives or as a complement to some other process that it might develop.

The announcement phrased the pause as a proposal, but Moloney also closed the discussion on the AI developer desktop proposal saying that the council was now unable to consider it " as a result of halting the Community Initiatives process ." The council would return to the question of " whether Community initiatives should be retired or revamped once this discussion has reached some kind of conclusion ".

Shortly before the council had made its announcement, FESCo member "Maxwell G" started a discussion on the Fedora development mailing list to gather feedback on how the changes process could be improved. He said he was not proposing anything specific, but wanted to throw out some ideas and see what other people thought.

For example, he wondered if it was time to move away from using Fedora's wiki for proposals, as well as the Wikitext formatting that goes along with it. The