Open source maintainers spend a disproportionate amount of their limited time re-explaining decisions that were already made once — usually because the reasoning lived in a closed PR discussion, a Discord thread, or a maintainer's memory, rather than anywhere a new contributor could actually find it.
Approved specs as contributor-facing documentation, for free
A spec folder with an approved requirements.md or implementation_plan.md is, incidentally, exactly the artifact a new contributor needs before touching a subsystem: what it's for, what was explicitly decided against (the non-goals), and why. You didn't write it for onboarding purposes — you wrote it because the workflow produces it as a side effect of building the feature at all. That it also answers "why does this work this way" for the next contributor is a bonus you get without extra effort.
Investigation findings as a searchable bug history
A project with a real ./investigations/ history — root causes cited to file and line, not just closed-issue comments saying "fixed in #4021" — gives future contributors (and future you) something to actually search when a similar-looking bug shows up again. "Wait, didn't we already dig into something like this" becomes answerable in a search instead of a guess.
The tier decision as a contribution-scoping tool
New contributors chronically misjudge scope — either timidly proposing a tiny fix for something that's actually architecturally significant, or confidently opening a sprawling PR for something that should have been small. Having the tier decision made explicitly and visibly for existing work gives new contributors a calibration reference: here's what this project considers light versus full tier, and why, in its own words, on real past examples.
Why this matters more for volunteer-maintained projects specifically
Commercial teams can absorb some tribal-knowledge loss because turnover is gradual and usually overlaps. Open source projects lose maintainers abruptly and often completely, with no handoff period at all. A project whose key decisions live in approved, linked spec documents survives a maintainer's departure in a way a project whose decisions live only in that maintainer's head does not.
If you maintain — or are trying to grow — an open source project, the spec trail isn't overhead on top of the "real" work. For a volunteer project, it might be the single highest-leverage thing standing between the project and becoming unmaintainable the day you get busy for a month.