📖 Source→⚡ Observation·Where the pattern works/Where the pattern breaks·Interpretation ≠ Conclusion

Cooperation

Cooperation

⏱ 1 minSEC

This section right now is pretty spare, insofar as most of the case studies have been moved elsewhere.

Contents

Next steps

What can we learn from reviewer comments that would improve things for our next submission(s)? :paper:

⚡ Unpeeragogy · Friction · Observation

Cooperation

⏱ 4 minaudit-v2cooperationconflictgovernance

The Assumption

The Peeragogy Handbook treats cooperation as a central component of peer learning, supported by shared goals, participation, and collective knowledge building. Cooperation is the natural expression of a well-functioning peer group — the condition you build toward through shared intention and mutual support.

Operational Reality

Cooperation becomes visible when disagreement surfaces. Not because the group was not cooperating before — but because harmony hides the mechanisms that hold the group together. When everyone agrees, you cannot tell if the group is cooperating or just mirroring each other. When disagreement emerges, you see what the group is made of: does it find a way to continue acting together, or does it fragment?

Building the container before the conflict arrives increases a group’s capacity to move through disagreement without fragmenting. GitLab had boundaries ready before tension arrived — a written pact defining where corporate strategy ends and community autonomy begins. Wikipedia and WebAssembly built their processes reactively, after failure was visible. Mondragon had governance and still lost Fagor — governance protects networks more reliably than it protects individual units. The difference is not about the quality of the people or the presence of structure. It is about whether the structure matches the scale and type of conflict the group actually faces.

Perturbatore: “What if we are confusing cooperation with harmony? A group can agree on everything and produce nothing together. It can also keep working while its members strongly disagree. Maybe the point is not the absence of conflict — but the capacity to move through it without losing the ability to act.”

Empirical Evidence

Resilience Cases (Confirming):

  • GitLab Stewardship Handbook — Explicit documentation of governance boundaries between corporate sponsor and community reduces friction in open-core projects. GitLab Inc and the open-core community signed boundaries before conflict arrived; when tension came, the structure channeled it without destroying the group’s ability to produce.

Fracture Cases (Complicating):

  • Mondragon / Fagor Electrodomesticos Collapse — Fagor, the founding cooperative of the Mondragon group, went bankrupt in 2013 and was liquidated. The wider network survived but the most iconic cooperative did not — explicit governance structures can protect a network while failing the specific unit.
  • WebAssembly Community Group — The W3C Community Group charter describes a structured process: 7-day objection window, multi-day Call for Consensus, formal Committer vote as fallback. Disagreements over features took years to resolve — the process existed and functioned, but structured peer consensus may not keep up with technical velocity.
  • Wikipedia Arbitration Committee — Informal cooperation failed systematically in certain types of editorial disputes. Wikipedia created a formal judicial body to handle what peer consensus could not — informal cooperation is insufficient for high-stakes conflict at scale.

Operational Heuristics

Positive Boundary: Apply cooperation patterns when governance boundaries are documented explicitly before conflict arrives — GitLab demonstrates that pre-built containers channel tension without destroying productive capacity.

Negative Boundary: Do not assume cooperation survives structural mismatches between governance design and conflict type — Mondragon shows that governance can protect a network while failing individual units; the container must match the scale and type of conflict the group actually faces.

Epistemic Synthesis

Building the container before conflict arrives increases capacity to move through disagreement. But the Mondragon case warns that the container can fail even when it exists — governance protects networks more reliably than it protects individual units. The open question: whether small peer groups benefit from explicit governance differently from large ones — and whether governance designed for cooperation can survive the moment cooperation breaks down.

Perturbatore: “What if we are confusing cooperation with harmony? A group can agree on everything and produce nothing together. It can also keep working while its members strongly disagree. Maybe the point is not the absence of conflict — but the capacity to move through it without losing the ability to act.”

Harmony is not a sign of cooperation. It is a sign that nobody has asked the hard question yet.

Evidence Status

Status Count
Confirmed cases 1
Cases under study 0
Unverified cases 0
Ambiguous cases 0

Traceability

Run: audit-v2 · Delta: 1.6 → 1.5533 (±0.0467) · Diversity D: 2

References

💬 Field Report: Cooperation

Every pattern in the Handbook has been tested in the real world — and the real world usually has something to say about it. If you tried something similar, or saw it fail differently, share the story here.

Write in your native language — the browser will translate. Lowering the entry barrier is more important than choosing the "right" language. GitHub translates threads automatically so everyone can follow along.
Read how evidence is collected →

What happens after I share my story?

1. Your post appears in GitHub Discussions in the Field reports category.

2. Once a week, the project reads new threads and checks for patterns worth integrating.

3. If your story reveals a new Failure Vector, a revision to tension_index, or a sharper edge for the Perturbator — the entry gets updated.

4. The change is logged at /log and goes live on the next deploy.

Don't have a GitHub account? Here's how it works

GitHub Discussions is free. You need a GitHub account (30 seconds to create one).

Once you're signed in, click "Share your story" above. Write in your own language — the thread will be translated for everyone else automatically.

You don't need to know how to code. You don't need to know what "git" is. You just need an observation that the theory didn't match reality.

What are GitHub Discussions? →

Every pattern raises more questions than it answers.
Read the theory. Then look at what happened.