But it's a little ironic, because now when we try to explain to people that if you want longer-term support you can go to RHEL or one of the rebuilds of RHEL, not everyone knows that Fedora and Red Hat are part of the same team. Fedora longterm support is there – it just has a different brand name.
LXF: I thought it was fascinating when you said in your talk at LUGRadio Live that Red Hat costs would triple without Fedora.
MS: About two-thirds of the Fedora packages are maintained by community people, and if we didn't have that community, that chunk of work would either not get done, which would significantly harm Red Hat's entire value, or would have to made up by more [paid] engineers. The challenge on the flip side of that is to make sure that everyone in the Fedora community feels valued, that everyone who contributes can be proud of the way that Red Hat uses their code.
LXF: I always got the impression that the Fedora community regards Red hat as a separate distribution. How important do you think it is to them that the quality of what gets rolled in to Red Hat is maintained?
MS: A lot of Fedora contributors maybe use RHEL in their jobs, or work for companies that are using RHEL; there are also a lot of people who contribute through derivatives such as CentOS. We want them to feel that the work we're doing is good.
There's a continuum of distros with respect to how they view freedom, and I think we take a pretty hard line in terms of what we will or will not include in Fedora and on the repositories, and I think people appreciate that and want to see Red Hat defend free software as well. That's what I mean by keeping trust.
When a Fedora contributor is doing a lot of work for Fedora, indirectly down the line he's helping to generate revenue for Red Hat, so we want to be sure that we can show those people what Red Hat is investing back into Fedora, and also that when Red Hat makes business decisions it promotes open source in general.
LXF: When the development process kicks off for a new Fedora release, how does the project go about deciding its goals? Does Red Hat ever conflict with community developers?
MS: The last couple of years have gotten more and more community driven, and that's the way it should be. If you want to have a feature in Fedora and you're a community member or a Red Hat engineer who has a mandate from their boss because they want something in RHEL, the process is the same.
By the time of the feature freeze you've got to be more or less feature complete, and it can get a little subjective, but if you've got your code into Rawhide, which is what we call the Fedora development branch, and you've got it tested and you've got some actual records of having it test cases where it has performed well, then your feature is going to make it in.
That decision is made by the Fedora engineers' steering committee, which is comprised of nine people who are elected by the Fedora community at large.
LXF: Do you think other projects could learn from Fedora's strict six-month release cycle – Debian, for example, seems to have a lot of trouble getting a release out the door on time.
MS: I think in the end we're just very brutal, and our release engineers know that there's going to be a release in six months. If [a piece of software] is going to take six and a half months, it's not going in. It's pretty brutal but we choose to go at that pace.
First published in Linux Format, Issue 112
