DP20 – Community Ownership

1. Purpose of This Draft

This draft articulates Desirable Property 20 (DP20) as the condition under which communities meaningfully own the digital environments, surplus, and governance artifacts they co-create, not as marketing language about “community,” but as enforceable rights and responsibilities: stake, voice, upside, and continuity that persist across tools and seasons.

DP20 completes a loop with DP18 (feedback and reputation), DP19 (presence and engagement), and DP12 (community governance of AI): participation must be able to mature into ownership, otherwise “community” remains a rented audience for platforms.

DP20 connects to DP4 (data commons and collective data rights), DP6 (fair distribution of commercial surplus), DP9 (incentives that return value to contributors), DP3 (adaptive governance at scale), DP17 (financial sustainability), and DP1–DP2 (accountability and agency for collective actors).

If DP20 is weak, predictable failures follow: extractive growth on volunteer labor, token claims without decision rights, capture of governance by insiders, inability to fork when values diverge, and surplus flowing outward while risks stay local.

DP20 does not mandate a single cooperative legal form or chain. It defines minimum legitimacy conditions for what “ownership” may claim in the meta-layer.

2. Problem Statement

In today’s web, “community” is often a label applied to users whose labor, attention, and data build value they cannot capture, audit, or exit with. Governance surfaces are optional; economic upside is asymmetric; and forking social reality is impractical.

In practice, this produces recurring failures:

• moderators and maintainers burn out while platform valuation rises
• creators depend on distribution they do not control
• tokens grant speculation liquidity without durable rights
• data generated collectively is sold without collective consent (DP4)
• communities cannot carry norms, memory, or economic terms across apps (DP7)

These failures are structural: ownership is confused with usage; participation is confused with consent to extraction.

DP20 reframes ownership as operational: rights you can see, exercise, and defend, including pathways to fork, exit, and recapture surplus when legitimacy breaks.

3. Threats and Failure Modes

3.1 Ownership theater

Marketing claims “community-owned” while decisions and keys remain centralized.

Example: A DAO where a multisig admin can override any vote without published criteria.

Why this matters: DP20 requires honest mapping between claims and controls.

3.2 Token liquidity without duties or rights

Tokens trade while governance is inactive or non-binding.

Example: Voter apathy plus whale dominance makes governance a periodic headline, not a constraint on operators.

Why this matters: Ownership instruments must bind to decisions and surplus, or be renamed.

3.3 Commons maintenance without reciprocity

Value is extracted from a space while moderation, safety, and infrastructure remain underfunded.

Example: A viral forum hosts commerce ads but does not fund anti-abuse capacity.

Why this matters: Connects DP6 reciprocity and DP17 sustainability.

3.4 Capture by concentrated stakeholders

Early contributors or large holders lock rules that favor continuation of privilege.

Example: Fee switches require supermajorities that insiders can block indefinitely.

Why this matters: DP3 adaptive governance and DP12 dialectic must resist ossified capture.

3.5 Forklessness

When values diverge, participants cannot exit with continuity of identity, memory, or economic position.

Example: A community schism loses all history because export is blocked and namespaces are not portable (DP5, DP7).

Why this matters: Forking is a safety valve for legitimacy.

3.6 Collective data sale without governance

Aggregated or derived data monetizes communities without authorization pathways.

Why this matters: DP4 sovereignty requires collective decision surfaces, not only individual toggles.

3.7 Illegible membership and shadow elites

Informal power structures make decisions without published accountability.

Example: Moderators coordinate bans off-platform without records or appeals.

Why this matters: DP1 contestability and DP12 governance memory must extend to collective actors.

3.8 Philanthropic dependency

Communities rely on unsustainable grants with no path to owned revenue or shared surplus.

Example: A civic space runs on a yearly sponsor who can pull funding overnight.

Why this matters: DP17 sustainability and DP6 commerce reciprocity must appear in ownership design.

3.9 Legal hostility to collective action

Cooperative forms face banking, tax, and liability friction.

Why this matters: DP20 acknowledges law as a design constraint while still demanding honest digital rights bundles.

4. Core Principle

Community ownership in the meta-layer means participants and communities hold defensible rights to govern, benefit from, and responsibly steward the environments and surplus they co-create, including credible paths to fork, exit, and recapture value, with transparency, accountability, and continuity of memory.

Ownership is not a vibe. It is power with responsibility, visible to members and bounded by human-rights baselines and law.

Example: A community charter defines decision rights, surplus split, audit rights, and fork procedures; tools entering the zone must acknowledge the charter’s machine-readable profile.

What this feels like: You are not the community in a slogan. You are a member with levers.

Without this: Participation is harvested; dignity is not.

5. Primary Mechanisms and Structural Conditions

5.0 Ownership Layer: Execution, Proof, and Exit

Community ownership requires more than charters and intent. It requires the ability to express, verify, exercise, and, when necessary, exit ownership as part of an operational system.

In many systems, “ownership” fails because it is not bound to decision rights, not provable in practice, or not portable across tools. Rights exist on paper while control remains elsewhere.

DP20 therefore requires a shared ownership layer composed of primitives that make ownership executable rather than symbolic.

Ownership objects

Ownership must be represented as structured, machine-readable objects that bind rights to actors and contexts.

An ownership object includes:

• scope: what environment, assets, or processes are owned
• rights: governance, economic, and data rights
• duties: stewardship and maintenance obligations
• transfer conditions: how ownership can change hands

This binds ownership directly to governance (DP3, DP12).

Ownership receipts

All ownership-relevant actions produce verifiable records.

An ownership receipt includes:

• who holds or exercised a right
• what action was taken (vote, allocation, fork, transfer)
• when it occurred
• what assets or policies were affected

These receipts make ownership auditable and connect to DP15 (provenance).

Surplus and flow proofs

Economic flows must be traceable to ownership claims.

Members must be able to see:

• how value enters the system
• how it is allocated
• how it maps to rights and contributions

Without flow proofs, ownership cannot capture upside in a defensible way (DP6, DP17).

Fork and exit primitives

Ownership must include executable pathways to exit or fork with continuity.

This includes:

• export of data and governance artifacts (DP4, DP7)
• migration of identifiers where honest (DP5)
• continuity of membership and contribution records

Forking is not a failure. It is a safety valve for legitimacy.

Membership and credential objects

Membership and contribution must be represented as portable, verifiable artifacts.

This enables:

• recognition across tools
• resistance to platform lock-in
• continuity of identity and stake

Ownership–governance binding

Ownership must map to decision rights in a visible way.

Participants must be able to see:

• who can decide what
• how ownership affects voting or delegation
• where overrides or special powers exist

Governance that cannot be owned is advisory. Ownership that cannot govern is symbolic.

Ownership memory

Ownership history must persist over time.

This includes:

• prior allocations and changes
• disputes and resolutions
• forks and mergers

Without memory, ownership becomes contestable without evidence.

These primitives do not replace the mechanisms below. They make them enforceable, portable, and auditable across contexts.

5.1 Charter and rights bundle

A written and machine-readable articulation of membership, decision rights, economic rights, data rights, fork rights, and sunset conditions.

This MUST include:
- explicit mapping between roles and powers
- conditions under which rights can change
- linkage to governance execution (DP3, DP12)

Verification:
- participants can inspect current and prior versions
- tools enforce charter constraints at interaction level

Failure modes:
- charter drift (rules change without visibility)
- unenforced rights (charter exists but does not constrain behavior)

5.2 Transparent surplus accounting

Revenue, fees, grants, and in-kind support are visible to members at useful granularity (DP6, DP17).

This MUST include:
- inflow sources and categories
- allocation breakdowns tied to functions
- linkage to ownership claims

Verification:
- members can trace value from source → allocation → outcome

Failure modes:
- surplus opacity (value cannot be traced)
- extraction masking (flows hidden behind aggregation)

5.3 Participatory budgeting and parameter control

Communities set budgets for safety, education (DP10), and incentives (DP9) through governed processes (DP12).

This MUST include:
- binding decision pathways
- budget execution tracking
- feedback loops into future allocations

Failure modes:
- advisory budgeting (decisions ignored)
- capture of allocation power

5.4 Credible exit and fork

Procedures to export collective artifacts, migrate identifiers where honest (DP5), and continue governance under divergent values without coercion.

This MUST include:
- executable export mechanisms
- continuity of identity, data, and governance artifacts

Failure modes:
- exit suppression
- fork degradation (loss of continuity)

5.5 Stewardship obligations

Ownership includes maintenance duties: moderation, security, inclusion, and accessibility commitments with accountability (DP1, DP15).

This MUST include:
- defined duties
- enforcement mechanisms
- reporting on fulfillment

Failure modes:
- duty abandonment
- free-rider extraction

5.6 Anti-capture controls

Rotation, conflict-of-interest rules, minority protections, and emergency pause pathways.

This MUST include:
- detection of concentration
- intervention pathways

Failure modes:
- ownership capture
- governance lock-in

5.7 Collective data governance

Shared corpuses require collective consent mechanisms and audit of downstream use (DP4).

This MUST include:
- consent pathways
- audit logs of use

Failure modes:
- data extraction without consent
- loss of collective control

5.8 Interoperable ownership artifacts

Membership and contribution receipts interoperate across tools (DP7).

This MUST include:
- portable formats
- degradation signaling across systems

Failure modes:
- lock-in via incompatibility

5.9 Succession and dissolution

Charters define succession for stewards and fair dissolution procedures.

This MUST include:
- transfer conditions
- fair distribution of residual value

Failure modes:
- power vacuum
- unfair dissolution

5.10 Intersectional inclusion in ownership

Governance design actively counters exclusion patterns through facilitation norms, translation, and accessible participation.

This MUST include:
- measurable inclusion practices
- correction mechanisms

Failure modes:
- systemic exclusion
- ownership concentration through bias

6. Governance, Accountability, and Agency Surfaces

DP20 requires that ownership is not only visible but defensible and enforceable.

Participants MUST be able to:
- verify ownership rights and mappings
- challenge illegitimate control or misallocation
- trigger governance review or dispute processes
- exercise exit and fork pathways without coercion

Communities MUST be able to:
- revoke or reassign ownership under defined conditions
- enforce stewardship obligations
- audit ownership actions and outcomes

Enforcement pathways include:
- rollback or invalidation of illegitimate actions
- governance-triggered reallocation of rights or surplus
- fork as a last-resort enforcement mechanism

Failure modes:
- non-actionable ownership
- illegitimate control persistence
- ownership without recourse

7. Incentives and Power Analysis

Ownership fails when incentives diverge from rights.

Key dynamics:

• extraction loops: value flows outward despite community contribution
• token manipulation: governance power decouples from responsibility
• dependency capture: infrastructure or distribution creates hidden control
• soft capture: influence accumulates without formal ownership

Adversarial patterns:

• governance capture through capital or coordination
• speculative ownership without stewardship
• platform rent extraction

Alignment requirements:

• ownership rights must correlate with value capture
• incentives must reward stewardship, not exploitation
• systems must detect divergence between formal ownership and real control

Failure modes:
- symbolic ownership
- incentive inversion
- ownership erosion over time

8. Community Signals Informing DP20

Across platforms and communities, recurring signals point to a shared breakdown between participation and ownership:

• maintainers and moderators demand compensation and decision power proportional to their labor
• skepticism toward “community-owned” claims following repeated governance failures and token collapses
• desire for portable community memory, identity, and governance tools
• frustration with value extraction from spaces built through collective effort
• growing interest in local, cooperative, and community-controlled digital environments

These signals are not isolated. They indicate structural gaps in how ownership is defined, enforced, and sustained.

DP20 treats these signals as design requirements, not feedback to be addressed after failure.

9. Non-Goals and Explicit Boundaries

DP20 does not:

• require all systems to be collectively owned
• eliminate private enterprise or hybrid ownership models
• guarantee equal distribution of value or influence
• remove the need for legal structures and compliance

DP20 defines the conditions under which ownership claims are legitimate and enforceable. It does not prescribe a single model.

10. Minimum Alignment (Non-Normative)

Minimum alignment defines the threshold where ownership is real, enforceable, and not misleading.

A DP20-aligned system MUST:

• bind ownership to executable governance and economic rights
• provide verifiable ownership records and history (DP15)
• ensure visibility into value flows and surplus allocation (DP17)
• enable credible exit and fork with continuity (DP4, DP7)
• maintain enforceable stewardship obligations

Failure modes to avoid:

• ownership theater (claims without control)
• fork suppression (no exit pathway)
• surplus extraction without rights
• historical erasure of ownership changes

Systems that omit execution, auditability, or exit MUST NOT be considered aligned.

11. Open Questions and Future Work

Key open questions include:

• how to design ownership models that function across jurisdictions
• how to balance tokenized and non-tokenized ownership structures
• how to maintain privacy while supporting interoperable ownership credentials (DP4)
• how to protect minority voices without blocking collective action
• how to measure contribution across visible and invisible labor (care, moderation, coordination)
• how to handle liability for collective decisions across legal systems
• how AI agents participate in ownership structures, if at all (DP11–DP13)

These questions reflect the boundary between social legitimacy and technical implementation.

12. Relationship to Other Desirable Properties

DP20 anchors ownership within the broader meta-layer system.

• DP3 defines how governance evolves under ownership
• DP4 constrains how collectively generated data can be used
• DP5–DP7 enable portability of identity, assets, and ownership artifacts
• DP6 and DP9 determine how value flows and incentives interact with ownership
• DP12 ensures ownership-linked governance can execute in practice
• DP15 ensures ownership claims and actions are provable
• DP17 ensures ownership structures can sustain themselves financially
• DP18–DP19 provide the participation and reputation inputs that mature into ownership

DP20 binds these properties into a coherent model of collective power.

13. Foresight and Failure Design

DP20 assumes ownership systems will be tested by capture attempts, economic pressure, and governance failure.

Common failure paths include:

• concentration of ownership among early or privileged actors
• erosion of rights through informal overrides or hidden control layers
• suppression of exit or fork pathways to preserve centralized power
• divergence between formal ownership and actual value capture

DP20 requires designing safeguards in advance, including:

• transparent allocation and reallocation mechanisms
• enforceable limits on concentrated control
• clear and executable fork and exit procedures
• public postmortems linking failures to structural changes

Failure is expected. Illegible failure is not.

14. Path Toward ML-RFC

Advancing DP20 toward ML-RFC requires:

• standardizing ownership object and receipt formats
• developing reference implementations of community-owned systems with open accounting
• aligning ownership models with interoperability and identity standards
• testing fork and exit mechanisms in real communities
• integrating legal and cooperative expertise into design processes

Progress should be demonstrated through functioning systems, not only conceptual agreement.

15. Closing Orientation

DP20 is where the meta-layer turns participation into power.

It rejects the model where communities create value but do not control it.

When ownership is real, communities can govern, sustain, and evolve the systems they depend on.

When it is not, “community” remains a narrative layered over extraction.

Ownership is the difference between presence and permanence, between contribution and control.

DP20 is where the meta-layer stops confusing audience with citizenship.

Ownership is the difference between a group that is used and a group that endures, with memory, upside, and responsibility held together.

When DP20 is strong, people can build commons that last because the commons can belong to those who care for them.