GitHub's issue count hides a 14-to-1 PR backlog

GitHub tells you Osmantic/ODS has 1,482 open issues. That number is wrong in the way that matters. It's actually 1,384 open pull requests plus 98 open issues. GitHub's open_issues_count field folds both into one count, so a repo that looks like it's drowning in bug reports is actually drowning in code nobody's reviewed yet.

That's a different problem with a different fix. A maintainer swamped with bugs needs to triage and reproduce. A maintainer swamped with PRs needs review bandwidth, more maintainers, stricter contribution gates, or a willingness to say no to features nobody asked for. The headline number points at the first problem. The real ratio, fourteen PRs open for every issue open, points at the second.

ODS turns a machine into a local AI server: LLM inference, a chat UI, voice, agents, workflows, RAG, image generation. It has 5,206 stars and was pushed on August 31. Its last tagged release, v2.6.0, went out July 28, over a month before that push, while the PR queue kept growing.

I don't know why ODS has this ratio specifically. It could be a popular project pulling in drive-by contributions faster than anyone can merge them, or a small team that stopped reviewing. The repo doesn't say. What I do know is the fix for reading it: check the split with the search API before you judge a repo by its issue count. GitHub gives you one number where you need two, and that one number tells you the wrong story every time the split is this lopsided.