Finding the next failure.

I caught up on the last couple days of the Planet, and found two particularly interesting posts, one by Kevin Fenzi and the other by John Poelstra. The former contains a years-old (but still 100% accurate) presentation on protecting an open source project from threats from within. The latter contains a rallying call against stagnation, and reminds us of the silent 5th ‘F’ in our project values — fail faster.

To improve Fedora, as a project we need to be willing to embrace some level of change. We can do this with the confidence that we don’t need to write change in stone just to make it happen. Looking back through the history of Fedora, we’ve been through some level of change continuously since the beginning of the Project. Sometimes the changes we’ve made have been to discontinue processes that don’t work. Excess governance comes to mind, for example, or having all our media and swag rely on someone in Red Hat. In other cases we’ve struck out to find new ways to collaborate, like expanding our roster of premier Fedora events, or setting up unique communications channels like Fedora Talk.

Whenever we’ve made these changes, we’ve tried to ensure we were identifying and solving specific issues by doing so — in other words, changing not for the sake of change, but to improve the Fedora Project and our software. The particular issue we’re faced with currently is how to resolve many different ideas about what Fedora users should expect from our stable releases. Recent discussions show that there are several competing ideas in play, and when disagreements exist, fortunately we have leadership bodies to help resolve them. This isn’t the first or last time that the Fedora community has found that we hold a variety of views yet need to find a unifying direction.

I brought up Kevin’s and John’s blog posts earlier because even though the content was created years apart — a Google video from 2006, and contemporary thoughts on embracing change — they both are completely applicable to Fedora as part of our shared philosophy. A prominent point made early on in the video Kevin posted is that attention and focus are valuable and scarce resources in any open source project. The presenters are largely pointing back to works like Karl Fogel’s excellent book Producing Open Source Software, which Red Hat’s Community Architecture and I continue to regularly recommend to people we advise.

To succeed, the presenters assert, a project must achieve a shared understanding of its mission and scope. Our mission includes producing a distribution that serves as both an effective R&D lab, and as a vehicle for attracting interest in and contribution to free software. Being unafraid of changing our approach improves our ability to reach these goals. Moreover, doing so is just as much a part of our founding precepts of community as openness and transparency. As John points out, this isn’t a problem with a binary solution for all time. (Many problems worth solving have that in common.) We have opportunities to improve continually, and as a project we need to be more aggressive about taking them. The prospect of failure is much less frightening than the prospect of stagnation.

The Fedora Project Board and I have been interested in leading this change for some time. In October set out a broad definition of a user base that would help guide decisions and choices about how to continue to improve the Fedora distribution — the sum total of software that we promote as part of the Fedora Project. The set of issues around how, when, and to what extent we provide updates is just one aspect of these improvements.

We went through many open discussions to get to that point so we could build a reference and a basis for helping to guide appropriate change in the Fedora Project. The Board and I want to make it easier for FESCo to make coherent decisions around distribution policies such as updates. Sharing an understanding of the wide user base we’re trying to serve helps us better identify situations that are problems for that broad group. Then we’ll find ways to solve them, iterating through successes and failures and learning from them if necessary — as we’ve done in Fedora from day one.