New forms of collaborative innovation and production on the internet

This paper does not test an intervention. It is a theoretical and literature-based review that examines:

The phenomenon of **peer production** (e.g., Wikipedia, open source software, user-generated content platforms)

How **voluntary contributions** by large numbers of users lead to new forms of production and innovation

How these forms challenge established insights into:

- Governance of economic action (e.g., why do people work for free?)

- Sources of innovation (e.g., user-driven vs. firm-driven)

- Collective action (e.g., overcoming free-rider problems without formal organisation)

- Social, legal, and technical preconditions for successful collaboration

The paper compares **peer production** (non-market, voluntary, decentralised) against **traditional firm-based production** (market-driven, hierarchical, proprietary) and **market-based innovation** (patent-protected, R&D-driven). It does not define specific outcome measures—instead, it discusses qualitative dimensions like "motivation," "governance," "quality," and "sustainability."

No human subjects were studied. The paper reviews case studies and prior research on:

**Wikipedia** (millions of volunteer editors, no formal hierarchy)

**Open source software projects** (e.g., Linux, Apache—thousands of volunteer developers)

**Social networks** (e.g., Facebook, Twitter—user-generated content)

**User-generated content platforms** (e.g., YouTube, Flickr)

**Firm-driven Web 2.0 services** (e.g., Google's crowdsourced data, Amazon Mechanical Turk)

The "sample" is the set of prior studies and examples cited, which span from the late 1990s to 2011. No demographic data, sample sizes, or effect sizes are reported because the paper does not conduct a meta-analysis or systematic review.

No measurement instruments were used. The paper relies on:

**Qualitative case descriptions** (e.g., "Wikipedia has over 3 million articles in English as of 2011")

**Theoretical arguments** (e.g., "Peer production challenges the Coasean theory of the firm")

**Citation of prior empirical studies** (e.g., studies on open source developer motivation using surveys, but these are not synthesised quantitatively)

For a self-experimenter, this means the paper provides no validated scales, no effect sizes, and no statistical tests. It is a conceptual framework, not an experimental report.

**Study design:** This is a **theoretical review / conceptual paper**—not an empirical study, not a meta-analysis, not a systematic review. The author(s) synthesise existing literature from multiple disciplines (economics, sociology, law, computer science) to propose a new interdisciplinary framework for understanding internet-enabled collaboration.

**Key design features:**

No randomisation, no blinding, no control group, no washout period, no duration.

The paper does not collect new data. It reinterprets existing case studies and theoretical work.

The "method" is argumentation: the author(s) identify gaps in existing theories (e.g., "theories of the firm assume hierarchical coordination, but Wikipedia has no hierarchy") and propose that peer production represents a third mode of production alongside markets and hierarchies.

**What this design can prove:**

It can identify conceptual gaps and propose new research questions.

It can synthesise disparate literatures to generate hypotheses.

It can argue that existing theories are incomplete.

**What this design cannot prove:**

It cannot establish causal relationships (e.g., "peer production causes higher innovation rates").

It cannot quantify effect sizes (e.g., "peer-produced software has 20% fewer bugs than proprietary software").

It cannot rule out alternative explanations (e.g., "Wikipedia's success is due to its specific governance, not peer production per se").

It cannot generalise to other contexts (e.g., "this model works for all types of knowledge work").

**Major methodological weaknesses:**

No systematic search strategy (e.g., no PRISMA flow diagram, no explicit inclusion/exclusion criteria).

No quantitative synthesis (no meta-analysis, no effect sizes).

Potential selection bias: the paper likely cites examples that support its thesis (e.g., Wikipedia, Linux) and may ignore failed peer production projects (e.g., abandoned wikis, failed open source projects).

No discussion of publication bias or conflicting evidence.

The paper is from 2011—many of its claims about "new" forms are now well-established, and some platforms (e.g., Google+) have since failed.

Since this is a conceptual paper, "findings" are theoretical claims rather than empirical results. The paper's main arguments (paraphrased from the abstract and implied structure):

**Peer production is a distinct mode of production:** It differs from both market-based (firm-driven) and hierarchy-based (state-driven) production. It relies on voluntary contributions, decentralised coordination, and non-proprietary outputs.

**Motivations are diverse:** Contributors are driven by intrinsic motivation (e.g., enjoyment, learning, ideology), social rewards (e.g., reputation, community recognition), and sometimes extrinsic rewards (e.g., future job offers). This challenges the assumption that people only work for money.

**Governance is emergent:** Successful peer production projects often develop lightweight governance structures (e.g., Wikipedia's "benevolent dictator" model, open source project maintainers) that are more flexible than formal organisations but still provide coordination.

**Quality can be high:** Examples like Linux (used in servers, Android) and Wikipedia (comparable accuracy to Encyclopaedia Britannica in some studies) suggest that peer production can produce high-quality outputs, though quality varies widely.

**Legal and technical preconditions matter:** Open licenses (e.g., GNU General Public License, Creative Commons) and low-cost communication tools (e.g., version control systems, wikis) are necessary for peer production to scale.

**Firms are adapting:** Many firms now use Web 2.0 tools to harness user contributions (e.g., user reviews, crowdsourcing), blurring the line between peer production and market production.

**No numbers are reported.** The paper does not provide:

Effect sizes (e.g., "peer production increases innovation output by X%")

Confidence intervals

P-values

Sample sizes for any cited study

Not applicable. This paper does not report any quantitative effects. The "effect" is conceptual: the paper argues that peer production is a significant phenomenon that requires new theoretical frameworks. For a self-experimenter, the magnitude of any effect (e.g., "how much more productive are peer-produced projects compared to traditional ones?") is not addressed.

**Acknowledged by the authors (implied):**

The paper calls for "an interdisciplinary approach," acknowledging that existing research is fragmented across disciplines.

It notes that "fine-grained empirical studies already exist" but does not synthesise them quantitatively.

**Critical reader's assessment:**

**No empirical data:** The paper is entirely theoretical. It cannot be used to make evidence-based decisions about running a peer production project.

**Selection bias:** The paper focuses on successful examples (Wikipedia, Linux) and ignores failures (e.g., abandoned open source projects, wikis that never gained traction). This creates an overly optimistic picture.

**Outdated:** Published in 2011, the paper predates the rise of platforms like GitHub, Stack Overflow, and the decline of some early Web 2.0 services. Its claims about "new" forms are now historical.

**No testable hypotheses:** The paper does not propose specific, falsifiable predictions. For example, it does not say "peer production projects with open licenses will have 30% higher contributor retention than those with restrictive licenses."

**No discussion of downsides:** The paper does not address issues like vandalism (Wikipedia), burnout (open source maintainers), or exploitation (crowdsourced labour on platforms like Mechanical Turk).

**No practical guidance:** A self-experimenter looking for "how to run a peer production project" will find no actionable advice on recruitment, motivation, governance, or quality control.

For someone running their own n=1 experiment (e.g., testing whether a peer production model works for a personal project):

**What to test:**

**Intervention:** Launch a small-scale peer production project (e.g., a wiki for a hobby community, an open source software tool, a collaborative document). Compare it to a traditional solo or hierarchical approach.

**Dose:** Run the project for a fixed period (e.g., 3 months) with a defined scope (e.g., "create a 10-page guide on X").

**Minimum meaningful duration:**

At least **3–6 months** to allow for initial contributor recruitment, content creation, and community formation. Peer production projects often take time to gain momentum.

**What to measure (specific metrics):**

**Contributor count:** Number of unique contributors per week/month.

**Contribution volume:** Number of edits, commits, or posts per contributor.

**Quality:** For a wiki, use a standardised rubric (e.g., completeness, accuracy, readability). For software, track bug reports and feature requests.

**Retention:** Percentage of contributors who return after their first contribution.

**Time to first contribution:** How long after launch do new contributors appear?

**Governance effort:** Hours spent by you (the organiser) on moderation, coordination, and technical maintenance.

**Key confounds to control for:**

**Topic popularity:** A project about a niche topic (e.g., "how to repair vintage watches") will attract fewer contributors than a broad topic (e.g., "how to cook pasta"). Control by choosing a topic with a known community size.

**Platform choice:** A wiki on a dedicated site (e.g., MediaWiki) may attract different contributors than a Google Doc. Use the same platform for the entire experiment.

**Your own effort:** If you actively promote the project, you may inflate contribution rates. Keep promotion constant (e.g., one post on a relevant forum, no further advertising).

**Seasonality:** Contributions may drop during holidays or exam periods. Run the experiment during a stable period (e.g., not December–January).

**Technical barriers:** If the project requires technical skills (e.g., Git for open source), this will limit participation. Choose a low-barrier platform (e.g., a simple wiki) if you want to test general peer production.

**What a positive result would look like:**

You observe **at least 5 unique contributors** (beyond yourself) within the first month.

**Total contributions exceed what you could produce alone** (e.g., the wiki grows to 50 pages in 3 months vs. 10 pages if you worked solo).

**Quality is comparable or better** (e.g., independent raters score the peer-produced content as 7/10 vs. 6/10 for your solo effort).

**Contributor retention is >30%** (i.e., at least 1 in 3 first-time contributors returns to make a second contribution).

**Important caveat:** This paper provides no empirical basis for these thresholds. They are derived from general observations of peer production projects (e.g., Wikipedia's early growth, open source project dynamics). Your n=1 experiment will be exploratory, not confirmatory. Treat any positive result as a hypothesis for further testing, not a proof that "peer production works."

**Alternative approach:** Instead of running your own project, you could run a **behavioural experiment** on yourself: test whether you are more productive when contributing to a peer production project (e.g., editing Wikipedia) vs. working alone on a similar task. Measure your output (e.g., words written per hour), enjoyment (e.g., 1–10 scale), and quality (e.g., peer review scores). Run each condition for 2 weeks, with a 1-week washout. This would test the paper's claim that intrinsic motivation drives peer production—but again, the paper provides no effect sizes to power your experiment.