Why GNU cannot afford to be a meritocracy (or even a democracy).

[Andreas]

In theory the idea of a meritocracy for a project like GNU sounds
appealing: those who do the most work have the greater say in what
course to set.

Meritocracy seems to naturally embodies an idea of fairness and
inclusion.

The problem is that software is not fungible. As such, some projects
will be more popular and some less, and also some software will be more
successful commercially than other software.

If a piece of software is commercially successful it sometimes means
that some people can find full time employment maintaining or extending
it. This is obviously a great thing.

Less obvious is that now, with full time employment, meritocratic
decision making will shift heavily in favour of those employed to work
on the commercially successful projects. 

The problem with this is twofold:

1. economic relevance of certain software will gain influence at the
cost of less economically viable software, even though from a software
freedom perspective the latter might be just as important.

2. people are notoriously biased when their employment is involved.
They might not vote in the best interest of the general project.
Compounding this is that if some piece of software is really
successful, companies formed around this software might employ new
people who have no interest in Free Software, but due to their skill
can become maintainers.

These flaws in meritocractic decision making can be extended to
democractic decision making: outcomes can be influenced by popularity
or self interest, neither of which has direct bearing on software
freedom.

To see what meritocracy can result in one has to look no further than
one of the most popular software projects under the GPL, which has a
governing foundation that cozies up to GPL violators and patent
abusers, and has a president that doesn't even use their own software.

The current situation for GNU is that there is a chief GNUIsance. A
position whose single power seems to be having a veto over what
interpretations of the four software freedoms are acceptable for the
project.

Having a single person in a pivotal position can be an unstable setup,
and it is nearly impossible to implement after a project has gained
some momentum. Fortunately for GNU, it has had someone to fill the
position from the very beginning, who has so far never faltered in
their duty of chief GNUisance.

As such, the current system has mostly worked and it would be counter
productive to try and exchange it at a whim for another system that is
either known to be inferior (from a software freedom perspective), or
of which the effects are completely unknown, for reasons that are not
related to the fundamental role of chief GNUisance.