The State of Dev-Tool Evaluation on GitHub: What 5 Million Developer Events Reveal (2026)
Of the 1,001,643 developer-to-repository star pairs in this dataset, 98.9% were never followed by a single comment, issue, or pull request from the same developer on that same repository. The star is the evaluation. When developers assess a dev tool, they do it almost entirely in silence. They look, they judge, and they move on — without ever announcing what they decided.
That single finding changes how you should think about developer GTM. We analyzed 5.04 million public GitHub events across 5,213 developer-tool repositories, tracking 760,325 unique developers from January 2024 through June 2026, using data from the GitHub signal intelligence platform LeadCognition. Here is what the data shows.
Key Findings
- 98.9% of stargazers never open an issue or PR on the same repository. The star is the signal, not a precursor to engagement.
- 62.9% of developers appear exactly once in the full corpus of 5 million events. Most evaluators are genuinely one-and-done.
- 25.6% of comparison shoppers star their second dev tool within 24 hours of the first; 35.3% do it within a week.
- 173,759 developers starred 2 or more tracked tools — these are the active evaluators, median gap between first and second star: 25.5 days.
- The top 1% of repositories capture 61.8% of all engagement. The top 10% capture 93.3%.
- 13.8% of title-resolved evaluators are decision-makers — founders, C-level, VP, director, or head-of.
- Stars peak on Tuesday (168k events) and trough on Saturday (112k — 33% fewer than Tuesday). Evaluation is a workday activity.
- 42.7% of enriched evaluator profiles are resolvable to a LinkedIn profile, despite a median follower count of just 2.
Silent Evaluation: The Star Is the Event
When people talk about GitHub signals, they often treat a star as a weak indicator — a bookmark someone might never return to. The data suggests the opposite: the star is the evaluation moment itself.
Of 1,001,643 unique developer-to-repository star pairings recorded over two and a half years, only 1.1% were ever followed by an issue comment, pull request, or PR review from that same developer on that same repository. The remaining 98.9% starred and went quiet.
This is not necessarily passivity. Developers are technical. They can read a README, scan the code, run a quick test, and form a clear opinion — all without ever needing to ask a question or submit a patch. Silence is not disinterest. Silence is a concluded evaluation.
The implication for dev-tool founders is important: if you are waiting for a developer to raise a support ticket or comment on an issue before treating them as a real prospect, you are missing the vast majority of people who looked at your tool and made a decision.
Drive-By Visitors vs. Genuine Evaluators
The event distribution makes a sharp split visible. 62.9% of the 760,325 developers in the corpus appear exactly once across all 5.04 million events. They touched one repository, left one trace, and never showed up again in tracked activity.
27.9% engaged with two or more tools in the dataset. 13.2% touched three or more. The median events per developer across the full corpus is 1.
These numbers matter for targeting. The single-event majority is not a useful segment — they may be students, hobbyists, or people who saw a tweet and clicked through. The meaningful population is the 173,759 developers who starred two or more tracked tools. That group demonstrated a pattern of active exploration. Within that group, 25.6% moved from their first star to a second within 24 hours. 35.3% did it within a week. The median gap was 25.5 days.
That 25-day window is when a developer is actively in evaluation mode for a category. A dev-tool company that reaches them before the window closes is competing on merit. A company that reaches them after it closes is playing catch-up against an already-formed opinion.
Comparison Shopping Is Fast and Concentrated
The 173,759 multi-tool evaluators are not browsing indefinitely. The 24-hour and 7-day comparison-shopping windows confirm that evaluation in many categories is rapid and decisive. A developer researching logging libraries, observability platforms, or auth SDKs often forms a shortlist fast.
The attention concentration data reinforces this. The top 1% of repositories in the corpus absorbed 61.8% of all engagement. The top 10% absorbed 93.3%. This is a winner-take-most dynamic, not a bell curve. Developers on a deadline are not doing exhaustive research across the entire market. They are picking from a short default list — the tools that already have social proof and visibility.
For challengers in a crowded category, this is sobering. The data suggests that being outside the top 10% of a category, by engagement, means competing for the remaining 6.7% of developer attention. Early traction compounds; late entrants face structural disadvantage.
Who the Evaluators Actually Are
The corpus includes 197,157 developer profiles that could be enriched with public data. Of those:
- 32.5% publicly declare an employer on GitHub.
- 44.3% list a location.
- 36.7% have written a bio.
- 42.7% are resolvable to a LinkedIn profile through public signal matching.
- 14.9% have the GitHub “hireable” flag set — a proxy for active job-seeking.
The median follower count is 2. These are not influencers or prominent open-source maintainers. They are working developers with limited public presence but real jobs and real purchasing influence.
Of 72,025 profiles that could be matched to a professional title:
- 13.8% are decision-makers: founders, C-level, VP, director, or head-of.
- 21.2% are senior, staff, principal, or lead engineers — the people who write the architecture decision records and own the tool choices.
- 4.3% are platform, DevOps, or SRE — the operators who actually install and run the tools in production.
Collectively, around 39% of title-resolved evaluators are either direct buyers or the technical leads who drive purchasing decisions. GitHub evaluation is not just developer curiosity. It is real organizational intent, distributed across individual profiles that look quiet until you know what to look for.
Account age is also relevant. The median account age in the corpus is 6 years. 57.1% of accounts are older than 5 years. These are not throwaway accounts. They belong to active, established members of the developer community.
Evaluation Is a Workday Activity
Stars peak on Tuesday with 168,000 events, and again on Monday with 167,000. They drop to 112,000 on Saturday — 33% below the Tuesday peak. Sunday (134,000) outperforms Saturday, likely reflecting Sunday evening preparation for the week ahead.
The pattern is a clear workday curve. Developers evaluate tools as part of work, not as a hobby outside of it. They are looking for tools because they have a problem to solve, a system to build, or an evaluation their employer needs done.
For dev-tool marketing, this has a direct implication: content and outreach timed to early-week release has a structural advantage over Friday or weekend publication. The audience is at their desks, in work mode, with a concrete reason to pay attention.
What This Means for Dev-Tool Founders
Four things follow from this data.
Stars are qualified intent, not vanity metrics. 98.9% of stargazers never talk to you. But the 1.1% who do are a small fraction of a real signal, not the whole signal. The full pool of developers who starred your tool and judged it seriously is much larger than the ones who ever opened an issue. Tracking stargazers is tracking buyers.
The comparison window is your best moment. When a developer stars your tool and a competitor’s tool within 25 days — or within 24 hours — they are in active evaluation. That is the window where direct outreach, a well-timed trial, or a sharp piece of comparison documentation can influence the outcome.
Decision-makers are in the data. 13.8% of resolvable profiles are founders, VPs, or directors. LinkedIn resolvability at 42.7% means a meaningful fraction of evaluators can be matched to real professional identities. The signal is not just developer curiosity; it often represents organizational buying intent.
Winner-take-most means positioning clarity is not optional. 93.3% of all engagement goes to 10% of repos. If your tool is not already in the default shortlist for your category, differentiation needs to be sharp enough to pull developers off that list. Vague positioning does not do that.
For more on how to act on these signals in practice, see our post on GitHub signal intelligence for dev-tool startups.
Methodology
Data was collected and aggregated by LeadCognition, a GitHub signal intelligence platform for developer-tool companies. The corpus covers public GitHub Events API activity across 5,213 developer-tool repositories monitored by LeadCognition customers and from the platform’s own discovery index, spanning January 2024 through June 2026. All timestamps are UTC.
The 5.04 million events analyzed include: stars and watches (1.02M), push events (925k), issue comments (810k), pull requests (736k), pull request reviews (723k), pull request review comments (482k), issues (270k), and forks (204k).
Developer profile enrichment used public GitHub profile data only. LinkedIn resolvability (42.7%) reflects matching to public LinkedIn profiles via public signal — no scraping or private data. Title resolution (72,025 profiles) used declared job titles from GitHub bios and linked public profiles. No individual developers are identified or named in this analysis.
Corpus bias note: the repository set skews toward tools that developer-tool companies actively monitor. High-traffic, commercially relevant repositories are over-represented relative to the full population of GitHub repositories. The engagement concentration figures (top 1% absorbing 61.8%) reflect the distribution within this commercially active subset, not GitHub as a whole.
Feel free to cite these findings with a link to this page. We will keep this post updated as the corpus grows.
Data queried June 11, 2026 from LeadCognition production aggregates. You can explore developer evaluation signals for your own repositories at leadcognition.io/tools/.