This is the third and last part of Christian Siefkes second installment on material peer production, which tackles the general topic of free cooperation. After having introduced distribution pools and local associations as mechanisms, he now tackles the governance issue.
“How will projects and associations make decisions, how will they resolve conflicts? I cannot discuss this here in detail (see my book for a longer treatment), but my basic assumption is that they will do so in a manner that is similar to the practices of current peer projects.
Current projects tend to combine a _meritocratic_ element (participants trust “maintainers” and other specialists to “do the right thing”) with a _democratic_ element (projects strive for _consensus_ or _rough consensus_ among the participants, people “vote with their feet” by choosing which projects to support). Note that the _meritocratic_ element is far from being autocratic: since maintainers cannot order anyone around, they have to _convince_ participants that their decisions make sense–if the project members feel their decisions to be unfair or incompetent, they will sooner or later leave the project or start looking for a new maintainer. Note also that the _democratic_ element hardly takes the form of _majority voting_–the open character of projects makes it hard to determine who should be eligible to vote, and narrow majority decisions on controversial issues would endanger the stability of projects (those who lose a vote might decide to “fork” the project, founding their own alternative).
The “enforcement” of rules and decisions is often based on _technical means_ (somebody without write access to the code repository cannot damage the source code of a project) as well as on _trust;_ most projects manage to do quite well without formal control and sanction mechanisms. If people violate the rules, they are usually just told that they did wrong and admonished not to do so again–mostly this happens in a friendly fashion, but more aggressive and scolding “flames” occur as well, especially in more serious cases. Due to the important role of _reputation,_ trying to give somebody negative reputation by “flaming and shunning” them tends to be a powerful way of sanctioning people if less aggressive ways prove ineffectual. If all else fails, _boycott_ and _exclusion_ remain as the toughest sanctioning mechanisms.
I suppose that future peer projects and associations will pursue similar ways of decision making, striving for _rough consensus_ among the participating people and projects and trusting _maintainers_ and other responsible experts to “do the right thing,” especially in regard to technical issues. One difference to the current situation is that projects that _require_ contributions might rely more heavily on democratic decisions, including majority voting (at least as fallback mechanism). In such projects, the problem of deciding who is eligible to vote and to prevent duplicate votes becomes void since voting rights can be tied to contributions; and it seems reasonable that people who have to contribute will want to have more say in regard to the activities of a project. However, the concern that narrow majority votes would endanger the stability of projects still applies, hence it seems likely that majority voting would only be used as a last resort when (rough) consensus fails to emerge. Another way of ensuring the influence of contributors while keeping the meritocratic character of peer cooperation would be to assign _revocable positions_ for maintainers and other special roles.”