Peer Production - Authority Structures
Summary by Michel Bauwens: "Aaron Krowne has done useful work to define the authority models at work in such projects. The models define access and the workflow, and whether there is any quality control. The free-form model, which Wikipedia employs, allows anyone to edit any entry at any time. But in the owner-centric model, entries can only be modified with the permission of a specific ‘owner’ who has to defend the integrity of his module. He concludes that “These two models have different assumptions and effects. The free-form model connotes more of a sense that all users are on the “same level," and that expertise will be universally recognized and deferred to. As a result, the creator of an entry is spared the trouble of reviewing every change before it is integrated, as well as the need to perform the integration. By contrast, the owner-centric authority model assumes the owner is the de facto expert in the topic at hand, above all others, and all others must defer to them. Because of this arrangement, the owner must review all modification proposals, and take the time to integrate the good ones. However, no non-expert will ever be allowed to “damage" an entry, and therefore resorting to administrative powers is vanishingly rare." The owner-centric model is better for quality, but takes more time, while the free-form model increases scope of coverage and is very fast. The choice between the two models can of course be a contentious issue. In the case of the Wikipedia, the adherents of the owner-centric model, active in the pre-Wikipedia "Nupedia" model, lost out, and presumable, the success of Wikipedia has proven them wrong, since the latter totally open process has been proven a success . Similar conflicts are reported in many other projects . Collaborative projects are no utopian scheme were everything is better, but subject to intense human conflict as well."
The arguments for the owner-centric model advocates for Wikipedia are summarized here at http://www.kuro5hin.org/story/2004/12/30/142458/25 .The article is very informative about the kinds of problems that arise within P2P communities.
“Second problem: the dominance of difficult people, trolls, and their enablers. I stopped participating in Wikipedia when funding for my position ran out. That does not mean that I am merely mercenary; I might have continued to participate, were it not for a certain poisonous social or political atmosphere in the project. There are many ways to explain this problem, and I will start with just one. Far too much credence and respect accorded to people who in other Internet contexts would be labelled "trolls." There is a certain mindset associated with unmoderated Usenet groups and mailing lists that infects the collectively-managed Wikipedia project: if you react strongly to trolling, that reflects poorly on you, not (necessarily) on the troll. If you attempt to take trolls to task or demand that something be done about constant disruption by trollish behavior, the other listmembers will cry "censorship," attack you, and even come to the defense of the troll. This drama has played out thousands of times over the years on unmoderated Internet groups, and since about the fall of 2001 on the unmoderated Wikipedia. Wikipedia has, to its credit, done something about the most serious trolling and other kinds of abuse: there is an Arbitration Committee that provides a process whereby the most disruptive users of Wikipedia can be ejected from the project. But there are myriad abuses and problems that never make it to mediation, let alone arbitration. A few of the project's participants can be, not to put a nice word on it, pretty nasty. And this is tolerated. So, for any person who can and wants to work politely with well-meaning, rational, reasonably well-informed people--which is to say, to be sure, most people working on Wikipedia--the constant fighting can be so off-putting as to drive them away from the project. This explains why I am gone; it also explains why many others, including some extremely knowledgeable and helpful people, have left the project… The root problem: anti-elitism, or lack of respect for expertise. There is a deeper problem--or I, at least, regard it as a problem--which explains both of the above-elaborated problems. Namely, as a community, Wikipedia lacks the habit or tradition of respect for expertise. As a community, far from being elitist (which would, in this context, mean excluding the unwashed masses), it is anti-elitist (which, in this context, means that expertise is not accorded any special respect, and snubs and disrespect of expertise is tolerated)… Consequently, nearly everyone with much expertise but little patience will avoid editing Wikipedia, because they will--at least if they are editing articles on articles that are subject to any sort of controversy--be forced to defend their edits on article discussion pages against attacks by nonexperts."
Town council vs. clique, a conflict in the early phases of Linux
"Alan Cox, a senior Linux developer, introduces two more organizational metaphors, the "town council" and the "clique," in an essay published on Slashdot in 1998. Cox provides a "guide to how to completely screw–up a free software development project" by describing the early days of the Linux on 8086 project, "one of the world’s most pointless exercises" and therefore one that has great "Hack Value." Cox writes that this obscurity meant that there were really only two or three people with both the skill and interest required, but also many "dangerously half–clued people with opinions — not code, opinions." These "half–clued" participants acted like a "town council" which created so much ineffectual noise that the core developers were lead to abandon the "bazaar model" and, using kill files, formed a "core team" which, Cox writes, "is a polite word for a clique." Cox argues that ignoring the "half–clued" was understandable but badly mistaken and ultimately caused the project to stall, not least because the real programmers were unable to help the wannabe programmers to learn to contribute usefully and thus change the unproductive "town council" into a productive project." (http://www.firstmonday.org/issues/issue10_2/crowston/index.html)
Types of conflict in open source communities
"Four types of conflicts can be identified in the FLOSS field: ideological, technical, personal and cultural conflicts. Of course, most actually existing conflicts are a mixture of these types.
Ideological conflicts are usually about differing ideas about and approaches to the meaning of freedom of software. The Gnome project, for example, was founded as a result of a conflict with KDE who used the then proprietary Qt library from Trolltech. It could be argued that the term Open Source also emerged as the result of such a conflict. A group of key people in the field — such as Eric Raymond — introduced the term to give the phenomenon a new name. They wanted to distance themselves from the FSF and its allegedly anti–commercial attitude. They hoped to popularise Open Source Software, as they now called Free Software, among wider groups of users, who, they felt, might have been alienated by the FSF’s value–conscious approach.
Technical conflicts are, evidently, about different views on the best solution for a given technical problem. Bearing in mind the strong role of technological perfection and code elegance, they have a huge conflict potential. Like the famous debate about macro– vs. micro–kernels, these conflicts are disputes about the best way to achieve a specified target.
Personal conflicts usually result from the behaviour of individuals who commit a breach of (social) norms. All discussions about how people should behave towards each other fall into this category. Also in this category was a case when a developer unjustifiedly claimed authorship.
The fourth and final type of conflict is best described as cultural. These are less about breaches of norms, and have more to do with the non–acceptance of norms. One such conflict has developed over the past few years following the wider spread of FLOSS; today, there are many users with only a very limited knowledge of computers. But it is not only their level of skills (which is lower), their attitude to computers is also quite different. They take a consumer’s view of FLOSS and have very different expectations vis-à-vis developers. They wait (or ask impatiently) for a specific feature instead of contributing to its development. They ask questions clearly answered in the documentation — both demands which are very similar to those made by purchasers of commercial products. This results in many conflicts between developers and users who are not part of the FLOSS (sub) culture, and to mutual alienation." (http://www.firstmonday.org/issues/issue9_11/lehmann/index.html )