# Comparative Analysis, Part 2: DAOs, Open-Source Foundations, Co-ops, and Standards Bodies **Purpose.** National constitutions iterate over decades; the systems in this file iterate over months. They are smaller and lower-stakes, but they are the only governance systems whose *full history is in version control* — every rule change, vote, and exploit is public data. They are this project's natural ancestors and its richest source of recent failure modes. Same extraction template as Part 1: meta-rules, failure modes observed, extracted lessons. --- ## 15. Debian (Constitution, 1998–present) **Overview.** ~1,000 developers governing the oldest community Linux distribution under a formal written constitution — probably the most constitution-like artifact in open source. **Meta-rules.** - *Amendment:* General Resolution (GR) with **3:1 supermajority** for constitutional changes; ordinary GRs at simple majority. - *Voting:* **Condorcet (Schwartz sequential dropping)** with a built-in "None of the above / Further Discussion" option on every ballot — voters can always reject all alternatives. - *Suffrage:* one developer, one vote; membership gated by a technical/philosophical vetting process (New Member process). - *Quorum:* 3√N (≈45 of 1,000) — a *square-root* quorum that scales sublinearly with membership. - *Officers:* an elected Project Leader with deliberately weak powers; a Technical Committee for technical disputes that may overrule a developer only at 3:1. **Failure modes observed.** (1) GR processes over hot disputes (systemd, 2014) were procedurally clean but socially brutal — several core contributors resigned regardless of outcome; procedural legitimacy did not produce social cohesion. (2) Low participation: many GRs barely clear quorum, so small motivated groups have outsized weight. (3) Ballot-construction fights: with Condorcet, *which options appear on the ballot* becomes the real battlefield; Debian added formal rules for option sponsorship after gaming attempts. **Extracted lessons.** (a) Sublinear quorum (√N-scaled) is a battle-tested answer to the participation-scaling problem — the kernel adopts a quorum floor with sublinear scaling as the default parameterization. (b) "Further Discussion" as a mandatory ballot option is a cheap, powerful safeguard: no vote can force a choice among only bad options — kernel adopts it. (c) Ballot construction is part of the attack surface and must be rule-governed, not clerk-discretionary. --- ## 16. Apache Software Foundation (1999–present) **Overview.** Hundreds of projects under one foundation; governance famous for "community over code" and lazy consensus. **Meta-rules.** - *Lazy consensus:* proposals pass after 72 hours with no objection — silence is consent, with a defined timeout. - *Veto with justification:* on code, a single -1 from a committer blocks, but **must carry a technical justification**, and an unjustified veto is invalid. - *Merit-gated suffrage:* contributors → committers → PMC members by demonstrated contribution; binding votes are PMC-only. - *Board oversight:* the foundation board can intervene in dysfunctional projects (rarely used; notable exception below). **Failure modes observed.** (1) Corporate capture at the project level: several projects became single-vendor fiefdoms where the PMC was one company's employees; the merit ladder doesn't distinguish independent merit from payroll-coordinated merit. (2) The veto can be used obstructively if "technical justification" is interpreted loosely; long stand-offs occurred. (3) Attic events: projects die quietly because nobody has the authority *or obligation* to call time of death until the board sweeps. **Extracted lessons.** (a) Lazy consensus with timeout is the right default for low-stakes decisions — explicit votes for everything is participation-budget suicide. The kernel's decision-class system grades procedure weight to decision stakes. (b) Justified-veto beats raw veto: objections must be legible and contestable. (c) Coordinated-identity capture (many votes, one principal) is the open-source version of Sybil attacks; the module spec requires modules to declare their identity model so tests can target it. --- ## 17. Python / PEP 13 (2018–present) **Overview.** Python ran 27 years under a BDFL (Guido van Rossum). In 2018, after the PEP 572 acrimony, Guido resigned *with no succession mechanism in place*. The community spent months in constitutional limbo, then drafted competing governance PEPs and voted (Condorcet) to adopt PEP 13: a five-member elected Steering Council. **Meta-rules (PEP 13).** Annual council elections (core developers vote, approval-style); the council holds broad authority but is *expected* to delegate; amendments to PEP 13 itself require a 2/3 vote of core developers; core developer status granted by 2/3 vote of existing core devs. **Failure modes observed.** (1) The original sin: no succession plan — the system worked only while one irreplaceable human consented to bear it, and his exit was a governance outage. (2) The selection-among-constitutions vote went smoothly *because* the BDFL's departure created a moment of genuine openness; under a contested departure it could easily have forked the project. (3) Membership-grants-membership (core devs vote in core devs) creates a closure risk: the demos can quietly stop growing. **Extracted lessons.** (a) **Bus factor is a constitutional property.** Every role in the kernel must have defined vacancy and succession handling; "the founder decides" is an outage waiting for an exit. (b) A community *can* choose its constitution by Condorcet vote among complete drafts — relevant precedent for how FablePool's own backers ratify v1. (c) Demos-growth processes need monitoring: a membership process controlled solely by incumbents trends toward closure (cf. Switzerland's suffrage lesson at national scale — same bug, different size). --- ## 18. Rust Project (2015–present; reorganized 2021–23) **Overview.** Pioneered structured open-source governance: RFC process for all significant changes, federated teams with domain authority, and consensus via "final comment period" (FCP). **Meta-rules.** RFCs require team consensus minus at most explicit dissent handling; FCP gives a 10-day public last-call; teams own domains; cross-cutting issues escalate. After the 2021 moderation-team mass resignation (the mod team resigned *in protest that no body existed with authority over the core team* — a literal "who watches the watchmen" outage), the project spent two years designing a Leadership Council (RFC 3392) with representation from each top-level team and explicit accountability mechanisms. **Failure modes observed.** (1) **Unaccountable apex:** the original structure had no procedure by which the core team could be sanctioned — the org chart had a root node with no check, discovered only when the moderation team's only recourse was resignation. (2) Burnout as systemic risk: consensus-heavy processes concentrate invisible labor. (3) The RFC process's success created its own DoS: RFC volume exceeded review capacity, and "the queue" became a silent pocket-veto. **Extracted lessons.** (a) **Every node in the authority graph must be checkable by some other node** — the kernel requires the accountability graph to be strongly connected (no unaccountable apex); this is checkable mechanically, a real test. (b) Queue starvation is a pocket veto: the kernel gives proposals a guaranteed decision timeline (decide or auto-escalate), so ignoring a proposal is not a free rejection. (c) Process load is a budget; the kernel keeps mandatory process minimal and pushes ceremony into opt-in userland. --- ## 19. IETF (1986–present) **Overview.** Standards body for the internet. "We reject: kings, presidents and voting. We believe in: rough consensus and running code." No formal membership at all — participation is open; consensus is judged ("hummed") by working group chairs and appealable up a chain. **Meta-rules.** No suffrage (no members!); rough consensus assessed by chairs per RFC 7282 ("lack of sustained, unaddressed objection" rather than majority); NomCom — a **randomly selected** committee of volunteers — appoints leadership; decisions appealable (WG chair → AD → IESG → IAB). **Failure modes observed.** (1) Consensus judgment is human and contestable; chairs can shade "rough." (2) Open participation invites flooding — large vendors send dozens of engineers; rough consensus resists raw counting but not agenda exhaustion. (3) Glacial pace on contested topics; "running code" requirement biases toward incumbent implementers. **Extracted lessons.** (a) Sortition for appointment (NomCom) works in practice at decades of scale and resists slate capture — the kernel includes sortition as a first-class appointment primitive userland modules can invoke. (b) "Rough consensus" doesn't transplant: it depends on dense shared context and trusted chairs; the kernel uses counted votes for anything binding, and reserves consensus processes for userland where context density is declared. (c) Layered appeal paths matter — but must terminate (the kernel's terminal appeal is always a member vote, the one referee that can't be packed without changing the demos itself, which is invariant-protected). --- ## 20. Wikipedia / Wikimedia (2001–present) **Overview.** The largest functioning anarchy in history: policy is written by the governed, on the same wiki, under the same edit process as the content. **Meta-rules.** Policy emerges by edit + talk-page consensus; "consensus can change" is itself policy; administrators elected by community discussion (RfA); Arbitration Committee (elected) as terminal dispute body; the Wikimedia Foundation holds a rarely-used superuser power (office actions). **Failure modes observed.** (1) **Policy calcification:** despite "consensus can change," core policies became practically unamendable because *any* change attracts enough objection to break consensus — consensus systems develop their own 203-year problems. (2) RfA became so adversarial that admin recruitment collapsed (an appointment process so unpleasant it starves the system of officers). (3) The 2019 Framgate crisis: the Foundation's office action banning an admin without community process triggered mass resignations — the superuser power was technically held but socially unspendable, and *ambiguity about its scope* was the actual harm. (4) Sockpuppetry — identity-cost attacks on every consensus measurement. **Extracted lessons.** (a) Pure consensus does not scale for *rule change*; you need a counted decision procedure as backstop or the rules freeze. (b) Reserve powers must have explicitly enumerated scope and process *before* first use — an ambiguous superuser is worse than either a defined one or none. (c) Appointment-process toxicity is a quantifiable failure mode (officer pipeline starvation) the test suite should measure. (d) Identity is the substrate of all vote-like systems; the kernel must require an explicit identity model declaration and treat Sybil-resistance as config-dependent, not assumed. --- ## 21. The DAO (2016) — and the Ethereum fork **Overview.** The first mega-DAO: $150M raised in weeks; "the code is the constitution," literally — governance was the smart contract. A reentrancy bug let an attacker drain ~$60M *within the rules as written*. Ethereum's community then voted (low-turnout carbonvote + miner signaling) to hard-fork and reverse the theft; dissenters kept the original chain (Ethereum Classic). **Meta-rules.** Token-weighted everything; no amendment process beyond contract upgrade paths; no human override layer (by design and pride). **Failure modes observed.** (1) **Spec/implementation collapse:** when code is constitution, every bug is a constitutional amendment in the attacker's favor; "follow the rules" and "follow the intent" became opposing camps. (2) The remedy (hard fork) had no constitutional basis, so it was improvised under time pressure with ad-hoc legitimacy measurement. (3) The fork itself, though traumatic, *worked*: both chains survived, dissenters exited with their assets — accidental proof that fork-as-remedy is viable. **Extracted lessons.** (a) The kernel must distinguish **text** (intent, human-readable, authoritative) from **implementation** (automation, subordinate): when they diverge, text wins and the implementation is the bug — the exact inverse of The DAO's stance, learned at a cost of $60M. (b) Crisis remedies must pre-exist the crisis (the kernel's invariant-violation procedure exists *before* any violation). (c) The fork right works in practice; formalizing it (who keeps shared assets? how is the split measured?) is the difference between a fork and a robbery — this drives Article VIII's asset-division rules. --- ## 22. MakerDAO (2017–present) **Overview.** The longest-running major DeFi DAO, governing a multi-billion-dollar stablecoin via MKR token voting. The richest single source of on-chain governance attack data. **Meta-rules.** Token-weighted voting (1 token = 1 vote; capital-weighted suffrage); continuous "executive votes" where the proposal with most staked MKR is live policy; Governance Security Module (timelock) delays executed votes; emergency shutdown mechanism. **Failure modes observed.** (1) **Flash-loan governance attack (October 2020):** an actor *borrowed* voting power within a single transaction to pass a proposal — suffrage that can be rented is suffrage that can be momentarily stolen; patched by timelocks and snapshot-based voting. (2) Chronic whale rule: a handful of addresses decide most votes; turnout among small holders is negligible because their vote provably doesn't matter — capital weighting converts inequality of stake into inequality of rule, and then participation collapse makes it worse. (3) Voter apathy → delegated "recognized delegates" → delegate cartel dynamics. (4) The 2024–25 "Endgame" restructurings concentrated effective control in the founder again — DAO governance round-tripping back to founder rule under complexity fatigue. **Extracted lessons.** (a) **Capital-weighted suffrage is a different kind of system, not a parameter setting of democracy** — the kernel's default is one-member-one-vote and the invariants forbid *purchasable* voting weight in kernel-level decisions; userland may weight votes for *its own* decisions only if declared, and such modules cannot touch kernel matters. (b) Timelocks between decision and execution are cheap and defeat whole attack classes (flash capture, panic ramming) — the kernel mandates a minimum decision-to-effect delay, parameterized. (c) Snapshot suffrage (eligibility fixed *before* the vote is announced) defeats last-minute demos manipulation — kernel rule. (d) Complexity fatigue is a capture vector: when governance is too complex to follow, members delegate to whoever shows up, usually the founder. --- ## 23. Compound / Governor framework (2020–present) **Overview.** Compound's Governor contracts became the de facto standard DAO constitution-as-code, forked by hundreds of DAOs: propose (with proposal threshold) → vote (token-weighted, snapshot) → timelock → execute. **Meta-rules.** Proposal threshold (minimum tokens to propose), voting period, quorum (fraction of token supply), timelock. All four are explicit parameters — the first widely-deployed *parameterized* constitution, structurally what our userland spec generalizes. **Failure modes observed.** (1) Parameter mis-tuning is the dominant failure: quorums set so high nothing passes (governance paralysis) or so low that one whale passes anything; proposal thresholds that lock out everyone but VCs. (2) The 2022 **Build Finance DAO hostile takeover**: an attacker cheaply acquired enough tokens to pass a proposal granting themselves the treasury — a fully legal 51%-style drain, the literal scenario from our project description ("if a 51% faction can drain the commons under your wording, the test fails"). (3) Governance proposals with malicious payloads hidden in complex calldata passed because voters approve summaries, not diffs. **Extracted lessons.** (a) Parameterized constitutions need **parameter validity bounds** — the kernel ships hard bounds (e.g., quorum may not be set below the kernel floor; timelock may not be zero) and the schema enforces them; tuning freedom inside guardrails. (b) Treasury motion above a size threshold must face a higher decision class than ordinary votes — magnitude-sensitive thresholds are the direct countermeasure to legal drains. (c) What is voted on must be the *actual diff*, not a summary — the kernel requires the ratified text/payload to be byte-identical to the proposed one (no post-vote edits), and the test suite checks proposal/payload equivalence. --- ## 24. Optimism Collective (2022–present) **Overview.** The most deliberate constitutional design in crypto: explicitly **bicameral** — a Token House (token-weighted) and a **Citizens' House** (one-person-one-vote, identity-attested) that must concur on key matters; retroactive public-goods funding decided by citizens. **Meta-rules.** Bicameral concurrence for protocol upgrades and treasury categories; a foundation with declared, *scheduled-to-decay* training-wheel powers; a written "Working Constitution" explicitly labeled as iterative and versioned. **Failure modes observed.** Young system; observed issues are (1) citizen-set bootstrapping is hand-picked, so the one-person-one-vote chamber's demos is founder-curated for now; (2) declared power-decay schedules have slipped — "temporary" foundation powers exhibit the universal gravitation of temporary powers. **Extracted lessons.** (a) Mixed-suffrage bicameralism is a live experiment in exactly the capital-vs-person tension; the kernel stays one-member-one-vote at kernel level but the module spec explicitly supports multi-chamber userland configurations with declared concurrence rules. (b) **Bootstrap powers must have expiry enforced by the system, not by the power-holder's promise** — the kernel's genesis provisions (Article X) carry hard sunset conditions. (c) Publishing your constitution as explicitly versioned and iterative ("Working Constitution") sets correct expectations — adopted wholesale. --- ## 25. Nouns DAO (2021–present) — the fork mechanism **Overview.** An NFT DAO notable for one thing above all: in 2023 it shipped a **formal, on-chain fork right**. If ≥20% of Nouns escrow into a fork, a new DAO deploys and the forkers exit *with their proportional share of the treasury*. Built explicitly as minority protection after "arbitrage raiders" bought tokens trading below treasury-share value. **Meta-rules.** Standard Governor-style voting plus: fork threshold (20%), escrow period, pro-rata treasury split on fork. **Failure modes observed.** (1) The first fork (September 2023) was used primarily by arbitrageurs to extract treasury value, not by an oppressed minority — the exit right became a financial instrument; ~56% of supply forked or ragequit in waves. (2) But: the *threat* of fork measurably disciplined majority behavior afterward — proposals hostile to minority holders stopped passing. Both edges of the sword observed within months. **Extracted lessons.** This is the only system on Earth with empirical data on formalized constitutional forking. (a) Fork rights *do* discipline majorities — the deterrence effect is real and observed. (b) Pro-rata *financial* split makes forking attractive to extractors, not just dissenters; the kernel's fork provisions therefore distinguish asset classes (members always take themselves and their data; divisible commons split by declared formula; *indivisible* commons stay with the continuing body, with the formula chosen at module-config time, before anyone knows which side they'll be on — a Rawlsian veil applied to fork design). (c) Fork thresholds and escrow windows are genuine security parameters needing bounds, not vibes. --- ## 26. Mondragon Corporation (1956–present) **Overview.** The world's largest worker co-op federation: ~70,000 worker-owners, ~80 cooperatives, Basque Country. Proof that one-member-one-vote governs industrial-scale economics for seven decades. **Meta-rules.** One worker, one vote in each co-op's General Assembly regardless of salary or seniority; elected Governing Council appoints management (managers are *hired by* the governed); pay-ratio cap (~1:6, assembly-amendable) as a structural invariant; federation level: co-ops are sovereign but bound by shared principles, with mutual-support funds — and co-ops *can and do leave* the federation (a standing fork right, occasionally exercised). **Failure modes observed.** (1) The 2013 Fagor collapse: the federation's flagship failed and the federation chose *not* to bail it out without limit — solidarity has a declared budget; worker-owners absorbed losses but the federation survived; messy, but the firebreak worked. (2) Manager/assembly information asymmetry: one-member-one-vote doesn't help if members vote on management's framing of the facts. (3) Two-tier erosion: international subsidiaries employ non-member workers without votes — the demos boundary quietly excludes a growing class, the co-op version of the metic/denizen problem. **Extracted lessons.** (a) One-member-one-vote at scale, for decades, with real money: the existence proof for the kernel's suffrage default. (b) Federated sovereignty with exit (co-ops leaving) is a functioning fork right at industrial scale. (c) **Demos drift** — a growing class of governed non-members — recurs everywhere from Athens to Mondragon to Discord servers; the kernel requires periodic demos review: an enumerated check of who is governed-but-voteless and a vote on whether that's intended (it can't force inclusion, but it forces the exclusion to be *explicit and re-affirmed* rather than ambient). (d) Structural ratios (pay caps) as amendable-but-entrenched parameters work. --- ## 27. Rochdale Principles / consumer co-ops (1844–present) **Overview.** The 1844 Rochdale Pioneers' principles — open membership, one member one vote, limited return on capital, education, autonomy — are the longest-lived *portable governance spec* in existence: the same principle set instantiated by hundreds of thousands of co-ops across two centuries and every continent. Structurally, Rochdale **is** a kernel with userland configs. **Meta-rules.** The principles function as invariants (a co-op violating them loses recognition as a co-op — identity-gated compliance); each co-op's bylaws are its module config; the ICA (International Co-operative Alliance) stewards the principle text and has amended it roughly twice a century (1937, 1966, 1995 revisions). **Failure modes observed.** (1) Demutualization raids: members vote to convert the co-op to a company and distribute the commons to themselves — the 1990s UK building society raids are the canonical *legal commons drain by current members against all future members*; co-ops developed counter-tech: asset locks and disinterested-distribution clauses (on dissolution, assets go to another co-op or charity, never to members). (2) Member apathy → board entrenchment, the universal small-turnout failure. (3) Principle drift: large co-ops behaving identically to corporations while keeping the label. **Extracted lessons.** (a) **A portable kernel + local config demonstrably works for 180 years** — Rochdale is the strongest precedent for this entire project's architecture. (b) The asset lock is the strongest known anti-drain device: making the commons *non-distributable to the deciders* removes the incentive rather than raising the threshold; the kernel adopts it as a default-on module parameter and the invariants protect future/absent stakeholders explicitly. (c) Kernel stewardship across instances (the ICA role) is a real function FablePool itself will eventually hold — with the same capture risks; noted for the design doc. --- ## 28. Robert's Rules of Order (1876–present) **Overview.** Not a constitution but the dominant *procedural* kernel of Anglophone civil society: a portable, versioned (12 editions!) protocol for deliberation and voting adopted by reference into thousands of organizations' bylaws. **Meta-rules.** Graduated thresholds keyed to what a motion does to *members' rights* (simple majority for ordinary business; 2/3 for anything suppressing debate or rights; previous notice requirements for higher-impact motions); quorum defined in bylaws with majority default; point-of-order / appeal mechanism so any member can challenge the chair's ruling and the assembly decides — a built-in, instant referee check. **Failure modes observed.** (1) Weaponized proceduralism: mastery of the rules becomes minority obstruction (motion spam, dilatory points of order) — expertise asymmetry converts neutral procedure into a skill weapon. (2) Complexity excludes: 700+ pages means casual members defer to parliamentarians, recreating clergy. (3) The chair's agenda and recognition powers remain soft capture points despite the appeal check. **Extracted lessons.** (a) **Threshold graduated by impact on member rights** is exactly the right axis (more than by topic) — the kernel's decision-class system keys on rights-impact and reversibility. (b) Any-member appeal against any officer ruling, decided by the body, is a cheap universal referee check — adopted in the kernel as the procedural-objection mechanism. (c) Procedure complexity is itself an attack surface (expertise capture); the kernel optimizes hard for brevity and includes the legibility invariant partly for this reason. (d) Versioned editions of governance rules, maintained over 150 years — precedent for governance semver. --- *Synthesis of both parts in `03-synthesis.md`: the meta-rules that independently recur (and therefore go in the kernel), and the failure modes that independently recur (and therefore go in the test suite).*