Short answer
A ready-to-switch developer is one whose public GitHub activity shows active dissatisfaction with an incumbent tool: migration-named issues, forks with integration-code changes, commits that remove the incumbent's dependency, issue comments citing alternatives, or a sudden spike in activity against a competitor repo while activity against the incumbent drops. Reach out within 48 hours of the trigger with a specific technical observation — not a sales pitch — and reply rates run two to three times category-cold.
TL;DR
- Five public GitHub patterns flag switch-intent: migration issues, competitor forks, removed dependencies, issue-comment citations, cross-repo activity shifts.
- A migration-named issue is the lowest-false-positive single signal in the DevTool intent stack.
- Confirm switch-intent with a second signal before sending outreach — single signals look like category-cold.
- Switch windows are short. Reach out within 48 hours.
- First-touch messages must cite the specific event; generic framing collapses reply rates.
- Doing this at scale requires a near-real-time GH Archive index, not manual monitoring.
Contents
What "ready-to-switch" actually means
A ready-to-switch developer is one whose public GitHub activity contains at least two independent signals of dissatisfaction with an incumbent tool in the 30 days before you look. The two-signal rule exists because single signals on a competitor repo are indistinguishable from category-cold curiosity. Dissatisfaction is the word that matters: not just interest in an alternative, but evidence of friction with what the developer has today.
Dissatisfaction expresses itself in five public patterns. Each one is observable in GitHub data if you know what to look for, and each one appears in the sections below with its recognition rule and expected false-positive rate. Building this recognition into a repeatable process is how you shift from episodic switch-intent outreach to a durable compete motion in your developer signal intelligence stack.
This playbook applies inside a competitor's ecosystem specifically. Stars on your own repo are outside the scope — they are adoption signals, not switch signals. For a broader taxonomy, see GitHub activity as a buying signal.
Pattern 1: Migration-named issues
Migration-named issues are issues whose title or body explicitly references switching from one tool to another. Examples: "Migrating from Datadog to OpenTelemetry", "Replace X with Y in the logging layer", "Alternatives to <incumbent> that support <feature>".
This is the lowest false-positive single signal in DevTool intent. The developer has publicly stated both the direction of the switch and the reason. False positives are essentially zero — the handful of cases that aren't real switch-intent are academic comparisons or library-choice posts, which are easy to filter on by actor seniority.
How to find them: search issue titles and bodies on competitor repos for migration keywords (migrate, migrating, migration, switch, switching, replace, replacing, alternatives-to). Combine with a competitor name list and a 30-day window.
Pattern 2: Competitor forks with integration changes
A fork of a competitor repo where subsequent commits modify integration or configuration code is a strong switch-intent signal. The developer is not just exploring — they are modifying the tool for their environment, which almost always means they plan to run it.
The asymmetry to watch for: if the same developer also has commits that remove integration code for an incumbent in a different repo, the switch is in motion. One-sided forks (fork + modify without incumbent activity) are adoption, not switch. Two-sided activity (fork one tool + remove another) is the switch you want to catch.
Pattern 3: Removed dependencies
A commit that deletes a package line from a public manifest — package.json, pyproject.toml, go.mod, Cargo.toml — is direct evidence that the developer has chosen to stop using a specific tool. If the same commit or a nearby commit adds a competitor's dependency, the switch has happened or is happening.
Removed dependencies are harder to find than added ones because most intent tooling indexes additions. But they are arguably more valuable: addition is the result of evaluation; removal is the completion of switch. A team that catches the removal while it is still on a feature branch — before the merge — has an extremely high-signal outreach moment.
Pattern 4: Alternatives cited in comments
Issue or PR comments that cite a competing tool by name — especially in the context of frustration with the incumbent — are public complaint signals. "We're looking at <alternative> because <incumbent> doesn't handle <use case>". The frustration language is what distinguishes this from benign discussion.
These are higher-volume than migration-named issues and have a slightly higher false-positive rate (~10-15%), but the signal-to-noise is still strong. The rule-of-thumb filter: require the comment to contain both a frustration keyword (broken, slow, expensive, doesn't support, can't, workaround) and a competitor name within the same paragraph.
Pattern 5: Cross-repo activity shift
The most sophisticated pattern — and the hardest to compute — is a shift in the same developer's activity from one tool's ecosystem to another over a 30-day window. Week 1: three stars and a fork on the incumbent. Week 3: no incumbent activity, but forks and an issue on a competitor. That inversion is a silent switch in progress.
No single event in the shift is unusual. The shape of the series is. This is where real signal intelligence tooling beats manual monitoring — human operators see individual events, not curves. The ecosystem snapshot tool and repo intent score tool surface these across a whole category at once.
Outreach rules that actually work
Spotting the signal is half the work. Converting it into a reply is the other half. Three rules from teams that run this motion at scale:
- Reach out within 48 hours of the triggering event. Switch windows are short — the developer picks a new tool in weeks, not months. Outreach at 14+ days frequently catches a post-decision developer.
- Cite the specific event in the first touch. "Saw your migration-from-X issue on <repo> — wanted to ask about <specific pain you mentioned>." Specificity is the only thing that earns reply rates above category-cold.
- Lead with a technical observation, not a pitch. Reference the code, not the pipeline. Developers reply to peers; they filter out sellers. The right first touch reads like a colleague who happened to watch the same issue.
Reply rates on well-executed switch-intent outreach run 15–25% — roughly 3× category-cold outbound for the same developer personas. For the full playbook, see the developer outreach playbook.
Frequently asked questions
What is a ready-to-switch developer?
One whose public GitHub activity shows at least two signals of dissatisfaction with an incumbent tool in a 30-day window.
What's the single strongest switch-intent signal?
A migration-named issue — one that explicitly references switching from one tool to another. Near-zero false-positive rate.
How fast should I reach out?
Within 48 hours of the trigger. Switch windows run weeks, not months.
What does a good first-touch message look like?
Cite the specific event, lead with a technical observation, skip the sales framing. Reply rates depend on specificity.
How do I find these at scale?
Index GH Archive against a competitor repo set and search issue/comment bodies for migration-plus-competitor keywords in a 30-day window.
What's the biggest mistake DevTool sales teams make here?
Treating a single fork or star on a competitor repo as switch-intent. Require a second signal before you send outreach.
Catch every switch in your category
LeadCognition indexes the GH Archive stream and surfaces ready-to-switch developers in your competitors' ecosystems — in real time. Start the free trial.
Start free →