Maintainers
Maintainers and continuity
The honest answer to the question a procurement review asks: what happens if the person who can ship a fix is unavailable?
Roster
| Person | GitHub | Contact | Role |
|---|---|---|---|
| Joel Parker Henderson | @joelparkerhenderson | joel@joelparkerhenderson.com | Maintainer (sole) |
The bus factor of this project is one. There is exactly one person who can
accept a pull request or change a repository setting. Publishing a release is similar but not
identical: the maintainer alone still decides whether a crate releases at all
— scoping and naming a release is his, unconditionally — but as of 2026-09-02 he
may direct an AI coding agent to judge whether an already-scoped release is ready and run cargo publish for it. No second maintainer exists, no organisation stands behind
the project, and no legal entity is a party to it. Nothing elsewhere in the repository should
be read as softening that sentence.
What is not here yet
Named rather than quietly omitted, because absence is itself information:
- No signing key escrow, and no second holder for it. Commits and tags are cryptographically signed, and GitHub’s “Verified” badge is live — but the signing key sits with one person, on one machine, the same single point of failure the bus-factor callout above already names.
- No second security responder. The security policy terminates at one email address, which is why it tells a reporter to disclose publicly after ninety days whether or not a fix exists.
- No release cadence commitment. Releases happen when there is something to release.
If the maintainer is unavailable
Everything already published stays published: released versions on crates.io are immutable, and the git history, the specifications, and this site’s source stay public. But nothing new ships — no releases, no security fixes, no answers to issues.
Forking is legitimate continuity. If you depend on this software in a clinical setting and a bus factor of one is not acceptable — and it is entirely reasonable for it not to be — the mitigation is on your side: pin an exact version, keep a fork you can build from source, and budget for maintaining it. The crates are built to make that cheap: near-zero dependencies, and every behaviour a numbered rule with a test bound to it, so a fork inherits a readable, testable artefact rather than an archaeology project.
The canonical document is MAINTAINERS.md at the repository root; this page is a summary of it, and the full version includes the publishing-identity inventory — every credential that can put bytes in front of a user, and where each one terminates.