Good Enough for a Stranger
The question people ask when a project goes quiet is usually "why did the author stop?" Wrong question. The author always stops eventually. The question is whether what they left can survive without them.
Maintenance intent gets substantial attention in open source discussions. Projects list it in their READMEs. Package registries are starting to surface it as formal metadata. Knowing a project is "actively maintained" seems relevant to deciding whether to depend on it. Fair enough. But it optimizes for the wrong variable.
A committed author with opaque code is a project with a longer runway to abandonment. When they leave, for any of the hundred reasons people do, what remains is still illegible. Nobody steps in. The project decays.
What determines survival is whether a stranger can enter the codebase without the author present.
What legibility means
A project is legible when someone who didn't write it can clone the repo, build it, understand why the major decisions were made, and submit a fix without having to ask anyone. Every gap in that chain is a place where the project depends on the author being reachable.
The components are specific: a README that says why the project exists, a build that works from a clean checkout, tests that describe expected behavior, commit messages that record reasoning, and code structure clear enough that a stranger can find what needs to change. Not glamorous. Also not what most authors write while they're deep in building something.
They carry context in their head and don't feel its absence. The hard part isn't producing documentation; it's anticipating questions the author doesn't have. You know why the config is structured the way it is. You know which flags are vestigial and which are critical. You know the tests need an environment variable that got set on your machine years ago and never made it into the setup guide. None of that absence is visible from inside.
The failure mode looks like this: a project that works well, does something real, and goes quiet after the author moves on. Interest exists; there's no way to act on it. Someone shows up, clones the repo, can't get the build running, asks in issues, gets silence. They leave. The code is still there. The project stopped accumulating contributors, which is functionally death.
Projects that survive author departure share specific properties: build instructions that work, tests that catch breakage, code clear enough that a newcomer can reason about the system. The author may have left suddenly or gradually. The project's structure made re-entry possible either way.
The author is always temporary
This is arithmetic. People have finite attention. Even projects with active stewardship eventually pass to someone else, or don't. The structural question is whether the artifact can outlast any individual author.
Stating intent to maintain a project is a signal about the next few months. Legible code is a structural property that doesn't degrade with the author's attention.
Writing for a future stranger also helps the author. Return to a project after six months and the context you carried is gone. A codebase written without that context assumption is one you can re-enter yourself. The stranger you're writing for is often you, later.
Maintenance intent as a formal registry field is downstream of the real problem. The signal that matters is whether someone can step in if the author doesn't. That's not declarable. It's either visible in the artifact or it isn't.