The Repo-Footprint Account Book: Open-Source Users to a Ranked Queue

This is the repeatable run that turns your own open-source repository's public footprint into a ranked book of enterprise accounts. It is for founders, account executives, SDR leads and partnerships teams at companies that ship a free repo and sell something on top of it. It covers pulling every footprint, resolving each developer to an employer with a stated confidence, rolling people up into accounts scored on depth, breadth and recency, and handing reps a queue that separates real users from star-only noise.

Which repository footprints can you pull, and what does each one prove?

Your repository records six kinds of public footprint: stars, forks, issue and discussion posts, pull requests, commits, and public dependents. They range from a single click (a star) to a public codebase that imports your package (a dependent), and the queue is only as good as your refusal to treat them as equal.

A footprint here means one dated public action by one GitHub login on your project. A dependent is another public repository that depends on your repository or on a package it publishes, as computed by GitHub's dependency graph.

Access limits that shape the pull

• Stargazers. GitHub restricted the list stargazers and list watchers endpoints to admins and collaborators. Its stated reason was that the public list was being harvested to collect user data for spam. As the repo owner you can still pull your own list. Request the star+json media type to get a timestamp for when each star was created. Pages hold up to 100 results, and the default is 30.
• Ordering. One practitioner reports the list comes back oldest to newest, with no sorting by starred_at. If that holds for you, a delta pull means paging to the end, not reading from the start.
• Star history. GitHub also offers a privacy-safe star history endpoint that returns counts, not identities. It caps per_page at 30 and page at 100. It can't identify anyone, but it does show spikes.
• Rate limits. 60 requests per hour without a token, 5,000 per hour per token.
• Dependents. These are listed for public repositories only, and only when your package is published on a supported package ecosystem and links to the public repository holding its source. The dependency graph also accepts any ecosystem identified by a purl (package URL, a standard string naming a package and its ecosystem) submitted through the API. GitHub Enterprise Server does not calculate dependents. I found no documented REST endpoint for dependents, so expect to page the web UI, and check the current dependency graph docs before you build on that assumption.
• Issues, PRs and discussions. I have not checked the exact limits for these endpoints. Take them from GitHub's REST docs when you write the pull.

The gating has a commercial consequence. Since only admins and collaborators can list stargazers, outside enrichers can no longer easily rebuild your stargazer export. Data you could once assume competitors had is now yours alone.

The refresh run, step by step

The run has eight steps, from a written ICP to a ranked queue with evidence on every row. By my desk estimate (not a sourced figure), a first full run takes 11 to 18 working hours across three people. Delta refreshes take much less, because only new logins need resolving. With deltas, one to two working days per refresh is a realistic budget.

Where practitioners order the steps differently

Published versions of this run disagree on sequence:

• Refolk's stargazers-to-meeting-list guide runs a fake-star check before anything else.
• One practitioner write-up puts ICP fit before activity tracking.
• Another enriches every login before filtering.

I write the suppression list first and apply the ICP filter after the rollup. Until a login has a domain you have nothing firmographic to filter on. If you filter people before you roll them up, you also lose breadth: three developers at one company only add up once they sit in the same row. If your repo has had a suspicious star spike, run the fake-star check from the existing guide before step 4 so you don't spend resolution hours on accounts that aren't real.

How do you resolve a GitHub login to an employer?

Work down a fixed ladder of evidence and record which rung produced each answer. Confidence comes from two independent rungs agreeing, never from one field alone.

What each rung proves, and how it lies

• Verified org membership. This is the strongest signal. It lies when someone stays in a public org after leaving, or when the org belongs to an open-source foundation rather than the employer.
• Company field. This is free text. "@google" can mean a current employer, a former one, a joke, or the user's own startup.
• Corporate commit email. This proves a corporate address was configured at some point. It undercounts badly. Adobe's oss-contributors project notes that "not many people use their company's e-mail in the git config they use with their public GitHub.com account." New accounts also default to a commit email of the form id+login@users.noreply.github.com and an empty public profile email, which tells you no domain at all.
• Bio or blog. This is self-description, so treat it as a weak hint.
• External profile match. This one is strong when name, location, and the repo or language history all line up. It is weak when only the name matches.

Assigning the confidence tier

• High: verified org membership, or any two lower rungs agreeing on the same domain.
• Medium: one of company field or corporate commit email, uncontradicted.
• Low: bio, blog or external match alone.
• Unresolved: no rung produced a domain. Keep these rows, because a later refresh may resolve them.

Nobody has published what share of GitHub profiles resolve to an employer, so I can't give you an expected hit rate. Measure your own on the first run: the unresolved share, plus the share at each tier. That number becomes your baseline for spotting a broken pull on later refreshes. Coverage matters less than honest tiers. A queue built on 300 medium-confidence guesses is worse than one built on 120 high-confidence matches. The adobe/oss-contributors project is a useful reference implementation of the profile-to-company step if your engineer wants to see how others have done it.

The bottom rung is where the hours go. Matching a login to a public professional profile by hand means opening tabs, comparing names and locations, and guessing. Refolk searches GitHub, LinkedIn and the open web from one plain-English question. That turns the external-match rung into a query, and it returns the person's current employer alongside their GitHub identity.

How do you score accounts on depth, breadth, and recency?

Roll every resolved login up to its domain, then score the account on three things. Depth is the deepest footprint type present. Breadth is the number of distinct, de-clustered people. Recency is the date of the latest event. Then split the accounts that show real usage from the ones that only starred.

The split comes from practice. As reported through BVP Atlas, Imply codes "PQLs that have previously used Imply's open source offering (either in testing, development, or production)" as "pre-buyers," while leads with no prior exposure are "pre-believers." A PQL (product-qualified lead) is a lead qualified by product usage rather than by form fills or firmographics alone. In repo terms, a pre-buyer account has at least one dependent, PR, commit or issue. A star-only account has not yet shown usage.

No published weighting of depth, breadth and recency exists. The rubric below is my starting point, not a benchmark. Calibrate it against your own closed-won accounts after two or three refreshes.

DEPTH - take the single deepest footprint at the account
  5  Public dependent repo (not a fork, not a tutorial, above your star floor)
  4  PR author or commit author
  3  Issue or discussion author
  2  Fork
  1  Star only

BREADTH - distinct resolved humans, after cohort de-clustering
  +0  1 person
  +1  2 people
  +2  3 to 5 people
  +3  6 or more people
  Count only High and Medium confidence logins.

RECENCY - latest dated event at the account
  +3  within 30 days
  +2  31 to 90 days
  +1  91 to 180 days
  +0  older than 180 days

TIER
  A  Depth >= 3 and Recency >= 2          pre-buyer, call first
  B  Depth >= 3 and Recency <= 1          pre-buyer, check for fork-and-customize
  C  Depth <= 2, Breadth >= 1, Recency >= 2   watch, do not hand to reps yet
  X  everything else                      star-only noise, hold

GATE
  Any account resolved only through Low-confidence logins goes to manual review, not the queue.

The 180-day line in the recency band follows one practitioner's claim that stars older than three to six months rarely convert. That claim comes with no data, so treat the cutoff as adjustable.

Every row reps receive should look like the one below. The evidence link is the most important field: it is what lets a rep open with something true.

account_domain | tier | score | deepest_footprint | evidence_url | distinct_people | latest_event_date | resolver_confidence | suggested_persona | suppression_checked
example.com | A | 10 | public dependent | <link to the dependent repo> | 4 | <date of latest event> | High | Head of Platform Engineering | yes

Who should reps call at each account?

Route to platform-engineering leadership by default. An open-source program office is a real buyer where one exists, but the pool is thin: in Refolk's index it is roughly one OSPO profile for every 37 platform-engineering leaders in the US. An OSPO (open source program office) is the internal team that governs a company's use of and contribution to open source.

Source: Refolk's index. The one off-target title in the platform sample was a sales-executive title. Among the US OSPO profiles, visible employers include Goldman Sachs, NVIDIA, State Farm and SAS. That fits the intuition that formal open-source offices sit in large, regulated or hardware-heavy firms. Don't expect one at a mid-market account.

The same persona thins out sharply by country

Source: Refolk's index; multiples are derived. "Head of Platform Engineering" is the most common matching title in all three countries, so it is the right title to search first everywhere. Adjust is the most frequent German employer in the platform-leader sample, with 3 of 25.

What this means for the queue:

• US accounts often have more than one named platform leader. Pick the one closest to the team that left the footprint.
• German accounts usually yield one named buyer at most. Breadth has to come from developer footprints, not from multiple titled contacts. A German account with three resolved contributors and one Head of Platform is a strong row. Don't mark it down for having a single title.
• OSPO first only when the account is a large enterprise and an OSPO profile actually turns up. Otherwise the OSPO adds a gatekeeper without adding a budget.

Once you have a resolved domain, finding the named platform leader there is a second search, and one that Refolk handles in the same plain-English way as the login match. To check whether a target segment has an OSPO at all before you build routing rules around one, run the query below.

What yield should you expect from the queue?

Plan for fewer than about 50 conversions per 1,000 under every published anchor, and treat even that as a ceiling. All the source rates are user-level, so nobody has published what share of accounts converts.

How to read the table:

• OpenView's dev-tool median is the best-sourced row. Its median six-month free-to-paid rate for companies selling to developers is 5%, against 10% for others. Selling to developers halves the benchmark.
• Handsontable reported a commercial-to-free ratio of about 1 to 25. That is one company's figure, and it is a ratio of users, not accounts.
• The secondary blog attributes 1-5% to OpenView, with top performers reaching 8-10% for targeted enterprise segments. I could not find the primary source, so don't quote it as OpenView's finding. The same blog says Elastic found community-forum participants were 3x more likely to convert, which is also unverified at source. If it holds, it supports weighting issue and discussion authors above stars.
• Wikipedia's claim that most commercial open-source firms convert well below 1% of downloaders carries "citation needed."

Use these numbers to size rep capacity and to reset expectations. Don't use them to promise pipeline. After three refreshes, your own tier-A meeting rate will be a better number than anything in this table.

How this goes wrong: failure modes and false positives

Most failures in this run produce a confident-looking queue that is wrong, not an obviously broken one. Each failure below comes with the check that catches it.

1. The stargazer pull returns 403 or 404. The usual cause is a non-admin token. Some users report 404s even as admin. Check: confirm the token's role on the repository and read the response body before concluding there is no data.
2. The company field is free text. "@google" can be a former employer, a joke, or the user's own startup. Check: require a second rung, either org membership or email domain, before marking High.
3. The commit-email fallback misleads. Noreply addresses give no domain. Gmail is not a company. Agency and consultancy domains create fake accounts that look like heavy users because one consultancy's engineers touch many client projects. Check: keep a suppression list of known consultancies and apply it in step 6.
4. Dependents cut both ways. Private enterprise repos are invisible, so you get false negatives. Students' public demo repos count as dependents, so you get false positives. Check: exclude dependents that are forks, that look like tutorials, or that fall below a star floor you set and write down.
5. Breadth gets inflated. Ten stars from one bootcamp cohort look like ten people at one account. Check: look at the date clustering of the stars. A burst inside a day or two from logins that resolve to a training provider is one cohort, not ten buyers. The star history endpoint helps here, because it shows spikes without needing identities.
6. The signal goes stale. Old stars and forks can mean the team has already forked and customized. Handsontable observed "many companies deciding to fork our open source libraries before even considering contacting us." Check: weight the most recent dated event, and send tier-B accounts to a rep with a migration or support angle, not a cold pitch.
7. The outreach breaches GitHub's terms. Bulk unsolicited email built from GitHub data violates the Acceptable Use Policies. Check: use the data to rank accounts, then reach people through permitted channels. The next section covers the detail.
8. Title noise creeps into persona counts. The US platform-leader sample in Refolk's index contained a sales-executive title written in Arabic. Check: spot-check samples before you quote a persona total to anyone.

What do GitHub's terms let you do with this data?

You can use your repository's footprint to decide which accounts to prioritize. You may not turn it into bulk unsolicited email. The line runs between ranking and spamming, and it holds whether you collected the data through the API or any other way.

GitHub's Acceptable Use Policies, as quoted: "You may not use information from the Service (whether scraped, collected through our API, or obtained otherwise) for spamming purposes, including for the purposes of sending unsolicited emails to users." Note that "collected through our API" is explicit. Using the official endpoint does not make bulk email acceptable. PyPI's policy is derived from GitHub's and states that "scraping does not refer to the collection of information through our API". Even so, read each registry's own policy before treating API access as a safe harbor for outreach. GitHub's own reason for gating the stargazer list was that it was being harvested for spam, which tells you how it views this use.

In practice that means:

• Reps contact the platform leader at the account through their normal permitted channels. They do not email the individual stargazer.
• The evidence link appears in your internal queue. Reference public, company-level usage carefully, and never imply you tracked an individual.
• I have not researched GDPR legitimate-interest guidance for this processing. That gap is open, so get counsel's view before you run this on EU accounts.

How do you keep the queue current?

Run a delta refresh on a fixed cadence, weekly or monthly, that pulls only events newer than your last cutoff, resolves only new logins, and re-scores only the accounts they touch. No published evidence says which cadence converts better, so pick the one your reps can actually work.

Published cadences range from a scan every morning to a weekly review. Neither comes with conversion data. My rule of thumb: refresh weekly if reps clear tier A within a week, and monthly if the queue routinely carries over. A refresh nobody works produces stale rows with fresh dates.

Keep these artifacts between runs:

• The cutoff timestamp of the last pull, per footprint type.
• The resolution cache, with each login's domain, tier and rung, so you never resolve the same person twice.
• The unresolved list, re-tried each run, since profiles change.
• Your baseline rates: unresolved share, tier-A count, and tier-A meeting rate. A sudden drop in any of them usually means a broken pull or a changed GitHub endpoint, not a change in the market.

GitHub's access rules for these endpoints have changed before and will change again. On each refresh, skim the GitHub changelog and the REST starring and dependency graph docs for changes to access, page sizes or rate limits before you trust a smaller-than-usual pull.