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

Peeragogy in Practice

Carrying capacity

⏱ 6 minPAT

Motivation

This pattern can help project participants recognize and communicate their stresses to make themselves and the project more resilient.

Context :key:

One of the important maxims from the world of FLOSS is: “Given enough eyeballs, all bugs are shallow” [8]. A partial converse is also true: there’s only so much any one person can do, since we all have limited time and energy.

Forces

Antifragility: each person’s potential can only be realized if people take on enough, but not too much.

Independence: in a peeragogy context, it is often impossible to delegate work to others.

Problem :key:

How can we help prevent those people who are involved with the project from over-promising or over-committing, and subsequently crashing and burning?

First, let’s be clear that there are lots of ways things can go wrong. Simplistic expectations – like /assuming that others will do the work for you/ [13] – can undermine your ability to correctly gauge your own strengths, weaknesses, and commitments. Without careful, critical engagement, you might not even notice when there’s a problem. Where one person has trouble letting go, others may have trouble speaking up. Pressure builds when communication isn’t going well.

Solution :key:

Serious frustration is a sign that it’s time to revisit the group’s and your own individual plan. Are these realistic?

If you have a “buddy” they can provide a reality check. Maybe things are not that hard after all – and maybe they don’t need to be done right now. Generalizing from this: the project can promote an open dialog by creating opportunities for people to share their worries and generate an emergent plan for addressing them [10].

Use the project Roadmap to make note of obstacles.

For example, if you’d like to pass a baton, you’ll need someone there who can take it. Maybe you can’t find that person right away, but you can bring up the concern and get it onto the project’s. The situation is always changing, but if we continue to create suitable checkpoints and benchmarks, then we can take steps to take care of an issue that’s getting bogged down.

Rationale

Think of the project as an ecosystem populated by acts of participation. As we get to know more about ourselves and each other, we know what sorts of things we can expect, and we are able to work together more sustainably [6]. We moderate stress and improve collective outcomes by taking concerns seriously.

Resolution

Guiding and rebalancing behavior in a social context can begin with speaking up about a concern. When we acknowledge concerns, we must take into account our own boundedness. We have find an opportunity to make ourselves helpful, without impinging on others’ independence. This doesn’t mean allowing all possible stresses to run rampant: we work to stay within the realm of antifragility, where manageable stress improves the system rather than degrading it [12]. As we share concerns and are met with care and practical support, our actions begin to align better with expectations (often as a result of forming more realistic expectations).

Example 1

Wikipedia aims to emphasize a neutral point of view, but its users are not neutral.[fn:1] topics that matter to them.[fn:2] and participation are not neutral in another less sanguine sense. More information on Wikipedia deals with Europe than all of the locations outside of Europe [2]. As we remarked in the pattern, most of the actual work is contributed by a small percentage of users. The technology limits the kinds of things that can be said [2]. The total number of active editors has been falling since 2007.[fn:3] Some blame outmoded technology and an insider culture [11], or a stringent editorial approach that emerged in response to the site’s popularity [3]. Others highlight the rise of successful competition, often inspired by wiki models, but driven by “corporate logic” [4,5]. Some proposed solutions focus on various indicators of “community health.”[fn:4]

Example 2

Progressive thinkers have for some time subscribed to the view that “there shall be no women in case there be not men, nor men in case there be not women” [7]. A separate Ladies Hall seems entirely archaic. However, in light of the extreme gender imbalance in free software, and still striking imbalance at Wikipedia [1,9], it will be important to do whatever it takes to make women and girls welcome, not least because this is a significant factor in boosting our .

\ Ladies Hall: Queens College, North Carolina.

What’s Next in the Peeragogy Project

Making it easy and fruitful for others to get involved is one of the best ways to redistribute the load. This often requires knowledge transfer and skill development among those involved; see .

BACK writing articles in PT_BR — have an edition in Portuguese? :handbook:

BACK Source guests for PT_BR Podcasts :podcast:

BACK Patreon :project:

BACK Bank account :project:

BACK Accounting :project:

BACK Promotion / social media :project:

References

  1. Rishab A. Ghosh, Ruediger Glott, Bernhard Krieger, and Gregorio Robles. 2002. FreeLibre and Open Source Software: Survey and Study/. International Institute of Infonomics, University of Maastricht.

  2. Mark Graham, Bernie Hogan, Ralph K Straumann, and Ahmed Medhat. 2014. Uneven geographies of user-generated information: Patterns of increasing informational poverty. /Annals of the Association of American Geographers/ 104, 4: 746–764.

  3. Aaron Halfaker, R. Stuart Geiger, Jonathan Morgan, and John Riedl. 2013. The Rise and Decline of an Open Collaboration System: How Wikipedia’s reaction to sudden popularity is causing its decline. American Behavioral Scientist 57, 5: 664–688. http://doi.org/10.1177/0002764212469365

  4. Daniel Kreiss, Megan Finn, and Fred Turner. 2011. The limits of peer production: Some reminders from Max Weber for the network society. New Media & Society 13, 2: 243–259.

  5. Mayo Fuster Morell. 2011. An introductory historical contextualization of online creation communities for the building of digital commons: The emergence of a free culture movement. Proceedings of the 6th Open Knowledge Conference. Retrieved from http://ceur-ws.org/Vol-739/paper_7.pdf

  6. Elinor Ostrom. 2010. Revising theory in light of experimental findings. Journal of Economic Behavior & Organization 73, 1: 68–72.

  7. François Rabelais. [1534] 1894. Gargantua and pantagruel. Moray Press.

  8. Eric S Raymond. 2001. /The Cathedral & the Bazaar: Musings on Linux and open source by an accidental revolutionary/. O’Reilly Media, Inc.

  9. Joseph Reagle. 2012. “Free as in sexist?” Free culture and the gender gap. First Monday 18, 1. Retrieved from http://firstmonday.org/ojs/index.php/fm/article/view/4291

  10. Jaakko Seikkula and Tom Erik Arnkil. 2006. /Dialogical meetings in social networks/. Karnac Books.

  11. Tom Simonite. 2013. The Decline of Wikipedia. Technology Review 116, 6: 50–56.

  12. Nassim Nicholas Taleb. 2012. /Antifragile: Things that gain from disorder/. Random House Incorporated.

  13. Linus Torvalds and Steven Vaughan-Nichols. 2011. Linus Torvalds’s Lessons on Software Development Management. Input Output. Retrieved from http://web.archive.org/web/20131021211847/http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/ba-p/440

[fn:1] https://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view

[fn:2] https://en.wikipedia.org/wiki/Wikipedia:Activist

[fn:3] https://strategy.wikimedia.org/wiki/Editor_Trends_Study/Results

[fn:4] https://lists.wikimedia.org/pipermail/wiki-research-l/2016-January/004959.html

⚡ Unpeeragogy · Friction · Observation

Carrying Capacity Is an Excuse

⏱ 4 minaudit-v2carryingstressconflict

The Assumption

Peer groups can absorb and redistribute the load when some members become fragile, maintaining collective function through mutual support. Recognizing and communicating limits is the first step toward sustainable peer production.

Operational Reality

The pattern of administrative burnout in large peer production projects is well-documented. Wikipedia editors who spend years mediating disputes, cleaning vandalism, and diplomatically managing personalities eventually face a structural trap: they are not carrying the project’s intellectual load but its emotional overhead — the friction that accumulates when thousands of humans try to coordinate without hierarchy.

Every peer production system discovers this eventually. Someone ends up carrying what everyone else will not.

OpenStreetMap’s Data Working Group shows that formal dispute resolution bodies with binding authority resolve what informal consensus cannot: someone must carry the authority to make binding decisions. The Linux kernel’s Code of Conflict shows that external pressure forces governance changes that peer communities cannot produce through internal deliberation alone. WebAssembly’s lighter governance prevents one kind of carrying burden (bureaucracy) while creating another (consensus fatigue).

Empirical Evidence

Resilience Cases (Confirming):

  • OpenStreetMap Data Working Group — Formal dispute resolution bodies with binding authority resolve peer production conflicts that informal consensus cannot. Someone must carry the authority to make binding decisions.

Fracture Cases (Complicating):

  • Linux Kernel Code of Conflict — External pressure forces governance changes that peer communities cannot produce through internal deliberation alone. Chronic carrying problems require external escalation mechanisms.
  • WebAssembly Community Group — Lighter governance prevents bureaucratic carrying burden but creates consensus fatigue as a different failure mode.

Operational Heuristics

Positive Boundary: Establish formal dispute resolution bodies as backstop for informal support — published reasoning and binding decisions reduce the emotional load on those who mediate.

Negative Boundary: Do not rely on informal mutual support when fragility affects the decision core or becomes chronic — peer communities cannot resolve chronic carrying problems through informal mechanisms alone.

Epistemic Synthesis

The assumption that groups can absorb and redistribute load through mutual support is contradicted by the evidence. OpenStreetMap shows that formal authority is required to resolve what informal consensus cannot. The Linux kernel shows that external pressure is necessary when internal mechanisms fail. Carrying someone sounds noble until you are the one being carried toward the exit.

Perturbatore: “What if the people who talk most about distributed leadership are the ones least willing to distribute the actual work?”

The quiet ones carry more than they say.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.7 → 1.745 · Diversity D: 2

References

💬 Field Report: Carrying Capacity Is an Excuse

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 →

✏️ Share your story🔍 Structural analysis📋 Browse field reports
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.

🗂️ Browse all patternsWhy this project? →← Back home