Direct answer
Package registries record something GitHub profiles often do not: who has the right to publish a package. On npm, npm owner ls lists the users who can modify a package and publish new versions, and npm has a single access level [S1]. On crates.io, named owners can publish, yank and manage owners, while team owners can publish and yank but cannot change owners [S4]. PyPI exposes project roles; the public JSON for the project we checked listed its collaborators under an "Owner" role [S3].
That makes registries a strong lane for one requirement, sustained maintainership of a library in the hiring stack. Fields like author and maintainer are self-declared package metadata and can be years out of date [S2][S3]. Treat a registry hit as a lead to corroborate on GitHub, a personal site or a conference talk, never as a profile on its own.
Why registries are a different evidence source from GitHub
A GitHub repository shows code and activity. A registry shows distribution: someone chose to publish a package, other projects depend on it, and specific accounts can release new versions. For roles that list "maintains open-source libraries" or "experience shipping SDKs", publish rights on a package in the target stack are closer to the requirement than commit counts. See the GitHub source atlas for the repository side of the same evidence.
It is also a narrower lane. Most working developers have never published a package, so a registry search finds a small, specific population. Use it next to other lanes, not instead of them; the GitHub X-Ray guide and the Google X-Ray guide cover the broader search side.
What each registry records, according to its own documentation
| Registry | Field or listing | What the registry says it means | What it does not prove |
|---|---|---|---|
| npm | npm owner ls <package> | Users with access to modify the package and publish new versions; npm has one access level [S1] | Who wrote the code, or that an owner is still active |
| npm | author and contributors in package.json | "author" is one person and "contributors" is an array of people, as entered by the publisher [S2] | Accuracy or currency; these are self-declared |
| npm | Top-level maintainers | npm sets it with the publisher’s npm user info [S2] | Ongoing maintenance activity |
| PyPI | Project ownership.roles in the JSON API | Collaborator accounts with a role; the project we checked returned "Owner" roles [S3] | Employment or authorship of specific code |
| PyPI | Owner vs Maintainer roles | A 2018 PyPI staff comment describes Maintainers as able to upload releases but not manage collaborators, while Owners can also add collaborators and delete releases [S5] | Current permissions; re-check the current PyPI documentation |
| PyPI | info.author and info.maintainer | Metadata fields supplied with the package [S3] | Who has publish rights today |
| crates.io | Named owner | Can publish, yank, and add or remove owners [S4] | That they wrote the crate |
| crates.io | Team owner (github:org:team) | Can publish and yank but cannot add or remove owners [S4] | Which individuals in the team did the work |
An evidence ladder for maintainership
Rank what you find from strongest to weakest for a requirement such as "has maintained a widely used Python library". Write down which rung you reached.
| Rung | Evidence | Supports | Still needs |
|---|---|---|---|
| 1 | Publish rights plus recent releases under the account, corroborated by matching repository activity | Current, hands-on maintainership | Identity match to the person and their current employer |
| 2 | Publish rights, but no release in a long time | Past maintainership | Whether they still work in this stack |
| 3 | Listed in contributors or repository contributor history only | Some contribution | What they contributed and when |
| 4 | Named in author or maintainer metadata only | Historic self-declared association | Almost everything |
| 5 | Uses the package as a dependency in their own project | Familiarity with the library | Any maintainership at all |
Traps that produce false positives
- Organization and bot accounts. Many popular packages are owned by a foundation, a company account or a release bot. Publish rights then say nothing about a person.
- Transferred or reclaimed names. PyPI has a documented process (PEP 541) for handling abandoned project names, so a current owner may not be the original author [S6].
- Stale metadata.
authorfields are written once and rarely updated. Treat them as historical. - Name collisions. A registry username is not a legal name. Do not merge it with a professional profile without independent links, such as the same personal site or repository on both.
- Popularity is not seniority. Download counts reflect how a package is used, not how hard it was to build or how senior its maintainer is.
A research workflow from requisition to evidence note
- From the requisition, list the libraries and frameworks the team builds on or would want maintained. Ask the hiring manager which packages matter, rather than guessing.
- For each package, check its registry page for owners or roles and its repository for recent maintainers. Note account names only.
- Look one level out: packages in the same ecosystem that solve adjacent problems often have maintainers with the same skills.
- Corroborate identity through links the person published themselves, such as the same personal site on the registry account, GitHub profile and conference bio.
- Write the evidence note: rung reached, dates of the last release you saw, and what is still unknown.
- Only then move to your normal, permitted outreach channels.
Searches like these find package pages, not people. Each result is the start of the workflow above, not a candidate.
Package maintainership evidence log
One row per package and account. It records the rung reached on the evidence ladder and the corroborating links, so identity is never assumed from a username alone. It holds account handles you looked up, not contact details.
Download the CSV worksheet (plain text, opens in any spreadsheet tool; contains no candidate data).
| Column | What to record |
|---|---|
requirement | For example "maintained a production Python library" |
registry | npm, PyPI or crates.io |
package | Package or crate name |
account_handle | Registry username or team, as listed |
role_or_listing | npm owner, PyPI role, crates.io named or team owner, author field, contributor |
last_release_seen | Date of the latest release under that account, if visible |
ladder_rung | 1 to 5 |
corroborating_links | Self-published links that tie the handle to a person |
identity_status | Unconfirmed, corroborated, or confirmed by the person |
checked_on | ISO date |
Related guides
Source ledger
npm statements come from the documentation bundled with npm CLI 10.9.4, read locally. PyPI field names come from a live public API response. The Cargo and PyPI documentation sites could not be opened from the drafting sandbox, so those claims come from search-result summaries and the locally installed `cargo owner --help` (Cargo 1.97.0). A person must re-check the live documentation before publication.
| ID | Source | Claim it supports | Accessed / method | Human re-check |
|---|---|---|---|---|
| S1 | npm Docs: npm-owner (CLI v10) | `npm owner ls` lists users who can modify a package and publish new versions; there is only one level of access | 2026-10-25 · Primary document read locally | Read from the npm 10.9.4 bundled docs; confirm the live page matches |
| S2 | npm Docs: package.json (CLI v10): people fields | "author" is one person and "contributors" is an array of people; npm sets a top-level "maintainers" field with the publisher’s user info | 2026-10-25 · Primary document read locally | Read from the npm 10.9.4 bundled docs; confirm the live page matches |
| S3 | PyPI: JSON API response for a public project (pypi.org/pypi/<project>/json) | The response includes `info.author`, `info.maintainer` and `ownership.roles`; the roles returned for this project were "Owner" | 2026-10-25 · Live public API response observed | Field names only were recorded; confirm against the PyPI JSON API documentation |
| S4 | The Cargo Book: Publishing on crates.io: cargo owner | Named owners can publish, yank and add or remove owners; team owners can publish and yank but not manage owners | 2026-10-25 · WebSearch summary; page not opened | Confirm on the live Cargo Book; local `cargo owner --help` confirmed the add, remove and list options only |
| S5 | pypa/warehouse (GitHub): Issue 4414: collaborator roles discussion | A 2018 PyPI staff comment describing Maintainer versus Owner permissions | 2026-10-25 · WebSearch summary; page not opened | Historic; replace with the current docs.pypi.org roles page if it differs |
| S6 | Python Enhancement Proposals: PEP 541: Package Index name retention | PyPI has a documented process for abandoned or reclaimed project names | 2026-10-25 · WebSearch summary; page not opened | Confirm scope and status of the PEP |