GitHub issues sales signals: the source your tools can't query

A GitHub issue is written by someone who already adopted a tool, put it into production, and hit the wall at the edge of it.

Nobody files an issue about software they're shopping for. They file it about software they're already running. GitHub issues sales signals start there.

A Reddit thread asks the room what to use. An issue reports what broke, with a stack trace, a version number, a public handle, and a title the author wrote to be findable by the next person with the same problem.

We queried the GitHub issues search API on July 30, 2026, over the trailing twelve months (created:>2025-07-30). In issue titles: roughly 4,763 for "alternative to", 3,060 for "switching from", and 1,138 for "migrating from". Roughly 4,852 issues mentioned "migrate away from" anywhere in the text. GitHub's search totals are documented as indexed approximations that exclude private and deleted repositories, so every one of those is a "roughly". The query URL is the method. Rerun it and the number moves with the window.

What makes a GitHub issue a buying signal?

The author has already chosen a tool, shipped with it, and found its limit. The report names the product, describes the failure in technical detail, and carries a public identity. No other artifact on the open web documents an unmet need that precisely, or that early in the decision to replace something.

Look at what that pre-qualifies. Budget, authority, and fit are settled questions, because the tool is already in the build. What's unsettled is whether it keeps its job, and that's a narrower and more useful uncertainty than anything a firmographic surge score resolves.

There's also a structural reason this genre concentrates on GitHub. Stack Overflow's Help Center states that "[q]uestions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic," so the tool-choice conversation was pushed off the largest developer Q&A site by rule. Some of it reappeared in issue trackers, phrased as feature requests. Meanwhile the surface keeps growing. GitHub's Octoverse 2025 reports issues created rising 11.3% year over year, from a monthly average of 15.7 million to 17.5 million.

This is the same class of buying signal you'd look for anywhere. What changes is the resolution.

What do GitHub issues sales signals look like?

Five shapes carry most of the value: a feature request that names a competitor, a "does X support Y" question, a migration or compatibility issue, an issue closed as wontfix, and dependency deprecation churn. Each resolves to a different fact about the buyer. None of them is an invitation to reply in the thread.

Signal shape	What it tells you	How to act
Feature request naming a competitor	The author knows both products and can articulate the gap in one sentence	Competitive positioning input. Quote the gap on your comparison page, never in the thread
"Does X support Y?"	An evaluation in progress with a specific blocking requirement	Answer it in your own docs, publicly, where search will find it
Migration or compatibility issue	A move is underway and something is in the way	Highest urgency. Reach the person only through a channel they opened
Closed as wontfix	The vendor has formally declined to build it. A dated, named, unmet need	Read the whole reply thread. It names what people did instead
Dependency deprecation or EOL churn	A forced decision with a deadline attached to it	Watch the upstream repo, not the downstream one. The trigger is upstream
Stale issue, open with no maintainer reply	The same unmet need, delivered by silence rather than a label	Check reactions and subscriber count. Volume of want is the measure

Someone asking whether a tool supports SAML, or ARM builds, or a specific Postgres version, has handed you their hard requirement without being asked. That belongs in your own documentation within the week.

Why is a closed wontfix the sharpest signal on GitHub?

A closed wontfix is an unmet need the incumbent has formally declined to meet, in writing, with a date, a maintainer's stated reason, and a thread of people who wanted it. A complaint is one person's opinion on a bad day. A wontfix is a roadmap decision the vendor published against itself.

Everything you'd otherwise pay for sits on that one page. You get the capability gap in the incumbent's own vocabulary, the reason it won't close (which tells you whether the gap is philosophical or a resourcing problem), and a reaction count that works as a rough census of how many people are blocked by it.

The stale issue is the slower version of the same thing. No label, no closure, no maintainer reply in 18 months, reactions quietly accumulating. Silence is a decision too, and it carries the same information with less honesty attached.

Now the discipline that keeps this from becoming nonsense. Most wontfix closures are correct. A maintainer writing "out of scope for this library" is usually protecting a codebase from becoming everyone's dumping ground, and treating that as a market gap will produce a product nobody wanted. The tell is what happens underneath the close. When people reply with what they did instead, which fork they took, which tool they moved to, that's a real gap. When the thread ends with "fair enough, closing," it was scope.

Date it before you act on it. A feature declined in 2022 may have shipped since under a different name, and arriving with a two-year-old grievance is worse than not arriving at all. A declined request with 50 reactions is a roadmap input and a comparison-page line long before it's a lead.

Is it against GitHub's rules to use issues for sales?

Reading is permitted and GitHub says so in its Terms. Pitching in the thread is prohibited by name. The Acceptable Use Policies state that you may not advertise in other users' accounts, including by posting bulk content in issues, and a separate policy treats off-topic comments and excessive notifications as sanctionable behavior.

The permission is unusually explicit. GitHub's Terms of Service, section D.8, effective April 27, 2026:

These Terms do not restrict lawful access to or use of the contents of public repositories by third parties, or by GitHub.

The prohibition is equally explicit. GitHub's Acceptable Use Policies, section 10:

You may not advertise in other Users' Accounts, such as by posting monetized or excessive bulk content in issues.

The separate Disrupting the Experience of Other Users policy lists "Posting off-topic comments" and "Engaging with platform features in a way that causes excessive notifications for other users," and warns that "GitHub staff may take further restrictive action against accounts that are engaging in these types of behaviors." The API terms close the other door. You may not use the API to download data for spamming purposes, including selling users' personal information to recruiters, headhunters, and job boards. AUP section 8 adds a duty to respond promptly to "do not contact" requests.

The policy is downstream of the real reason. An issue tracker is a maintainer's work queue, and it's where unpaid people triage other people's problems. Every comment you add fires a notification to everyone subscribed, so a pitch aimed at one person taxes the attention of 30, most of whom are volunteers. There's a documented case of what happens when volume lands in that inbox. DigitalOcean's own Hacktoberfest 2020 recap counted 621,104 pull requests, of which 34,595 were not accepted by a maintainer, 9,598 were labeled spam or invalid, and 172,599 went to repositories that had decided not to participate. DigitalOcean changed the rules mid-event.

So, plainly: don't comment your product in someone else's issue. You'll be blocked, reported, and screenshotted, and you'll deserve all three.

Two things are fine. If the issue is on your own repository, answer it, because that's your house and the person came to you. If it's on someone else's, treat the issue as market research and reach the person through a door they opened themselves, such as a contact link on their profile or a thread they started somewhere vendors are welcome. Hacker News works the same way, for the same reason.

Why is GitHub issue search so under-served?

The blocker is the query itself. GitHub's search API rejects any query with more than five AND, OR, or NOT operators, caps queries at 256 characters excluding operators and qualifiers, and returns at most 1,000 results per search. A realistic competitor-migration query needs more operators than that, so it can't exist as one saved search.

Count it out. A product name, plus three aliases people use for it, plus migrate or switch or replace. That's six operators before you've scoped a date range, and GitHub's documented limits reject it. Around that sit 100 results per page, 30 requests per minute authenticated, and a rule that searching more than 10,000 repositories forces scoping to an org, account, or repository.

One part is generous. Free-text issue search covers the title, body, and comments by default, so the phrase you want doesn't have to be in the title to be found.

What that leaves is decomposition. Many narrow queries instead of one broad one, run on a schedule, results merged, deduplicated, and remembered between runs so the same issue doesn't resurface every morning. That's software rather than a saved search, and it's the honest reason this source stays under-served.

This source is under-served, not unserved, and it is worth saying so plainly. Syften has monitored GitHub alongside 15 other sources from $29.95 a month for years. The accurate version of the claim is narrower: Reddit-only tools see none of this, and a person running hand-built GitHub searches can't cover the query space that matters.

That gap is what LeadSurface works on. It watches GitHub issues alongside Reddit, Hacker News, Stack Exchange, and Discourse forums, classifies each item rather than pattern-matching a keyword, deduplicates by URL so an issue you already read stays read, and hands you the few worth acting on with the source thread attached. Nothing goes out on your behalf. It never comments in an issue, it doesn't enrich anyone to an email address, and do-not-contact is a switch rather than a promise.

You can test the premise before dinner. Search GitHub issues for your closest competitor's name plus "alternative to", filtered to the last 90 days, and read every result. Then read the closed ones.

The open issues tell you what people want. The closed ones tell you what your competitor already refused to give them.