About

This site is in ALPHA. The exact semantics of the maintainer graphs, and the amount and kind of details shown, are still being figured out.

Cargo

Library and binary crates in the Rust ecosystem are (almost) exclusively published on crates.io. New versions of crates may be published by their owners, which are either user accounts (which usually but not always map to individuals), or GitHub teams (with opaque membership). Most crates only have user accounts as owners, while those that have GitHub teams usually only have a single team (in addition to the user accounts). There are two main exceptions:

• The rust-lang:libs and rust-lang-nursery:libs teams. These teams commonly appear as crate owners alongside other rust-lang teams, while also appearing on their own. We interpret the libs teams as being the general catch-all for rust-lang when there isn't a more specific maintainer team.
• "Bus factor" user accounts and GitHub teams. These are run by members of the community who make themselves available as backup maintainers, able to publish in the event that the primary maintainers become unavailable.

We use the following strategy to select the set of maintainers for each crate:

1. Filter out the rust-lang:libs, rust-lang-nursery:libs, and "bus factor" teams and users from the crate's owners.
2. Select as maintainers the first non-empty set out of:
   1. Any non-filtered teams.
   2. The rust-lang:libs team.
   3. The rust-lang-nursery:libs team.
   4. Any non-filtered users.
   5. The "bus factor" teams and users.
3. Merge GitHub teams from the same GitHub Organization (because team membership is always controlled by the organization).

Go

Go uses a decentralized system for publishing modules. The canonical locations for published modules are their respective source repositories; these are then indexed by pkg.go.dev for discoverability, and cached by proxy.golang.org for performance. As such, we need to inspect the individual repositories to figure out the maintainer information. For now, we leverage the fact that publicly-reachable Go modules have a domain name as the first component of their module path, and treat that domain as synonymous with maintainership.

We use the following strategy to select the maintainer for each module:

1. If the module path starts with github.com or gitlab.com, parse the module path as DOMAIN/USER/PATH and treat DOMAIN/USER as the maintainer.
2. If the module path starts with gopkg.in/USER/, parse the module path as gopkg.in/USER/PKG.v* and treat github.com/USER as the maintainer.
3. If the module path starts with gopkg.in, parse the module path as gopkg.in/PKG.v* and treat github.com/go-PKG as the maintainer.
4. Otherwise, parse the module path as DOMAIN/PATH and treat DOMAIN as the maintainer.

Gradle

The Gradle build system is primarily used for Java-based projects. There are several common dependency hosting locations (like Maven Central), but Gradle can be configured to fetch dependencies from anywhere. We use the Gradle Tooling API to extract the dependencies (currently using the tooling models for IntelliJ IDEA, which do not preserve the dependency tree).

We use the following strategy to select the maintainer for each dependency:

1. Obtain the list of GROUP:NAME:VERSION dependencies from Gradle.
2. Parse GROUP as reverse domain name notation, and attempt to resolve it (or any parent of at least two labels) as a domain name.
3. If a resolvable domain name is found, that is treated as the maintainer, and UNUSED_LABELS:NAME is treated as the package name.
4. Otherwise, GROUP is treated as the maintainer, and NAME is treated as the package name.

npm

Packages in the npm registry can be published by user accounts. It is common to see either one or two users with publish permission, or a long list of users; the latter normally corresponds to a package published by an organization. Some user accounts correspond to bots or are otherwise organization-controlled, but the registry API treats them all as humans, so we cannot distinguish them with that dataset alone. Some packages include a repository URL in their package.json file that can be used to infer further information.

We use the following strategy to select the set of maintainers for each package:

1. Query the npm registry for the latest version of the package.
2. If the package has a repository field with a GitHub URL, and that repository is owned by a GitHub Organization, treat that organization as the maintainer.
3. Otherwise, treat the maintainers field (the list of npm users with permission to write to the package) as the maintainers.