Success indicators
Qualitative signals that tell the maintainer this methodology is working. One operational rule. No specific star, fork, or adoption counts — those go stale, look braggy when exceeded, look bad when missed, and invite gaming.
Early signals (first year)
- At least one externally-authored adoption story exists. A blog post, a forked repo with substantial additions, a Discussions thread saying “I tried this on project X and Y happened.” Stars are bookmarks; stories are use.
- The methodology survives non-author use. Someone other than the maintainer applies it to a project the maintainer didn’t write. Specific feedback comes back.
- Forks have commits. Substantive additions, not just bookmarks. That’s what proves the methodology is generative.
- The self-development cycle ships methodology improvements. Real releases attributed to cycle output, not just internal cleanup. Without this, the “self-improving” claim is theoretical.
Sustained signals (multi-year)
- Appears in field discussions on its own merit. Comes up because it offers something specific. Counting mentions invites gaming; appearance at all is the signal.
- Public sustained use. At least one team or company publicly uses it as their internal standard and is still using it 12+ months later. Public + sustained beats either alone.
- Maintained forks for specific niches (regulated industries, research teams, specific stacks). CC BY 4.0 enables forking; maintained variants prove the methodology is worth maintaining a fork of.
- Patterns adopted by other methodologies in the field. Generative beyond this project. The strongest possible signal of methodology quality.
What success is NOT
- Revenue. CC BY 4.0; no monetization. Commercial activity around the methodology is downstream of the open source, not the methodology’s success.
- Star counts above some target. A small adoption base that uses the methodology beats a large bookmark base that doesn’t.
- Release frequency. Quality and coherence > cadence. Bursts of releases (like the 2026-05-25 cluster) happen; they’re not the target.
- Personal recognition for the maintainer. The methodology should outlive any one person’s attention.
- Followers / subscribers / newsletter signups. Marketing-flavored. Not channels this methodology has, or needs.
- Volume of features or sections shipped. Adding more pages is not value.
Counter-signals — when things are failing, not succeeding
- Stars climb but adoption stories don’t. People bookmark, don’t use.
- Forks appear but never get commits. People fork to try, then abandon.
- Issues asking “how do I do basic X?” The docs aren’t clear.
- Maintenance load grows unsustainable. The lean-maintainer model is breaking.
- Methodology releases stop happening. The cycle stalled.
- External contributions arrive and get bounced back repeatedly. The contribution surface isn’t clear.
The one operational rule
Maintaining this should not feel like a second job. If it does, something in the methodology or the maintenance posture has to change. Specific time budget is private — it’s the maintainer’s time. This is the qualitative rule that other docs cite (P8 — Maintenance sustainability; strategy plan exit criteria).
Leading indicator: cycle health
The self-development cycle’s health is the leading indicator for every signal above.
- Healthy cycle → methodology improves at loop velocity → adopters experience an improving artifact → stories, forks, sustained use follow.
- Stalled cycle → static methodology → adoption plateaus → everything else slows.
If the other signals slow, check the cycle first.
Review cadence
- Quarterly — scan signals + counter-signals; investigate drift.
- Semi-annually — tied to the methodology self-evaluation pass; includes “are these still the right indicators?”
- Annually — review trajectory; restate qualitative targets if context has shifted.