Since we have been at it for quite a while we have a lot of data on how things have been going, but maybe not yet such a clear sense of where it’s going.

In order to get anywhere we need to keep apprised of all of our resources; as well as whether and how they are sustained.

In any enterprise it makes sense to be careful to ‘spread tasks thin, not people’.

The Peeragogy project is an example of A specific project. To sum up what we do:

“Finding tools to facilitate peer production & peer learning experiences”

We think that people who are interested in our work may be in two main tracks:

People who want to build their own ‘peeragogy projects’, and:
People who just want to improve the way they work

One of the challenges is to identify why we are doing a next edition (and maybe another edition after that). We should have a clear understanding about what worked and did not work in the previous versions, and why, so we know what to revise, why we are revising it and it can lead to informed discussions about how.

This itself is work in progress.

Next steps

For now “project” is one of the tags used on peeragogy.org, but it should probably develop into its own pattern.
- There’s a short-form draft at the top of this page
The way this is framed seems related to Carrying capacity, maybe these are actually two aspects of the same pattern

The Assumption

The Peeragogy Project demonstrates how peer learning initiatives can produce collaborative outputs like handbooks while maintaining ongoing community engagement through regular meetings and sustained participation.

Operational Reality

Peer projects without governance are just expensive coffee shops with version control.

The Peeragogy Project produced a handbook — and then entered decision-stagnation. Not because the community lost interest. Not because the work was complete. Because the project was a container that could not decide whether it was done or not. Apache Software Foundation has governed consensus-based development for 25+ years — not because it has better contributors, but because it has clearer governance.

GitLab’s stewardship handbook documents boundaries between corporate and community decision-making. The Apache Foundation separates governance from contribution — merit determines authority, not attendance. The Peeragogy Project’s stagnation after handbook completion shows what happens when the container lacks the structure to answer “what is next?”

Empirical Evidence

Resilience Cases (Confirming):

GitLab Stewardship Handbook — Explicit documentation of governance boundaries between corporate sponsor and community reduces friction in open-core projects. Structured containers enable sustained peer production.
Apache Foundation How It Works — Twenty-five-plus years of consensus-based governance demonstrates that structured peer production with formal mechanisms succeeds at scale. The container matters more than the contributors.

Fracture Cases (Complicating):

Node.js/io.js Merger (SDTimes) — Differing visions for project governance create schism even when abundant knowledge resources exist. Projects without explicit governance boundaries fragment when direction is contested.

Operational Heuristics

Positive Boundary: The project works when explicit governance structures are established from the start — structured peer production with formal consensus mechanisms and merit-based advancement scales successfully over time.

Negative Boundary: Do not assume that collaborative goodwill alone sustains peer projects — the Peeragogy Project’s stagnation after handbook completion shows that projects without formal governance structures degrade into decision-stagnation.

Epistemic Synthesis

The Peeragogy Project produced a handbook — and then entered decision-stagnation. Not because the community lost interest. Not because the work was complete. Because the container could not decide whether it was done or not. Apache governs consensus-based development for 25+ years — not because it has better contributors, but because it has clearer governance. The container is what holds the project together over time.

Perturbatore: “What if peer projects without governance are just expensive coffee shops with version control — and the project is a container that needs walls, not open space?”

The container without walls holds nothing. The project without governance decides nothing.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.4 → 1.3317 (±0.0683) · Diversity D: 2

References

💬 Field Report: The Project Is a Container

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? →