Commons-Based Peer Production Ecosystems and Platform Capture Risks

1. Meaning

Commons-based peer production (CBPP) refers to a system in which a large number of individuals or organisations collaboratively create and maintain resources through decentralised participation rather than through a traditional hierarchical firm.

The concept is strongly associated with Yochai Benkler.

Examples include:

open-source software;

Wikipedia;

open mapping projects;

open databases;

open educational resources;

open scientific repositories;

collaborative AI datasets;

decentralised digital communities.

The basic structure is:

Contributors → Shared resource/commons → Users

A platform can be added to this structure:

Contributors → Platform → Commons → Users

The competition-law concern arises when the platform becomes sufficiently powerful that it can capture, control, restrict, monetise, or selectively govern access to the commons that it did not originally create.

This is called platform capture risk.

2. What Is Platform Capture?

Platform capture occurs when a platform or intermediary acquires substantial control over a community-created resource, network, dataset, ecosystem, or user base and uses that control to influence competitive conditions.

Capture can occur through:

control of access;

control of ranking;

control of interfaces;

ownership or control of data;

exclusive licensing;

interoperability restrictions;

acquisition of important contributors;

self-preferencing;

tying;

discriminatory treatment;

restrictive terms of service;

conversion of an open resource into a closed commercial ecosystem.

A simplified structure is:

Open community → Platform becomes intermediary → Platform becomes gatekeeper → Platform controls access to the commons

The competition concern is strongest where users and contributors cannot realistically bypass the platform.

3. Commons-Based Production vs Traditional Production

Examples of CBPP resources include:

open-source code;

collaboratively produced knowledge;

open geographic data;

shared scientific resources.

4. Why Platforms Become Important

Large platforms can provide:

hosting;

discovery;

search;

distribution;

authentication;

payments;

advertising;

moderation;

reputation systems;

data storage;

developer tools;

APIs.

This can dramatically increase the reach of commons-based projects.

However, the same infrastructure can create dependency.

For example:

Open-source developers
↓
Platform repository
↓
Platform search/ranking
↓
Users and enterprises

The platform may become the primary gateway to the commons.

5. The Platform Capture Cycle

A common capture mechanism can be described as:

Stage 1 — Community creation

Contributors create a valuable resource.

Stage 2 — Platform adoption

The platform provides infrastructure.

Stage 3 — Network effects

More contributors attract more users.

Stage 4 — Dependency

Users and contributors become dependent on the platform.

Stage 5 — Gatekeeper position

The platform controls access, visibility, ranking or distribution.

Stage 6 — Monetisation

The platform begins extracting value from the ecosystem.

Stage 7 — Competitive exclusion

The platform may favour its own competing services or restrict rival access.

This is the central platform capture risk.

6. Competition-Law Importance

Platform capture can raise several competition-law issues.

Article 101 TFEU

Potentially relevant where platforms and participants coordinate through agreements involving:

exclusivity;

access restrictions;

licensing;

data sharing;

distribution restrictions.

Article 102 TFEU

Potentially relevant where a dominant platform uses its position to:

exclude competing services;

discriminate against rivals;

restrict interoperability;

impose unfair conditions;

tie complementary services;

self-preference its own products.

Merger control

Relevant where a platform acquires:

major open-source projects;

important developer communities;

complementary infrastructure;

repositories;

data resources.

Digital-market regulation

Modern EU digital regulation can also affect gatekeeper behaviour, although competition-law analysis and regulatory obligations should be kept conceptually distinct.

7. Important Distinction: Platform Capture Is Not Automatically Illegal

A platform providing infrastructure to an open community is not inherently anti-competitive.

For example, a platform may legitimately:

invest in hosting;

improve security;

provide developer tools;

moderate harmful content;

monetise premium services;

charge reasonable fees.

The competition issue arises where market power is used to undermine competitive access or eliminate alternatives.

Therefore:

Platform participation ≠ platform capture.

8. Main Platform Capture Risks

A. Access Control

The platform controls who can access the commons.

This may create dependency.

B. Ranking Control

The platform decides which projects appear first.

A platform could potentially favour:

Platform-owned project > independent community project

This resembles self-preferencing concerns.

C. Data Capture

The platform may accumulate:

contributor information;

usage data;

project data;

behavioural data;

performance data.

Data accumulation can reinforce its position.

D. Interoperability Restrictions

The platform may make it difficult to move:

projects;

users;

data;

identities;

reputations;

followers.

This can increase switching costs.

E. Ecosystem Lock-In

Once contributors build their reputation within a platform, leaving may become costly.

For example:

10 years of developer reputation + followers + project history

may not be portable to another platform.

F. Licensing Capture

A platform may alter licensing or contractual conditions in ways that increase its control over community-created resources.

The precise legal effect depends heavily on the applicable licence and contractual structure.

9. Case Law

Because “commons-based peer production” and “platform capture” are not standalone competition-law causes of action, the cases below provide established principles by analogy.

10. Case 1: Microsoft v Commission

Case: Microsoft Corp. v Commission, Case T-201/04

Background

The European Commission found competition concerns concerning Microsoft's refusal to provide interoperability information to competing work-group server operating systems.

Principle

The case addressed:

interoperability;

technical information;

market access;

dominance;

exclusionary effects.

Relevance to commons ecosystems

Open-source ecosystems frequently depend upon interoperability.

If a dominant platform controls an important technical interface and prevents rival systems from interoperating effectively, the platform can potentially reinforce its ecosystem position.

Lesson

Control over interoperability can become a mechanism for ecosystem foreclosure.

11. Case 2: Google Shopping

Case: Google and Alphabet v Commission, Case C-48/22 P

Background

The case concerned Google's treatment of comparison-shopping services within its general search results.

Principle

The Court examined the relationship between:

a dominant search platform;

ranking mechanisms;

adjacent markets;

competitive disadvantage to rivals.

Relevance

A commons ecosystem can depend heavily upon platform ranking.

For example:

Community project → platform search → users

If the platform favours its own competing service, independent community projects may become less visible.

This creates a potential distribution bottleneck.

Lesson

Control over discovery and ranking can become an important source of competitive power in platform ecosystems.

12. Case 3: Google Android

Case: Google and Alphabet v Commission, Case T-604/18

Background

The case involved Google's Android ecosystem and various contractual arrangements concerning:

application distribution;

search;

browsers;

device manufacturers.

Principle

The case illustrates how a dominant platform ecosystem can use contractual arrangements to influence adjacent markets.

Relevance to commons-based ecosystems

A platform may control:

operating infrastructure → distribution → users → applications

A similar structure can arise where an open community resource becomes dependent on a platform for distribution.

The platform may then have incentives to favour its own complementary services.

Lesson

Control over an ecosystem's gateway can affect competition in neighbouring markets.

13. Case 4: Bronner v Mediaprint

Case: Oscar Bronner GmbH & Co. KG v Mediaprint, Case C-7/97

Principle

The Court considered whether access to a dominant undertaking's newspaper home-delivery system should be compelled.

The Court applied a strict test concerning indispensability and alternatives.

Relevance to commons ecosystems

A platform may become the principal distribution infrastructure for a community-created resource.

But simply being important is not enough.

The question becomes:

Is the platform genuinely indispensable?

Are alternatives realistically available?

Would denial of access eliminate effective competition?

Lesson

Platform importance does not automatically create an obligation to provide access; the strict conditions of the refusal-to-deal/essential-facilities doctrine remain relevant.

14. Case 5: IMS Health

Cases: Joined Cases C-418/01 P and C-419/01 P, IMS Health v NDC Health

Background

The case concerned access to a pharmaceutical sales-data structure.

Principle

The Court developed strict conditions relevant to compulsory licensing/access involving an indispensable resource.

Relevance

A commons-based ecosystem may generate an extremely valuable:

dataset;

software architecture;

technical standard;

digital resource.

If a dominant platform controls the principal gateway to that resource, access questions may arise.

But the legal threshold for compulsory access is demanding.

Lesson

Control over a strategically important resource must be distinguished from legally established indispensability.

15. Case 6: Slovak Telekom

Cases: Joined Cases C-165/19 P and C-167/19 P

Principle

The case concerned exclusionary conduct involving access to telecommunications infrastructure.

The Court examined issues involving:

access;

pricing;

infrastructure;

downstream competitors;

foreclosure.

Relevance

This provides a useful analogy for platform-controlled commons.

A community may create the resource, but if a platform controls the infrastructure through which users access it, the platform can become a bottleneck.

Lesson

Control over infrastructure used by downstream competitors can create competition concerns where it is used to foreclose rivals.

16. Case 7: Apple v Pepper

Case: Apple Inc. v Pepper, 587 U.S. ___ (2019)

Principle

The U.S. Supreme Court considered the relationship between Apple, its App Store and consumers.

The case recognised the significance of Apple's role as an intermediary between app developers and consumers for standing purposes.

Relevance

It demonstrates the economic importance of platform intermediation.

In a commons ecosystem:

Contributor → platform → user

the platform may occupy a strategically important intermediary position.

Lesson

An intermediary can become economically significant even when it does not itself create all of the underlying products or resources.

17. Case 8: Epic Games v Apple

Case: Epic Games, Inc. v Apple Inc., U.S. District Court for the Northern District of California (2021)

Background

The litigation concerned Apple's App Store ecosystem and restrictions affecting app distribution and payment systems.

Relevance

The case illustrates conflicts involving:

platform governance;

distribution;

payment systems;

access;

commissions;

alternative channels.

These issues can arise in commons ecosystems where contributors depend upon a platform to reach users.

Lesson

Control over distribution channels can become a significant competitive issue when creators depend upon a platform for market access.

18. Case 9: Magill

Cases: Joined Cases C-241/91 P and C-242/91 P, RTE and ITP v Commission

Principle

The case concerned access to television programme information and the conditions under which refusal to license protected information could constitute abuse.

Relevance

Commons-based ecosystems often depend on information resources.

The case demonstrates that:

Information control + market power + exclusion of downstream products

can potentially generate competition-law concerns.

Lesson

Control over information can become economically significant when it prevents downstream competitors from creating products that consumers demand.

19. Case 10: Bronner and IMS Health Together

These cases should be remembered together because they illustrate an important limitation.

Suppose:

Community resource → platform → users

The fact that the platform is highly important does not automatically mean:

“The platform must provide unrestricted access.”

EU competition law has traditionally treated forced access cautiously.

The strongest refusal-to-deal cases involve demanding conditions concerning:

indispensability;

elimination of effective competition;

lack of alternatives;

technical/economic feasibility;

objective justification.

20. Platform Capture Through Self-Preferencing

One major risk is:

Platform controls the marketplace and competes within the marketplace.

Example:

Open-source projects → platform repository → platform's own developer tools

If the platform gives preferential:

ranking;

search placement;

recommendations;

API access;

visibility;

distribution

to its own products, independent projects may face competitive disadvantage.

This is closely related to the principles developed in the Google Shopping litigation.

21. Platform Capture Through Data

Commons ecosystems can generate enormous amounts of information.

For example:

Thousands of contributors → millions of interactions → platform collects metadata → platform develops competing service.

This creates a potential data-feedback loop:

More contributors

↓

More data

↓

Better platform

↓

More users

↓

More contributors

↓

More data

This can strengthen market power through network effects.

But again:

Data accumulation alone is not proof of an infringement.

The legal question is how the data advantage is acquired and used and whether the undertaking has market power.

22. Platform Capture Through Acquisition

A platform may acquire an important project or community.

Example:

Independent open-source project → acquisition by dominant platform.

Potential concerns may include:

elimination of future competition;

control over strategic technology;

access to developer communities;

control over standards;

reduction of interoperability;

integration with the platform's ecosystem.

Merger-control authorities can examine whether the acquisition substantially lessens competition or creates/strengthens dominance under the applicable merger-control regime.

23. Platform Capture Through Licensing

Open-source licensing creates a special legal environment.

A project may be available under:

permissive licences;

copyleft licences;

dual licensing;

community-specific arrangements.

A platform cannot necessarily convert every community-created resource into exclusive proprietary property merely by hosting it.

The legal position depends upon:

licence terms;

copyright ownership;

contributor agreements;

contractual arrangements;

applicable law.

Therefore:

Competition law and intellectual-property law must be analysed separately and then together where relevant.

24. Platform Capture and Switching Costs

A contributor may become dependent upon:

platform reputation;

followers;

issue history;

contribution records;

project statistics;

API integrations;

automated tools.

If these cannot easily move to another platform, switching becomes expensive.

Formula

Platform Identity + Reputation + Data + Network Effects = Switching Cost

High switching costs can strengthen platform dependency.

25. Platform Capture and Network Effects

Commons ecosystems often exhibit powerful network effects.

More contributors:

→ more content

→ more users

→ more visibility

→ more contributors.

Once one platform becomes the primary gateway, competing platforms may face a chicken-and-egg problem.

A new platform needs contributors to attract users.

But contributors need users before joining the new platform.

This can reinforce incumbent advantage.

26. Multi-Homing as a Protection Against Capture

Multi-homing means contributors or users participate on multiple platforms.

Example:

GitHub + GitLab + independent repository

Multi-homing can reduce platform dependency.

If contributors can easily move between platforms, the incumbent has less ability to impose restrictive conditions.

Therefore:

Low switching costs + multi-homing = reduced capture risk.

Conversely:

High switching costs + single-homing = increased capture risk.

27. Platform Governance and Competition

Platforms usually establish rules governing:

moderation;

access;

ranking;

monetisation;

APIs;

data;

licensing;

account suspension.

Governance rules become competition-relevant when a dominant platform can use them selectively against competing ecosystems.

For example:

Platform-owned project receives favourable treatment while independent competing projects face restrictive rules.

The critical question becomes whether the platform is using governance power as an instrument of competitive foreclosure.

28. Commons Governance vs Platform Governance

Commons governance

Usually emphasises:

participation;

openness;

community decision-making;

shared resources;

decentralisation.

Platform governance

Usually emphasises:

central administration;

terms of service;

technical control;

ranking;

moderation;

monetisation.

The tension is:

Community creates the value, but platform controls the gateway.

This is the central conceptual problem of platform capture.

29. Competitive Harms

Potential competitive harms include:

1. Foreclosure

Rival platforms or services may lose access to contributors/users.

2. Reduced innovation

Independent projects may have fewer incentives to develop.

3. Reduced interoperability

Users become trapped within one ecosystem.

4. Higher switching costs

Moving to another platform becomes expensive.

5. Self-preferencing

The platform favours its own competing services.

6. Data exploitation

Community-generated information strengthens the platform's competitive position.

7. Reduced diversity

Alternative governance models may disappear.

8. Reduced contestability

Potential entrants cannot achieve sufficient scale.

30. Potential Efficiency Benefits

Platform involvement can also create substantial benefits.

Platforms may provide:

reliable hosting;

security;

global distribution;

search;

moderation;

developer tools;

financial support;

infrastructure;

technical standards.

Thus:

Platform capture analysis must distinguish value-creating intermediation from exclusionary exploitation.

31. Legal Analysis Framework

When analysing a potential platform-capture problem, use the following sequence.

Step 1 — Identify the commons

What resource is being created?

software;

data;

knowledge;

content;

scientific information.

Step 2 — Identify the platform

What function does the platform perform?

hosting;

distribution;

discovery;

payment;

identity;

infrastructure.

Step 3 — Determine dependency

Can contributors and users realistically operate elsewhere?

Step 4 — Examine market power

Does the platform possess substantial market power?

Step 5 — Identify conduct

Is the platform:

self-preferencing?

tying?

restricting access?

discriminating?

blocking interoperability?

imposing exclusivity?

acquiring rivals?

Step 6 — Assess foreclosure

Are competing platforms or services being disadvantaged?

Step 7 — Examine efficiencies

Does the conduct have legitimate technological or economic justification?

Step 8 — Apply appropriate law

Potentially:

Article 101;

Article 102;

EU merger control;

intellectual-property law;

digital-market regulation.

32. Hypothetical Example

Imagine an open-source AI community creates a powerful machine-learning framework.

Thousands of developers contribute.

A platform begins hosting the framework.

Initially:

Community → open framework → many users

Later:

Community → Platform → framework → users

The platform then:

controls search visibility;

controls API access;

collects usage data;

launches a competing AI framework;

gives its own framework preferential ranking;

makes migration difficult.

The legal question is not simply:

“Did the platform use the open-source framework?”

Instead:

Has the platform's control over access, data, ranking and infrastructure created market power that is being used to disadvantage competing services?

That is the essence of the platform-capture analysis.

33. Key Case-Law Principles

34. Important Distinctions

Platform success ≠ platform capture

A platform may legitimately become successful by providing superior infrastructure.

Open-source resource ≠ competition-law immunity

Open-source projects can still participate in commercial markets.

Data advantage ≠ automatic dominance

Possessing large amounts of data does not automatically establish dominance.

Network effects ≠ unlawful exclusion

Network effects can arise naturally from superior products.

Switching costs ≠ infringement

Switching costs become competition-relevant depending upon their source and use.

Self-preferencing ≠ automatically unlawful

Its legal treatment depends on the applicable market, dominance, conduct and competitive effects.

Access refusal ≠ automatic abuse

The Bronner/IMS Health principles demonstrate the demanding conditions surrounding compulsory access.

35. Policy and Governance Safeguards

Potential safeguards against platform capture include:

1. Data portability

Allow contributors to move their data and project history.

2. Interoperability

Permit alternative services to communicate with the ecosystem where appropriate.

3. Open APIs

Reduce dependence on a single intermediary.

4. Transparent ranking

Increase visibility into important platform governance mechanisms.

5. Non-discrimination

Apply comparable access rules consistently.

6. Multi-homing

Encourage contributors and users to maintain alternatives.

7. Community governance

Give contributors meaningful participation in important ecosystem decisions.

8. Independent infrastructure

Avoid complete dependency on one platform.

9. Competition-law monitoring

Assess whether platform practices create foreclosure.

36. Conclusion

Commons-based peer production creates value through decentralised collaboration, while platforms can provide infrastructure that dramatically increases the reach and usefulness of that commons.

The central competition concern appears when:

Community-created resource + platform dependency + network effects + switching costs + platform control

produces a situation in which the intermediary can act as a gatekeeper and potentially use that position to disadvantage competing services.

The most important legal principles come from cases such as Microsoft, Google Shopping, Google Android, Bronner, IMS Health and Slovak Telekom.

The key distinction is:

The existence of a powerful platform is not itself unlawful. The competition-law question is whether substantial market power is being used through exclusionary, discriminatory, restrictive or otherwise anti-competitive conduct.

Ultra-Short Revision Formula

CBPP = Decentralised Contributors + Shared Resource + Peer Production

Platform Capture = Commons + Intermediary Control + Dependency

Capture Risk = Network Effects + Switching Costs + Data + Gatekeeping

Competition Concern = Market Power + Exclusionary Conduct + Foreclosure

Keywords

Commons-based peer production — CBPP — Open source — Digital commons — Platform capture — Platform governance — Gatekeeper — Network effects — Switching costs — Multi-homing — Data capture — Self-preferencing — Interoperability — Essential facilities — Refusal to deal — Ecosystem foreclosure — Community governance — Article 101 — Article 102 — Digital platforms — Open-source ecosystems.