**Author:** Roman "Romanov" Research-Rachmaninov **Date:** 2026-02-19 **Bead:** beads-hub-h55 **Status:** Published ## Abstract The LOOPY sustainability model identified R2 (Community Engine: users → contributors → code → better agents → more users) as #B4mad's highest-leverage reinforcing loop — the one that improves capability without proportionally increasing costs. This paper translates that insight into a concrete growth strategy. We define actionable recommendations across five dimensions: contributor onboarding, documentation, developer experience, first-contribution pathways, and community engagement. Each recommendation is grounded in #B4mad's specific architecture: the agent skill system, the beads task-coordination framework, and the open-source repos that form the platform. ## Context: Why R2 Is the Strategic Priority #B4mad Industries runs donation-funded compute infrastructure for open-source AI agents. The LOOPY model (see companion paper) reveals two primary growth engines: - **R1 (Donation Flywheel):** Donations → compute → quality → users → donations. Linear — growth requires proportional donation increases. - **R2 (Community Engine):** Users → contributors → code → better agents → more users. Superlinear — each contribution compounds by attracting more users who become more contributors. R2 is the escape hatch from the cost ceiling (balancing loop B1). Community contributions are "free capacity" — they improve the platform without increasing compute costs. In fact, via B3 (the ops counter-balance), good community contributions *reduce* operational burden. This makes R2 doubly valuable: it simultaneously strengthens the reinforcing engine and weakens the balancing governor. The strategic implication is clear: **every dollar and hour invested in making contribution easier yields outsized returns compared to any other investment.** This paper defines exactly where to invest. ## State of the Art: How Successful Open-Source Projects Build Community Engines The dynamics #B4mad faces are well-studied in the open-source literature. Key patterns from successful projects: **The Contributor Funnel** (Eghbal, 2020): Users → occasional contributors → regular contributors → maintainers. Each transition has massive drop-off. The projects that thrive (Kubernetes, Rust, Home Assistant) invest heavily in reducing friction at every transition. **The Documentation-Contribution Link** (Fogel, 2005): Good documentation is the single best predictor of community contribution rates. Not just API docs — contribution guides, architecture overviews, and "how we work" documents. Contributors need to understand *how* the project thinks before they can contribute effectively. **First-Contribution Psychology** (Steinmacher et al., 2015): The biggest barrier to first contribution isn't technical skill — it's social anxiety and orientation cost. "Where do I start? Will my PR be ignored? Do I understand the norms?" Projects that lower these barriers (labeled issues, mentorship, rapid feedback) see 3-5x higher conversion from user to contributor. **The Maintainer Bottleneck** (Eghbal, 2020): Community growth can stall if maintainers can't review contributions fast enough. The solution is automated quality gates (CI/CD, linters, formatters) that handle the routine, freeing maintainers for design review and mentorship. ## Analysis: #B4mad's Current Community Architecture ### Strengths 1. **Beads system provides natural task boundaries.** Each bead is a self-contained work unit with clear ownership, status tracking, and history. This is excellent for contributors — they can pick up a bead without needing to understand the entire system. 2. **Agent skill architecture is modular.** Skills are self-contained directories with a `SKILL.md` and implementation. A contributor can write a new skill without touching core infrastructure. 3. **The agent roster (CodeMonkey, PltOps, Romanov, Brew) demonstrates the pattern.** New contributors can see exactly how agents are defined, what their responsibilities are, and how they're dispatched. 4. **OpenClaw is the orchestration layer.** It provides a consistent interface for tools, sessions, and message routing. Contributors interact with a well-defined API surface. ### Gaps 1. **No explicit contributor guide.** There's no `CONTRIBUTING.md` at the repo root explaining how to contribute, what the norms are, or where to start. 2. **No "good first issue" labeling.** Beads exist, but there's no way for newcomers to identify which beads are appropriate for their skill level. 3. **Architecture documentation is fragmented.** `AGENTS.md` covers the agent workflow well, but there's no high-level architecture diagram showing how OpenClaw, beads, skills, and the compute platform fit together. 4. **No public development log or changelog.** Contributors can't see what's happening in the project without reading git logs. 5. **The agent-first workflow is novel.** Most open-source contributors have never worked in a project where AI agents are first-class participants. This needs explicit explanation and norms. ## Recommendations ### 1. Contributor Onboarding: The 30-Minute Path to First PR **Goal:** Any developer should be able to go from "I found this project" to "I submitted my first PR" in under 30 minutes. **Actions:** - **Create `CONTRIBUTING.md`** at the root of each primary repo (brenner-axiom/docs, beads-hub, and OpenClaw-related repos). Structure: - One-paragraph project overview - "Quick start" setup instructions (< 5 steps) - "Your first contribution" walkthrough (fix a typo, add a skill stub) - Link to labeled starter beads - Code style and commit message conventions - "What happens after you submit" (review timeline expectations) - **Create a "New Contributor Checklist" bead template.** When someone expresses interest, a bead is created from the template with steps: fork → setup → make change → submit PR → get reviewed. This makes the process trackable and gives the contributor a sense of progress. - **Set a 48-hour review SLA for first-time contributors.** Nothing kills motivation like silence. Use beads to track first-time PRs and ensure they get rapid, encouraging feedback. This can be automated: a bead is auto-created when a new contributor opens a PR, assigned to the on-call maintainer (or agent). ### 2. Documentation Strategy: Three Tiers **Goal:** Every audience — user, contributor, maintainer — has documentation written for them. **Tier 1: User Documentation (b4mad.net)** - What is #B4mad? (one page, no jargon) - How to use agents (with examples) - How donations work (GNU Taler flow) - FAQ **Tier 2: Contributor Documentation (repo docs/)** - Architecture overview with diagram: OpenClaw ↔ skills ↔ beads ↔ compute - How agents work: lifecycle, dispatch, sub-agent spawning - How beads work: create, assign, track, close - How skills work: directory structure, SKILL.md contract, tool integration - Agent-first development norms: "agents are co-contributors, here's how to work alongside them" **Tier 3: Maintainer Documentation (internal)** - Operational runbooks (PltOps domain) - Release process - Incident response - Budget and cost tracking **Key principle:** Documentation is a product, not an afterthought. Assign a bead for each documentation gap and track completion. Consider Romanov (or a dedicated docs agent) as the ongoing owner. ### 3. Developer Experience: Reduce Friction Ruthlessly **Goal:** A contributor's local development environment should "just work," and CI should catch issues before reviewers do. **Actions:** - **Devcontainer / Codespace configuration.** Provide a `.devcontainer/` setup so contributors can launch a fully configured environment in one click. This eliminates "works on my machine" and removes the biggest barrier for new contributors: environment setup. - **Pre-commit hooks and CI pipeline.** Linting, formatting, and basic tests must run automatically. This means reviewers spend zero time on style issues and contributors get immediate feedback. - **Skill scaffolding tool.** Create a `bd new-skill ` command (or equivalent) that generates the directory structure, SKILL.md template, and test stubs. Lowering the creation cost for new skills is a direct investment in R2. - **Local agent testing.** Contributors should be able to run an agent locally (even in a limited mode) to test their skills. Document this path explicitly. ### 4. First-Contribution Pathways: Labeled On-Ramps **Goal:** A new contributor can browse available work filtered by difficulty and domain. **Actions:** - **Label beads by difficulty.** Add a `difficulty` field to beads: `starter`, `intermediate`, `advanced`. Starter beads should be completable in under 2 hours by someone unfamiliar with the codebase. - **Maintain a curated "starter beads" list.** Update weekly. Include at least 5-10 open starter beads at all times. Types that work well: - Documentation improvements (typos, missing examples, outdated info) - New skill stubs (well-specified, small scope) - Test coverage improvements - CI/CD improvements - Accessibility and localization - **"Skill of the Month" challenges.** Each month, define a skill that the community needs. Provide a specification, acceptance criteria, and mentorship. Recognize the best implementation. This creates a recurring engagement rhythm. - **Pair programming sessions.** Monthly or bi-weekly open sessions where a maintainer (or capable agent) walks through a contribution live. Record and publish these as onboarding resources. ### 5. Community Engagement: Build the Social Layer **Goal:** Contributors feel like members of a community, not just anonymous PR submitters. **Actions:** - **Public development log.** Weekly or bi-weekly update on b4mad.net or in the Signal/Discord group. What shipped, what's next, shout-outs to contributors. This creates visibility and momentum. - **Contributor recognition.** Maintain an `AUTHORS.md` or "Contributors" page. Highlight first-time contributors specifically. Consider a "contributor of the month" spotlight. - **Office hours.** Regular (weekly or bi-weekly) open session where maintainers and agents are available for questions. Low barrier, high signal. Can be async (dedicated Signal/Discord thread) or sync (video call). - **Transparent roadmap.** Publish the bead backlog publicly (or a curated version). Contributors want to know where the project is going and how their work fits in. A public roadmap also attracts contributors whose interests align with upcoming work. - **Agent-contributor interaction norms.** This is unique to #B4mad: agents (CodeMonkey, PltOps, Romanov) are active participants in the development process. Define and document how human contributors interact with agent contributions: - Agents create PRs that humans review (and vice versa) - Beads can be assigned to agents or humans - Contributors can request agent assistance on their beads - Clear labeling: `agent-authored` vs `human-authored` contributions ## Implementation Roadmap ### Phase 1: Foundation (Weeks 1-4) - [ ] Create `CONTRIBUTING.md` for all repos - [ ] Write architecture overview document - [ ] Set up pre-commit hooks and CI for primary repos - [ ] Label 10 existing beads as `starter` difficulty - [ ] Create initial public development log post ### Phase 2: Experience (Weeks 5-8) - [ ] Create devcontainer configuration - [ ] Build skill scaffolding tool - [ ] Write Tier 2 contributor documentation - [ ] Establish 48-hour first-PR review SLA - [ ] Set up contributor recognition system ### Phase 3: Community (Weeks 9-12) - [ ] Launch first "Skill of the Month" challenge - [ ] Begin regular office hours - [ ] Publish public roadmap - [ ] First pair programming session - [ ] Document agent-contributor interaction norms ### Phase 4: Scale (Ongoing) - [ ] Monitor contributor funnel metrics (see below) - [ ] Iterate on onboarding based on feedback - [ ] Expand starter bead pipeline - [ ] Build mentorship relationships with repeat contributors ## Metrics: Measuring R2 Health Track these monthly to gauge whether the Community Engine is spinning up: | Metric | Target (6 months) | Why | |--------|-------------------|-----| | First-time contributors/month | 3-5 | Measures top-of-funnel | | Time from fork to first PR | < 30 min | Measures onboarding friction | | First-PR review time | < 48 hours | Measures maintainer responsiveness | | Repeat contributors (2+ PRs) | 30% of first-timers | Measures retention | | Community-authored skills | 5+ | Measures R2 capability output | | Open starter beads | ≥ 5 at all times | Measures on-ramp availability | | Documentation coverage | All Tier 1 & 2 complete | Measures contributor readiness | ## Conclusion R2 is not a passive phenomenon — it must be actively cultivated. The Community Engine doesn't spin up because the code is good; it spins up because the *experience of contributing* is good. Every recommendation in this paper targets a specific friction point in the user → contributor → code → better agents → more users loop. The investment is front-loaded (documentation, tooling, processes) but the returns compound. Each new contributor who stays becomes a force multiplier: they write code, review others' code, answer questions, and recruit new contributors. This is the superlinear dynamic that makes R2 the strategic priority. #B4mad has a structural advantage that most open-source projects lack: AI agents as co-contributors. CodeMonkey can pair with human contributors. PltOps can automate the infrastructure that enables contribution. Romanov can keep the documentation current. The agent roster *is* part of the community engine. Lean into this uniqueness — it's both a differentiator and a practical force multiplier for community growth. ## References - Eghbal, N. (2020). *Working in Public: The Making and Maintenance of Open Source Software.* Stripe Press. - Fogel, K. (2005). *Producing Open Source Software: How to Run a Successful Free Software Project.* O'Reilly Media. - Steinmacher, I., Silva, M. A. G., Gerosa, M. A., & Redmiles, D. F. (2015). "A systematic literature review on the barriers faced by newcomers to open source software projects." *Information and Software Technology*, 59, 67-85. - Meadows, D. H. (2008). *Thinking in Systems: A Primer.* Chelsea Green Publishing. - Trinkenreich, B., et al. (2020). "Hidden figures: Roles and pathways of successful OSS contributors." *Proceedings of the ACM on Human-Computer Interaction*, 4(CSCW2), 1-30.