Codifying the meritocracy [LWN.net]

Free software communities are often described as being meritocracies - those who do the most, best work rise to positions of relative power and influence. The truth tends to be a bit more complicated than that; though. Politics and social "coolness" play a role in any community; free software is not exempt from the forces which act on any group of people. Projects dominated by a single company can also have a tendency to prioritize corporate control over merit. Even so, in a project of any size and independence, at least a shadow of the meritocratic ideal can be seen. Solid contributions lead to respect and influence.

That does not keep people from wanting to tweak the system, however. A number of projects, for example, would like to find ways to broaden the definition of merit beyond simple contributions of code. Finding ways to motivate documentation writers, artists, and reviewers is a common topic of discussion, for example. There is also interest in making the meritocracy more fair; that, in turn, can lead to an attempt to codify the merit system into a formally-described system.

The Debian Developer gauntlet is one longstanding example of a formal system; nobody can reach developer status without having gone through the seven-step process of convincing the project of their skills, commitment to free software, and more. This process is not perfect; in particular, it can take a very long time for a prospective new package maintainer to be accredited by the project. But it does help ensure that Debian maintainers are committed and able to do the job.

Now the Fedora Project is considering a formal system of its own - but this project, it seems, is not satisfied with just approving maintainers. Instead, the proposal currently under discussion would create a full seven levels of developer "merit." These levels would be:

FD0: the "probationary" level for new developers. This level grants the ability to modify one's own packages and to access the source code management system in a read-only mode.
FD1: a proper package maintainer. This level adds the privileges of orphaning one's own packages and subscribing to the glamorous fedora-maintainers mailing list.
FD2: Adds the ability to work with packages not specifically protected against outside access.
FD3 and FD4: at this level, developers can invite others to fedora-maintainers and take ownership of orphaned packages. (The proposal does not give any additional privileges to FD4). Attainment of these levels might be necessary to be eligible to sit on the steering committee.
FD5 is the "sponsor" level which can bring other developers into the system. Sponsors can control access to packages maintained by developers they sponsor, give unowned packages to anybody, etc.
FD6 is the "elder sponsor" level.

Developers who just want to maintain a few packages but who are not otherwise interested in influencing the direction of the project are likely to operate at the FD1 or FD2 levels. The proposal suggests that many Red Hat engineers would find their homes at those levels.

There is a rough set of proposed rules on how promotion through the ranks would be handled. Some criteria would be established:

Example: FD3 requires 17 quality reviews or 9 owned packages and shows clear competence in package guidelines. FD4 requires a history of giving opinions or helping others when needed in addition to other technical requirements...

Sponsor-level developers would have the power to promote anybody, possibly with a requirement that a certain number of other high-level developers agree. There is an interesting suggestion that promotion to the top level could require votes from a relatively large number of lower-level developers - promotion from below, in other words. There is a brief mention of a demotion process as well, though it is short on details.

This whole system may seem rather bureaucratic, and perhaps it is. The proposal is clear on why the project might want to impose this on itself:

As the project grows, you can't possibly know all contributors on the other side of the project. Viewing that member's stat page gives you a convenient snapshot of what they are working on, who they work with, who sponsored, who promoted, etc.

Fedora is a project which is trying to open itself up in a hurry. Its developers want to let outsiders come in and take responsibility for pieces of the distribution, but they are understandably reluctant to throw the doors open wide. So they need a process; the proposal discussed here is a starting point for the development of that process. By taking this approach, Fedora would appear to be breaking new ground in an attempt to formalize how the meritocracy works. It will be interesting to see how this experiment works out.

Time

Posted Mar 1, 2007 14:56 UTC (Thu) by rwmj (subscriber, #5474) [Link]

Free software isn't a running race. If it takes months or years for able people to rise through the ranks and become developers through recognising their contributions and skills, then so be it.

In this way free software is quite different from the internal hierarchies of companies which, in their own strange way, are often run like communist states or totalitarian fiefdoms. If you "gain the ear" of the CEO, you'll be placed high up no matter how incompetent you are.

Rich.

It's a bureaucracy, but necessarily so

Posted Mar 1, 2007 17:49 UTC (Thu) by pr1268 (guest, #24648) [Link]

This whole system may seem rather bureaucratic, and perhaps it is.

In my opinion, this bureaucracy is necessary for the following reasons:

The project community only has developers who have demonstrated their desire and intent to participate in the project (by satisfying all the requirements of the join process).
Often the membership process entails gaining an understanding of the project's goals, mission, and vision (I haven't read the specific process for Debian or Fedora). The side effect of this is that those developers who finish the join process are usually aligned in their thought processes and actions toward realizing the project's vision.
A formal, codified procedure for membership, production of deliverables (code, documentation, etc.), and quality review all work towards maintaining high standards of quality for the project's products.

Now that I think about it, this isn't that much different than private companies with employees who receive compensation (I'm thinking of proprietary software firms as an example), but the fundamental difference here is that the project's philosophies aren't totally distorted by motivations of monetary profit or time constraints. Instead, creative thought and ingenuity prevail. Gee, I'm loving FLOSS more and more every day!

Risks in codifying merit

Posted Mar 3, 2007 10:59 UTC (Sat) by jmtapio (guest, #23124) [Link]

I hope Fedora can make this work (good competition tends to be a good
thing for distributions), but I worry a bit about systems like these.

This resembles a lot the military rank system. What I have learned from
that field is that promotions tend to create tensions and bitterness
between people. When someone's "value" is codified officially, some people
become undervalued and some overvalued, and that always tends to lead to
pissed off people.

Secondly, in the military system usually the right to do something is not
directly bound to a certain rank. There people can be ordered to be able
to do something by their superiors just because they are trusted, even
though the person might not be officially highly ranked enough. I do hope
that Fedora does not end up limiting maintainer's contributions just
because they have not yet managed to rise enough in the official ranks.

The Debian system is nice because after someone has been qualified as a
developer, the rest of his/her rights depend mostly on how much key people
trust him/her. There is much less need in Debian to jump through the hoops
after the initial qualification.

Anyway, I hope Fedora can make this work.

Codifying the meritocracy

Read-Only Access to Package SCM

Time

It's a bureaucracy, but necessarily so

Risks in codifying merit