category-creation-positioning

Commons Boundary Setting

Also known as:

Participating in the ongoing negotiation of who belongs to a Commons, who stewards it, and what lies outside its scope — the boundary decisions that define the Commons' identity and viability.

Participating in the ongoing negotiation of who belongs to a Commons, who stewards it, and what lies outside its scope — the boundary decisions that define the Commons’ identity and viability.

[!NOTE] Confidence Rating: ★★★ (Established) This pattern draws on Ostrom / Commons Theory.

Section 1: Context

A Commons emerges when a group recognises shared resources or challenges and creates structures to steward them together. But a Commons without clear boundaries is not yet a Commons—it is an aspiration without operating logic. In organisations, product teams inherit codebases and user bases they didn’t author. In movements, activists inherit networks and principles they didn’t establish. In public service, stewards inherit jurisdictions and stakeholder groups shaped by history. In each case, the system is alive but undefined. Its members feel the pressure: Who gets to decide what this Commons is? Who is in; who is out? What belongs to us, and what belongs elsewhere? Without explicit boundary negotiation, Commons fragment into factions, stewards burn out enforcing invisible rules, and members leave because they never knew what they were joining. Boundaries become the living tissue that separates the Commons from its setting—the ecosystem around it.

Section 2: Problem

The core conflict is Commons vs. Setting.

A Commons needs clear edges to function: rules that clarify membership, decision rights that specify who stewards which resources, and scope that names what the Commons governs and what it does not. But boundaries are also the most contentious act of a Commons. Setting them means saying no to some people, some uses, some values. Every boundary is a loss for someone.

The tension sharpens under pressure. Early in a Commons’ life, boundaries feel flexible—”we’ll figure it out as we grow.” But as the Commons gains resources, members, or stakes, the lack of clear boundaries breeds conflict. Is the Commons open to all comers, or only those who share its origin story? If a new use case emerges—say, a product Commons suddenly asked to support a different market segment—does that belong inside or outside? Who decides? Without this negotiation, boundary-setting becomes an accident: the boundary is whatever emerges from the loudest voices, the longest tenure, or the last person who cared enough to enforce it. Members lose trust because the rules are invisible and changeable. Stewards collapse because they enforce rules no one agreed to. The Commons either rigidifies (boundaries become dogma, vitality drains) or dissolves (boundaries evaporate, the Commons becomes indistinguishable from its setting).

Section 3: Solution

Therefore, create and renew a living boundary practice: convene the stakeholders who steward and inhabit the Commons, name the tensions in who belongs and what lies outside, make explicit choices about membership and scope, document them as provisional agreements, and return to this negotiation on a regular cycle—quarterly, annually, or when new forces arrive.

This pattern treats boundaries as not fixed but actively maintained. Like the skin of an organism, boundaries must be both permeable and protective. They keep the system coherent while allowing necessary exchange with the setting.

Ostrom’s work on commons governance found that the longest-lived Commons shared one trait: they had clear, locally-crafted rules about who could access resources and who could modify the Commons itself. These rules were not imposed from outside; they emerged from negotiation among the people who lived with their consequences. And crucially, these rules were revisited and revised. Communities didn’t set boundaries once and assume they held. They gathered regularly to update them in light of new pressures, new members, and new learning.

Commons Boundary Setting operationalizes this. The practice names who participates in boundary decisions (typically stewards, long-term members, and representatives of new or marginal voices). It uses explicit tension-mapping to surface what each stakeholder group needs from membership and scope. It creates a decision protocol—not a majority vote, but a structured conversation that surfaces real conflicts and looks for agreements that hold across disagreement. Most vitally, it schedules revisitation. A boundary is not a decision made once; it is a renewable practice. This cycle prevents boundaries from calcifying into dogma or evaporating into invisibility.

Section 4: Implementation

Step 1: Name the stakeholder architecture. Before you can set a boundary, you must know who has a stake in where it falls. Map four groups: (a) founding/core stewards, (b) active members (people who contribute regularly), (c) peripheral members (people who benefit but contribute rarely), (d) would-be members or affected communities outside the Commons. Each group has different boundary needs. Core stewards often want tighter boundaries to preserve the Commons’ original intent. Peripheral members often want looser boundaries to reduce friction. Would-be members want in; affected outsiders may want the Commons to stay out of their domain. This asymmetry is the real terrain.

In organizations: If you are stewarding a shared engineering platform, map platform maintainers (core), product teams using the platform (active), legacy teams evaluating adoption (peripheral), and teams whose needs the platform explicitly doesn’t serve (outside). This prevents the conversation from defaulting to “the maintainers decide.”

Step 2: Surface boundary tensions. Hold a working session with representatives from each group. Use this framing: “The boundary of our Commons determines who can contribute decisions, who shares access to resources, what kinds of work we take on, what we deliberately exclude.” Ask each group:

  • Who do you think should be inside the Commons? Who should definitely stay outside?
  • What would it mean for you if the boundary shifted more open? More closed?
  • Are there groups we’re not seeing—people or communities affected by where we draw the line?

Document tensions without resolving them yet. The goal is honesty, not consensus.

In government: If you are stewarding a public service Commons (say, an open data platform), convene civil servants, civil society organisations, private sector users, and underserved communities. Ask: “Who gets to contribute to governance of this data? Who has veto power? What data stays inside public commons, and what belongs in private or specialist domains?” Tensions will emerge between transparency advocates (want maximum openness) and privacy protectors (want tight boundaries). Name both.

Step 3: Establish a boundary protocol. Design a decision method that works for your Commons’ culture. This might be:

  • Consent-based: Boundaries hold if no one has a principled objection (not just a preference).
  • Supermajority + steward veto: 75% agreement is needed, but founding stewards retain veto on scope.
  • Nested circles: Core stewards set internal boundaries; all members vote on external boundaries.

The protocol should specify: Who has voice? Who has decision rights? What counts as sufficient agreement? How do we resolve deadlock?

In activist contexts: Many movements use rotating facilitation and consensus-based boundary decisions. One structure: proposals about membership or scope are made by anyone; discussed in small groups; refined; brought to a full assembly; held with a 3-day cool-off period before final adoption. This slows decisions but strengthens legitimacy.

Step 4: Document boundaries as provisional. Write down your boundaries. Be specific:

  • Membership: Who can contribute to decisions? (e.g., “Anyone who has contributed code in the past 6 months, plus founders, plus two representatives elected annually from peripheral users.”)
  • Scope: What does this Commons govern? (e.g., “We steward the shared codebase, the release schedule, and the developer experience. We do not govern how individual products use the platform—that is their domain.”)
  • Exclusions: What explicitly lies outside? (e.g., “We do not make decisions about pricing or commercial terms. That stays with the product leadership.”)

Publish these. Let them sit for 30 days. Invite feedback. This is not final truth; it is a working hypothesis.

In tech product Commons: A mobile app platform might write: “Membership in governance: active SDK maintainers + one representative per platform partner with >100k users. Scope: SDK features, security standards, release cadence. Outside: individual app features, user acquisition strategies, data collection policies.” This clarity allows platform partners to know where they have voice and where they don’t.

Step 5: Schedule boundary revisitation. Set a recurring cycle—quarterly for young, fast-moving Commons; annually for mature ones. Trigger points for an unscheduled boundary review:

  • A new major stakeholder group emerges or requests membership.
  • A significant tension surfaces about what belongs inside vs. outside.
  • The Commons grows or shrinks by >30% in members or resources.
  • A steward or core member departs, forcing succession questions.

At each revisit, use the same protocol: surface tensions, make explicit choices, document, republish.

Section 5: Consequences

What flourishes:

This pattern generates trust through visibility. When members know the boundary rules and see them applied consistently, they stop wasting energy on invisible politics. Newcomers can assess fit quickly. Stewards stop enforcing rules from thin air. The Commons gains the capacity to sustain multiple voices without fracturing—people can disagree on strategy while sharing confidence in the governance structure.

Boundaries also create productive autonomy. When a Commons is clear about what it does not govern, the people and teams outside that boundary gain freedom. A product team knows the platform Commons doesn’t make decisions about their user experience, so they stop waiting for platform approval. A movement member knows the Commons doesn’t govern personal tactics, so they act without seeking consensus. Clarity is liberating.

What risks emerge:

Boundaries can rigidify. If the negotiation becomes routine but not genuine—if people show up to meetings but the core stewards’ choices are never actually revisited—the boundary practice becomes theatre. Members sense this and withdraw. Vitality drains even though the formal practice persists.

A second risk is boundary brittleness at the edges. Gray zones—ambiguous cases that don’t clearly fall inside or outside—breed endless micro-conflicts. A Commons Boundary Setting practice can clarify the major lines but will always leave some edge cases fuzzy. Practitioners must accept this and build a lightweight dispute-resolution channel for edge cases rather than pretending the boundary is perfect.

Finally, note that resilience scores for this pattern are moderate (3.0). Boundaries alone don’t create adaptive capacity; they create order. A Commons with tight, clear boundaries can be brittle if the setting changes fast. Watch for signs that the boundary practice is filtering out important new signals—that the Commons is tuning out voices that belong in the conversation. The boundary is the immune system; when it becomes overactive, it kills the host.

Section 6: Known Uses

Linux Kernel Commons, 1990s–present: Linus Torvalds and the kernel community faced an early crisis around 1996: who gets to commit code? who decides what features the kernel includes? Early lack of clear boundaries created chaos—Torvalds made decisions by decree, alienating contributors who felt unheard. The community negotiated explicit boundaries: subsystem maintainers would govern their own domains (filesystems, networking, etc.), but Linus retained final veto on the main trunk. This created a nested boundary structure that has held for 25+ years. The community revisits this structure roughly annually, adding new maintainer roles and clarifying what kinds of code stay inside the kernel vs. moving to userland. The clarity allowed the kernel to scale to thousands of contributors.

Platform Cooperative Movement, 2010s–present: When ride-sharing and delivery cooperatives began, they faced a boundary question Ostrom didn’t address: what happens when workers want to co-own a digital platform? Stocksy (a photographer-owned stock photo platform), Equal Care Cooperative (a home care co-op), and Savvy Cooperative (a personal assistant co-op) each had to negotiate: Who is a member? (Just workers? Or users and workers together?) What decisions do members govern? (Pricing? Algorithm design? Feature roadmaps?) They learned quickly that loose boundary statements (“everyone has a voice”) led to gridlock. Successful cooperatives like Stocksy developed explicit protocols: workers vote on price, governance structure, and revenue share; users vote on feature requests and community standards; professional board members and paid staff have specific decision rights in their domains. Stocksy revisits these boundaries annually in member assemblies. This clarity allowed them to scale to 600k+ images while remaining member-owned.

Open Source Project Stewardship, varied: Apache Software Foundation and Rust Foundation both operationalized Boundary Setting as a mature practice. Apache established “Incubator” status for projects entering the Foundation—a 6-month period where new projects must clarify membership, governance, and scope before full inclusion. This prevents the confusion of projects thinking they’ve joined Apache but never agreeing what Apache membership means. The Rust Foundation went further: they explicitly named what lies outside the Foundation’s governance (language design decisions stay with the core team; trademark licensing is Foundation-only). These boundaries are revisited every 18 months. The clarity reduced political friction that plagued earlier open source projects.

Section 7: Cognitive Era

In an age of AI-assisted coordination and real-time distributed decision-making, Commons Boundary Setting faces new pressures and gains new leverage.

The pressure: AI systems now generate insights about Commons membership and value flows in real-time. Machine learning can detect when a contributor’s behavior has shifted, when a peripheral member might become core, or when the Commons’ scope has de facto expanded beyond its stated boundary. This creates temptation to let algorithms set boundaries—to optimize membership dynamically based on contribution metrics or engagement signals. The risk is profound: boundaries become invisible and changeable, eroding the trust that makes Boundary Setting work.

The leverage: Conversely, Commons can use AI-assisted transparency to make boundary negotiations more rigorous. An open data Commons can analyze what questions its stakeholders actually ask and use this data to inform scope decisions. A product Commons can track where integration requests come from and use this signal to revisit who-should-be-inside questions. AI can surface hidden stakeholders—communities affected by boundaries who weren’t in the original conversation. This is not AI deciding boundaries; it is AI making the boundary conversation more informed and honest.

For tech product Commons specifically: Product Commons stewarding AI systems face an acute boundary question: as AI systems make decisions affecting users, who belongs in the governance of those decisions? Early tech commons (GitHub, npm) could defer governance to “maintainers who care.” But Commons stewarding AI-driven products must answer: Do affected users have boundary voice? Do the people whose data trained the system? Do regulators? Clear boundaries here are non-negotiable. The boundary practice must explicitly map who can influence decisions about AI behavior and who cannot, and revisit this frequently as regulation and user expectations shift.

Section 8: Vitality

Signs of life:

  1. Members can articulate the boundary. When you ask a random member “Who gets to make decisions in this Commons?” and “What does this Commons not govern?”, they give you consistent, specific answers—not vague ones. This means the boundary is real, not aspirational.

  2. New members are explicitly onboarded to the boundary. They receive a document, have a conversation, or complete a small ritual where they learn the rules before they have power. You see newcomers showing up with accurate mental models of what they can and cannot do.

  3. The boundary provokes real negotiation, not rubber-stamping. When the community gathers to revisit boundaries, people argue. They propose changes. The conversation is alive and contested—not procedural theatre. Stewards find themselves defending choices, not announcing decrees.

  4. Edge cases are handled with a clear escalation path, not political warfare. When someone questions whether their work belongs inside or outside the Commons, the community has a lightweight protocol (ask a specific role, get an answer, revisit if needed) rather than an all-hands argument.

Signs of decay:

  1. Boundary talk evaporates. You notice the Commons used to have explicit boundary conversations, but they’ve stopped. People still invoke the boundary (“that’s outside our scope”), but no one has revisited it in years. The boundary has become dogma, not a living agreement.

  2. New members keep breaking the boundary rules. They propose features that clearly fall outside scope, or try to participate in decisions that are members-only. When you tell them the rule, they’re surprised—no one explained it to them, or they didn’t believe it was real.

  3. Stewards privately negotiate boundaries differently than they publicly state them. Behind closed doors, certain people get exceptions; publicly, the boundary is rigid. Trust erodes because the visible rule is not the actual rule.

  4. Boundary questions don’t get resolved; they get forgotten. Someone asks, “Should we include this new user group?” The conversation stalls. Eventually, someone else acts unilaterally, creating resentment. The boundary drifts rather than shifts intentionally.

When to replant:

If you see signs of decay, the boundary practice has become hollow. The remedy is not to write a better boundary document—it is to return to the negotiation itself. Convene the stakeholders again. Use the same protocol you used to create the original boundary. Make it a genuine conversation, not a confirmation ritual. If stewards are privately negotiating boundaries, make those negotiations public and formal. If new members consistently break the boundary, revisit whether the boundary actually reflects the Commons’ real culture or whether it is aspirational—and if it is aspirational, decide: revise the boundary to match reality, or invest in culture-building to match the boundary.