Scoring an Account's Open-Source Footprint for Buying Intent

You have a list of companies whose developers touched your open-source repo, and a rep's day is finite. This guide is for founders selling their own product, AEs, SDR leads, and partnerships teams who need to decide which of those accounts is a real enterprise evaluator worth reaching today, versus an enthusiast to nurture, versus noise to skip. It gives you a repeatable per-account score built from five dimensions, the thresholds that separate a team evaluation from a lone hobbyist, and a walk-through of every way the score lies.

The public best answers are vendor blogs that rank signals loosely - a fork beats a star - but stop before they hand you a number or a threshold. This is the number and the threshold.

Why repo activity needs a scoring model, not a ranked list

A ranked signal list tells you a fork is stronger than a star. It does not tell you whether this account, with three forks 40 days ago and one issue comment yesterday, is hotter than that account with a single fresh pull request. You need a composite that folds signal type, recency, concentration, seniority, and competitive clustering into one figure you can defend in a pipeline review.

The core problem is that a repo footprint is mostly individual-contributor behavior, and most people scoring it are looking for the wrong titles. In Refolk's index there are roughly 80 times as many Platform Engineer, SRE, and DevOps titles in the US as there are Developer Advocate and DevRel titles. Treating a senior IC's fork as noise while chasing titled "advocates" inverts the real evaluator population.

Both counts come from Refolk's index; the multiple is derived (25,634 / 319 = 80.4). The read is simple: the humans on your repo are overwhelmingly ICs doing evaluation work, not advocates doing outreach.

The five dimensions and what each one proves

The model reads five dimensions per account. Each proves something specific, and each has a way it lies - which is why the failure-mode section later carries as much weight as the scoring itself.

• Signal type. Proves depth of engagement. A pull request or commit proves someone ran and modified your code; a star proves almost nothing. It lies when the star count is inflated (see fake stars below) or when one issue is a complaint, not evaluation.
• Recency. Proves the evaluation is live. A signal from this week is actionable; a fork from 90 days ago is a cold artifact. It lies when an old signal is scored as hot without a fresh action to reset the clock.
• Developer concentration. Proves a buying group rather than a lone champion. Two or three distinct people from one domain inside ten days is a team. It lies when one prolific developer's many actions get read as many people.
• Seniority and enterprise markers. Proves stage. Security-questionnaire language (SSO, SCIM, RBAC, audit logs) written by a senior engineer signals a real procurement path. It lies when a keyword appears in a complaint or a student tutorial.
• Competitive clustering. Proves category intent and urgency. A developer active on both your repo and a competitor's inside 30 days is evaluating the category. It lies when the person is a vendor-neutral consultant who touches every repo in the space.

Weighting signal type: fork vs star and everything between

Order signals by how much work they required: pull request and commit first, then issue opened, issue comment, fork, watch, and star last. This ordering is practitioner consensus, not a benchmarked ranking, so treat it as weighting rather than proof.

The reasoning is concrete. A fork indicates a developer actively working with your code, while a star suggests passive appreciation. A GitHub star is a one-click, zero-commitment gesture. It does not mean the person read the code, used the tool, or even cloned the repo. It is closer to a social media like than a product endorsement.

One production model operationalises this as a composite: volume at 30%, recency at 30%, quality at 25% (where pull requests and commits count more than stars), and diversity at 15% (activity across multiple related repos). You do not have to copy those exact weights, but the shape is right - quality and recency together should dominate raw volume.

The recency decay schedule that decides urgency

Multiply every signal by its age band. A signal from the last week is worth full value; anything past 30 days is effectively dead unless a fresh action revives it. This is where pipeline leaks, because most teams score on a weekly cadence and lose value before a rep ever touches the account.

Multipliers come from published practitioner curves; the interpretation column is derived for this framework. Other sources use half-life logic, halving the contribution every 30 days, or a per-week rule that cuts the score roughly 10% per inactive week. One glossary puts intent decay at roughly 50% within 30-45 days for typical B2B SaaS. They disagree on whether the hard reset lands at 30 or 60 days, so pick one and apply it consistently.

The practical consequence: with multipliers falling to 0.6x by day 15, a weekly batch loses about 40% of a signal's value before it reaches a rep. This is the mechanism behind the old finding that responding within 5 minutes rather than 30 is associated with roughly 21x higher odds of qualifying. Speed of routing often beats better targeting.

Reactivation matters too. Re-engagement signals from past visitors often convert at 2-3x the rate of cold first-touch stars, so a dormant account that fires a fresh action deserves a boost, not just a reset to full value.

Same-day routing beats better targeting, because a signal loses 40% of its value before a weekly batch ever ships it.

Concentration and enterprise markers: the tier-jump signals

Two dimensions do most of the work of separating an enterprise evaluation from a lone enthusiast: how many distinct people from one company are active, and what language they use.

Concentration. Account-level activity is stronger than one-person activity. If several contacts from one company engage within about 10 days, that is a stronger sign. The high-confidence heuristic from adjacent intent work is three stakeholders from one company inside a 10-day window - much stronger than one contact doing the same. For GitHub, multiple signals from the same company domain, indicating team evaluation, are the highest priority. A concrete distinct-developer numeric threshold is not established publicly, so treat "2+ distinct people in ~10 days" as a working floor, not a benchmark.

Enterprise markers. Enterprise stage is textual, not behavioral. The strongest tier-jump comes from procurement language in an issue or PR, because those words map to the exact security-questionnaire cluster that gates large contracts. The documented cluster is SSO, SCIM, audit logs, and RBAC, with audit logs and SSO the most demanded first. When a big logo shows up, the security questionnaire arrives full of SSO, SCIM, MFA, RBAC, audit logs, and SOC 2 - so those acronyms in an issue are a stage marker a keyword scan can catch before any human reads the thread.

Once you have identified enterprise-marker language and concentrated activity, the friction is resolving those handles to reachable people fast enough to matter. Refolk does that resolution from a plain-English query, which closes the gap between a hot signal and a rep who can reach the right person before the multiplier decays.

The scoring procedure, end to end

This is the repeatable run. Budget roughly half a day for a first pass on one repo, most of it in identity resolution. The steps below match the machine-readable procedure attached to this guide.

Turning the composite into a tier

Bucket each account into reach-now, nurture, or skip using two axes: composite intent and ICP fit. Fit is the ceiling - a hobbyist at a five-person shop scoring high on behavior still caps out, because firmographic fit gates the tier regardless of enthusiasm.

A defensible tier statement reads like this: Account clears ICP, composite intent high on two distinct engineers with a fresh audit-log issue - reach now, owner assigned. If you cannot write that sentence, the account is not reach-now yet.

Account: <company>
Distinct devs (10d): <n>
Top signal: <PR / commit / issue / fork / star> on <date>
Recency multiplier: <1.0 / 0.85 / 0.6 / ~0>
Enterprise markers: <SSO / SCIM / RBAC / audit log / none>
Competitor co-activity: <yes, repo X within 30d / no>
ICP fit: <strong / partial / weak>
Tier: <reach now / nurture / skip>
Owner: <rep>

How this scoring goes wrong

Every dimension has a false positive, and the model is only as good as your discipline about them. This is the section to reread before you route.

• Star count as intent. A repo spikes a thousand stars overnight and the model marks it hot. Check the fork-to-star ratio and account age. A CMU study presented at ICSE 2026 found about 6 million fake stars across 18,617 repositories from roughly 301,000 accounts, and tied them to accounts with no follower or contribution history. AI and LLM repos were the largest non-malicious category.
• Company field trust. A developer lists "Google" in their bio but left two years ago. Check the commit-email domain and recency before routing.
• Recency without reactivation. A 90-day-old fork gets scored as hot. Zero it unless a fresh action reset the clock.
• Enterprise keyword literalism. An issue mentions SSO only to say the tool lacks it, or a student writes a tutorial. Read the sentence, then confirm the author's seniority and employer.
• Single enthusiast masquerading as a team. One prolific developer opens five issues and inflates account activity. Require distinct logins mapped to distinct people before calling it a team evaluation.
• Competitive co-activity noise. A maintainer or consultant active across every competitor repo is not evaluating - they sell services. Check whether the profile is vendor-neutral tooling.
• Enrichment gaps read as not-ICP. A strong account gets dropped because email or company would not resolve, and only 60-80% do. Route unresolved-but-active accounts to manual review, not skip.
• Ignoring the ICP ceiling. A hobbyist at a tiny shop scores high on behavior. Firmographic fit caps the score regardless of enthusiasm.

The enrichment gap deserves its own emphasis. With email hidden by default and only a partial share of developers resolvable, a purely automated pipeline silently discards its highest-intent, hardest-to-identify accounts. The fix is a manual lane, not a tighter filter.

The DevRel-vs-IC read, and market context

One firmographic note shapes how you set the ICP ceiling and where you hire to support this motion. The evaluator on your repo is an IC, but the person who runs a developer-signal program is often DevRel, and that pool is small and geographically concentrated.

Both counts come from Refolk's index using the title set Developer Advocate, Developer Relations, and DevRel; the ratio is derived by division. The practical implication: if you are staffing this program, the US pool is nearly seven times the UK's, and either way it is dwarfed by the IC population your scoring model actually reads. Do not build a program that only listens for titled advocates.

Keeping the model current

The model has moving parts that decay, so schedule a re-check rather than treating the weights as fixed. Run this before you trust a scored list, and re-run it quarterly.

Two things to watch over time. First, GitHub's access rules to stargazer and metadata endpoints change, and public stargazer-list access was already restricted - re-check what your collection method can still fetch, and remember that authenticated API access allows 5,000 requests per hour versus 60 unauthenticated. Second, the recency curve is the highest-leverage assumption you own; if your reps consistently find fresh signals cold on arrival, tighten the cadence before you touch the weights. The score is a tool for spending rep time well, and rep time is the thing decaying fastest.