Max, the last time you spoke to LFY was after the release of Fedora 7, when you were the Fedora Project Leader and that release in itself was an ambitious task, considering the merger of Core and Extra. Now, a year and a half later, a period in which we saw three more Fedora releases, what all do you think has changed? What were the important things you had in mind back then, and how many of those set goals have been achieved?
For me, Fedora 8 was about two main things. The first was maintaining Fedora’s innovative trends, while giving the new infrastructure a chance to settle down and get polished. This also included nurturing along the idea of Fedora Spins, which the infrastructure changes and the Core/Extras merge enabled.
The second major thing that I was doing during the Fedora 8 timeframe was working internally with Red Hat to lay out a plan for the future organisation of Fedora. I was ready to step aside as Fedora Project Leader, and when we sat down and inventoried all of the responsibilities that I had acquired over the past two years, we agreed that it would be useful to do three things. First, hire a successor for the Fedora Project Leader (FPL) role (this turned out to be Paul Frields). Second, create an official Fedora Engineering Manager role (this turned out to be Tom Callaway), and third, set up an official Community team within Red Hat, which is the role that I took on.
During Fedora 9, my primary contribution was in helping to ensure a smooth transition as Paul Frields came into the Fedora Project Leader role and joined Red Hat. We officially changed jobs about halfway through the release cycle, and I wanted to make sure that I gave him the same kind of help that Greg DeKoenigsberg gave to me when I started as Fedora Project Leader.
Simultaneously, of course, Greg and I were putting together the Community Architecture team, and figuring out the ways that it did, and did not, intersect with Fedora. I’ll talk more about that later.
So, now that you’re in charge of the Community Architecture team, how does this role differ from that of being an FPL?
The primary difference between the Community Architecture team and the Fedora Project is the recognition that while Fedora may be Red Hat’s most successful community endeavour, it is by no means the only place where Red Hat interacts with the open source community.
The Community Architecture team is responsible for Red Hat’s global community development strategy, leveraging the talent and abilities of the free software community worldwide as a force multiplier for the goals of Red Hat.
In short, our job is to ensure that Red Hat is a good citizen in open source communities, and that the same community lessons that have made Fedora successful are applied to other strategic Red Hat projects — in the education realm, in the OLPC work that Red Hat is part of, etc.
The Community Architecture team still is very active in Fedora—especially in organising FUDCons, worldwide events, and in being the place inside Red Hat that is responsible for Fedora’s non-engineering budget.
Therefore, the team really has two focuses. One is an internal focus, making sure that Red Hat as a whole is getting all the benefits possible out of the open source business model that it has chosen—which means building successful communities. The other focus is still in the Fedora space, where we participate more or less the same way we always have, as some of the ‘senior leaders’ in the Fedora community.
Tell us something about the Fedora infrastructure. What are the different facilities provided by the project to the contributors and what is expected in return?
The Fedora Infrastructure team, led by Mike McGrath, doesn’t get nearly the credit it deserves. It is arguably the most critical piece of the entire Fedora community, because it provides everyone in the project with the raw materials necessary to do their jobs. It’s massively volunteer-driven, and I believe that it is more innovative, and provides better services than most fully-staffed and enormously-budgeted IT departments in many companies.
There are a lot of things I could talk about here, but in the interest of keeping the answer short I’ll mention the work that we call ‘Fedora Hosted’ and ‘Fedora People’, because it is an example of a proactive infrastructure team understanding the needs of a development community and giving them the tools necessary to get their work done.
Fedora Hosted provides repositories, Trac instances, and wikis for various upstream projects that are associated with Fedora. The project is a little bit over a year old now, and it has grown tremendously, to the point where even many Red Hat employees are using it because it is better than some of Red Hat’s internal tools that try to serve the same needs.
Similarly, Fedora People provides every contributor with some Web space that can be used for personal git repositories, mockups, etc. This space is activated along with a person’s Fedora Account.
Among Fedora Project contributors are RH employees and volunteers. How do you ensure that the project as a whole is not directed by the interests of RH (as it’s the primary sponsor) rather than those of the community?
The answer to this is actually quite simple. There is one set of rules, and everyone plays by it. If you want a feature in Fedora, the process is clear. It doesn’t matter if you work for Red Hat, or if you are a student hacking in your spare time. If you follow the processes—managed by John Poelstra, our rock star Fedora Project Manager—then you get your work into Fedora. If you don’t follow the processes, then you wait until the next release.
How does the Fedora Project facilitate Red Hat? Also, what do the two entities expect from each other?
The Fedora Project is upstream for Red Hat Enterprise Linux. Red Hat expects that the Fedora Project will provide innovation, and constantly represent the best of what exists in the open source universe today.
In return, the Fedora Project expects that Red Hat Enterprise Linux will take the best of what exists today, and turn it into a supportable product that represents the best of what will exist for the next seven years. The revenue made by Red Hat’s enterprise products allows for (among other things) continued growth and investment in Fedora.
It’s a very symbiotic relationship.