How to Find Product Gaps in Open Source Tools
Rank gaps in open source tools by the trailing mention window instead of lifetime issue counts, filter for breadth across projects, and read the four shapes a real gap takes.
Alessio Persico Founder of EchoSift 
On EchoSift’s 28 July 2026 snapshot, two open source pain topics sat within eight mentions of each other by lifetime volume. Low Visibility Issues in Light Mode had accumulated 66 mentions across 25 distinct projects. Frustrations with CI/CD and Deployment Reliability had 58 across 31. Sort that list by volume and the first one wins the top slot. Read the same two rows through their trailing mention window and the picture inverts: the light-mode topic logged 0 mentions in the last period against 1 in the period before, while the CI/CD topic logged 16 against 10. One of those gaps quietly closed. The other is being filed against this week.
Picking apart an open source project for product opportunities usually starts with the issue tracker sorted by reactions or by age, which surfaces the loudest complaints of the last three years rather than the open ones. What follows is the ordering that survives contact with a real backlog: rank by the window first, filter by breadth second, then classify the gap by its shape before writing any code. The wider discipline of noticing rather than brainstorming is covered in how to find startup ideas, and the mechanics of reading an individual thread are in SaaS ideas from GitHub issues.
Lifetime counts rank history, the window ranks the present
Every aggregate on a mature issue tracker is cumulative, which means it keeps paying out long after the underlying problem stopped existing. A theming bug filed by 25 separate projects in 2024 still reads as a 25-project problem in 2026, even if the upstream library shipped a fix eighteen months ago and every one of those projects has moved on.
The correction costs two numbers: mentions in the trailing window, and mentions in the window before it. Their ratio tells you the direction, and their absolute size tells you whether the direction means anything. Three readings from the same snapshot make the categories concrete:
| Signal | Lifetime | Window, previous to last | Read |
|---|---|---|---|
Low Visibility Issues in Light Mode | 66 | 1 to 0 | ✗ Cooled, do not build |
Improve Project Documentation for Onboarding | 260 | 36 to 6 | ~ Cooling fast, investigate why |
Frustrations with CI/CD and Deployment Reliability | 58 | 10 to 16 | ✓ Still open, accelerating |
The middle row deserves a pause. Improve Project Documentation for Onboarding is the largest topic in the sample by a wide margin, with 260 lifetime mentions and 139 distinct projects behind it, and it dropped to a growth ratio of -0.83 as reports fell from 36 to 6. A decline that steep on a topic that large has three possible causes, and only one of them is good news for a builder. Either the problem got solved by a tooling change that landed broadly, or the people who cared stopped filing because nothing ever came of it, or the classifier reshuffled the topic boundary underneath you. Onboarding documentation does not get solved industry-wide in one window, so the second cause is the live hypothesis, and a gap people have given up reporting is still a gap. It just cannot be found by counting.
Contrast that with the CI/CD row, which rose while the baseline it sits in was falling.
A topic rising against a falling baseline is doing something that the aggregate is not.
Four shapes a gap takes inside a healthy repository
A well-run project does not leave obvious holes. Maintainers triage, label, and close, and the residue of that process is where the openings live. Four shapes recur, and none of them appear as a blank cell on a feature comparison grid.
Declined scope. An issue closed as out of scope, then reopened or re-filed by three other people. The maintainer’s reasoning is usually correct for the project and irrelevant to the person who needs the thing. GitHub’s own open source guides treat saying no as a maintenance skill, and every principled no is a demand signal with a timestamp on it.
The pinned workaround. A shell snippet buried in comment 47 that half the thread has copied into their own repo. Nobody owns it, nobody versions it, and it breaks on every minor release. Reaction counts on the comment, rather than on the issue, are the tell.
Plugin dumping. The core project punts a job to the plugin ecosystem, and the plugin that was supposed to handle it has not shipped a release in two years. The documentation still links to it. This one is easy to verify and easy to underestimate.
Only fails in CI. Works on a laptop, breaks on a runner, gets closed as flaky. The snapshot has a small clean example: Broken CI workflow for automated merging shows 18 lifetime mentions with 4 in the last window against 0 in the previous one, across 6 distinct projects. Small, recent, and attached to a budget, because build minutes cost money in a way that theming annoyances do not.
Breadth is the second filter, not the first
Recency alone will hand you somebody’s bad afternoon.
Recent, urgent, and one project deep
Challenges with CLI Connectors and Authentication recorded 9 mentions in the last window against 0 in the previous one, off 10 lifetime mentions, and every single one came from 1 project. That is a genuine, currently-burning problem with exactly one sufferer. Building for it means consulting, not shipping a product.
Put the same rows on two axes and the quadrants sort themselves. Enhancing Contributor Documentation and Guidelines sits in the useful corner with the top composite score in the sample at 95, 39 lifetime mentions and 28 distinct projects behind it, still logging fresh reports. The CI/CD topic sits further right with 31 projects and rising volume. The single-project CLI topic sits low regardless of how recent it is.
Breadth is doing a specific job here: it separates a project’s internal debt from a shared constraint that several independent teams hit. That distinction also governs whether anyone will pay, which is the subject of finding underserved developer niches.
A protocol for one repository
Pick a project you already use in anger. Familiarity beats market size at this stage, because you can tell a real complaint from a support question in one read.
- Pull closed issues, not open ones. Query the tracker for issues closed in the last 90 days with a resolution label like
wontfix,invalid, orout-of-scope. The GitHub issue search syntax handles this withis:issue is:closed label:wontfix. Open issues tell you what the maintainer has not gotten to. Closed-as-declined tells you what they have decided never to do, which is the part that stays true. - Timestamp every hit. For each candidate, count comments in the last 30 days and the 30 days before that. Discard anything that scores zero on both. The rule is unforgiving on purpose, and it removes roughly the same set of rows that the light-mode example represents.
- Cross-check outside the repo. Search the same phrasing on Stack Overflow and Hacker News. A gap that only exists in one issue tracker is a project decision. A gap that shows up across the 4 sources EchoSift ingests is a market condition. The snapshot logged 2,889 new signals in the trailing 7 days, and the ones worth acting on are the ones that appear in more than one place.
- Read the governance, not just the code. A maintainer who declined on architectural grounds will decline again. One who declined for lack of time may merge your patch and erase your product. The leadership and governance guide is a good primer on telling those two apart from public artefacts.
- Check what the licence permits. Forking is legal under any OSI-approved licence, and a fork is rarely a business by itself. The interesting position is usually adjacent: hosting, compliance, observability, or the migration path, rather than a competing copy of the tool.
Three ways the window reading misleads you
| How the window misleads | What it looks like | The correction |
|---|---|---|
| Release cadence masquerades as demand | ✗ Volume spikes for two weeks after a major version, then decays whether or not anything was fixed | Compare a window against the same phase of the previous release cycle, not against the calendar |
| Triage sweeps look like resolution | ✗ A maintainer closes 400 stale issues in an afternoon and the curve dives | Check whether the close events cluster on a single day |
| A partial day reads as collapse | ✗ 3,451 mentions on 27 July 2026 against 1,942 for 28 July, read before the day was half over | Confirm the last bucket in your series is a closed period before you let it vote |
Anyone extrapolating from that second figure would have concluded the ecosystem had gone quiet.
Turning the gap into something buildable
A verified gap gives you three facts: a problem that is currently being reported, a set of independent projects reporting it, and a maintainer position explaining why it will stay unfixed. Turn that into the smallest artefact that tests willingness to pay, which for developer tools is usually a working command-line utility plus a page describing the failure mode in the exact words from the thread.
Two rules keep the exercise honest
Do not build the fork, build the thing the fork would need. And do not solve the whole macro area: DEVOPS_INFRA covers everything from runner cost to deployment rollback, while the row that earned its place in your list was one specific failure with 16 recent mentions behind it.
Public pricing for EchoSift is $39/month, and the mechanics above work perfectly well by hand on one repository. What does not scale by hand is the cross-source check in step three, since holding 33,887 signals across GitHub, Stack Overflow, Hacker News and Bluesky in your head is not a weekend activity.
The short version
Rank by the trailing window, not by lifetime volume, because a cumulative count keeps paying out on problems that ended. Apply breadth as a second filter to separate one project’s debt from a shared constraint. Classify the gap by shape, since declined scope and CI-only failures behave very differently from a missing feature. Then confirm the last bucket in your series is a closed period before you act on its direction.
This article was drafted with AI assistance and reviewed against EchoSift’s proprietary signal data before publishing.
