A skill for designing open infrastructure that makes paywalls and artificial scarcity obsolete.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add sethmblack/paks-skills --skill commons-building --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Commons Building?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/sethmblack-commons-building)More formats (shields.io, HTML) on the badges page.
---
name: commons-building
description: A skill for designing open infrastructure that makes paywalls and artificial scarcity obsolete.
license: MIT
metadata:
author: sethmblack
version: 1.0.3630
repository: https://github.com/sethmblack/paks-skills
keywords:
- commons-building
- structure
- writing
---
# Commons Building
A skill for designing open infrastructure that makes paywalls and artificial scarcity obsolete.
## When to Use
- When fighting enclosure is less effective than building alternatives
- When the commons needs infrastructure to function
- When network effects could serve openness instead of lock-in
- When you have resources to build, not just critique
## Inputs
| Input | Required | Description |
|-------|----------|-------------|
| input_data | Yes | The primary data or content to analyze |
| context | No | Additional background or constraints (default: none) |
| output_format | No | Preferred format for results (default: structured markdown) |
## Workflow
### Step 1: Phase 1: Define the Commons
Clarify what will be shared:
- What resource will be available to all?
- What rights do users have? (Use, modification, redistribution)
- What is explicitly not enclosed? (Data, content, code, infrastructure)
- What are the boundaries of this commons?
Clear definition prevents later enclosure.
### Step 2: Phase 2: Design for Openness
Build with openness in the architecture:
- Open source code
- Open standards and protocols
- Open data formats
- Federated or decentralized structure where possible
- APIs that enable interoperability
Avoid dependencies on proprietary systems or single points of control.
### Step 3: Phase 3: Plan Sustainability
The commons must persist:
- How is development funded? (Grants, donations, membership, services)
- How is hosting/infrastructure funded?
- Who maintains it, and with what incentives?
- How does it survive the loss of any individual?
Commons that depend on unsustainable labor collapse.
### Step 4: Phase 4: Build Community
The commons is tended by its users:
- How do people find this?
- How do they contribute?
- How are decisions made?
- How are conflicts resolved?
- What governance prevents capture?
Technical infrastructure without community is empty.
### Step 5: Phase 5: Compete on Features
Make the open option better:
- Identify where proprietary systems fail users
- Build features that enclosure prevents
- User experience should not require sacrifice
- "Almost as good but free" loses to "better and free"
People use what works.
## Outputs
A commons-building plan including:
1. Definition of the commons and what it provides
2. Technical architecture supporting openness
3. Sustainability model with realistic numbers
4. Community development strategy
5. Competitive advantages over enclosed alternatives
6. Governance structure preventing capture
## Constraints
- Sustainability is not optional - unfunded commons die
- Governance matters - ungoverned commons get captured
- Users need reasons beyond ideology to switch
- Network effects are hard to overcome - plan accordingly
- Some enclosure funds valuable work - acknowledge tradeoffs
## Anti-Patterns to Avoid
| Anti-Pattern | Why It Fails | Instead Do |
|--------------|--------------|------------|
| **Build it and they will come** | Commons without community is empty infrastructure | Design community and governance alongside technical architecture |
| **Unsustainable heroism** | Relying on volunteer burnout kills commons | Build explicit funding and maintenance models from the start |
| **Ideological purity over usability** | "Almost as good but free" loses to proprietary options | Compete on features; make the open option genuinely better |
| **Governance neglect** | Ungoverned commons get captured by well-funded interests | Establish explicit governance and anti-capture provisions |
| **Ignoring network effects** | Assuming quality alone overcomes switching costs | Plan specifically for how users will migrate from enclosure |
---
## Example 1: Academic Journal Commons
**Input**: Build commons alternative to proprietary academic journal system
**Output**:
"Commons: Open access journal platform with author-side APC-free model. Defined: All published research immediately available under CC-BY. Code, infrastructure, and governance all open. Architecture: Federated platform - universities and learned societies host their own instances, interoperable through shared protocol. No single point of control. Sustainability: Funding consortium of university libraries redirecting subscription funds. Estimated cost $300/article vs current $3,000 average. Libraries already spending the money - this redirects it. Community: Editorial boards recruited from researchers frustrated with current system. Overlay journals for low-cost disciplinary organizing. Peer review tracking and credit. Competitive advantages: No embargo, author retains rights, transparent peer review, better discoverability, actually fulfills funders' mandates. Governance: Elected board from member institutions, published decision-making processes, explicit anti-capture provisions in charter."
## Integration
Works with:
- **open-access-audit**: Audit reveals what commons is needed
- **systemic-analysis**: Understanding enclosure helps design alternatives
- **technical-civil-disobedience**: Bridges period until commons is builtIs this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!