Fedora considers a new governance structure

At Flock 2014 in Prague, members of the Fedora project took the first steps toward a significant change in the project's governance structure. Most of the details have yet to be worked out, but there appears to be a rough consensus about what type of change is required. At issue is how the Fedora Board, ostensibly the top-level governing body for the distribution, functions. While the Board is, today, an elected body chosen by the project as a whole, in the future it may be made up of representatives selected separately by Fedora's many sub-projects. The goal would be a governing entity better poised to provide clear long-term guidance for the distribution.

The primary discussion took place during a two-hour workshop session on the last day of the event. Toshio Kuratomi and Haïkel Guémar moderated, as well as providing a general introduction to the topic, but the majority of the discussion, fittingly, came from members of the audience.

The central idea up for discussion was a proposal first put forward in late 2013 by Josh Boyer in an email to the board-discuss list. Boyer contended that the Board's job description is too vague, and that in practice it does very little, particularly in the realm of setting "long-term vision" for the project—which is allegedly one of its primary functions. In contrast, everyone seems very clear on what tasks the Fedora Engineering Steering Committee (FESCo) does, from making technical decisions that range from the "go/no-go" vote on each release to setting practical goals for each development cycle.

One reason the Board is not very effective, Boyer said, may be that it is composed of essentially random people who were elected or appointed, but do not necessarily represent the Fedora community as a whole. During the session, he elaborated a little on that point, saying that many people run for the Board simply because the Board exists, and that the project-wide elections basically boil down to a name-recognition contest.

Boyer's original proposal was that the Board be replaced with a "community council" that was guaranteed to include representatives from all of the major sub-projects in Fedora: engineering, documentation, infrastructure, design, QA, marketing, and so on. This Board-replacement body would be better suited to think about long-term strategy for the project, which is especially important now that Fedora is moving toward its new "three product" approach: separate deliverables for desktops, servers, and cloud instances.

The solution Boyer proposed was to dissolve the Board and replace it with a new council. The details have changed somewhat in the months since his original email—and, indeed, many variations on how such a replacement would be chosen and what it would do were discussed during the session.

Today's Board

In its current form, the Board consists of ten members: the Fedora Project Leader (FPL), four board members appointed by the FPL, and five elected directly by the members of the Fedora project as a whole. As current FPL Matthew Miller pointed out, this ten-member structure has a safeguard against deadlocking on decisions in the form of the FPL's "trump" vote, which can be used to break ties. However, this special vote can only be used as a veto, to vote no on a proposal, so it is limited in its utility.

At the start of the session, Kuratomi and Guémar outlined a few current concerns that Fedora project members have about the Board—some related to Boyer's proposal, but not all. Among them is the perception that the Board is completely passive (i.e., it only considers questions that others bring to it, rather than setting direction), that there is no clear delegation of power from the Board to the project (e.g., when the Board makes a decision, it is rarely clear who should implement it and how), and that it does not produce useful documentation of the policies and guidance that it is responsible for.

Several, including Boyer and Miller, said that this makes the board much like the US Supreme Court: it stays out of the way unless appealed to, it makes its decisions as narrowly as possible with others left to interpret them, and it produces only "case law" to refer to, rather than legislation. There are good facets to this model, of course, but, at a practical level, there are already a large number of Fedora teams and committees outside the Board that do the day-to-day work of setting the direction of the project and stewarding its development. Perhaps it would be better, the argument goes, for the Board to be more of an executive body.

There would be a general benefit to having a more active Board—one that meets regularly and considers the direction of the project—and such a revised Board would be particularly helpful at present, when Fedora is undertaking several significant (and, at times, confusing) changes to how it makes releases, packages software, and interacts with users.

A council rather than a board?

Perhaps predictably, the open discussion during the session consisted of quite a bit of back-and-forth about the details of how a Board-replacement body might function (as well as quite a few tangents, which Kuratomi and Guémar admirably strove to reign in). But a straw poll (which, of course, is non-binding) taken halfway through the session revealed that participants in the room universally supported a community council designed to guarantee representation from a wide swath of the Fedora project's teams.

But the details are not as clear. Miller illustrated the problem of defining a council that is representative of the whole project when he drew a diagram of all of Fedora's teams and sub-projects on a whiteboard. The diagram took up an entire classroom-sized panel, and even then, audience members pointed out multiple missing pieces. A council with 100 members might represent all of the active teams, but would find it nearly impossible to conduct (or even schedule) meetings.

Furthermore, it is not clear than every individual team in the project needs its own representative on the council. As an example, Miller pointed out that he only recently discovered that there is a separate team that works on QA just for translations. While that is an important task, perhaps the team would be well represented by a committee member from the translation community or the QA team (although which one, in this case, is yet another open question).

Exactly what a Board-replacing council would be charged to do is another topic still up for debate. Ultimately, those in the meeting generally agreed that a representative council would be better suited to tackle tasks like setting long-term vision for Fedora—say, three-to-five years out—while FESCo could handle the issues that arise for each development cycle.

A second straw-poll vote was taken on the topic of whether or not the council should take an active role in setting policy. On that question, a large majority voted yes, but the yes was not universal. Vít Ondruch pointed out that the Fedora.next long-term plan, which includes the multiple "product" deliverables, was made (and so far has been implemented) without a new, active community council, and was not driven by the existing Board, either.

Debate.next

Naturally, even a two-hour session was not enough time to discuss all of the possibilities. Most of the last hour of session was spent brainstorming and debating the merits of various possible council designs and configurations: having proportional representation for the larger "supercommunities" in Fedora, having two council chambers, having the FPL personally select representatives versus having individual communities select their own council delegates, and so on.

The discussion is clearly nowhere near its end, but then again it should not be: as several in the room pointed out, restructuring the governance of Fedora is a major undertaking that affects hundreds of contributors. A few dozen people in one session room at Flock are not enough to capture every viewpoint, much less make decisions for all.

Unfortunately for the FPL and Board, those decisions will eventually have to be made. At this point, it seems like Miller and the current Board members will have to guide the decision-making process to its next stage. But there does appear to be momentum in play to restructure Fedora's top-level governance, providing more active guidance and a voice to more participants. It is a scary thing to contemplate changing the head of a large organization. Although, as Boyer pointed out, Fedora has done well pushing out release after release for years now even with a governance model that many feel does not work; if it tries something new that doesn't work, it knows how to adapt and move on to the next idea.

[The author would like to thank the Fedora project for travel assistance to attend Flock 2014.]