This is part two of a series based on talks in February at DevConf in the Czech Republic. You should start with Part I, “Why?”, unless you are inclined to just believe everything I say with no justification. That part covered the background and outlined some problems we are trying to solve; this part talks about what we are actually doing, and why we think those things address the problems. Next week I’ll cover the governance structure and current status, followed by panel discussion, and Q&A after that.



As before, you can watch the video on YouTube, but there are a few reasons you might want to read this instead. First, videos are hard to skim or search. Second, time moves on and this contains a few updates (which I have marked with Update, so if that’s all you care about they will be easy to find). And finally, I made some embarrassing typos on the slides, which I have fixed. You can see those slides on my web site, starting with slide 11. What follows is basically each one with commentary.

The Video, Continued

(For this article, we start at 13 minutes, 47 seconds in.)

Time for Some Answers!

So, having talked about some of the questions we face, here we go with some of the answers. At this point, I’m going to focus on proposals that the project has accepted and that we’re going forward with now. They certainly don’t solve all of the possible problems, and in some cases they probably raise yet more questions. That’s fine, and even great — let’s keep that conversation going and eventually answer even more of them.

Here, though, I cover a few of these initiatives briefly, and connect each into why we are doing it.

Multi-level “Rings” Approach

This is something I took to Flock last summer — the “Fedora Rings” proposal. You can see the video and slides. Update I won’t reproduce those slides here, but instead, please enjoy these two snaps from my whiteboard at my office, which eventually evolved into that presentation.

Never before seen in public!

In any case, it’s not really very complicated, despite all those words and colors. We start with a central core, which is the “base design”, and we work on defining what the API for that is, and what it means to have the core of Fedora installed.

Then we have a ring out from that where we have different programming environments. Especially in the initial proposal, I came to this from a Fedora Cloud viewpoint where I’m talking to developers and asking what they want out of an operating system, and they want that base to be boring — but want exciting things on top of that. If we can provide those exciting things in a useful way rather than making everyone drag along their own custom-brewed stuff, then we are actually providing a service to the world, so that’s part of the idea here.

And then, in the future, it’d be nice to be able to say “okay, we can just plop down applications that use all of these services that we’ve provided”, and there’s a nice, seamless user experience. On the desktop, that’s probably the Linux Apps proposal, and we’ll see how that develops… some of the infrastructure is being put down with kdbus and related things, and maybe that will end up being integrated with Docker, or maybe there will be different solutions; we’ll see. It would be nice if our container approaches can share technology, because a lot of the problems are the same. Expect to hear more about this as part of Fedora.next and outside and around it as well; it’s a whole ‘nuther topic on its own.

Also, couple of asides on the rings proposals, brought forward from last year’s Flock talk.

First, this is not a return to the old Fedora Core / Fedora Extras split. That was a division based primarily on who you worked for, with the center developed behind closed doors and community only at the edges. Fixing that made Fedora what it is today, and no one is suggesting going back. This proposal slices a different way, based on what’s appropriate for each package, with community at every level.

Second, the circles are levels of policy, not a literal architectural diagram. The actual architecture is still being figured out and will evolve over the next several Fedora releases.

Why Rings?

So, now, let’s connect this back to some of the questions raised in Part I of the talk. Why is this particular proposal relevant?

First, it gives us a framework in which to balance innovation and change. We will have a base design and an API where we are more strict about making changes. It doesn’t mean that it can’t move fast, but we need to make sure it’s done in a controlled, planned way, rather than parts just falling in. Then, you can have different layers which move at a different speed. Even if they are rebuilt (and released) together, their API promises — the guarantees they make to users of that layer — can move at different pace from the base.

This can also reduce the barriers to entry, because we can have layers outside of the core where we just say, “Okay, it’s ugly, fine. We can still include it in this way.”

And, being more clear about what and where the stability promises are (and aren’t) could make it easier to have projects that work on Fedora without necessarily being in the distribution proper. I want to be careful about saying “in Fedora”, because the Fedora Project is bigger than the Fedora distribution, but we call both “Fedora”, so that’s sometimes confusing. And many of the changes I’m talking about could affect the project without being changes to the distribution — although since that’s our primary output, most of them will in some way.

Products Proposal

Next… this is from another proposal that Stephen Gallagher brought to last year’s Flock — the Three Fedora Products. Basically, these are three directions we see the distribution pulled, so we thought it would be useful to actually make a split along those lines, so we can build and market each in different ways. We talked about it at that conference, and FESCo (the Fedora Engineering Steering Committee) brought the idea to the Fedora Project Board; I’ll cover the results of that further in Part III next week.

Now, though, let’s jump right to “why”. How does this help with those different directions?

Why Products?

It gives a voice for our server people, the sysadmins who never really had a good place to talk and be heard in Fedora before (see the last slide from Part I if you missed it) a way to be constructive and build something instead of feeling limited to being negative.

It gives a focus for the workstation, because previously while the desktop was the “default offering”, it also kept being pulled towards these other roles that the Fedora distribution needs to serve, so with this we can say that the desktop is actually supposed to be a desktop, and it can make questions like “is sendmail supposed to be installed” have more obvious answers.

There was an issue a few releases ago with storage, where enterprise storage features were being pushed. The desktop-focused people thought: storage is the hardest thing in installing and setting up a new system, so maybe we could just leave out some of the more confusing stuff that people don’t really use, and then there will be a better experience for users. But then, people using Fedora for other things actually needed that. If we make a split, we can have places where complicated storage fits, and places where a streamlined user experience is more important, and both developers and users can better understand where to put things and where to find them.

Another example is GUI components in the minimal install. If you’re building a desktop system, worrying about that is a waste of time, because by definition those are going to need to be there anyway. But if you’re building a server or spinning up a cloud image, it can actually be important that those aren’t pulled in when not wanted. So this gives us a better way of articulating that.

And cloud — Fedora is a great fit for many cloud computing uses, but isn’t hugely popular. That’s not because of anything particularly wrong with it. We’ve put a lot of work into the Fedora Cloud Image over the past few releases and I’m very proud of it, and I know it’s great, but why would you use that instead of one of the other Linux cloud images? Unless you’re already big into into Fedora, there’s really no compelling reason to pick it.

Meanwhile, there are projects like CoreOS happening out there which are exciting. Fedora Cloud needs to be exciting too. Having a separate product lets us go further away from what might be going on in the mainstream Fedora distribution and experiment with more radical things. Maybe we’ll have rpm-ostree in Fedora Cloud first, because it’s a use-space where it’ll be easier to adapt than a more traditional server (although the vision for ostree is to eventually make it useful everywhere).

Update rpm-ostree now has a fancy new name as Fedora Atomic Initiative, and I’ll be demoing it with Docker at the Fedora booth at Red Hat Summit in April. See, shiny!

Is three a magic number?

Update The team behind the Workstation product includes people working on several different desktop technologies, but decided to use Gnome as the software behind that product. This week, Fedora project members in the KDE SIG launched a proposal for a Fedora Plasma product aimed at an academic audience of scientists, students, and teachers. The Fedora Project Board is discussing this proposal now. There is also an in-progress proposal to have the KDE SIG work more closely within the Workstation product.

There is a broad strategic question about the ideal number of different products, and their possible overlap in scope, and reasonable people have different but strong positions on that. There is also continuing debate about whether products need to be focused on user audience and use cases, or whether some could focus on delivering a particular technology. We don’t have everything figured out, let alone set in stone, and this is one of the areas that will evolve as we go forward. The debate might be a little frustrating to some, but let me share my new favorite quote, from Russ Allbery over at Debian:

Yes, this is to some extent hair-splitting, but, well, welcome to free software. 🙂 Doing this stuff requires a lot of hair-splitting, since it involves quite a bit of, as the saying goes, “tepid change for the somewhat better.”

Now, I think that really Fedora can have at least reasonably quick change for the significantly better, but as I emphasized last week, it will take time and effort.

One thing I want to make absolutely clear right now, though: spins aren’t going away. Spins are customized Fedora media, and the most popular way to consume our different desktop technologies. We had a big mailing-list discussion about how spins fit with Fedora.next, and there was a clear community consensus that they fill an important role. I agree, and we’re not going to break that. In fact, it may be that making “desktop technology showcase” spins more visible is a good path for Fedora.next. We’ll figure this out together.

Lego vs. Playmobil

One of the related (and perpetual) community discussions centers around what exactly Fedora is. Traditionally, the answer is: we take the “raw plastic” of the software out there in the universe and we mold it into high-precision Lego bricks, and users can plug them together. “Here! Here are your bricks. It’s Fedora! We’ve made these bricks nice and pretty and you can put them together however you want!”

Another approach in operating system design is Playmobil. It’s a playset, you buy it, it’s a castle with a knight, and that’s what you get. No assembly required — you can take it out of the box and start playing with it right away.

So, a lot of people feel this tension between “here’s your bricks” and “here’s your playset”, and are worried that with Fedora products is that we are going to take away your bricks, give you a set, and if you don’t like it, too bad for you.

But actually, we are doing something different

We can ship sets… without taking away the basic blocks.

(These are classics from my childhood; maybe your childhood too. The modern sets are more sleek, but… did anyone else have this spaceship? It was awesome. Anyway….)

The idea is: we can take some of our bricks, and we can ship those as sets. And maybe even, unlike Lego, we will ship them preassembled for you, but we’re not gluing them together, and we’re not getting rid of the basic supply of bricks. You can build other things — we want you to build other things. If you want to take apart the sets we ship and reassemble them into something else, that’s great, although when you do that, it should be clear that you no longer have the official set, you have your new asteroid mining complex or whatever. Share your creations, maybe even make new sets.

More Why

And finally for this week, more on “why” for the products idea. We think this will grow the user base in the areas we’ve identified, make more clear targets for development, and in particular the Server product can be more connected to future Red Hat Enterprise Linux.

I don’t think there’s anything controversial here, although a little bit on the last point is worth expanding on. One of Fedora’s important roles is that RHEL comes out of it, and it’s important for Red Hat that that keep working, and just talking about that in an open way is better. It’s not saying that Red Hat is going to take super-control over Fedora in a way they haven’t before, but we want to get Red Hat more clearly saying “this is what we need”, and I think that’ll help the overall conversation. Check out Fedora Project Leader Robyn Bergeron’s blog post on Fedora, Red Hat, and investments in the future for more thoughts on this in depth, too.

Watch for Part III Next Week

And that’s where I’ll break for this week. Next week, in Part III, “Governance, Progress, and More Ideas”, I’ll talk about the new governance structures we’ve set up, and the current progress (including some significant updates since DevConf). After that, the Working Group summary presentations, and then questions and answers.

As before, let’s continue this conversation in comments and replies, and in addition to responding, I’ll distill that into the Q&A post at the end of this series.