How and when did you realise that FOSS was something you were really interested in?
I had been using FOSS professionally for a few years as a forensic examiner. Then I started teaching it to others as a means of both saving taxpayer money, and producing results that could be independently verified, since the code was open and available to anyone. Also, if there were problems, frequently we could discover the reasons behind them and resolve them ourselves. I was really fascinated with the idea that all this great software was produced by people who, in many cases, hadn’t ever met in real life, collaborating over networks simply in pursuit of better code.
So what is your opinion on proprietary software?
Proprietary software is probably only useful in very niche cases—cases where the overall body of knowledge about whatever the software does is very rare or hard to obtain. For general-purpose uses, proprietary software has really had its day and is on the way out. The idea of paying for personal information management software, database services or word processing is pretty antiquated.
You’ve been in systems administration in previous work places, are an active documentation writer/contributor, and also maintain a few packages yourself. Can you explain a bit about each of these roles, and whether you’d rather call yourself a writer, a developer or a systems administrator?
Actually, I wasn’t ever really a true systems administrator. I did some work that bordered on sys admin work, but really, I was more of a dabbler. That having been said, I did get to touch upon a lot of different technology areas, from scripting and clustering, to building customised kernels and distros. I also spent a lot of time documenting what I did for other people, and teaching them hands-on. So I think the term ‘dabbler’ is probably best—Jack of all trades and master of none!
How did you get associated with the Fedora Project?
I started with Slackware but used Red Hat Linux starting with 4.1, all the way up until Red Hat Linux 9 was released. I didn’t watch project schedules that much or subscribe to a lot of lists, so I didn’t know about the Fedora Project until the fall of 2003. I was delighted to have a chance to contribute back to a community that had helped me build my skills, knowledge and career. I decided to get involved with documentation because I wasn’t really a software developer, but I was a decent writer.
What’s your role as the Fedora Project Leader?
The Fedora Project Leader is much like the Fedora Project’s CEO. Ultimately, I’m accountable for everything that happens in Fedora. Red Hat pays me to make sure that the Project continues to fulfil its mission as a research and development lab for both the company and the community, and that we are consistently moving forward in our mission to advance free and open source software worldwide.
Among Fedora Project contributors are those who are RH employees, and there are those who work as volunteers. How do you ensure there’s minimal clash of interests? For example, what if there’s a significant difference of opinion on the direction Fedora should be headed towards?
To minimise the chances of this happening, we have a well-defined governance structure. For example, we have a Fedora Engineering Steering Committee (FESCo) that is entirely community-elected and makes technical decisions on features, schedules, and is in charge of special-interest technical groups such as our packaging group. Having a central place for technical decision-making means that there’s a regular venue where arguments can be heard from both sides whenever someone is suggesting a change, whether that person is a volunteer or a Red Hat employee. We’re all members of the same community.
Just about every engineer in Red Hat works for some time in Fedora, since Fedora is the upstream for the Red Hat Enterprise Linux product. Part of my job, and the job of the Fedora Engineering Manager, Tom ‘Spot’ Callaway, is to make sure that work is coordinated between the internal Red Hat groups that work in Fedora and the external community. When decisions are made by the community, we make sure that the internal groups participate and are informed, and when there is something that the internal groups want to pursue, we make sure they are discussing those needs with the community. In general, it ends up being a pretty smooth interaction.
What is Fedora’s vision? By whom or how is it set or defined?
The Project Leader sets the vision for Fedora, which goes hand-in-hand with our mission to advance free software worldwide. The FPL’s vision is often about finding the next big challenge for our project to overcome, as a community. In the past, those challenges have included establishing governance, unifying the way we manage our software, and creating a leadership team for Fedora inside Red Hat. I’ve spent the last ten months turning my sights outward on two problems—making it easier for people to join our community, and enlarging that community to include all those who remix or reuse Fedora in various ways. Really, the vision can only be a reality if the community agrees it’s worthwhile, and it’s my job not just to identify that vision, but to enlist the community’s help to realise it.
There are some distributions that don’t really care about upstream, where the distro developers and maintainers want to push their patches first into the distros to make it stand out from the rest of the crowd. Fedora, I believe, has a strict policy of working with the upstream, and whatever feature sets are available in the final distro are completely in sync with the upstream. What’s your take on this and why do you think upstream contribution is more important?
Upstream contribution benefits the entire FOSS community. It’s how the open source development model works—it’s about collaboration and constant code review and refinement. When a distribution changes behaviour in a way that goes against the upstream model, three things happen.
First, there’s immediately an uneven user experience. Users who try out newer versions of the same software from the upstream find that the behaviour changes suddenly and without warning. They think this is either a regression or a mistake on their part, when in either case the difference has been caused by the distribution vendor.
Second, the workload on the maintainers of that distribution begins to multiply and, in some cases, increase exponentially. The further out of step with the upstream the distribution becomes, the more difficult it becomes to integrate the distribution-specific changes with new upstream releases as time goes on.
Third, because the upstream is testing the interaction of their software with other pure upstream releases, arbitrary changes downstream create problems in those interactions with other packages used in the downstream distribution. Every change begets more changes, and the result is a rapidly accelerating cycle of bugs and resulting patches, none of which are likely to be accepted upstream. So once you get on that treadmill, it’s very difficult to get off without harming the users and the community.
What’s the role of the Fedora Project Board, and you, as its chairman?
We have a Board with five community-elected members and four members appointed by Red Hat, who make policy decisions for the project as a whole. We document our mission and meetings through our wiki page.
One of my jobs is to chair the Fedora Board, and ensure that the governance of Fedora is working as smoothly as possible. I also am the person responsible for choosing the people who will fill the seats reserved for appointment by Red Hat. We turn over roughly half the seats on the Board after each Fedora release, so that there is always a chance for the community to make informed decisions about the leadership of the Project.
I always try to respect the need for balancing different constituencies on the Board, so these appointments are not limited to Red Hat employees. Last election cycle, for instance, I appointed Chris Tyler, a professor at Seneca College in Toronto and a long time Fedora community member, to the Board, which has proved to be an excellent choice. This flexibility goes hand in hand with the community’s ability to elect who they wish to the Board, so we tend to always have a mix of Red Hat employees and volunteers, which changes in a fairly smooth and continuous way every six months.
Tell us something about the Fedora Docs Project. What are the objectives and the to-dos?
The Docs Project is responsible for creating user-oriented guides and tutorials for Fedora, and also to keep our wiki-based information fresh and well-groomed. Although I don’t get to participate in the Docs Project as often
or as deeply as I used to, I still spend significant time keeping up with its tasks.
Right now, the most important task on which the Docs Project is engaged is fixing up our own process documentation, so we can enable all the new contributors to participate fully in writing, editing and publishing. We have an enormous virtual hack-fest happening over the Christmas and New Year holidays, where we will be training new volunteers on how to use tools, edit the wiki, and publish to the Web. In addition, we hope to also make some choices for an upcoming content management system that will make all these tasks easier in the future.
What do you think are the best features of Fedora 10? And your personal favourites?
I’m very excited about two capabilities in particular. One is PackageKit, and the other is our enhancements to virtualisation. Richard Hughes has built up some incredible capabilities for desktop interaction that, for Fedora 10, allow automatic search and installation of media codecs, which is very helpful for desktop users. In the future, though, these capabilities will be extended to add on-the-fly installation for user applications, fonts, hardware enablers, and a lot of other features. That’s something that proprietary desktops can’t provide because their model revolves around selling software to users, whereas we’re in the business of giving it away.
On the virtualisation front, we’ve made a lot of advances in areas like remote installation and storage provisioning. We’re showcasing a lot more flexibility for administrators who want to go from bare metal to a complete virtualisation platform without having to spend time in a noisy closet with their equipment. I’d like to see a lot more people looking at the power and capability of KVM, which is the Linux kernel’s built-in hypervisor. With 64-bit hardware becoming the norm, everyone’s system is potentially a virtualisation powerhouse and we’re going to be in a great position to tap that.
Of course, the advances we’ve made in PackageKit and in the virtualisation system pieces like libvirt and virt-manager are all run as independent upstream projects, so all distributions and users can benefit. I imagine that you’ll be seeing these advances in other distributions soon enough, but the Fedora platform tends to make that possible through our commitment to leading-edge development through the upstream.
What’s your opinion about Linux on the enterprise desktop? In which sectors do you find people are most likely to resist switching over from Windows and Macs? And what do you think the reasons are, behind their resistance?
As I mentioned before, I think the general-purpose case for proprietary operating systems on the desktop is becoming harder and harder to win. Information interchange becomes trickier, and vendor lock-in is too expensive a proposition for businesses that have to find a steady profit margin in a highly competitive, globalised market. Ultimately, I think there’s a broad range of businesses that are served by integrating open source technologies at every level from the edge to the desktop, and one of our purposes in Fedora is to provide a wide proving ground for those technologies, whether they’re targeted at the desktop user or the systems architect/administrator, and make them available to as large an audience as possible, for contribution.
There are some essential professional-quality software that are still missing from the ‘FOSS desktop’, viz. layout software like QuarkXpress and Adobe InDesign, that media houses like ours depend on; or there are professional sound and video editing tools that studios depend on. How can projects like Fedora, or FOSS heavyweights like Red Hat, encourage and facilitate developers of FOSS alternatives to develop something as good as the Linux (kernel), on which professionals can bet on?
By providing a robust platform for development, integration, and deployment that includes the latest advances in tools and toolkits, and making it flexible enough for ISVs and appliance builders to develop cost-effective and innovative solutions for their customers. That’s something at which the free software stack excels, and which we in Fedora and at Red Hat are constantly advancing through our upstream development model.
We can also advance by illustrating the open source development model as the best way to provide features faster to users and customers. Many software vendors that ‘get it’ are already moving to the way of doing business that Red Hat has been proving for years. They have a stream of constantly developing technology on the one hand, which feeds a stable, supportable branch on the other, backed by services, support, and training with extremely high value, for which users and customers are willing to pay—and that puts them in charge of their own technology roadmap.
What’s the road map of Fedora, and what can we expect in Fedora 11?
As we set the schedule for Fedora 11, we acknowledged that we were getting towards the time when Red Hat will be looking to branch our feature set for use in its next edition of the enterprise product, Red Hat Enterprise Linux 6. So there’re quite a few features we want to get entered into our Fedora 11 release, and we track those openly and transparently, like everything in our project. Have a look at feature list for Fedora 11.
That list changes over time as the FESCo evaluates developers’ proposals, and makes decisions on how best to include that work in the Fedora platform. In addition, there are always quite a few features and initiatives that come out of our engineering-focused North American FUDCon conference, which is happening January 9-11, 2009, in Boston. I would expect in the weeks following that conference, that the list will be expanding quite a bit, but some interesting additions are the Windows cross-compilation toolset and the introduction of DeviceKit.
Thanks for your time, Paul. Is there anything else you’d like to share with our readers?
I have never been so excited to be part of free and open source software. I would encourage readers to not only use the software we develop, but to consider how they can get involved in Fedora to advance the FOSS ecosystem as a whole. Even doing simple things like filing bugs, fixing text on a wiki, or writing small tutorials, can be useful to hundreds or thousands of people. Getting involved in free software was one of the best and most fulfilling decisions I’ve ever made, and I hope you’ll consider making the jump from consumer to contributor as I did.
Thanks for the chance to talk to your readers!
