This interview with Red Hat Community Architect Greg Dekoenigsberg is a continuation of the
LQ Community Manager Interview Series. I'd like to thank Greg for taking the time to answer these questions.
Greg, to get us started, can you give us a little background information about yourself?
Sure. I was a computer geek from an early age; my first computer was an Epson QX-10 running CP/M when I was 12 years old. When I got to college, I decided to pursue a degree in English literature, since there were plenty of girls in the English lit classes and almost none in the CS classes. I figured I'd always be able to fall back on a computer career, and as things turned out, I was right.
How did you get involved with Linux and Open Source, and what was the path that lead to you become a community architect?
I first used Perl in 1991 in my day job, and was impressed at how much power I could get out of free tools. My bias towards Free Software began then, and continued in my years with IBM and other companies. When I got an opportunity to work for Red Hat in 2001, I jumped at it.
My first job with Red Hat was as an engineering manager for the Red Hat Network team. It was a pretty tough job, largely because we were the only proprietary product at the company. It's ironic that I got my best firsthand lessons about the fundamental shortcomings of the proprietary development model while working at the most successful open source company in the world.
Shortly after we announced the split between Red Hat Enterprise Linux and Fedora, the job of "community manager" came open. At the time, it was largely an evangelist role, but I saw a lot of opportunities in the job. At the time, we'd made a promise -- to give the community a larger role in the development of Fedora -- that I thought we hadn't yet fulfilled. So I took the job, with the goal of helping Red Hat keep its promise to make Fedora a truly community-driven distribution.
Four and a half years, eight Fedora releases, a failed 501(c)(3), and two Fedora Project leaders later, I think we've accomplished much of what I originally envisioned. But there's plenty yet to be done.
What do you consider your most important role as community architect? Has this remained consistent over time?
The job is always the same, across all of Red Hat's community projects, and at its core, the job is very simple. Find people in the community who are passionate about solving problems with technology. Give them opportunities to solve those problems using Fedora or other Red Hat projects as their springboard. Identify obstacles to their success and try to knock them down. Empower our best and brightest community members to take leadership roles in our community. It's been a great recipe for success for us.
If someone is interested in taking on a more active role in the Fedora community, how would you recommend they get started?
There's the official answer -- go to join.fedoraproject.org, where there are all kinds of guidelines to help potential volunteers -- but I'd rather respond to that question by telling a story.
It was maybe a bit more than a year ago, now, that I received an email from an enthusiastic Fedora user. He was particularly interested in creating a Fedora Education Spin, but wasn't sure where to start. I pointed him to the Fedora Education SIG pages on the Fedora wiki, sent him to a mailing list, and encouraged him to let me know if he had any questions.
A while later, he responded that there didn't seem to be much happening on the mailing list, which was disappointing to him, since he had many ideas that he wanted to try out. I told him that he didn't need anybody's permission; if he wanted to try out an idea, go ahead, and that he should tell people what he was doing, so they others could help if they liked the idea. Over the next few weeks, he became the de facto leader of the Fedora Education SIG.
As the months passed, he took more and more responsibility, not only in the Fedora Education SIG, but in other parts of the project, where various tasks intersected with his own interests. He was becoming such a valuable contributor that I invited him to attend one of our events in Europe, and told him that we would pay to help get him there.
His response was that he would have to ask his parents -- because Sebastian Dziallas, the volunteer of whom I speak, was sixteen years old at the time.
I had originally assumed that he was interested in the Fedora Education SIG because he was a teacher, when he was, in fact, a student. He was passionately involved in solving a problem that was important to him: getting high quality free software on the computers in his own school.
Fedora, like all great free software projects, is a meritocracy. If you want to get involved, find something that interests you, and dig in. Whether you're sixteen or sixty, you can be useful. You can even become a leader. Just join a project listed on our Join page and ask "what can I do"?
What do you consider Fedora's biggest hurdle to participation and what have you done to try to address that hurdle?
I believe that there is one acute problem suffered by almost all free software projects: a lack of well-defined problems that are articulated as "on-ramps" to learn about a project.
Google Summer of Code has been a great help in forcing projects to consider how "newbie friendly" they are, but there's a long way to go. Lately I've been working with college professors and industry professionals to try to tackle this problem in a coherent way across projects. Ultimately, I'd love to see every free software project working with computer science classes all over the world, since the vast majority of student-written code is throwaway code, and doesn't teach much -- but professors are intimidated when they explore a free software project and find a huge mass of undifferentiated bugs. We have established teachingopensource.org to work on solutions to these kinds of problems.
How would you describe the Fedora governance model and how important do you consider this to community participation?
I believe that our governance model has been absolutely crucial to our success -- but maybe that's because I was the one who defined it.
We have essentially three layers of governance. The smallest is the Special Interest Group, which is an ad hoc structure that can be formed by any community member; create a wiki page, a mailing list and an IRC channel, and you've got a SIG. The next largest is the Steering Committee, which directs our subprojects (engineering, ambassadors, documentation, etc.) and generally has more structured governance, usually with periodic elections. Finally, there's the Fedora Board, which is partly appointed by Red Hat and partly elected by members of the Fedora community, and is led by the Fedora Project Leader, which is a paid position at Red Hat. The Fedora Board is the arbiter of all disputes, making decisions only when necessary. The Fedora Project Leader ultimately has "Benevolent Dictator" status, but almost never uses that power in practice, because nothing will drive contributors away like abuse of power.
Ultimately, the real control is in the hands of every individual who chooses to contribute to Fedora. The contributors give Fedora its power. Without them, there would be no Fedora.
If you had to give advice to someone starting a new Open Source project about how to interact with their community, what would it be?
Listen. Especially when it comes to the details. Your users are usually smarter than you are. The great advantage of the Free Software model is that those users actually have the power to fix your stupid mistakes. Use that advantage wisely.
What are the signs you think indicate that an Open Source project has become large enough to need a community manager?
I think it depends. For one thing, people mean different things when they talk about "community managers". To some projects, the community manager is the uber-evangelist of the project, logging endless hours on the road and delivering the good word to as many people as possible. At Red Hat, though, the community architect is more than that: it's a position that focuses on making the life of the individual contributor as productive, and as painless, as possible.
In my opinion, any free software project that is large enough to support a business needs a dedicated "community guy," whatever the particular title may be. Any successful business in free software depends upon a leveraged development model; the free software company that doesn't actively solicit help from its contributor base might as well be writing proprietary software. Therefore, you want to grow that contributor base, by whatever means. You want your core developers to be community-oriented, of course -- but you also want them to spend the vast majority of their time doing what they do best, which (one hopes) is coding. Which means that you want someone else worrying about keeping your community of contributors happy and growing.
What do you consider the best metrics for evaluating how successful a community manager is?
Again, it depends on the goals. For us, the metric is an ever-expanding community of contributors, who continue to produce great work and great leaders. When I was leading Fedora, I considered a particular project a success only when I was able to give leadership of that project to someone in the community.
The best community managers are utility players. Sometimes that means organizing a conference. Sometimes it means packing boxes full of T-shirts. Sometimes it means digging into a project and finding all the places where it might get bumpy for newbies, and smoothing those bumps out. Which means that it can be difficult sometimes to measure success. It's not hard to measure failure, though -- when your mailing lists go quiet, or fill up with angry noise, and when your good contributors disappear, you know it. If you're paying attention.
In your opinion, what it Fedora's single biggest strength and single biggest weakness? In what ways do those impact your community?
Our greatest strength is our association with Red Hat, which is an incredible company that believes deeply in Free Software. Hundreds of the best engineers in the world are paid to work on Fedora, and they work alongside thousands of volunteers who are just as passionate. The relationship between Redhatters and volunteers teaches both how to make better software.
Our greatest weakness is our association with Red Hat, which is a grown-up company and has grown-up company problems. Last year's security incident is a perfect example; once it became clear that there had been an intrusion, we immediately had to cut off communication with even our most trusted community members, so that the company could pursue appropriate legal actions. As a Redhatter, I am personally confident that Red Hat acted with the true best interests of both Red Hat, the company, and Fedora, the community, at heart. But it can be difficult for community members to see it that way sometimes, and rightly so.
Describe the current relationship between Red Hat and Fedora. How do you think that relationship has changed over time?
In the early days, a lot of people at Red Hat were scared of Fedora. Many saw it as a potential threat to the business, and did a great deal to downplay its importance. As we've matured, though, the company has come to understand the crucial role that Fedora plays.
Fedora is where the Linux world innovates. Fedora is the upstream to Red Hat Enterprise Linux, of course, but it has become the upstream to just about every other major Linux distribution as well. Most importantly for us, Fedora is what allows Red Hat customers to see the future, and the business understands the vital importance of that now in a way that was not as well understood even a couple of years ago.
What do you think is the biggest misconception about Fedora?
That it's just a beta for Red Hat Enterprise Linux. It is most assuredly not. There are over ten million users of Fedora worldwide. If Fedora were "just a beta", I can't imagine that so many people would use it, and contribute so proudly to it.
Now, it is true that innovations hit Fedora first, and therefore Fedora is often the place where issues are sorted out. KDE 4 comes to mind. But with thousands of developers using Fedora every day and committed to its stability, I think we do a pretty amazing job of producing the most stable, innovative, usable operating system in the world every six months.
The Fedora 11 release is right around the corner. What key features or innovations are you most proud of in this release?
There's a great overview of accepted features here:
http://fedoraproject.org/wiki/Releases/11/FeatureList
Personally, I'm a big fan of Presto. From my earliest days in RHN, I wanted to see package delta functionality, and with Presto, we're finally there. This will be especially useful to our users around the world who need updates, but must pay a premium for bandwidth. To many of us, a 50% decrease in package download size might not be that meaningful, but to a user in India, that savings can be hugely important.
I'm also excited by the 20-second startup feature. I'll have my stopwatch out for testing on release day. If it takes 21 seconds, I will be bombarding the Talented Mr. Frields with angry emails. Of course, I do that every day.
With 10 releases already under Fedora's belt, what lessons have been learned?
That a strong community can handle almost any task you throw at them. Not only that, but in most cases, they will excel at those tasks.
Here's a great example. Until very recently, Red Hat produced all of the Fedora schwag for events in North America. Elsewhere in the world, it seemed like the community produced awesome hats and t-shirts and all kinds of great stuff, and every time I went to a show outside of North America, I would impressed by what our community could accomplish. So we made the decision to hand off the Fedora schwag production -- shirts, DVDs, pins, banners, everything -- to the Fedora North America ambassadors.
The Fedora 10 CDs and DVDs came in at half the price, and were of far better quality, and were shipped around the country more cheaply, and the process was just way better.
Why was this so? Simple. The "leaders" of a project can be overwhelmed with mundane tasks, and with so much to get done, some tasks just get pushed to the back burner. But if you can find the right volunteer, and if you say to that volunteer "this is your task, and I'm counting on you to do it better than I did," that task becomes *incredibly* important to that volunteer, and they become embarrasingly awesome at it in very short order.
When you trust people, and when you expect them to do great things, they will. That's the most inspiring lesson of Fedora, for me, and I continue to learn it over and over again.
