WikipediaOS

Purpose of this wikiresearch

Detecting and validating the parallelisms between Wikipedia's peer-production model and the way programmers and developers interact and work together in collaborative Open Source environments.

Main question: aka Central Hypothesis

The dynamics of interaction among participants in Wikipedia replicate the system of relations, values, processes, channels and other key aspects in communities and groups of open source development.

Methodology: for those about to rock contribute

The following table differentiates the 17 hypotheses that compound this thesis in a modular way: for validating, discussing or dismissing similar features, routines, proceedings and characteristics between Wikipedia and some OS projects, one by one and independently.

If you're familiar with OS development and Wikipedia (or wikis in general), please add your feedback inside any of the secondary pages accordingly. Regardless of your opinion, I would like to consider you then as a member of the Distributed Thesis Committee below :)

Thank you in advance!

Distributed Committee

This is a list in progress of the people helping to demonstrate that the central hypothesis of this wikiresearch is right (or not, we'll see :)

• Abd
• Erkan Yilmaz
• Fasten Specially for his comments at the discussion page :)
• Dave Braunschweig For adding the gender variable to the table..

Table of similarities: aka SubHypotheses (aka "core stuff")

Similarities Wikipedia / OS	SubHypothesis	Wikipedia examples	Open Source examples
Task specialization	Different tasks among wikipedians (wikigardening, adding external resources, proofreading, programming boots, etc) are equivalent to the same type of specialization among contributors in the development of free source software (adding code, testing programs, correcting bugs, translating, improving usability, etc). Support / oppose / comment	Users with different responsibilities: administrators, bureaucrats, stewards, Mediation Committee members, Arbitration Committee members and other “hybrid” users (from programming and tech issues to generating content, translating, spell-checking or wikification).	HowTo contribute to Debian ProjectNews, it "depends on people's skills and the amount of time they can spare". Tasks for sharing news, editing, translating, debugging, etc.
Meritocracy as a Decision-Making system	Contributors have a task-driven reputation (they "are" what they "do" for improving parts of the system). Obtaining trust from more experienced participants is mainly what allows them to participate wider, with higher levels of responsibility. Support / oppose / comment	Although not officially enumerated, for being electable as an admin different merits are needed (a record of article edits, help to other users, maintenance tasks, mediation, discussion of rules), otherwise nominations could not succeed.	The Apache Software Foundation and its govern based in merit. "When the group felt that the person had 'earned' the merit to be part of the development community, they granted direct access to the code repository".
Content and process transparency	Environments are based in transparency, potential contributors and other people interested in activities can know the details of its output (being an article or a piece of software) as well as the discussions generated during its development. Support / oppose / comment	Regarding processes, there are discussions about articles, content and every individual category, in talk pages or others. Also detailed records like the ones for bot edits. Regarding content, each page has it every minimum detail registered in the page history	Possibility of accessing the source code for modifying it, like in the case of the Linux kernel where source can be downloaded or changes viewed (for example in changelogs).
Release early, release often	Quick processes of development guarantee the possibility of growing articles and programs with the help of many participants. They have this way the opportunity to watch and/or test improvements or mistakes in non definitive versions, then solve them directly or by notifying other active members of the community. Support / oppose / comment	In Wikipedia (and wikis in general) the main editing philosophy is about being bold, publishing frequently and without needing to wait for the complete development of articles. Like a work in progress, that spurs the elaboration of content.	A practical way of seeing that philosophy in the production of open source software could be to browse Freshmeat’s list of projects by its vitality, based in a calculation about the antiquity of the project, its number of announcements, and the date of its last release. According to another OS leit motifs: "given enough eyeballs, all bugs are shallow" (Linus law).
Development of parallel comments	Actions of communication among contributors in both areas are primarily object-oriented, leading to asynchronous awareness with comments and discussions mainly about development details (whether of Wikipedia articles or pieces of code, and as close as possible to where the work is done) rather than about general issues. Support / oppose / comment	Talk pages, a meta level for opinions, questions, planning, debating, etc. around articles but also users, categories, portals, special pages. Sysops noticeboard as another example.	Between programmers it's usual to leave comments within pieces of code, making it easier to install but also to understand programs (even for oneself). Another good example could be specific forums for each project at SourceForge.
Benevolent dictatorship	When it comes to impose authority and leadership in large, voluntary, and consensus oriented communities such as Linux, Drupal, Python or other open source software-development projects, the role of founders is to have final control over the direction of projects, like at the beginnings of Wikipedia did Jimmy Wales or Larry Sanger. Support / oppose / comment	For example Jimmy Wales, being (or rather ‘not needing to be’, usually :) the maximum (and recognized) authority in case of polemics between Mediation and Arbitration Committees.	Benevolent Dictators For Life (BDFL) are for example Guido van Rossum (Python), Larry Wall (Perl), Dries Buytaert (Drupal) or Steve Coast (OpenStreetMap)
Possibility of forking	Projects may be forked from the original development team without prior permission, resulting in a distinct piece of software or content that initially had the same structure. Support / oppose / comment	Depending on the level, it could be a page forking (with subpages linked or specially disambiguation needed) or parallel projects derived from Wikipedia, like it happened with the Spanish Enciclopedia Libre.	See Fear of Forking, an essay that gives account of some famous forks, in projects like Unix, emac or BSD, and where forking is considered a non negative possibility in decentralized programming.
Licensing	Copyleft licensing determines all actions, processes and outputs as pieces that can be copied and recombined. Also reinforces the prominence of contributors and his work. Support / oppose / comment	In Wikipedia, the initial adoption of the GNU documentation license guaranteed the same replicability and scalability of contents that programs or distributions have. It was changed to CC-BY-SA in 2008.	What's GNU? Gnu's Not Unix! "The golden rule requires that if I like a program I must share it with other people who like it."
Social filtering	Against attacks and vandalism mainly, but also destructive or negative inputs, some tools and roles protect projects from certain type of users and its intentions. Support / oppose / comment	Due to the high amount of vandalism acts (and other types of intentional damage or disruption), blocking users is sometimes a must.	Trust metrics like in Advogato, for validating accounts but also reducing the impact of attackers, spammers or trolls.
Platforms for nesting projects	In order to obtain and maintain a critical mass of quantitativa and qualitative participation, as well as transversal activity, sister projects should share communication channels and appear somewhere at the same level. Support / oppose / comment	Wikimedia Foundation projects. Although at a lower level each different language Wikipedia or specific portal could be understood as a platform for nesting projects.	SourceForge’ most active projects. Also sites like Advocato, that centralize projects and participants’ identities while maintaining the forges outside.
Reusing of sources	Copy and paste task and practices speed up productive tasks, that require afterwards peer revision and adaptations for new purposes and functions. Support / oppose / comment	Is common practice (specially in non English Wikipedias) to begin articles with translations from the English one (that later on can acquire its own local or cultural perspective).	Recycling code is an usual practice, based in the principle that nobody should solve the same problem twice.
Netiquette	People (digital identities) need to address each other respectfully, but also following written rules that don't let discussions have an adverse effect on a good environment for productivity. Support / oppose / comment	Wikiquette as a good manners guideline, for avoiding personal attacks or edit wars.	How to ask questions the smart way is a classic reference for understanding communication among hackers and programmers.
Need of "enemies of the common"	Community cohesion sometimes comes from shared criticism to individuals or organizations which represent an opposed model to the core values of the project. Support / oppose / comment	In the genesis of Wikipedia there is already a certain critic to Britannica’s or Encarta’s knowledge production model (see for example this table).	There is a shared culture of opposition to Microsoft’s hegemonic model, also applied to proprietary software and to the conceptual split between "free software" and "open source" movements.
Activity tracks	Active or stigmergic signs in platforms generate critical mass of contributors, who can follow last changes easily. Activity tracks and signs lead to more activity tracks and signs. Support / oppose / comment	Special pages like recent changes or most wanted articles constitute a temporal track for attracting participants to active focal points of information.	SourceForge projects recently approved or Github timeline are good examples.
HowTos and ad hoc guidelines	Active learning leads to educational resources (dynamic, always in process) generated by new and repetitive types of activity, specially for newcomers. Support / oppose / comment	Wikipedia HowTos about technical, content, editing or vandalism, like the deletion guidelines for admins.	The HowTo is a genuine hacker learning informational product. See for example this list of Linus howtos or this one in the Gentoo wiki.
Issue Tracking / Debugging	Problem-solving activities are consequence of the "release early and often" approach. Some processes focus in critical bugs, while some others in improving details for more quality. Support / oppose / comment	For problem-solving related to quality growth see articles for deletion and special pages related to vandalism.	See SourceForge's bug list. This is another strong point of Open Source development, since it leads to stable versions and represents one of its motivational driving forces (detecting and fixing bugs).
"Self-interested" participants ${\frac {r\cdot B\cdot m}{n}}$	Even in voluntary communities like Wikipedia or OS development some people contribute or play a role due to motivations more connected to third parties than the community itself, like corporate interests. Support / oppose / comment	See controversy about Microsoft funding for someone editing its Wikipedia article	See IBM and its strategy of involvement in the development of OS projects
Differences in gender participation	Big difference between the percentage of men contributing, while women represent a significant minority of participation	87 percent of contributors to Wikipedia are men.	Example in OS...
Other examples?	Write the hypothesis here	Example in Wikipedia...	Example in OS...

Further questions

• Are the technical features of wiki tools making possible the rapid adoption of this type of development strategies for collaborating?
• The possibility of vandalism, inherent to every wiki editing philosophy, could work as a spur for integrating and bonding the community of participants for their merits?
• Did the initial strategies for spreading the Wikipedia project and philosophy lead to a significant participation of users closely related to open source development?

About the researcher

Enric Senabre Hidalgo (user:esenabre): I did my PhD courses at the Open University of Catalonia (where I teach Multimedia now) and my final research seminar with Professor Manuel Castells.

This collaborative research process is based on a presentation I did back in 2007 at Wikimania in Taipei. I had the idea of this implementation since then, but you know work, family and life in general didn't let me have time for doing it until now :)

I'm twittering here You can contact me at esenabre[at]uoc.edu More info about me here