Good morning: bugfixing and thinking about Fedora.next

Well, this has been one of the best mornings I've had for a while.

I spent a couple of hours tracking down a rather subtle issue between OwnCloud, Google's PHP client library, and Google itself - required me to bump up my PHP skills further and learn/remember some stuff about HTML entities, so yay self-improvement!

But far cooler than that, some discussion on the desktop@ list led me to a bit of a personal revelation about Fedora.next.

I'm really hoping I'm right about all this, as I've hated all along being something of a .next sceptic. I like doing big cool new things, I like getting behind them and pushing. I just couldn't really feel the shape of this big new thing at all, and was worried about where it was going to wind up. I think there's probably a lot of other Fedorans (Fedorites?) and interested onlookers in the same position, so - and with the caveat that this is just my own personal interpretation I cooked up this morning, but I really hope it lines up with how the Relevant Authorities see things - here's the way of looking at .next that I think might make it look much less worrying and much more exciting.

Fedora.next is about providing some new particular spaces within the whole Fedora project where we can add on some interesting and exciting new capabilities. It's not really about reducing the 'possibility space' within the whole Fedora project or distribution at all.

Let's take the Fedora Workstation "product" as an example. Let's say that what the "Workstation product" really is, is a way of marking off one particular space within the larger space of the Fedora project as a whole. You can choose to "paint within the lines" and be running "the Fedora Workstation product", and in exchange for you doing that, we can offer you some exciting new capabilities and possibilities that weren't really viable before.

Take, for instance, the question of third-party software, a popular bugbear for Linux. One of the problems for third-party software distributors is that it's quite hard for them to choose a target to write to. If they decide they want their software to run on Fedora, what does that mean? Let's say Alice has every one of the ten thousand packages in our repositories installed, and Bob has just done a minimal install. Both Alice and Bob are "running Fedora".

So the only way for a third-party distributor to have any certainty about the platform is to use the distribution's packaging system, but then they have to understand the distribution's packaging system, and that's something that a) they might not want to spend the time doing, and b) they frequently get wrong.

If we define "Fedora Workstation" as a particular space within the Fedora project, though, it goes a long way to helping with this problem. We can say that, to be considered as running "Fedora Workstation", you have to have a particular set of packages installed - and maybe there are other requirements to do with configuration, etc. This is all stuff we're still sorting out, but the concept is the key here. So a third party can write to that platform, and put their software out and say it "works on Fedora Workstation". The Workstation product has provided an extra possibility that just wasn't feasible before.

This is only one example, and there are many others. It's even more obvious for, say, the Fedora Server product. We can say that to be running Fedora Server you have to have installed a set of packages that provides the kind of "role configuration" mechanism we've been discussing, and use it to configure your server roles. In exchange for that requirement, we can provide you with some cool new guarantees that just aren't viable without this Product mechanism - we'll handle migrations to a new, non-backward-compatible version of some component of your server role cleanly, for instance.

So the Products provide new spaces within the existing Fedora project and, precisely by restricting your 'choice' in certain regards - but only so long as you want to be considered to be running a Product - open up new possibilities in return.

The second key realization, for me anyway, is that none of this needs to make things worse for people who aren't running Products. We can keep the concept of "just running Fedora". Nothing about the Products requires us to throw that away, or compromise it significantly. We may find issues here and there where we have to resolve some kind of tension between the Product space and the non-Product space, and have a big argument about it on devel@, and throw rotten fruit at each other. It wouldn't be Fedora if that kind of thing didn't happen. But that's not really new, we already have that kind of tension between the requirements of different use cases - we just don't even have any good mechanism for codifying particular use cases at present, so it's very difficult to do a good and consistent job of reconciling the differing requirements. The Product concept actually gives us the potential to do this better.

So, say you want to use Fedora, but you find some of the requirements of the "Fedora Workstation" product are not things you want - say it requires GTK+ or GNOME Software to be installed, or something, and you don't want that.

You know what? That's fine. So far as I can see, no-one is really suggesting that we need to take away the whole Fedora 'possibility space' as it currently exists. We can still provide generic installation media that you let install any package set you like. We can discuss Spins and whether we want to change that system at all, but we don't really have to change it, and nothing about the Products plan requires us to do anything horrible to spins - obviously we might choose to feature Products more heavily on the download page and in PR stuff than spins, but that's really just marketing. The current devel@ discussion about Spins was kicked off in a slightly unfortunate way, with a bit too heavy an emphasis on some radical scenarios, but that really doesn't seem to have been intentional. We've been talking about the Spins system not being perfect for years, long before the Products idea ever came along - it's not really that worrying that we're talking about it again.

It's just the same for servers. You want to run a server box on Fedora, but the "Fedora Server" product's approach doesn't work for you? That's fine. You can still go ahead and install from a generic medium and build your server configuration out from the Fedora packages, just like you do now, and there's no reason we can't continue to make that experience work as well (or, y'know, badly :>) as it currently does.

We can still provide all the expectations we currently provide for the non-Product space. I don't see anything in the Product space that has to conflict with it. We can ship generic media, and ensure they work, and pledge that we'll do our best to provide a coherent, up-to-date and secure 'Fedora distribution' space, just as we do right now. But we can also mark off particular areas within that space, call them Products, and say "if you stay inside these lines, we'll give you these extra capabilities in exchange". It's optional, and we don't have to make your experience any worse if you choose not to do that.

Sure, there's still lots of stuff to discuss and decide about what media will be shipped by what groups, how they'll be promoted, what QA guarantees the project as a whole is going to provide for what situations, and so on and so forth. Those are all significant issues that I'm sure I'll have an opinion on! But if my interpretation of all this lines up with the folks working hard to make the Products plan a reality, I'm feeling way more optimistic now about the fundamental concept. I think it gives us a big big chance to make things better, and only a small small chance to make things worse.

Comments

Stephen Gallagher wrote on 2014-02-01 14:37:
Adam, thank you very much for this blog. Yes, yes a thousand times yes: you have very eloquently described the Fedora Products plan as I originally envisioned it and pitched at Flock. This is exactly what I've been trying to say (apparently insufficiently) throughout this whole process.
Neville A. Cross wrote on 2014-02-01 14:53:
You have help me understand better this fedora.Next idea from a more down-to-earth point of view. As a non technical person, all that babbling about stacks and cores where way over my head. Thanks.
Zoltan Hoppar wrote on 2014-02-01 15:09:
I think it would be nice to have more article about this, and how will affect to our infrastructure. Eg. Fedora Hosted as I have mentioned earlier. But this writing lights up more pieces.
adamw wrote on 2014-02-01 17:07:
I think it's a bit early right now, as all that is still being figured out. Right now I think it's safe to write with any certainty only about the high-level concept. I don't see any immediate implications for fedorahosted, though there kind of is a problem with fedorahosted in the sense that people don't *like* it that much :) Or rather, it's sort of been surpassed. A lot of new projects seem to be skipping it and getting hosted at github instead.
bochecha wrote on 2014-02-01 16:42:
> other Fedorans (Fedorites?) My personal favourite is « Fedoristas » As for the article itself, it's very close to how I've been seeing Fedora.Next all along, but you provide some great examples here that I hadn't thought about. :)
Jonathan Dieter wrote on 2014-02-01 19:32:
Thanks so much for this. I think I finally get it now.
Michael Schwendt wrote on 2014-02-01 21:15:
How to "paint within the lines"? Won't it still be possible for a user of the "Workstation product" to access the entire Fedora Package Collection and pull in stuff that may cause side-effects? (such as theme engines that break GUIs)
adamw wrote on 2014-02-01 21:39:
I don't know precisely how they envisage this working, but the PRD covers it in theoretical terms: "The Workstation working group will define a set of packages that are considered required be installed in order for the system to qualify as a Fedora Workstation...The Fedora Workstation working group will also define two set of requirements, one for anything that is to be considered for inclusion in the core platform components list and one for optional packages. This will include a requirement to support specific system services and libraries, for example the working group might make it a requirement that any software that wants to be part of Fedora Workstation can run against Wayland or directly output sound to Pulse Audio." So, I don't know what they envisage the 'enforcement mechanism' as being, but I can think of a few. It wouldn't be particularly difficult to do it with metapackages, just as an example, though there's probably a better way. It may simply be that they'll *only show stuff in Software* that meets the given requirements, and not try too hard to stop you doing whatever you want with yum. Just as a fr'instance. Again, I don't see any insuperable technical problems there. It probably wouldn't even be that difficult to write, say, a plugin for yum that would restrict you to stuff in the Workstation 'lines', if you wanted that.
djc.id.au/ wrote on 2014-02-02 00:41:
So Fedora Products are the new LSB (but with maybe a bit less red tape)? Fedora Workstation = redhat-lsb-desktop?
Alejandro Nova wrote on 2014-02-03 23:37:
Just read the entire thread, and all I can see are conceptual assumptions of "Fedora Workspace", how removing or installing desktops are detrimental to the Fedora.next image, and I don't grasp and don't understand what does that mean to me, a Fedora 20 using, KDE fan, who loves a pure KDE install with as few GNOME parts as posible. Questions, plain and simple: 1. Will I be forced to install GNOME via metapackages, obsoletes and yum/dnf if I keep using Fedora (and don't reinstall)? 2. Will I be forced to install GNOME when I install Fedora? 3. If I decide to install KDE instead of GNOME, will I lose functionality? 4. Closely related: Will Apper and KDE distro-specific tools be removed from Fedora?