From Package Name to Account List: Who Runs Your Library

This is the method for turning one package name into a company-level account list: a deduplicated, ranked set of firms that run your open-source library in production, each resolved to a real employer and tagged with how deeply they depend on you. It is for engineering managers, technical founders, DevRel leads, and technical sourcers who need to hand DevRel or sales something better than a raw GitHub tab. The top search results stop at the Dependents tab and download counts. This guide covers the resolve-repo-to-employer and dedupe-and-rank steps those results skip.

The job splits into two halves. The first half is evidence: which public repos actually depend on you, and how deeply. The second half is resolution: which company sits behind each repo, and how to collapse many repos to one account. Both halves are bounded by GitHub's own gaps, not by your effort, so a large part of this document is about what you cannot see and how to say so honestly.

Why the raw Dependents tab is not an account list

The GitHub Dependents view is a repo list, not a company list, and it silently omits large classes of adopter. It is built by parsing manifest and lock files, and it only covers public repositories. GitHub Enterprise Server does not calculate dependents at all. So the private-heavy adopters you most want, the banks and defence contractors, are structurally invisible and can only be inferred from the employers behind your committers.

Three more properties make the tab a starting point rather than an answer. There is no official API for the dependents or "Used by" count; GitHub does not expose it through REST or GraphQL, and scraping the network/dependents page is the only route. The "Used by" home-page badge reflects a single package chosen from the repo, admin-selectable when a repo ships several packages, so a multi-package project undercounts itself. And the list is a flat set of repo names with no owner, no employer, and no notion of whether the code ever ran.

That asymmetry matters for how you use the deliverable. Refolk's index lists 351 people with Developer Advocate or DevRel Engineer titles in the US, top employer Google, against 58 equivalent people in the UK, again led by Google. A US DevRel org can work a hundred accounts in parallel; a UK team of a handful cannot, so pace and prune the same list differently by geography.

What each public signal actually proves

Four public signals confirm usage, and each proves something different. Ranking companies later depends on knowing which signal you have, because a package declared in a manifest is a world away from one imported and locked into a shipping build.

Registry downloads sit at the bottom because they prove the least. npm's download stats are a naive count of HTTP 200 responses that served a tarball, and most packages get a trickle of daily downloads that is not indicative of active use. Only above roughly 50 downloads per day can you be confident you are seeing signal instead of noise, and even then the number tells you nothing about which company pulled it.

A manifest entry proves declared intent, nothing more. A lock-file entry is the cheapest production signal you have, because lock files pin the exact versions resolved into a build across direct and indirect dependencies. An import or require statement in default-branch source proves a human wrote code against your API, but code search indexes only default branches, not all code is indexed, and each query is capped at 1,000 results.

The practical rule: never rank on downloads, and treat manifest-only as a lead rather than an adopter until you find a lock-file entry or a source import.

The end-to-end procedure

The method runs from one package name to a ranked account list in eight steps. Filtering before resolution is cheaper on API budget; resolving before filtering preserves small but real corporate accounts. Pick deliberately based on how large your dependents list is and how tight your rate-limit budget is.

Rough timings: pulling and cross-checking the raw list runs 35 to 50 minutes; confirming production use is the long pole at 30 to 60 minutes depending on how many repos survive; resolution and enrichment take 50 to 70 minutes with rate limits in mind; dedupe and ranking close it out in about half an hour. Budget an afternoon for a mid-size library.

Step 1 and 2: build the raw repo set from two sources

Because there is no official count API, use a wrapper that parses the network/dependents HTML for you. github-dependents-info scrapes dependents to JSON, markdown, or badges and supports a minimum-star filter such as ten stars, which you will want in step 4. Then cross-check against an open dataset so you catch ecosystems the GitHub tab misses.

ecosyste.ms indexes roughly 14.4 million packages across about 293 million repositories, and Libraries.io covers around 25 million repositories with about 100 million declared dependencies. Merging both against the GitHub scrape gives a wider net than any single source, then you dedupe by repo full-name before moving on.

Step 3 and 4: confirm real use, then cut the noise

For each surviving repo, run code search for your import or require string and record whether the package appears in a lock file or a manifest only. Then filter. Forks are indexed and searchable exactly like normal repos, so a documented workflow narrows by file type and excludes forks; one practitioner uses a path filter for the language and excludes forks to reduce noise. Drop archived and demo repos too, and use the relationship:direct qualifier to remove transitive-only hits where the company depends on something that depends on you.

Step 5 through 8: resolve, verify, dedupe, rank

Call the Users and Orgs API for the owning account's company, location, and public email. Where the profile hides the email, recover the domain from commit history, remembering that recovery skips GitHub noreply addresses. Then collapse every repo and committer onto one company key and rank by strongest signal plus repo count.

The resolution and routing steps are where Refolk removes the most friction. Instead of hand-calling the Users API for every committer and then hunting for the right DevRel or sourcing contact at each resolved employer, you can ask for the people in plain English and get them resolved to a real employer across the public GitHub graph and public LinkedIn records.

How this goes wrong: failure modes and false positives

Every step above has a characteristic way of lying to you, and the failure modes cluster into inflation, weak evidence, and quiet resolution gaps. Treat this section as the checklist you run before you trust a single row.

The funnel figures above are illustrative of the shape, not counts from your library. What is real is where the losses happen: fork removal and production-use confirmation cut hardest, and resolution quietly loses the senior maintainers you most want.

• Fork inflation. A company appears dozens of times because forks are indexed like real repos, so 40 apparent dependents can be one upstream re-forked. Filter forks and dedupe by upstream repo.
• Download-count vanity. A spike looks like adoption but is mirrors and CI re-pulling on publish. Ignore anything under roughly 50 downloads a day and look for import evidence instead.
• Manifest-only mirage. The package is in package.json but never imported, left over from a scaffold, so you tag a "user" that never ran your code. Confirm a lock-file entry or a source import.
• Transitive-only inclusion. The company depends on X, and X depends on you; they never chose your library. Use the relationship:direct qualifier.
• Personal-account misattribution. A maintainer's side project gets counted as their employer, so you tag Google because a Googler's hobby repo uses it. Require org ownership or a corporate email domain, not just the profile company field.
• Noreply email dead-end. Resolution silently drops committers whose email is a GitHub noreply address. Fall back to the org owner or the profile company field.
• Result-cap truncation. Code search returns only the first 1,000 hits, so your largest adopters can be invisible. Split queries by language: or path: to stay under the cap.
• Rate-limit gaps. At 10 code-search requests a minute you under-collect silently on big libraries. Paginate with backoff and reconcile your total against the dependents page count.

The counterintuitive lesson from the caps: a mid-size library gives a more complete company list than a mega-popular one, because you never hit the 1,000-result truncation. If your library is huge, accept that the map is a sample and reconcile against the raw dependents total rather than pretending the code-search hits are exhaustive.

A library with millions of downloads can still yield a short, honest account list once you resolve owners.

The deduplication rule and adoption-depth tiers

There is no single canonical public standard for how to collapse repos to companies or how to tier adoption depth, so treat what follows as a defensible construction from primary sources, not a cited authority. The dedupe rule keys company records on the resolved employer or a verified email domain. The tiers rank on the strongest artifact you found for each company.

The dedupe key is the point where the job actually becomes a company list. Resolve each surviving repo to an owning org or employer, then key on that employer name or its verified email domain. Multiple repos, multiple committers, and multiple package versions all collapse onto one company row, with the supporting repos carried as evidence.

Within a tier, break ties by repo count and star weight, since a company running you across several active repos is a deeper adopter than one with a single dependency. Mark this scoring as writer-load-bearing: it is a synthesis grounded in the lock-versus-manifest distinction and star filtering, both documented, but the tier labels themselves are not a published standard, so document your thresholds so a colleague can reproduce the ranking.

Here is a rubric skeleton you can paste into a spreadsheet or a scoring script and adapt.

Tier gate:
  Tier 1 base = 60   (import + lock + commit in last 12 months)
  Tier 2 base = 35   (lock-file entry, no confirmed import)
  Tier 3 base = 10   (manifest only)
Add:
  + 5 per additional supporting repo (cap +20)
  + 10 if repo is org-owned (not a personal account)
  + 5 if resolved via corporate email domain (not just company field)
Subtract:
  - 40 if transitive-only (relationship != direct)
  - 20 if only source is a fork or archived repo
Final = clamp(base + adds - subtracts, 0, 100)

Who you hand the list to, and how to pace it

The finished deliverable is one row per company, sorted by adoption-depth score, with supporting repos and a resolved employer on each row. Who works it depends on your org, and the two most common audiences differ in size, which changes how much of the list you should activate at once.

In Refolk's index, US technical sourcers outnumber US DevRel people by roughly 1.5x, 525 against 351, and the top employers for sourcers include Rippling, Zipline, Verkada, and Anthropic. If your account list is going to sourcers building outreach against adopter companies, there is more capacity to work it than if it goes to a DevRel team. And the US-versus-UK gap of about 6x means a UK DevRel team should receive a shorter, more heavily pre-ranked slice of the same list.

For DevRel, the top-tier companies become target accounts for talks, sample integrations, and case studies. For sourcers, the same companies become firms to recruit from or sell into, since a company that has resolved your library into production has engineers who already know your API. In both cases, Refolk shortens the last mile: once you have the resolved employers, you can ask for the specific people at those companies rather than manually walking each org's public profiles.

Keeping the list current and honest

An adoption map decays the moment you finish it, so treat it as a standing query rather than a one-off. Re-scrape the dependents page on a cadence that matches your release rhythm, because new dependents appear whenever downstream projects bump versions, and archived or deleted repos silently fall out.

Two habits keep the map trustworthy over time. First, always keep the unresolved rows visible rather than quietly deleting them, because a package with many unresolvable committers is telling you something real about private or noreply-heavy adoption, and hiding that overstates your confidence. Second, re-run the reconciliation between your code-search hits and the raw dependents total on every refresh, since a library gaining popularity will eventually cross the 1,000-result cap and your map will start sampling without warning.

The discipline that separates a useful account list from a vanity dashboard is naming its limits. You are mapping the public, default-branch, non-fork, resolvable slice of your adoption, and that slice is smaller than your true footprint. Ranked honestly and refreshed on a cadence, it is still the most concrete demand signal a dev-tools team has: the exact companies that chose to build against your API, ready for someone to call.