Esse quam videri. That's the first thing I saw when I went to see what Paul Frields was up to on his blog. Fun fact: it's also the North Carolina state motto and something I talk about at new hire orientation here at Red Hat. But then I thought about that phrase, and I thought about the responses to the interview questions below. I came to the conclusion that Paul is one of the few people I know who actually exemplifies the meaning of this Latin phrase. "To be, rather than to seem."
Paul works for Red Hat and is currently the Fedora Project Leader and chairman of the Fedora Project Board. It's no coincidence that our chat with Paul was posted on the day that Fedora 13 was released. But I can't express how excited I was when I saw his responses to the interview questions drop into my inbox. Then I read the email. Twice. When Paul started talking about overcoming failure, curating leadership, and fostering community participation, I was ecstatic. I think you will be too.
What one big opportunity, outside of technology, has the best chance of being solved the open source way?
I firmly believe that open source principles can help combat what I see as a growing problem: local apathy. Apathy comes from feeling you don't have a voice or a way of making change, while open source makes the opposite possible. I've heard people compare open source to barn raising, which I always found to be a great analogy. Communities used to come together for that sort of activity as a survival mechanism. Now that some wealthier societies have made it easy for people to get by without that kind of community involvement, how do we fill that void? Sharing information openly about issues and opportunities for change has helped increasingly galvanize social and political action. Since information about big issues--national and global politics--is so plentiful, a lot of our attention is devoted to sounding off about those topics. That's completely laudable, but at the same time there are immediate problems going on in our own backyards where each of us can have a very direct impact.
At the same time as the global network shrinks the scale at which we experience the world, it can reduce our perception of local political and social issues. Applying the open source way, especially creating capabilities for citizens to collaborate on ideas and solutions, brings us closer in touch with the communities we live in. The technology can be a tool in this process, but it doesn't need to be the focus. It's important that the social process raise low (or no) barriers to access and encourage the feedback cycle and iterative improvements that are a hallmark of the open model. I believe children should receive instruction from school systems about this cycle as part of their civics education, and be prepared to engage with local communities as part of their work in upper grades like high school. We may not all need to raise barns anymore, but understanding and being connected to our local community is as important as being connected to the global one.
What aspects of the open source way do you use most often outside of technology?
Two important and connected tenets of the open source way are (1) not letting the possibility of failure get in the way of doing something potentially great, and (2) recognizing when you've failed so you can learn from it and move on. These bits of wisdom are so universally applicable that you can apply them anywhere. I've used them in being a musician, running a volunteer group, and trying to get back in shape after years of overly sedentary lifestyle. Every missed note or sore morning is an opportunity to learn from making constructive mistakes. Setting measurable goals helps you divide success from failure and course correct when you need to do that.
The most important thing I'm trying to do with these principles, in the limited amount of time I have for non-technology pursuits, is to use them as fundamental lessons for my two children through both words and deeds. So many of our social systems are dedicated to risk avoidance and regulation that it can be very difficult for children to adopt a healthy belief in their abilities and talents, and the value of honest, hard work. My wife and I are firm believers in rewarding effort and not just results. Getting an easy "A," or just doing what's expected, are not the kind of thing we generally reward with high praise at home. When the children try their best, even if they don't get the results they wanted, that's the moment to teach them it's OK for their reach to exceed their grasp. And when they do get the expected results, enjoy the success briefly, and then try something new and different.
What qualities are needed for an open source leader to be successful and curate the next group of leadership?
Being a community leader means being willing to give away all credit, shoulder all blame, and generally suffer the slings and arrows of outrageous fortune. It also means you have to actively look for the many success stories happening every day, especially in a large community effort. Telling those stories to a wider audience rightfully gives community members a greater sense of ownership and pride in what they do, and it can be both motivating and energizing for the right people.
One of the ways to identify community leaders is that they're typically people who take it upon themselves to become linchpins in the project. They're independently motivated, and seek to make improvements and connections not just in the areas in which they're deeply involved, but also across the project when they find those opportunities. So it's important to keep a keen eye out for people who have risen up of their own accord not just to claim ownership of tasks, but also to actively listen in other parts of the project and try and grow bridges across different teams.
Do you find it easier or harder to delay a release that's run by a community?
I suspect it's probably easier because the external pressures are different than in the case of a commercially driven product. Fedora, as a truly community driven project and distribution, takes a collaborative approach to our release schedule. Although, we do set a schedule and do our best to adhere to it. We try to achieve a balance between the technical quality of the product, how tightly the project leadership tries to run that schedule, and the perception of the project in terms of timeliness. To maintain that balance and the open, community-driven nature of the release process requires that it scale as our community grows.
The open source way has helped us do this, in that we're now doing a much better job documenting our release and quality criteria, against which we judge technical readiness. In the past, maybe four or five releases ago and previously, a lot of the decisions about what makes a release slip were made based on subjective measures or gut reactions about the seriousness of particular bugs. Now we are using a more objective approach, not just to eliminate needless subjectivity but to make sure that anyone who joins our release engineering or QA teams can understand the decision-making process.
Fedora's program manager, John Poelstra, and members of our QA team like Adam Williamson have been invaluable in driving the process of identifying and documenting these criteria. Having the criteria well documented means that we can increase the shared understanding of the yardstick against which we measure our releases. It also helps us avoid running into the "eaten by raptors" problem--if a key member of the team departs, how can we minimize the effects of their institutional knowledge being lost? The more of it we have written down, the easier it is not only for us to share agreement on what we're doing, but the simpler for the community to engage with the work wherever desired.
Another aspect of the open source way we apply is iteration. We work through developing and refining these criteria in an open and transparent way on our community mailing lists. The Fedora Quality Assurance team has spent a significant amount of time over the past few releases building up these criteria, and a matrix of tests that support them. That way when we hit specific schedule milestones we can do a better job of judging release readiness and identifying precisely which issues we might need to address to get to that release point. Furthermore, we come back to assess the process after release with a list of post-release issues to discuss and potentially fix. This assessment happens on a number of teams, including our QA team which has been gathering issues for their retrospective regularly over the course of the Fedora 13 development cycle.
How does Fedora get contributions and participation beyond just code and downloads?
We have an extremely robust community of contributions outside purely technical areas. We have hundreds of volunteer translators who localize the documentation and software for every release of Fedora so it can be enjoyed around the world. We have a team that produces documentation for Fedora such as our release notes, an installation guide, a deployment guide, SELinux documentation, and many other works. We have a community marketing team that produces collateral such as articles and interviews about Fedora features and contributors. These are just a few examples of places where non-programmers can easily contribute to Fedora. All of these teams practice the open source way in a friendly and supportive community effort, with two very important foci: easy participation and scalability through trust.
First, they all encourage the lowest effective barriers to participation. We strive to ensure the process of joining a team is as simple as possible, and that once someone joins, they find it easy to communicate with the rest of the team. We're also spending more time giving new team members well-defined expectations on what to expect from team membership, so that the collaboration is as smooth as possible. Team leaders are empowered to pursue new ideas that members bring to the table. For example, in the Fedora marketing team, one of our volunteer contributors from Germany, Henrik Heigl, is a credentialed member of the press. He is helping to define the future press kit to use in briefing journalists worldwide about basic facts concerning the Fedora Project and the distribution.
Second, these teams all strive to grow participants into leaders. When we find a process that is not easy to understand for a new participant, we encourage that person to help us explore, document, and solve the problem. The whole team learns something in the process, the new member feels a sense of belonging with the team, and is empowered to drive further improvements. This process also effectively accelerates the new member's movement from novice to expert, and we actively encourage members to become teachers themselves. The members that naturally gravitate to more responsibility, involvement, and communication with other Fedora Project Teams effectively identify themselves as future leaders.
Bonus: Where can users find out about the latest features and get access to Fedora 13?
The best place to get your hands on Fedora is at our download page, http://get.fedoraproject.org. We have a full feature list available on our wiki for each release at http://fedoraproject.org/wiki/Features.
Our community marketing team has produced a variety of feature articles in which we talk to individual developers about their work in Fedora, and the improvements they've produced for the Fedora 13 release. The list of articles can be found here: https://fedoraproject.org/wiki/F13_feature_profiles
More about Paul Frields
- Blog: the grand fallacy
- Follow Paul on Twitter: @stickster
5 Comments