Open source doesn't have a generosity problem. It has a routing problem.

Right now, across eight languages, 25,987 open issues carry a help wanted label put there by the person who runs the repo — and have gone three weeks or more without a single reply.

Read that again. Not unresolved. Unanswered. Nobody said anything at all.

The reflex is to blame apathy. It isn't apathy. The people who could answer those issues are online today, doing work they find less interesting, and they have never seen them. Open source is not short of generosity. It is short of routing.

The discovery surface is broken in a specific way

Every "contribute to open source" guide points at the same places: the good-first-issue lists, the curated boards, the seasonal events. Those surfaces are picked clean within hours and they optimise for the wrong thing — they rank issues that are easy, not issues that are stuck.

Meanwhile GitHub search will happily return ten thousand open issues and tell you nothing about the only two questions that matter: did a real maintainer ask for this, and is anyone already on it?

The primitive: filter by who asked

There is a field sitting in every GitHub search result that almost nobody uses. author_association tells you whether an issue was opened by the repo's owner, a member, a collaborator, or a passer-by.

That one field turns a vague pile into a specific claim. A maintainer asked for help here, and nobody came. Combine it with zero comments, no assignee, and a three-week floor, and the noise falls away — no popularity heuristics, no curation, no stars.

Which matters, because the star filter is a trap.

The stars: qualifier silently lies in issue search

GitHub's issue search does not support stars:. It does not reject it either. It matches the number against the issue number.

stars:>20 returns only issues numbered 20. Raise it to 100 and you get issue #100. A control query with stars:>7 returned thirty results, every one of them issue #7.

Two hours went into believing those repos were machine-generated spam farms — every result carrying the same issue number is a convincing pattern. They were real maintainers whose twentieth issue happened to be an unanswered ask.

If you are building anything on GitHub's issue search, repo quality has to come from somewhere else: author_association, sorting by updated, or a GraphQL query that actually returns stargazerCount.

Put the model where the friction is

Once the list is honest, the blocker moves. It stops being find something and becomes work out what this person actually wants, and write the first sentence.

That is the part that eats an evening. Reading an issue written in a codebase's private vocabulary, deciding whether you can genuinely move it, and then composing an opening that offers help without over-promising.

So that is where the model goes — not on discovery, where a well-shaped query already wins. Search finds the ask; the model translates it into plain words, says why it fits you, and drafts a reply that offers exactly one concrete step and promises nothing else.

Then it stops. The draft is yours to edit and post yourself. Nothing is posted on your behalf, and there is no write access to GitHub anywhere in the system. Generosity is a human act; the tool only removes the friction in front of it.

What to take from this

If you maintain something: your help wanted label is a routing request, and it is currently being dropped. Say what you want in the first two lines of the issue body, in words someone outside your codebase can parse. That single habit is worth more than any tag.

If you build tools: the interesting unit is not the open issue. It is the unanswered ask — and the field that makes it addressable was in the API the whole time.

Try it: unanswered.hyperdrift.io — tell it what you know, and see who has been waiting.

Building something where the hard part is reach rather than code? Talk to us.