Mapping the Repository Landscape Around One Seed Project

You have one repository you care about, and you need to know the whole neighbourhood around it: the direct alternatives, the projects that depend on it, and the adjacent tools that share its domain but do a different job. This playbook is for engineering managers, technical founders, developer-relations leads, and technical sourcers who need that map to survive scrutiny. It sequences the free public sources into one repeatable pass and, just as important, tells you how to reconcile their conflicting, approximate counts instead of pretending one of them is truth.

Most pages on this topic either explain a single tool or hand you a generic list of places to look. Neither gets you to a finished artifact. By the end here you will have a deduplicated, ranked landscape map in which every project is labelled alternative, dependent, or adjacent, with the evidence behind each label written down.

What the finished landscape map contains

A finished map is a single ranked table of distinct projects, each tagged with one of three classes and the signal that earned the tag. Nothing in it is a fork, mirror, template, or archived repository, and no count appears without its source.

The three classes are not interchangeable, and the whole method exists to keep them apart:

• Alternative - a project a user could choose instead of the seed. It shares the seed's core purpose, usually visible in overlapping topics or registry keywords.
• Dependent - a project that builds on the seed. It appears in a reverse-dependency list for one of the seed's packages.
• Adjacent tool - a project in the same domain that solves a different problem. It shares context but not purpose.

The reason to be strict about this is that the three come from different sources and carry different confidence. Dependents come from dependency graphs, which are approximate but machine-verifiable. Alternatives and adjacent tools come from topic and keyword overlap, which is a human judgement dressed as data. A map that blends them without saying which is which cannot be defended in a review.

A landscape map that hides its sources is a guess wearing the costume of a dataset.

The four sources and what each one actually covers

Four free sources feed this map, and each covers a different slice. No single one is complete, which is the entire reason the pass triangulates rather than trusting one number.

GitHub's dependency graph lists other public repositories that depend on the repository or on packages it publishes. It is not reported for private repositories, and GitHub Enterprise Server does not calculate dependents at all. You can filter the list to package-only dependents with the "Packages" toggle above it. Critically, there is no official count endpoint: GitHub does not return the "Used by" or dependents count through its REST or GraphQL API, so you either read the UI or run a community scraper against the Dependents page.

The open datasets extend past GitHub's graph. Libraries.io monitors over 2 million open source packages across 36 package managers, gathering license, releases, contributors, and dependency data; its published dataset holds about 2.5 million unique components, 9 million versions, and 100 million declared dependencies across 25 million repositories that use them. ecosyste.ms aggregates package registries, software repositories, vulnerability databases, containers, and operating systems, with a packages index on the order of 5,684,962 packages and 72,603,805 versions, and it exposes dependent-repository counts per package. Google's deps.dev supports Cargo, Go, Maven, npm, NuGet, PyPI, and RubyGems, but resolves full dependency graphs for only Go, npm, Cargo, Maven, and PyPI, and carries the fork and parent metadata you need to strip duplicates later.

The end-to-end procedure

Run the eight stages below in order. The whole pass takes an analyst roughly four to five hours plus a half-hour reviewer pass, and the ordering matters: fork exclusion happens before ranking, not after.

Why step 1 is per-package, not per-repo

Reverse-dependency data is keyed on packages, not repositories. A repo that publishes three packages has three separate dependent lists, and GitHub's "Used by" sidebar shows only one of them. If you record the seed as a single URL and stop there, you will undercount a multi-package project against a single-package rival before you have gathered a single number. Write down every ecosystem:package pair first.

How to classify: the signals and when they lie

Classification turns on three signals, one per class. Each proves something specific, and each fails in a recognisable way. Record the deciding signal for every project so the classification is auditable rather than remembered.

GitHub topics are the primary machine-readable classifier. Topics appear on a repository's main page, and clicking one shows related topics and other repositories classified with it; registry keywords play the same role for packages. A repository allows a maximum of 20 topics, each up to 50 characters. But topics only work as a signal when they agree with the repository name, description, README, and actual code. A repo labelled kubernetes with no Kubernetes code has spent a free label to buy attention, and it will poison your alternatives list if you trust the tag alone.

There is no published numeric cutoff for how much topic overlap makes a project an alternative rather than adjacent. That threshold is not established publicly, so it is a choice you must make and write down. A workable default is: two or more shared core-purpose topics, confirmed against the README, counts as an alternative; one shared domain topic with a different stated purpose counts as adjacent. State whatever rule you pick at the top of the map so a reviewer can argue with it.

Once you have your dependents and peers gathered, the slow part is often the human layer: finding the people who maintain the leading alternatives, or the teams shipping the dependents, so you can act on the map. That is a plain-English search rather than another graph query.

Refolk turns the landscape map from a list of repositories into a list of people, which is usually the point of building it. Once you know the alternatives and dependents, you can ask for the maintainers, the DevRel leads at the companies shipping dependents, or the engineers who contribute to both the seed and its closest rival, without hand-assembling contributor lists from commit histories.

Ranking that survives a review

Rank by percentile rank of each signal, not by raw values, so one dominant project cannot swamp the map. This is the single change that separates a defensible ranking from one that collapses the moment an incumbent enters the set.

The OpenSSF Criticality Score is the reference model: a project's criticality score is a number between 0 (least critical) and 1 (most critical), computed from signals including project age, time since last update, contributor count, organization count, commit frequency, recent releases, closed-issue activity, and dependents count, with weights an end user can adjust. The Linux Foundation variant improves robustness by scoring on rank, not raw value: the scoring function is a linear combination where each term is the percentile rank of a project's signal relative to all others. More contributors than 75% of the set gives that signal a value of 0.75.

The reason to prefer percentile rank is concrete. In most niches one incumbent has orders of magnitude more dependents than everyone else. Sum raw dependent counts and that one project takes the entire top of your ranking while burying real differences among the rest. Convert every signal to its percentile first and the incumbent still ranks first, but the spread below it stays legible.

A minimal, reproducible scoring rubric you can adapt:

score = 0.5 * pct(dependent_count)
      + 0.3 * pct(commits_last_90_days)
      + 0.2 * pct(contributor_count)

where pct(x) = fraction of projects in the set with a lower value than x
example: more contributors than 75% of the set -> pct = 0.75
output: a single 0-1 number; sort descending to rank the map

How this goes wrong

The failure modes below are where landscape maps quietly become wrong. Each has a false positive that looks fine on the page, and each has a check. Treat this section as the load-bearing part of the method.

Trusting "Used by" as total demand. The "Used by" figure represents a single package from the repository and only appears once more than 100 repositories depend on that package. A multi-package seed is structurally undercounted, so a monorepo publishing ten packages can look far smaller than a single-package rival. Ranking on this figure alone rewards packaging shape, not adoption. Check: sum every package's dependents separately.

Treating GitHub counts as exact. They are explicitly approximate and may not match the dependents actually listed, and the peer-reviewed error rate is around 10% for dependents. The false positive is a clean-looking number no other source confirms. Check: cross-reference ecosyste.ms and deps.dev before trusting any single count.

Missing whole languages. deps.dev has no C or C++ data, so a systems-language seed looks unused when it is simply not indexed. Check: confirm the seed's ecosystem is actually covered before concluding low usage.

Counting forks as competitors. Popular repos carry thousands of forks that inflate the map and can even appear in dependent lists. Check: verify the fork/parent flag before labelling anything an alternative, and exclude forks, mirrors, templates, and archived repos early.

Keyword-only classification. A topic present in name only misleads. The classic false positive is a repo tagged kubernetes with no Kubernetes code. Check: confirm every classifying topic against the README and the code.

Averaging conflicting counts. Silently averaging GitHub against registry numbers hides the disagreement that is itself a finding. Check: record all sources side by side and annotate; never merge into one number.

Raw-threshold ranking. A single mega-dependent repo swamps raw sums. Check: use percentile rank so one outlier cannot dominate.

Who acts on the map, and how thin that pool is

A landscape map is only useful if someone senior owns the response to it, and that population is smaller and more concentrated than most teams assume. Competitive-landscape work in open source ecosystems tends to land on a handful of developer-relations owners rather than a broad bench.

In Refolk's index of professional profiles, the geographic and seniority distribution is stark:

The US developer-relations population outnumbers Germany's by about 11.7x. The seniority split narrows the pool further:

Leadership is only about 18% of the US base, so roughly 63 people carry the Head, Director, and VP of Developer Relations titles in the country's largest market. If your map is meant to drive outreach, competitive positioning, or hiring, the people who can act on it are a small, senior group. Plan the follow-through accordingly, and use the map's classified alternatives and dependents as the entry point to reach the right owners at each project rather than starting from scratch.

Before you call it done

Run this checklist before shipping the map. Each item is a specific thing to verify, not a topic to think about.

Keeping the map current

The map decays as the ecosystem moves, so treat it as a living artifact with a re-check cadence rather than a one-time deliverable. The mechanisms that change are predictable: new packages get published, dependent counts drift, projects get archived, and topics get retagged.

Re-run the reverse-dependency pull whenever the seed publishes a new package, because a new ecosystem:package pair is a new dependent list you do not yet have. Re-check archived and fork status on the top-ranked entries on a fixed schedule, since a project that goes dormant should drop in the ranking. Because deps.dev data is licensed CC-BY 4.0 and clients may cache it, you can store a snapshot and diff against it on the next pass instead of re-fetching everything, which makes it cheap to see what moved. When two sources disagree by more than the known error band, that gap is a signal worth investigating on its own, not noise to smooth over. The point of building the map this way, with sources and evidence attached, is that the next update is a diff, not a rebuild.