Fedora—as a Linux distribution—will celebrate the 15th anniversary of its first release in November, though its technical lineage is much older, as Fedora Core 1 was created following the discontinuation of Red Hat Linux 9 in favor of Red Hat Enterprise Linux (RHEL).

That was a turbulent time in Red Hat history, and Fedora has had its own share of turbulence as well. Since becoming project leader in June 2014, Matthew Miller had led the Fedora.next initiative, intended to guide the second decade of the Fedora project. That initiative resulted in the creation of separate Fedora Workstation, Server, and Cloud editions—the latter of which has since been replaced with CoreOS—as well as the addition of an Internet of Things (IoT) edition.

SEE: How to choose between Windows, macOS, and Linux (free PDF) (TechRepublic)

Five years after the start of Fedora.next, the distribution is on the right track—stability has improved, and work on minimizing hard dependencies in packages and containers, including more audio/video codecs by default, flicker-free boot, and lowering power consumption for notebooks, among other changes, have greatly improved the Fedora experience, while improvements in upstream projects such as GNOME and KDE have likewise improved the desktop experience.

In a wide-ranging interview with TechRepublic, Fedora project leader Matthew Miller discussed lessons learned from the past, popular adoption and competing standards for software containers, potential changes coming to Fedora, as well as hot-button topics, including systemd.

This interview was lightly edited for clarity.

TechRepublic: Historically, there have been a variety of Linux distributions that tout themselves as being approachable for not necessarily technical users, to varying degrees of success. Fedora has never really marketed itself—as a distribution—though there have been noticeably more overtures toward addressing desktop/consumer-type papercuts. How would you describe Fedora’s target audience?

Matthew Miller: Five years ago, [we took a] look at where we were. At that time, things were a little bit demoralizing. User adoption was slumping, contributors didn’t quite know where they fit in—or [feel] that things were going in a direction they felt empowered to do something exciting. We started a project called Fedora.next… one of the things we came up with was the idea of the Fedora Edition.

Previously, Fedora had been basically a general purpose, one-size-fits-all operating system. We had a lot of conflict between people who wanted to use Fedora as a server OS—including Red Hat, who wanted to build RHEL out of Fedora as an upstream—and people who use Fedora as a daily driver on their desktop, and the desktop team wanted to make decisions to benefit those users.

We re-construed the project as more of an umbrella project, where we have a package collection and we work together on a lot of technical things, but then we have independent working groups, teams that have their own deliverables with their own market. When we started, those were Fedora Workstation, Fedora Cloud, and Fedora Server.

Through the years, Fedora Cloud has been replaced with Fedora CoreOS, as we had acquired that company, and had to find a home for them. We’re adding an Internet of Things (IoT) edition soon, as well. Each of those has its own target audience and niche, and I think some of the things you [see] as a desktop user are the fruit of that, as the desktop team had embraced their desire to have a desktop that just works.

Particularly, [Fedora] targets software developers and advanced users, but with the idea that developers are human, too. The first thing we need to do is address the making things work, and then we can work on more advanced features.

Some of our other deliverables—specifically CoreOS, the audience is people who are doing the next forefront of container development, and the next wave of how computing works in the data center and everywhere else.

We want to work in a modern computing framework with a container-focused server operating system, where you don’t have to worry about the operating system. It’s almost like the project provides operating system as a service to you, rather than something where you’re dealing with the day-to-days of managing the operating system itself. Then you can worry about the things above that, the container level.

Possible changes to Fedora’s release schedule

TechRepublic: There have been proposals, or otherwise less formal discussions, of changing Fedora’s release cadence to nine months or a year. Is this still something being considered?

Miller: We’ve come to the idea that, for the general package set release, a six-month cadence is pretty good. We want to look at how some of those editions—not just the main editions, but also things like Python Classroom Lab, things that are meant to fit more specific use cases—can release their user-focused deliverable on their own cadence, on top of that base.

CoreOS is presented as a rolling release—there is a release version underneath it that changes, but as a user you don’t care what Fedora number happens to be powering it.

We may look at that for some of the other deliverables as well. For the Workstation release, having it tied with GNOME works pretty well, because GNOME has a six-month release cadence. Maybe for Server, a once-yearly update fits better with people’s life cycles. For something like Classroom Lab, you’re tying it to academic calendars, that may make more sense than to tie to our release. We want to split those things apart, and allow different parts of Fedora to move at different speeds.

Why Fedora prefers Flatpak as the portable application standard

TechRepublic: Perhaps the biggest encumbrance users face when moving from Windows or Mac to any Linux distribution is app distribution. Distribution repositories are great for open-source software, and there are two competing standards—three if you count AppImage—for proprietary-friendly software deployment on Linux. Ubuntu uses Snap, while Fedora leans toward Flatpak. What’s the practical benefit Flatpak offers over Snap?

Miller: There are definitely some technical differences. If you talk to our engineers who are working on this, they are very, very passionate about the technical differences. One of the things with Snap is that it is the answer to all things. We see OCI Docker containers as having won the server, enterprise, and Internet of Things (IoT) use cases. [Docker] doesn’t necessarily fit well for the desktop, so Flatpak is a technology specifically meant for the desktop.

The main thing for me that is a deal breaker with Snap, is that it is tied to Canonical-owned infrastructure and app store, whereas Flatpak is a project under the GNOME Foundation. Although some Red Hat engineers have put a lot of work into it, it is a distribution-neutral technology, and can work with any sort of app store.

Fedora is working on a process to automatically convert to Flatpak some of the applications we’re already maintaining, and we can easily put those in our own place for distribution. We could also push them to Flathub, which is vendor-neutral.

We also have people working on doing similar things for Snaps, with Fedora contributors and people from Canonical working with them on this. But, we don’t have a good answer [for] where we put them. I think it seems pretty clear that—as they’re doing it right now—although [Canonical] wants it to be a vendor neutral standard, they also want to be in control, at the center of the app ecosystem. I don’t know if that centralized style is really beneficial for users in the long run.

Will Flatpak become the default way applications are distributed?

TechRepublic: Do you see a future for Linux on the Desktop where applications are distributed via Flatpak by default, while internal components are kept within repositories?

Miller: Yes, that’s basically what we’re doing, and I think that’s definitely the future. It’s a little ways in the future, but assuming work on Silverblue goes forward, I think that is likely to become our default desktop offering sometime in the next, throw the dice, two to five years.

In that case… we’ll have to look at how we want to continue packaging and shipping things for traditional desktop, and see what the user demand is. If demand is still high for traditional RPM packaging of applications, that’s one thing. Also, Fedora’s packaging is a vast community of volunteers, there’s definitely people at Red Hat who are paid to work on it, but there’s a lot more people who are doing it because it’s something that they care about, and are passionate about. If those people want to keep packaging things up in whatever they want, that’s awesome, more power to them. I don’t think we’re going to take anything away, it will be an additive thing.

How autonomous Spins are from Fedora Workstation

TechRepublic: Fedora Workstation ships with GNOME, though Spins are offered for users who prefer alternative desktop environments. Fedora Workstation is conservative for preinstalled apps, though, for example, the KDE spin ships with three browsers—Falkon, Konqueror, and Firefox—installed by default. What’s the planning process like for Spins?

Miller: Basically, each group that makes a Spin makes its own decisions on these things. We want to increase that. I think that the more power they have to do what they think is right for their users, the more success that the different Spins will have.

In this case, the people who work on [the KDE Spin] want to showcase the amount of different choices people have. The GNOME people prefer to do a solid default [where] everything is very polished, within the things that are offered. It’s kind of a difference in philosophy there. As Fedora overall, I think we’d like to embrace both of those things and make room for both of them.

What’s in a name?

TechRepublic: This has nothing to do with Fedora as a project, though a lot of Fedora users rely on GIMP for photo editing. The name, as a problem, pops up every two to three years. Do you have a thought to share on that?

Miller: I think it’s an impediment to adoption, and we can argue all we want that there is no Pulp Fiction-inspired imagery associated with that, but come on, of course there is. That’s what everybody who is not a geek thinks, and I think it blocks the use of it. I’m not going to tell them what to do, but it would be better for everybody if a new name were found.

This isn’t even just any idea of vulgarity or something like that, there was a vector drawing program called SodiPodi. That got forked and built into Inkscape, which is a beautiful product with a beautiful name. That’s one of the shining examples of open source applications now. I think there’s room for something like that around GIMP, and I hope that it’s something that could happen without it being forked as well. But that is just my very passionate opinion on that one.

Lessons learned from 15 years of the Fedora project

TechRepublic: So you’ve been involved with Fedora for 15 years. In that time, what’s the biggest innovation that you’ve seen that eased a pain point for using Linux on the desktop?

Miller: I think it’s when the graphics driver people decided to go with open source. Intel buying in, first on the network drivers, and then on the graphics drivers was huge. Now AMD coming along—I have an AMD desktop that I use for gaming, it’s awesome how it just works without having to fiddle with anything. I love that. There’s obviously a subtext of, “come on NVIDIA, get with the program,” but I think that was really one of the big game changers. The more that hardware vendors get invested in Linux and upstream support for [devices], the better it will be for everybody.

The biggest innovation in Fedora itself is when the former Fedora project leaders, Greg De Koenigsberg and Max Spevack saw what we had with Fedora Core, which was a corporate-owned and controlled open source project, developed behind closed doors, and dumped out. Fedora Extras, as a community project, helped around the edges of things.

They spent a lot of effort reconciling and merging those together into one project where we have community leadership, with Red Hat as a company who works as part of that community, rather than as the guardians and owners of the Core. That’s been really successful both in growing the project, making it really feel like a family. It also improved the technical excellence of the way the Core was put together in huge ways, which benefited Red Hat as a company, and benefited RHEL. That was the big success that made Fedora the project that it is, and that made me happy to stay with it.

TechRepublic: This was before you joined Red Hat as an employee, but In 2011, when Fedora 15 was released with GNOME 3.0, there was a sort of schism that happened, leading to an exodus of users. What work is being done in Fedora to prevent that from happening, with GNOME 4.0 on the horizon?

Miller: That release had an incredibly dramatic amount of change. Both GNOME 3 and systemd landed in the same release. Basically, we lost half of our users doing that. Or, at least half of our users didn’t upgrade from Fedora 14, and we stopped getting growth. That was a pretty bad situation, and there’s plenty of ways for blame to go around. But, I think just absorbing all that change, all at once, is hard on people.

That’s a lesson learned. If you look at the GNOME user interface, if you go back and install GNOME 3.0 and compare it to 3.32, it’s a very different experience. The designers working on GNOME, despite some reputation, actually do listen to feedback and adjust. They really do want to provide a user polished experience.

I think that if GNOME goes to 4.0, it is not going to be a radical redesign, like that. It’s going to be architectural shifts under the hood. In one of your earlier interviews, someone mentioned concern about Wayland, and the split between the desktop and the shell compositor. If your shell crashes under [x.org], it automatically restarts, you barely notice it. If you crash under Wayland, it brings things down. That actually requires a big architectural change to fix, that might be GNOME 4. That isn’t necessarily something that means that the user interface has been run into a blender and changed all around just for the sake of it.

TechRepublic: There’s still a lot of resistance to systemd.

Miller: Yeah. I was the system administrator at Harvard when systemd was being pushed in Fedora. If you go back in the mailing list archives, you can find some passionate arguments from me against putting systemd in as a default, at least as it was at the time.

I’ve come around, and I came around pretty quickly. I always saw systemd as being something interesting and innovative. I think it’s most of the people who don’t like it, don’t like it for reasons that don’t make any sense. The complaints are often things that are [already] addressed, or that it doesn’t follow Unix philosophy, which I don’t find very compelling.

The important thing is, the way computers work was changing in a significant way. A new approach to initialization was necessary. Computers used to be very static things. You initialize it on boot, and then that’s how it is. Everything is plug and play these days, devices come and go, applications can stop and start, and services can stop and start in response to that. Something that was meant to deal with that dynamic world was really necessary. I think it was a good call.

There are a lot of things that systemd makes awesome and easy, like cgroup spaces, if you want to assign resource limits to things that weren’t really possible before.

One of those things I’ve always struggled with, as a systems man in HPC, is that you have a scheduler, but somehow peoples’ jobs would escape the scheduler, and it would be running and taking up resources… systemd can track what jobs are part of a thing, and kill them all cleanly. You wouldn’t think this is that hard, but it actually turns out to be difficult. Having a process manager that can handle all of these things is innovation, and it’s a good thing.

Fedora 31 is anticipated to release before the end of October.

For more, check out TechRepublic’s other recent interviews with open source leaders:

Screenshot: James Sanders/TechRepublic