--- title: bookpower.org canonical: https://bookpower.org/ --- # bookpower.org > Bring the right book into your work. Give your agent the charter, workshop, strategy, or live question already in front of you. It can call a structured tool built from the book and return the relevant method or passage with its source attached. ## Browse by the work in front of you The catalog includes MCP servers and Agent Skills organized around the work they support. Public entries show how to use the tool. Private entries let you request access. Forthcoming entries are marked coming soon. Each catalog entry names the practitioner's job, source book, author, publisher, license, artifact type, and availability. Browse the entries linked from [/llms.txt](/llms.txt) or visit [the catalog](https://bookpower.org/#catalog). ## What your agent sees through the book’s lens A budgeting platform, a DAO proposal, a watershed agreement, an open-source repository. Each example shows your agent calling a tool built from one book and returning a source-grounded reading of the work. [See the examples](https://bookpower.org/#examples). ## Other paths - To understand the context-engineering case and build process, see [/how-it-works.md](/how-it-works.md). - To commission a book-powered tool from source material you have the right to use, start a conversation at https://app.harmonica.chat/chat?s=101072b8-81a2-483e-8f35-3b8011bfdcbd. - To follow the public build specification and submit your own finished artifact, see [/build.md](/build.md). --- --- title: How it works slug: how-it-works canonical: https://bookpower.org/how-it-works --- # How it works We translate books into structured tools your AI agent can call. Here's why that matters, and what we actually do. ## The context-engineering case Context engineering is the practice of curating what goes into an agent's context window. Everything the model sees when generating — system prompt, user message, conversation history, tool definitions, retrieved documents, tool results — competes for the same space, and shapes the answer in proportion to what gets through. When you ask an agent a substantive question, the answer comes from one of three places. Each has tradeoffs: 1. **Training data.** Whatever the model absorbed during training. Fast, but uncited, fuzzy, and frozen at the training cutoff. 2. **Direct retrieval.** Paste source pages into context at the moment of the question — the RAG pattern. Works for public-domain text. Doesn't work for paywalled or copyrighted material; wasteful for long documents. 3. **Tool calls.** The agent invokes a structured function and gets back a scoped, typed answer — like `web_search` or your project's file search. Fast, citable, in-scope. But only useful if the right tools exist for the source material you care about. Books-as-tools is the third option, applied to books. We translate a source book into structured tools — MCP servers and skills — that an agent can call when relevant, returning cited excerpts on demand. ### An agent's context window — where books-as-tools sit Everything the model sees when generating a response: 1. **System prompt** — role, persona, behaviour 2. **User message** — the task in front of you 3. **Conversation history** — prior turns in the session 4. **Tools** — what the agent can call: - `web_search` — general information retrieval - `file_search` — your project's own files - **book-power MCPs & skills** — cited, scoped, book-derived ← *here* 5. **Tool results** — only the cited excerpt enters context 6. **Response** — what the user reads, with citations intact The agent calls a tool only when the current question warrants it. The book's content enters context only on demand, only the pieces that matter, with chapter and page right there — ready to be cited back to the user. ## What we build For each book in the catalog we ship one of two artifact types: - **An MCP server** — a Model Context Protocol server any MCP-compatible client (Claude Desktop, Claude Code, and a growing list of others) can install and call as a tool. Most of our work to date. - **An Agent Skill** — a structured directory of files loaded into the agent's context as referenceable knowledge — no separate server, no install step. The choice depends on the source. Get in touch if you want to talk through which would suit yours. ## How a book becomes a tool Licensing is the filter, not a step. Public-domain or open-licensed sources ship as public artifacts under an open license. Copyrighted sources require an agreement with the rights-holder before any work begins. With that settled: 1. **Read the book.** A human (us) actually reads it, with notes on what the book contains that a practitioner would call on, and the questions they'd come with. 2. **Process the source.** Run the book through Kreuzberg to get clean chapter-by-chapter text from the PDF or EPUB. 3. **Extract the catalog.** Use Claude Sonnet via the Anthropic API, with structured-output schemas, to extract the book's load-bearing content from each chapter — cases, frameworks, definitions, quotes — preserving the source location for every entry. 4. **Wrap as MCP or skill.** Build the artifact that exposes the catalog as callable functions or consultable files. Every return value carries a citation back to the source. 5. **Deploy.** For MCP servers, host on Railway with HTTP transport — installable from any MCP-compatible client without the user setting up anything locally. ## Build your own That's the pipeline we run, and it's one you can run too. The same approach — extract a book's method layer into a typed, cited dataset, then wrap it as an MCP server or skill — is written up as a public build spec you hand to your coding agent. Make a tool from a book you wrote, teach from, or one already under an open license, then submit it to the catalog. See [/build.md](/build.md). --- --- title: For publishers slug: for-publishers canonical: https://bookpower.org/for-publishers --- # For publishers > Bring your books into your readers' context. We translate one of your titles into a small MCP server your readers' agents can call — cited, scoped, author-attributed — in partnership with you and the author, with no production cost to either of you. ## The case When a reader of your book sits down to apply it — drafting a charter, planning a workshop, reviewing a governance proposal — they increasingly do that work alongside an AI agent. The agent's answer to *"what does Bollier say about clear boundaries?"* comes from one of three places: paraphrased training data (uncited, partial, frozen at the cutoff); a 200-page paste of the book if the reader happens to own a PDF (wasteful, blocked for paywalled text); or a structured tool the agent can call. Books-as-tools is the third option. We translate one of your titles into a small, opinionated MCP server — 8 to 13 tools the agent invokes when the question warrants it, each returning a cited passage with chapter and page intact. The agent only pulls what's relevant; the reader sees a citation that points them back to your edition; the author gets attribution at the point of use. You get a new surface for an existing title without writing a new product. The context-engineering case in full — and the pipeline we run on each source — is on [/how-it-works.md](/how-it-works.md). ## How a partnership works We propose to start small. One book. One author. Four weeks of build. A working MCP installed for a handful of people — you, the author, your representative, and us — to use for a week before anything is shared more widely. The pilot does three things at once: proves the artifact works for the book in question, surfaces every author-contract and licensing question that needs answering, and gives all of us something concrete to base the model conversation on. We cover the build. Nothing is published, sold, or distributed during the pilot without explicit consent from you and the author. If the pilot answers the author's question and yours, we look together at what comes next. ### A pilot, week by week - **Week 0** — Book and author selected. Author signs a one-paragraph permission (template below). 30 minutes total from you and the author together. - **Weeks 1–2** — Extraction. Same pipeline that built Plurality and Think Like a Commoner — text-driven, no author work required during this phase. - **Week 3** — Tool design and review. The author can adjust voice and emphasis on the tool set before it's wrapped. - **Week 4** — Working MCP installed for the pilot group. We use it for a week and compare notes. Decide together what's next. ### What you keep - Full rights to the book. The MCP is derivative, not a replacement. - Author attribution on every citation the MCP returns. - Control over what happens after the pilot — public, gated, private, scrapped. - Co-ownership of the MCP, the legal template we converge on, and everything we learn. ### What we ask for - A signed one-paragraph permission from the author for the pilot scope. - 30 minutes from you to align on the book and the author. - An open conversation about a sustainable model if the pilot works. ## The author permission The smallest legal thing that lets the pilot run. The wording below is a starting point; you and the author will adjust it to fit your existing arrangements. > I, *[author name]*, grant Book Power permission to build an MCP server derived from my book *[title]* (*[Publisher]*, *[year]*) for the purpose of a private pilot. The pilot artifact will be installable only by the named pilot group, and will not be distributed publicly or to third parties without my written consent. This permission is valid until *[date]* and is revocable on seven days' notice. ## If it works — the model conversation If the pilot works, we have something concrete to base the larger conversation on. The questions that need answering at that point are publisher questions: how does this become a sustainable surface, who gets paid for what, what's the relationship to existing rights, how it sits alongside an audio or translation deal. The questions we'd want to take into that conversation: - **Chapter-based access.** Does the MCP charge per use, per chapter, per book? - **Author share.** What fraction of revenue flows to the author, on what terms? - **Distribution.** Public catalog, gated to your customers, or sold separately? - **Exclusivity.** Does our build for you preclude other arrangements you may have or want? These are real, hard questions. We don't carry fixed answers into the room. The pilot exists so that conversation has a working artifact between us, not abstractions. ## Common questions **What if the author isn't interested?** No pilot. The author's permission is the gate; no permission, no work. We won't approach an author over a publisher's no. **What if we want to commission a build without the pilot?** We do paid custom builds for publishers and methodology shops. Get in touch and we'll talk about scope. **Does this conflict with our existing AI deals?** Probably not. An MCP is a different surface from chat-over-catalog and a different surface from a training-data license. Worth checking against the specific terms. **Can we white-label?** Yes. The MCP can ship under your imprint with your branding. We do the build; you do the publishing. **What about open-license titles?** If the book is already under an open license we may have already built it (see the catalog). If not, the build can ship as a public artifact under the same license — we've done this for Plurality (CC0), Think Like a Commoner (CC BY-NC-SA), and Governable Spaces (CC BY-NC-SA). ## Get in touch Tell us about the book and the author at [bookpower.org/for-publishers#inquiry](https://bookpower.org/for-publishers#inquiry). A short form — publisher, contact, the title(s) you'd consider for a pilot. We'll respond within a couple of days. --- --- title: Build a book-powered tool slug: build canonical: https://bookpower.org/build --- # Build a book-powered tool > The catalog is open to tools built by others. If a book belongs in an AI workflow — one you wrote, one you teach from, one under an open license — you can build the MCP server or skill yourself with a public build spec, then submit it to the catalog. ## What you'd build A book-powered tool makes a book's methods callable inside an AI workflow — frameworks, checklists, workflows, diagnostic questions, principles, warnings — each cited back to the source. It is not a chapter dump. Example: a weak version of a *Producing Open Source Software* tool exposes `get_chapter("communications")` and returns 4,000 words; that just relocates the book. The good version extracts the project-health method and exposes an `audit_project` tool that scores a repo across ten areas and names the single highest-leverage fix, each with a citation. Tool names map to the work; the data holds the method, never the full text. The agent decides the book's shape first — prescriptive, descriptive, dialectical, or procedural — so a book that only describes patterns doesn't get flattened into a fake checklist. You publish only what you have the right to publish. Open-license and public-domain books can become public tools with attribution preserved; copyrighted books stay local or private unless the author or publisher has granted permission. See [/how-it-works.md](/how-it-works.md) for the context-engineering case. ## How to build one The build spec is a single file designed to be copied into a coding agent (Claude Code, Cursor, Pi, or similar) together with a book URL or file. The agent ingests the source, decides the extraction discipline, extracts the method layer into a typed data contract, generates an MCP server and/or an agent skill, and runs a smoke test before reporting back. It is a public build spec, not Book Power's source code. Build spec: https://gist.github.com/zhiganov/dfe35598ba30d0468f75c84e75c8c300 ## Submit to the catalog Built something useful? Submit it at [bookpower.org/build#submit](https://bookpower.org/build#submit). Public tools from open-license books can join the catalog alongside *Think Like a Commoner*, *Governable Spaces*, *Plurality*, and *Producing Open Source Software*. A `book-power.json` manifest at the artifact root makes it faster to process; a link and a few lines are enough to start. --- --- title: Beautiful Solutions slug: beautiful-solutions visibility: public domain: Solidarity economy canonical: https://bookpower.org/beautiful-solutions --- # Beautiful Solutions > A source-grounded map of 85 values, principles, questions, solutions, and stories for exploring solidarity-economy challenges without turning situated examples into universal recommendations. > > **Practitioner use:** Explore a solidarity-economy challenge and prepare a grounded discussion without turning precedents into recommendations. ## Source - **Beautiful Solutions: A Toolbox for Liberation** — Edited by Elandria Williams, Rachel Plattus, Eli Feghali, and Nathan Schneider (2024). Publisher: OR Books. License: CC BY-NC-SA 4.0. Source: https://beautifultrouble.org/store/p/beautiful-solutions ## Artifact - **beautiful-solutions-mcp** (MCP server) Repository: https://github.com/zhiganov/beautiful-solutions-mcp Live: https://beautiful-solutions-mcp-production.up.railway.app/mcp ## Why this book *Beautiful Solutions* gathers work from more than seventy contributors into a toolbox for people building more just and livable economies. Its examples range from food sovereignty and debt abolition to folk schools and energy democracy, with stories spanning Argentina to Zimbabwe. The book was created through a partnership of Beautiful Trouble, New Economy Coalition, People's Hub, and Highlander Center. The online toolbox is organized as a connected set of values, principles, questions, solutions, and stories. That structure matters. It lets a practitioner approach a live challenge from several directions without flattening one community's experience into a recipe for another. ## What we built `beautiful-solutions-mcp` exposes the English online toolbox through eight deterministic tools: - **Find and inspect.** `search_toolbox`, `list_entries`, and `get_entry` locate material and return its summary, authors, references, reviewed method card, and canonical source link. - **Follow the source.** `get_related_entries` traverses relationships supplied by the toolbox rather than inventing new connections. - **Work across possibilities.** `map_challenge`, `compare_entries`, and `build_discussion_guide` assemble exploration leads and discussion prompts without ranking entries or claiming that a model will transfer to a new place. - **Check provenance.** `get_source_info` reports the inventory, source snapshot, adaptation notes, and reuse conditions. Tool responses require no LLM, database, or live source at runtime. Every result includes attribution and the CC BY-NC-SA 4.0 license envelope. ## What's in the catalog The MCP contains 85 English toolbox entries: - 8 values - 10 principles - 8 questions - 27 solutions - 32 stories Each entry retains its source-authored summary and relationships, author and reference metadata where supplied, and a link to the complete entry on Beautiful Trouble. Manually reviewed method cards add source-grounded purposes, mechanisms, actors, conditions, constraints, tensions, observable signals, and transfer questions where the source supports them. Complete source write-ups and images are not bundled. ## What you can ask - "Map community ownership of housing and land across the toolbox's questions, values, principles, solutions, and stories." - "What does the toolbox connect to Community Land Trusts, and where should I read further?" - "Compare participatory budgeting and community land trusts without declaring a winner. What local information would still be needed?" - "Build a discussion for a neighborhood housing coalition using Community Land Trusts and Limited-Equity Housing Cooperatives." - "Explore community-controlled renewable energy. Show why each result matched and keep the results framed as possibilities, not recommendations." ## License Beautiful Trouble states that the written online toolbox is licensed under **CC BY-NC-SA 4.0**. The adapted dataset and source-grounded output templates use the same license: attribution and ShareAlike are required, and commercial use requires separate permission. The software code is MIT licensed. This is an independent adaptation, not an endorsement by Beautiful Trouble, the editors, or contributors. It is an aid for finding and discussing the source work, not a substitute for the book or complete online toolbox. ## Related - [Think Like a Commoner](/think-like-a-commoner) names commons, enclosures, and commoning practices in David Bollier's framing. - [Governable Spaces](/governable-spaces) examines democratic design for online communities through Nathan Schneider's work. - [Plurality](/plurality) offers another lens on collaborative institutions and democratic technology. --- --- title: Democracy Without Politicians slug: democracy-without-politicians visibility: public domain: Democracy tech canonical: https://bookpower.org/democracy-without-politicians --- # Democracy Without Politicians > Bouricius's case for sortition, as a verbatim search-and-read MCP: 10 tools that return the author's own words on the multi-body sortition design, the 17 chapters, key topics, glossary, and the real assemblies he cites. > > **Practitioner use:** Find Bouricius's own words on sortition, citizens' assemblies, and the multi-body design. ## Source - **Democracy Without Politicians: Government By the People** — Terry Bouricius (2026). Publisher: Routledge. License: CC BY-NC-ND 4.0. Source: https://www.taylorfrancis.com/books/oa-mono/10.4324/9781003665373/democracy-without-politicians-terry-bouricius ## Artifact - **democracy-without-politicians-mcp** (MCP server) Repository: https://github.com/zhiganov/democracy-without-politicians-mcp Live: https://democracy-without-politicians-mcp-production.up.railway.app/mcp ## Why this book *Democracy Without Politicians* is a former elected politician's case against his own trade. Terry Bouricius argues that electoral "democracy" is inherently undemocratic — it enshrines rule by a political class rather than genuine popular self-rule — and that the usual reforms (proportional representation, campaign-finance limits, ranked ballots) can't fix what elections structurally do. His alternative is **sortition**: forming representative deliberative bodies by lot, the way Athens did and the way modern citizens' assemblies do. The book's centrepiece is a worked design — **multi-body sortition** (Ch. 16): not one citizens' jury but a system of specialised, randomly-selected bodies that set the agenda, hear interests, draft, decide, coordinate, and oversee. It runs from the cognitive and psychological case against elections, through the history of sortition from ancient Greece to Ostbelgien, to a concrete transition path. A practitioner designing a citizens' assembly, a sortition pilot, or a deliberative process doesn't need the whole book in context. They need Bouricius's argument, scoped to their question, in his own words. ## What we built This one is built differently from its catalog siblings. The book is **CC BY-NC-ND**, and Bouricius gave permission on one condition: the tool must *find relevant text and display his actual words, not AI-generated summaries.* So `democracy-without-politicians-mcp` is a **verbatim** search-and-read server — every one of its 10 tools returns passages straight from the book, with attribution, never a paraphrase. A build test asserts that every excerpt any tool can return is a verbatim substring of the source. - **Read it.** `get_book_info`, `list_chapters`, `get_chapter` (verbatim text, paginated), `get_chapter_highlights`. - **Search it.** `search_content` — keyword search returning the most relevant verbatim paragraphs with their chapter. - **Navigate it.** `get_principles` (12 key topics), `get_multi_body_design` (the seven bodies of Ch. 16), `get_glossary` + `define_term` (the terms he coins), `find_cases` (the real assemblies he cites). Each is a curated label that resolves to a verbatim excerpt at request time — the label orients you, the substance is always Bouricius's own words. ## What's in the catalog Five navigation layers, each a set of labels that resolve to Bouricius's verbatim text: - **The 17 chapters** — from "Democracy in Dysfunction" and "The Inadequacy of Election Reform" through "The Sortition Solution," "Objections to Sortition," and "A Transition to Sortition Democracy." Readable in full, paginated. - **12 key topics** (`get_principles`) — the book's load-bearing arguments (the electoral imperative, neuro-politics, accountability and legitimacy, the re-emergence of sortition), each returning the passage that makes the point. - **The multi-body design** (`get_multi_body_design`) — the seven specialised bodies of Chapter 16: Agenda Council, Interest Panels, Review Panels, Policy Juries, Coordination Council, Rules Council, Oversight Councils. - **~20 glossary terms** (`get_glossary` / `define_term`) — the vocabulary he coins or leans on, each resolving to the passage where he introduces it. - **The cases he cites** (`find_cases`) — Ancient Athens, Ostbelgien, the British Columbia Citizens' Assembly, the Paris assembly, deliberative polls, and more, each with the excerpt where he discusses it. ## What you can ask Plain questions; the agent calls a tool and hands back Bouricius's own words: - "What's Bouricius's case that election reform can't fix democracy?" → `search_content` → the verbatim passages, cited to chapter. - "Show me the difference between Review Panels and Policy Juries in his multi-body design." → `get_multi_body_design` → the Chapter 16 excerpts for each body. - "How does he answer the objection that ordinary people aren't competent to govern?" → `get_chapter` on "Objections to Sortition," or `search_content`. ## License Source code: MIT. Embedded book text: **CC BY-NC-ND 4.0** — attribution to Terry Bouricius required, non-commercial, no derivatives. The server honours that by returning verbatim passages only; nothing is paraphrased. Shared with the author's express permission (2026-06-23). The book is open access at [Taylor & Francis](https://www.taylorfrancis.com/books/oa-mono/10.4324/9781003665373/democracy-without-politicians-terry-bouricius). ## Related - [Governable Spaces](/governable-spaces) — Schneider names sortition as one democratic primitive among many for online life; Bouricius makes it the whole architecture of government. - [Facilitating Deliberation](/facilitating-deliberation) — once sortition has selected the panel, this is the practitioner's craft of running the deliberation itself. --- --- title: Plurality slug: plurality visibility: public domain: Democracy tech canonical: https://bookpower.org/plurality --- # Plurality > Glen Weyl, Audrey Tang & ⿻ Community on plural-voting, augmented deliberation, and digital democracy — Taiwan-tested civic-tech, made queryable from any AI agent. > > **Practitioner use:** Examine a civic system through Plurality's failure modes, design moves, and cases. ## Source - **Plurality: The Future of Collaborative Technology and Democracy** — E. Glen Weyl, Audrey Tang & ⿻ Community (2024). Publisher: Self-published. License: CC0. Source: https://www.plurality.net/ ## Artifact - **plurality-mcp** (MCP server) Repository: https://github.com/zhiganov/plurality-mcp Live: https://plurality-mcp-production.up.railway.app/mcp ## Why this book *Plurality* is the most comprehensive recent argument that digital democracy is neither a monist project (let AI optimize policy) nor an atomist one (let markets and crypto sort it out), but a third path — ⿻ — that recognizes partially-overlapping social groups and intersectional identities as the substrate of legitimate collective decisions. Weyl and Tang back the argument with a decade of working civic tech: vTaiwan, Polis, g0v, JOIN, presidential hackathons, quadratic funding, augmented deliberation. The book ships under CC0, and the authors actively want it to be remixed and applied. ## What we built A 13-tool MCP server that makes Plurality's catalog callable — cases, failure modes, design moves, policy strategies, and verbatim quotes, all indexed for an agent that's working through a real situation rather than researching in the abstract. The catalog covers the Taiwan civic-tech canon and the global ⿻ scene — vTaiwan, Polis-style cross-faction consensus, g0v hackathons, Decidim Barcelona, Estonia's e-government, Iceland's crowdsourced constitution, Gitcoin quadratic funding, Wikipedia, OpenStreetMap, Mastodon — alongside the failure modes the book names (monist technocracy, atomist libertarianism, engagement-maximization, captured-DAO plutocracy) and the design moves it argues for (quadratic and plural voting, augmented deliberation, intersectional social identity, social markets, federated subsidiarity, data unions). ## What's in the catalog - **Cases** — civic-tech and digital-democracy examples Plurality documents (Taiwan-centric + global). - **Failure modes** — counter-⿻ patterns and the historical instances that exemplify them (the "monist" and "atomist" failure modes are the book's central diagnostic). - **Governance forms** — ⿻ primitives with diagnostic questions (quadratic voting, augmented deliberation, polis-clustering, conviction voting, partial common ownership, depreciating licenses, data unions, etc.). - **Policy strategies** — scaled moves at the policy/regulatory level (digital ministries, public-interest media funding, antitrust as ⿻, public-option platforms, data-union frameworks). - **Glossary** — the book's vocabulary (⿻, augmented deliberation, post-symbolic communication, intersectional social identity, plurality publics, Yushan view, lost dao, monist, atomist, g0v). - **Quotes** — themed verbatim passages indexed for citation. The book is CC0 — no license restrictions — but quotes carry attribution as a scholarly norm. ## What you can ask - "Help me write up vTaiwan as a case study, grounded in the book's framing" - "Is this AI-policy proposal ⿻ or monist? Walk it through the diagnostic" - "I'm designing a city-budget deliberation platform — what does Plurality say about layering identity, association, deliberation, voting, and markets?" - "Reframe 'free markets solve coordination' in ⿻ terms" - "What does the book mean by 'intersectional social identity'?" - "Find me a passage on the Yushan view" - "What policy moves would scale digital democracy across cities?" ## License Plurality is dedicated to the public domain under CC0 1.0. The server code is MIT. Re-use freely; attribution to the authors is included as a scholarly norm. ## Related - [Governable Spaces](/governable-spaces) — Schneider's framing of democratic design for online life. Strong complement on the diagnostic side (implicit feudalism in platforms, federation as response). - [Think Like a Commoner](/think-like-a-commoner) — Bollier's commons framing. Adjacent vocabulary (the commons as a different cut at the same "neither monist nor atomist" question). --- --- title: Governable Spaces slug: governable-spaces visibility: public domain: Democracy tech canonical: https://bookpower.org/governable-spaces --- # Governable Spaces > Schneider's framing of democratic design for online life — 13 tools for diagnosing implicit feudalism, finding precedent democratic-medium cases, and surfacing governance forms (sortition, federated subsidiarity, plural voting). > > **Practitioner use:** Diagnose power in an online community and explore democratic governance forms. ## Source - **Governable Spaces: Democratic Design for Online Life** — Nathan Schneider (2024). Publisher: UC Press / Luminos. License: CC BY-NC-SA 4.0. Source: https://luminosoa.org/books/m/10.1525/luminos.181 ## Artifact - **governable-spaces-mcp** (MCP server) Repository: https://github.com/zhiganov/governable-spaces-mcp Live: https://governable-spaces-mcp-production.up.railway.app/mcp ## Why this book Schneider opened *Governable Spaces* with a question anyone who has spent time in a moderated platform will recognize: why does so much of online life feel feudal? You spend years in a community — follow the norms, earn trust, contribute. Then a single owner — a Discord admin, a subreddit founder, a platform CEO, a multisig holder — makes a unilateral move that affects everyone, with no formal seat at the table for the people who actually live in that space. Schneider names this pattern *implicit feudalism*: not a slogan, a diagnosable structure. A platform governed by a single owner with unchecked, arbitrary power; no meaningful voice, exit, or ownership stake for members; rules imposed top-down without democratic legitimacy. The book is a working argument that implicit feudalism is the *default* of digital life — and that the alternative, a *governable space*, has to be deliberately designed. He's not a doomer about it. *Governable Spaces* catalogs democratic mediums that work: Wikipedia, Mastodon and the wider fediverse, Loomio, Decidim, the Drupal community, parts of the Ethereum ecosystem. The design primitives he names — sortition, federated subsidiarity, plural voting, modular politics, metagovernance — compose into workable counter-patterns. The moves that close down democracy (the *politics of no politics*, *digital colonialism*, *captured-DAO plutocracy*) get explicit names so practitioners can call them out. Practitioners working on a co-op platform, a fediverse instance, a DAO migration, or a research-community charter don't need to read the whole book on demand. They need Schneider's framing scoped to their question, with the chapter intact. ## What we built `governable-spaces-mcp` — an MCP server that exposes the book's content as 13 callable tools, grouped by job: - **Routing.** `start_analysis` (a branching entry point that scaffolds an analysis from the situation: diagnosing implicit feudalism, designing a governable space, finding precedent, exploring) and `suggest_next_step`. - **Diagnostic.** `diagnose_implicit_feudalism`, `find_failure_mode`, `find_precedent_case`, `list_policy_strategies`. - **Design.** `assess_governable_space`, `find_similar_case`, `suggest_governance_forms`. - **Reference.** `apply_democratic_mediation`, `get_glossary_term`, `find_quote`, `search_book`. Every return value carries a citation back to the book. ## What's in the catalog Six structured stores, organized around Schneider's central distinction between *governable spaces* and *implicit feudalism*: - **Cases.** Democratic-medium examples Schneider documents — Wikipedia, the fediverse, Loomio, Decidim, the Drupal community, the Ethereum DAO ecosystem, Porto Alegre participatory budgeting. Each entry names its *community* (who participates), the *governance forms* it uses, and concrete *democratic features* with MUST / SHOULD / MUST NOT modal markers drawn directly from Schneider's framing. - **Failure modes.** Recurring counter-democratic patterns (implicit feudalism, politics of no politics, digital colonialism, captured-DAO plutocracy, BDFL dictatorship, affective-voice-without-effective-voice) plus specific historical instances Schneider names (the 2023 Reddit API revolt, Twitter's acquisition). Each has a `kind` discriminator (*pattern* or *instance*) and cross-references the governance forms that counter it. - **Governance forms.** Democratic primitives with diagnostic questions: representational voting, sortition, federated subsidiarity, plural voting (quadratic and weighted), consensus decision-making, modular politics, metagovernance, participatory budgeting, bylaws-based community self-governance. Each lists which failure modes it counters and which cases exemplify it. - **Policy strategies.** Scaled moves that embed democratic design at the policy / regulatory level: governable-stack acts, antitrust as democracy-tech, public-option mandates, platform-cooperative tax incentives, exit-to-community securities reform. - **Glossary.** Schneider's vocabulary, defined as he uses it: *implicit feudalism*, *governable space*, *governable stack*, *modular politics*, *democratic mediation*, *metagovernance*, *politics of no politics*, *digital colonialism*. - **Verbatim quotes.** Source-located passages indexed by theme, with attribution to Schneider built into every response — for citation, framing, or a writer who wants the exact language. Example *democratic feature*, from the Wikipedia entry: "Editors MUST reach consensus or supermajority before major content or policy changes take effect." ## What you can ask The tools chain. Some real shapes: **Diagnosing implicit feudalism.** "Help me write up the 2023 Reddit API revolt as a case study, grounded in real framing." → `start_analysis(situation: "diagnose_feudalism")` → `find_failure_mode(...)` → `suggest_governance_forms(countering_failure_mode_id: "implicit-feudalism")` → `find_quote("implicit feudalism")` for the closing. **Designing a governable space.** "I'm starting a small federated discussion platform for environmental researchers — 200 people across a few institutions. How do I design this as a governable space, not yet another admin-run forum?" → `start_analysis(situation: "design_governable_space")` → `assess_governable_space(...)` → `find_similar_case(...)` → `suggest_governance_forms(...)`. **Naming a pattern.** "I'm seeing reaction-emoji used as a proxy for vote without binding effect. What does Schneider call this?" → `find_failure_mode(signs: ["reaction-emoji as vote"])` → `get_glossary_term(...)` → `find_quote(...)`. ## License Source code: MIT. Embedded book content: **CC BY-NC-SA 4.0** — attribution to Nathan Schneider required, non-commercial only. The book is open access via [Luminos](https://luminosoa.org/books/m/10.1525/luminos.181), UC Press's open imprint. ## Related - [Think Like a Commoner](/think-like-a-commoner) — Bollier's commons framing. Different territory (resource commons + commoning practice) but adjacent move: a structured catalog of cases, design principles, and counter-strategies, with citations. --- --- title: Think Like a Commoner slug: think-like-a-commoner visibility: public domain: Commons canonical: https://bookpower.org/think-like-a-commoner --- # Think Like a Commoner > Bollier's commons framing — turned into 12 tools for naming enclosures, finding precedent commons, walking Ostrom's 8 design principles, and reframing market-mind problems. > > **Practitioner use:** Name an enclosure, assess a commons, or find a precedent grounded in Bollier's frame. ## Source - **Think Like a Commoner: A Short Introduction to the Life of the Commons** — David Bollier (2024). Publisher: New Society Publishers (2nd edition). License: CC BY-NC-SA 4.0. Source: https://thinklikeacommoner.com/second-edition/ ## Artifact - **think-like-a-commoner-mcp** (MCP server) Repository: https://github.com/zhiganov/think-like-a-commoner-mcp Live: https://tlac-book-mcp-production.up.railway.app/mcp ## Why this book Bollier wrote *Think Like a Commoner* as a short, structured introduction to the commons — not the textbook caricature (a resource that gets depleted because it's "free for everyone"), but the working sense the word has carried for centuries: a community of stewards, a body of social protocols, and the wealth they care for together. Bollier walks Elinor Ostrom's eight design principles for self-governing commons, names a working catalog of commoning practices around the world, and gives the moves of enclosure — financialization, commodification, "commons-washing" — explicit names so practitioners can call them out. He treats the commons as a *living social system*, not a resource to be managed. The book is brief, but each chapter is load-bearing. A practitioner drafting a co-op charter, designing a community land trust, or naming an extraction pattern doesn't need to read the whole book on demand. They need Bollier's framing scoped to their question, with the chapter intact. ## What we built `think-like-a-commoner-mcp` — an MCP server that exposes the book's content as 12 callable tools, grouped by job: - **Routing.** `start_analysis` is the branching entry point — it scaffolds an analysis based on what kind of situation you're in (threatened commons, designing a commons, naming an enclosure, just exploring) and points at the next tools to call. `suggest_next_step` keeps the flow going. - **Diagnostic.** `classify_situation`, `find_enclosure_pattern`, `find_precedent_commons`, `list_response_strategies`. - **Design.** `assess_ostrom_principles` (against all eight), `find_similar_commons`, `suggest_commoning_protocols`. - **Reference.** `apply_ontoshift`, `get_glossary_term`, `find_quote`. Every return value carries a citation — chapter, sometimes a verbatim source quote — back to the book. ## What's in the catalog Six structured stores, extracted directly from the book: - **Commons cases.** Living examples Bollier names — from acequia irrigation associations to community land trusts, makerspaces, blood-donation gift economies, language as commons, mesh-network WiFi, Indigenous commitment-pooling traditions, platform cooperatives. Each entry carries the source chapter, the kind of *care-wealth* involved, the community that holds it, and the protocols (in Bollier's MUST / SHOULD framing) the case demonstrates. - **Ostrom's eight design principles.** Each principle has its full description, a set of diagnostic questions, and the example commons that illustrate it (Törbel alpine commons since 1224, Spanish huerta irrigation, Los Angeles groundwater management). - **Enclosure patterns.** Named patterns of dispossession — privatization, financialization of nature, commons-washing, market/state duopoly lock-in, cultural erasure of commons language — paired with the counter-strategies the book proposes. - **Response strategies.** Commoning practices Bollier names: building a parallel polis, vernacular law, commons-based peer production, self-organized resource governance — with the situations they fit and the case examples that ground them. - **Glossary.** Bollier's working vocabulary, defined as he uses it: *commoning*, *commons-washing*, *parallel polis*, *OntoShift*, *vernacular law*, *commonsverse*, *neo-extractivism*, *financialization of nature*. - **Verbatim quotes.** Source-located passages — for citation, framing, or a writer who wants Bollier's exact language. ## What you can ask The tools are designed for chained workflows. Some real shapes: **Naming an enclosure.** "Our city is selling off its public WiFi infrastructure to a telco. Help me write a piece naming what's being lost." → `start_analysis(situation: "naming_enclosure")` → `classify_situation(...)` → `find_enclosure_pattern(...)` → `list_response_strategies(...)` → `find_quote("financialization")` for the closing. **Designing a commons.** "We're drafting a co-op charter for shared agricultural land. What design principles should we install, and what's a working precedent?" → `start_analysis(situation: "designing_commons")` → `assess_ostrom_principles(...)` → `find_similar_commons(...)` → `suggest_commoning_protocols(...)`. **Writing on the commons.** "I need a Bollier passage for a piece on language itself as a commons." → `find_quote("language as commons")` returns the passage with its source location; `get_glossary_term("commoning")` returns Bollier's working definition for the same piece. ## License Source code: MIT. Embedded book content (catalogs, glossary, quotes): **CC BY-NC-SA 4.0** — attribution to David Bollier required, non-commercial only. Read the book free at [thinklikeacommoner.com](https://thinklikeacommoner.com/second-edition/) or order from New Society Publishers. ## Related - [Governable Spaces](/governable-spaces) — Schneider's framing of democratic design for online life. Different territory (digital communities) but adjacent move: a structured catalog of failure modes and counter-forms, with citations. --- --- title: Producing Open Source Software slug: producing-open-source-software visibility: public domain: Open source canonical: https://bookpower.org/producing-open-source-software --- # Producing Open Source Software > Karl Fogel's canonical guide to running open-source projects — turned into a Claude Code skill (claude-audit-oss) that audits OSS repos against Fogel's chapters. > > **Practitioner use:** Audit an open-source repository against Fogel's ten areas of project health. ## Source - **Producing Open Source Software: How to Run a Successful Free Software Project** — Karl Fogel (2023). Publisher: Self-published 2nd ed. (1st ed. O'Reilly, 2005). License: CC BY-SA 4.0. Source: https://producingoss.com/en/index.html ## Artifact - **claude-audit-oss** (Agent skill) Repository: https://github.com/zhiganov/claude-audit-oss ## Why this book Karl Fogel has been writing *Producing Open Source Software* since 2005. The second edition shipped in 2023 and gets minor revisions still. It's the working manual for the technical infrastructure layer, the social and political layer, the legal frame, and the day-to-day practice of leading volunteer contributors. His argument is plain: most open-source projects fail not because of the code but because of the human systems around the code. Communications, response-time culture, project identity, contributor onboarding, license compatibility, governance design — Fogel walks each layer with concrete advice grounded in his years on Subversion. The book is more *checklist-shaped* than *catalog-shaped*: a maintainer reads it cover-to-cover, then refers back to specific chapters when their project is stuck on a specific layer. So we built it as an Agent Skill — invoked by a slash command — that audits a project against Fogel's framework and produces a structured scorecard. ## What we built `claude-audit-oss` — a Claude Code skill, invoked via `/audit-oss `. It reads the project's repo (README, CONTRIBUTING, LICENSE, CI configs, package metadata, issue templates, recent commit history, branch protection) and audits it against Fogel's framework. An optional `--focus ` flag scopes the audit to one of the ten categories below. The output is a scorecard. Each item is marked `[x]` (present), `[~]` (partial), `[ ]` (missing), or `[n/a]` (not applicable), with a brief note on what was found. A *Top Priorities* section at the bottom names the most impactful missing items first. ## What's in the catalog The skill audits ten categories that trace the structure of Fogel's chapters: 1. **Project Identity & Presentation** (`identity`) — name, mission statement, README, demos, "starting from what you have." 2. **Documentation** (`docs`) — user-facing docs, developer docs, examples, availability. 3. **Contributor Experience** (`contributor`) — how-to-report-a-bug page, response-time culture, "treat every user as a potential participant." 4. **Technical Infrastructure** (`infra`) — version control, bug tracker, communication channels, hosting. 5. **Versioning & Releases** (`releases`) — release numbering, semver, branches, stabilization, release manager. 6. **Licensing & Legal** (`legal`) — license choice, application, contributor agreements (CLA vs DCO). 7. **Governance & Decision-Making** (`governance`) — benevolent dictator vs consensus democracy, voting, vetoes, written rules, committers. 8. **Communication & Community** (`communication`) — written culture, tone, handling difficult people, growth, publicity. 9. **Automation & Maintenance** (`automation`) — automated testing, CI, the *automation ratio*. 10. **Project Health Signals** (`health`) — activity, contributor diversity, transitions, forks. ## What you can ask The skill is invoked as a slash command. Some real shapes: **Full audit.** `/audit-oss harmonica-web-app` — reads the repo, scores all ten categories, outputs the scorecard with Top Priorities at the bottom. **Scoped audit.** `/audit-oss harmonica-web-app --focus contributor` — audits only Contributor Experience. Useful when you know a specific layer is the problem and don't want noise from the rest. **Pre-launch readiness check.** `/audit-oss my-new-project --focus identity` — checks that name, mission statement, README, and starting-points are in place before you announce. ## License Source code: MIT. The book itself: **CC BY-SA 4.0** (Karl Fogel). Read it free at [producingoss.com](https://producingoss.com/en/index.html), or order the paperback from O'Reilly (1st ed. 2005). ## Related - [Governable Spaces](/governable-spaces) — Schneider's framing of democratic design overlaps with Fogel's chapter on governance (BDFL vs consensus democracy). The two read as companion volumes for an open-source maintainer thinking through governance transitions. --- --- title: Facilitating Deliberation slug: facilitating-deliberation visibility: private domain: Facilitation canonical: https://bookpower.org/facilitating-deliberation --- # Facilitating Deliberation > A private, book-grounded reference for planning deliberative processes, building sessions, checking readiness, and choosing what to do in the room. > > **Practitioner use:** Plan a deliberative process, check readiness, or shape the next session. ## Source - **Facilitating Deliberation: A Practical Guide** — Kimbra White, Nicole Hunter, and Keith Greaves (2023). Publisher: MosaicLab. License: copyrighted. Source: https://www.mosaiclab.com.au/the-big-book ## Artifact - **facilitating-deliberation-mcp** (MCP server) ## Why this book *Facilitating Deliberation: A Practical Guide* is MosaicLab's working textbook of deliberative-democracy practice, written by directors Kimbra White, Nicole Hunter, and Keith Greaves. The book reads like a handbook for practitioners running structured deliberative processes in the field, not a theoretical text about them. The book is structured around the work itself. It separates the *macro design* of a deliberation (the structural decisions made weeks ahead) from the *micro design* of a single session (the choices made minute to minute in the room). It also treats *readiness assessment* — whether a sponsoring organisation is ready for a genuine deliberative process — as a category of its own. ## What it helps you do - **Plan the whole process.** Work through the macro-design template, readiness assessment, and stage-specific checklists before recruitment begins. - **Build the next session.** Turn the current stage of a deliberation into a run sheet with relevant activities, timing, and facilitation guidance. - **Respond to the room.** Find an activity for the group and context you have, or get next-step guidance when disagreement, low energy, or time pressure changes the plan. The private MCP packages the book's methods into 12 tools covering process design, session design, readiness, activities, principles, checklists, and decision frameworks. ## A question you can bring > “I need to design a three-day citizens' jury on local housing policy for 30 participants. Walk me through the macro-design template and help me fill it in.” For this question, the MCP can bring together the macro-design template, macro-design checklist, and organisational readiness assessment, then help the facilitator work through them in context. ## Why access is private Because the book is copyrighted and the MCP contains substantial structured material from it, we cannot distribute the server publicly. We review access requests individually instead. ## What happens next Send your email and a short description of the process, session, or facilitation challenge you are working on. We will review the request by hand. If access is approved, we will email you with instructions.