FCC for Open-Source Maintainers¶
Welcome to the track for open-source maintainers. This is written for people who run their own OSS projects — large or small, solo or team — and want to adopt some of FCC's patterns for their own governance, docs, and persona-based contribution workflows.
FCC is itself an open-source project (MIT license, public on GitHub). It has a few patterns that translate well beyond AI workflows: the R.I.S.C.E.A.R. specification as a general contributor-role template; docs-as-code with auto-generated cross-references; release-cadence rhythm from the v1.0 → v1.7 arc; sister-project coordination without merging codebases.
What you will learn¶
- How to adapt R.I.S.C.E.A.R. as a contributor-role specification for your project.
- A docs-as-code setup adapted from FCC's Jinja2 + cross-reference pattern.
- A contributor-ceremony pattern that scales from solo to multi-maintainer.
- Release-cadence lessons learned across FCC's 20+ releases.
How this track is organized¶
| Page | Focus | Effort |
|---|---|---|
| Getting Started | Orientation; adapt nothing yet | 20 min |
| Adopting R.I.S.C.E.A.R. | Contributor-role spec for your project | 1-2 hours to draft |
| Docs-as-Code Patterns | Build a docs pipeline from FCC's | 3-4 hours |
| Contributor Ceremony | Onboarding, review, release rituals | 1-2 hours |
| Release Cadence Lessons | What FCC learned the hard way | reading |
| Further Reading | ADRs, references, tools | reference |
Prerequisites¶
- You run or help run an open-source project. Doesn't matter the language.
- You have some experience with Markdown, YAML, and at least one template engine (Jinja, Handlebars, Liquid, etc.).
- You use Git and GitHub (or a similar forge).
You do not need to be using FCC itself. This track is about adopting patterns from FCC.
Why bother?¶
Three reasons open-source maintainers tend to benefit from these patterns:
- R.I.S.C.E.A.R. is a remarkable role-description format. It makes implicit expectations explicit. Adapting it to define contributor roles ("Bug-triager," "Docs reviewer," "Release manager") tends to reduce onboarding time measurably.
- Auto-generated cross-references. FCC generates 56 doc files per persona with automatic cross-reference. A similar pattern applied to modules, packages, or APIs reduces drift between the code and the docs.
- Release hygiene. The FCC 1.x series (roughly monthly releases for two years) has surfaced patterns worth stealing: how to version, when to branch, when to patch, and how to document.
Cost of adoption¶
Honest accounting:
- A couple of hours to read this track.
- A day to draft your own role specs (adapted R.I.S.C.E.A.R.).
- A day or two to set up a docs-as-code pipeline if you don't have one already.
- Ongoing discipline to actually use what you built. The patterns pay off only if you use them.
What FCC is, in one paragraph (so you can orient non-AI patterns)¶
FCC is a Python framework for structured multi-agent AI workflows. Each "agent role" is defined in a ten-field YAML spec called R.I.S.C.E.A.R. Runs produce machine-readable traces. The code is under src/fcc/, docs under docs/, data (YAML personas, JSON schemas, workflows) under src/fcc/data/. It has 20+ releases, a plugin system, multiple sister projects, and ten constellation-vertical repos maintained by the same group.
You do not need to understand the AI parts to benefit from the documentation and governance patterns.
Non-AI projects that have adopted similar patterns¶
Three anonymized sketches:
- A Rust library maintainer adapted R.I.S.C.E.A.R. to describe module ownership. Each module has a YAML file with
role,constraints,responsibilities, androle_collaborators(other modules). CI enforces that every constraint in each module's YAML has a matching test. - A docs-site maintainer built a 3-template docs-as-code pipeline modelled on FCC's 23-template system. Reduced time to add a new doc page from "45 minutes" to "5 minutes."
- A small nonprofit OSS adopted FCC-style ADRs for their decisions. After six months, new contributors cited the ADRs as their single most useful onboarding material.
What not to adopt¶
Not every FCC pattern generalizes:
- 164 personas is a domain-specific number. Do not port it literally.
- The compliance framework is specific to AI regulation.
- The workflow graphs are specific to the Find/Create/Critique cycle.
- The plugin system is useful only if your project has a genuine extension surface.
Copy patterns; do not cargo-cult them.
Where next¶
If you are unsure whether this is worth your time, go to Getting Started for a shorter orientation. If you know you want to try, start with Adopting R.I.S.C.E.A.R. — it is the pattern with the highest return for most projects.
Related reading in this repo: ADR-0001 Plugin System, ADR-0002 Persona Schema.