I too have thoughts on the base image and would like to share them regularly and often. I don’t see myself on any of those teams, but willing to join if thats theres any value I can provide.
I knowingly agree to be bothered by nimbinatus on a regular basis.
Thanks for putting this together @nimbinatus 
I think being explicit about having the infra team involved would be good, even if in practice most folks from Release Engineering also contribute to the infrastructure.
I believe it would be good to have folks from Konflux upstream too.
I think we could target naming/website identity for Fedora 44. I would love to have Image Mode being more visible on getfedora.org. I also wonder if we could target to have a good adoption and contributions metrics systems. If we do this in the F44 cycle it would give us a good baseline to measure the impact of future changes.
I would be happy to volunteer to help drive these changes.
I’ve been working on setting up CoreOS builds on konflux so I’d happily join that discussion.
I am interested in attending the base images discussion as well
I read this thread, but I don’t understand what the idea of the universal installer is. Can someone here briefly and in concrete terms explain what is meant by it?
@nimbinatus: you can’t layer Flatpaks, but you can install them. Maybe this can better be done during the GNOME initial setup?
I think you are getting some of this engagement already! And for what you are not getting, I can try to offer some pointers.
I already see @joseph in this topic. At the moment, between him and me, this is the persistently-present Fedora Marketing Team. 
So, I think you are getting this input.
I for one always appreciate the thoughtful input and perspective @joseph brings to the conversation around these things. He has a lot of lived experience and wisdom in driving and running our Fedora social presence and brand voice. While he may humbly only take credit for running the Mastodon, I also think he has helped refine the overall Fedora “voice” in a lot of our external outreach.
I’m not sure a Fedora Docs Team perspective is what you need. Is it? I see the Fedora Docs Team as providing more guidance on the technical bits and pieces of helping teams set up their own documentation site inside the web of things with Fedora. While there is probably some institutional knowledge in terms of “what is and has been named in Fedora”, I think the Docs Team would have less input here until there is something more fully-baked and ready to publish.
Beyond naming, as I scroll through the topic, I see Fedora Docs get called out a lot. I will let @pbokoc and @pboy weigh in on the callouts and whether they see opportunity and potential for the Docs Team to contribute on the called-out areas of the Image Mode Initiative.
Community Ops focuses on contributor experience and data & metrics. I am not sure this is relevant for the naming, but I think there is a role that Community Ops could play as things get going and the focus is more on rallying the contributor community.
Ambassadors is tricky, but this will be more of our external folks who deliver a message outward to the wider public and our user community at events. I think Ambassadors would benefit more from clearly-defined talking points about how to communicate about an Image Mode Initiative, or whatever name is settled on in the end.
@ekidney and @madelinepeck always have incredibly thoughtful feedback as visual and web designers. I think they have valuable input on a Fedora brand and identity perspective, as the stewards of the Fedora Brand Book.
For the website, you want to look more into the Websites & Apps Team, which is more or less led by @glb and @darknao. They are pretty active on #websites:fedoraproject.org on Matrix.
Atomic Desktops please 
IIRC Fedora CoreOS and Fedora IoT can use either the Simplified Provisioner or the Anaconda graphical installer which all Fedora Desktop editions used prior to Fedora 42.
Note that all Fedora deliverables except the Fedora Server install images are, by definition, image based deliverables. They all install complete images and are atomically applied to systems.
The major difference is that post-install updates are done normally with the package manager. So using “image based” to describe Atomic vs mainline Fedora isn’t a useful distinction either.
This isn’t going to happen. The Fedora strategy has been to provide marketable focused deliverables, which is the strategy pioneered by Ubuntu. Ubuntu proved that the categorizations matter. And among other things, the high level parts of Fedora (e.g. Council and Mindshare) are only able to reasonably communicate to the broader world about Fedora because of this.
And a reminder, there is no capability to develop the necessary features for what you’re asking for in Anaconda.
Have you thought about what you would do if it turns out that a shift away from what you think you want to do now is required? Have you defined what success looks like for every stage and what failure looks like too? Knowing these things can help us identify whether additional support is needed or to prevent wasting resources.
This has to be part of the plan at the start. If you don’t, you risk another collapse like what happened with the Fedora Containers work.
This success condition needs to be in place from the beginning, before you start anything. Otherwise delays will slowly whittle this away.
Make it simple before you try to make it hard. Do absolutely everything assuming you don’t have super-complicated technologies in place to support it. Volunteers cannot run that kind of stuff. If you make sustainability require complex technologies people can’t run, it will become a problem in the future.
I’d rather us not use any terms that are associated with RHEL. Can we please come up with something of our own?
How about something akin to “container native initiative” instead of image mode? My limited understanding of this whole thing is that all of this is based on bootc, and bootc is afaik part of the CNCF, and one of Fedora’s missions is to be as upstream as possible, so selecting a name that’s defined as being a part of an open ecosystem should be a good starting point for the naming of the initiative.
It would still be associated with Red Hat, since afaik Red Hat was the one who gave the CNCF bootc (again, I have limited understanding, correct me if I’m wrong), but it would signal being a part of the open ecosystem of the CNCF and bootc (and related projects)
Well, I think part of the idea is that we want a name that could also be used if a different stack is used in the future. Tying ourselves to CNCF terminology would not be great in that respect.
Not to mention, the CNCF and things associated with it are divisive in the Linux space for a variety of reasons.
Could somebody please put a call together to discuss this? Naming things is way too difficult to do in a mailing list/chat thread. Who is “responsible” and “accountable” (to use the RACI, Responsible, Accountable, Consulted, and Informed nomenclature)? As a RHEL person, I’m likely only consulted, or informed, which I’m fine with, but it’s painful to see this conversation drag on so long. Naming things is hard. We all know that. Typically, on the product side, we just defer to the product marketers because you’re never going to get it right, and never going to make everyone happy. Also, IMHO, no single person should have veto power just because.
Kind Regards
Scott M
Just my 5 cents: I think Fedora Atomic Desktop sounds quite powerful!
I already imagine a big powerful and colourful banner!
Generated with AI (mock-up for the website):
Edit: I’m getting an error that I can only tag 10 people in a post
So if you raised your hand to help, I’m tagging you, but otherwise I’m just naming you. And I’m only tagging the first person in a team so I can get this posted; sorry!
Now that KubeCon NA 2025 is over, I’m back online
I’ve opened the Council ticket here: Fedora Council #549 (edit: Fedora-Council/tickets ticket #549: Renewal of the Fedora Image Mode Initiative).
I’d like to reiterate that we’re not deciding on naming yet. I get that folks have strong opinions. However, we’re going down the route of bikeshedding[1] as we try to figure out the name. For now, I’m keeping Image Mode as a reference point (since we cannot keep using “bootc”) so folks can search the relevant archives. When we do decide on a name, I’ll add a note or tag or something to each relevant thread so that archives are searchable with the right wording.
Once we get approval to move forward from Council, I’ll set up workstreams with proper RASCI charts (I’ve got you, Scott! ). We can do a lot of async work, and then those of you wanting to think about naming can argue in the branding/naming workstream 
Summing up volunteers so far:
and those volunteered by others:
I’m still missing volunteers from the following groups:
Addressing a couple additional questions:
Yes, that’s something I’ve considered for this specific initiative, as would anyone choosing to work in an experimentation space. Often a hypothesis is wrong, either fully or partially. Having a smaller space to try things out and pivot is better than doing it in the larger space where everyone else is working as you don’t disrupt everyone else. Everyone else using this space will also have to define success and failure, as well as the intermediate points where you can decide go/no-go; I don’t think there will be a universal definition for every single experiment.
I do think that’s a separate conversation, which I’m happy to move to a different thread, if needed.
Yup, I already defined that at the very beginning, in post 1:
Finally, a lot of other folks chimed in here regarding the name. Would you all like to be included in the actual meeting discussing naming (i.e., part of the responsible team or part of the consulted list)? If I do not get an affirmative from you either here or via DM on Matrix, I will assume not and will not include you on the meeting nagging list 
Instead, you’ll be part of the general informed group that will get updates at key decision points via forum posts.
For folks not familiar with the term, I reference this Wikipedia article on the law of triviality to explain it. In short, the example is of a committee designing a nuclear power plant who all focus too much on the color and materials making up the shed that will hold bicycles rather than how to actually build the power plant and design the nuclear reactors safely. ↩︎
Yes, adding docs early was completely deliberate. As a former technical writer and editor, I always think docs belongs in the beginning of the discussions of new releases and features; they often have a great perspective from users ↩︎
For folks interested, we are on the agenda for the Council today: Council Meeting Agenda 2025-11-19
Edit: The logs for the Council meeting are at Meetbot Logs
How’s the idea of a streamlined nimble initramfs, immutable and common across every system, layering another CPIO over it which contains detailed configuration for preparing the rootfs?
This would require basic support in bootc maybe, I am not too sure about all the nitpicks yet.
The discussions around “image mode” and “atomic” tend to skate over a more fundamental question: who is responsible for configuring the OS? The answer, for most Linux distributions, is the end user. Users determine their system’s state by passing their desired packages to the package manager, and the package manager configures the OS according to the requested list of packages. The distribution provides a repository of parts for users to assemble in various configurations; the user is ultimately responsible for composing their OS.
The main alternative to this paradigm is for users to all download the same pre-built base system and then layer various customizations on top. This is the model for Fedora-based “image mode” distributions.
These paradigms do not entirely align with the dichotomy between “image-based” and “package-based” systems, and characteristics like reproducibility, robustness, wire efficiency, and computation requirements all depend on implementation details. For example, MicroOS implements transactional changes of system state using btrfs snapshots, but the OS configuration is essentially user-defined. On the other hand, Google implemented “image-based” updates for their internal servers for many years by rsyncing files in-place.
While there’s a lot of discussion in this thread about technical details, one should also keep product goals in mind so that they inform the implementation and not the other way around. Here’s one possible formulation of the “image mode” initiative from the perspective of the intended user experience:
A new Fedora user in 2028 (or 20xx):
Here’s another way to phrase the two paradigms. Linux distributions were traditionally parts vendors, not system integrators. Although they may publish golden images like “Fedora Workstation” or “Ubuntu Desktop”, those are merely suggested configurations; the system package manager permits and encourages end users to remodel their OS however they like. In the other paradigm, users accept a certain rigid core of their system managed by someone else they aren’t normally supposed to touch.
/etc allows configuration.
sysexts allow layering those things that aren’t in the image
My idea of introducing configurability into an image-based initramfs (written above) while making it more streamlined, also helps if implemented. (It basically loads a second cpio for the intricate configs)
AND for really common combinations of modifications, one can just host a derived container image.
