The original Building in the Open post ended with a claim that was easy to write and much harder to stand behind, that we read all of it, respond to most of it, and merge more than you might expect, and a sentence like that is marketing until somebody counts it, so this post is the count, three months of GitHub traffic across the visorcraft organization measured against the promise, including the parts where the honest number makes us look slower than the promise sounded.
The numbers, without rounding up
Since July 8, fourteen issues have been filed across the organization by people who do not work here, and because that is also the all-time total, every external issue the org has ever received landed inside these three months, which tells you something about how quietly these repos sat before we started writing about them. Four pull requests came in from human beings over the same stretch, and that phrasing is doing real work, because the all-time external PR count is 121 and only fourteen of those came from humans; the other 107 are Dependabot, and a bot bumping clap from 4.6.4 to 4.6.6 is not community engagement, no matter how badly the quarterly deck wants it to be.
Of the fourteen human PRs all-time, ten merged, and here is the part we keep turning over: all ten came from a single contributor who went through IdleHands with a fine-toothed comb across two days in February, months before the original post was even written, finding real problems, duplicate tool calls, cache keys that missed their own pagination flags, shell pipelines that thrashed the same file, and every one of the ten was merged within minutes of being opened, which is where the “we merge more than you might expect” line actually came from. It was not a prediction, it was a memory, and one person who knows your codebase well enough to send ten good PRs in two days is worth more than a hundred drive-by stars, so if you are a small company wondering whether publishing is worth the triage cost, that ratio is the answer, one contributor like that pays for a lot of bot noise.
Where the traffic actually went
The engagement did not spread evenly across the 140 public repositories we counted at the September census, it clustered on exactly two kinds of repo, the ones where we are the only ones who ever did the work, and the ones people actually use day to day, and the gap between those two and everything else is the single clearest signal in the data.
Roamarr drew seven of the fourteen issues, five of them from one user who is very obviously planning real trips, and the requests read like a usage report rather than a wish list: city search that ignores GeoNames alternate names so “München” returns nothing, currency inputs that default to USD no matter what the user configured, grid tables that forget their page size on reload, a missing document type for national ID cards, and a translation request, which is the kind of issue you only file against software you intend to keep using. Two more Roamarr issues cover the AI email parser storing the wrong segment time on table-layout confirmations and the semantic search holding onto its embedding model’s memory after you turn it off, and both are the sort of bug that only surfaces when a stranger runs your code against data you never tested with.
The Kensington VeriMark reverse-engineering repo drew four issues and two of the quarter’s four PRs, which is a remarkable hit rate for a repository about a discontinued fingerprint reader, and the reason is simple: nobody else has published this protocol work, so everyone on the internet who owns this sensor eventually lands in our tree. One contributor sent a debug branch with an independent capture of the real enrollment protocol, blocked on the same undocumented status code that has us stuck, which means the notes we published because we wished someone had published them in 2014 did exactly what they were supposed to do, the next person to pick up the device started from our spec instead of from a raw USB capture, and now there are two of us staring at the same byte.
What the merge count actually means
“We merge more than you might expect” is historically true and currently slow, and both halves of that sentence belong in this report. All four human PRs from this quarter are still open as of this writing, and the reasons are mundane rather than dramatic: the Roamarr parser fix needs a review pass against the parser’s fixture suite before we trust it, the VeriMark debug branch is hardware archaeology that nobody can responsibly merge until the undocumented status code is understood, the VeriMark README build-dependency fix will almost certainly land once someone spends the ten minutes, and the Strix Halo benchmarking guide is good work that we want to verify against our own runs before it becomes documentation, because a reproducibility guide that we have not reproduced is just a rumor with formatting.
That is the honest shape of it. The ten-for-fourteen historical merge rate is real, the current quarter is zero-for-four so far, and the difference is not a change of heart, it is that the easy PRs merged fast in the past and the hard ones are the ones still sitting open, which is how every maintainer queue everywhere has ever worked.
What we have not said yes to
The hardest open item is a feature request for Windows support in LinSync, and it is still open because the truthful answer is “not soon” and we would rather leave the issue open with that answer than close it with a polite fiction. LinSync is a Qt 6 and Kirigami codebase with a Linux-first plugin host, and a Windows port is not a build target, it is a second maintenance surface, new sandboxing primitives, new packaging, new bug reports about paths with backslashes in them, and a small company says no to that not because the request is wrong but because the cost is real and ongoing. The request deserves an honest answer and a link to the architecture docs, not a roadmap entry we do not mean.
The other quiet no of the quarter is Dependabot itself, which we keep enabled and keep mostly unmerged in batches, because auto-merging version bumps is how you ship a broken release at 2 AM and manually reviewing 107 trivial PRs is how you stop doing the work the repos exist for, so they get processed in sweeps and the sweeps are slow and that is a deliberate trade, not an oversight.
What three months actually taught us
The fantasy that publishing alone produces contributors is dead, and good riddance; what publishing produces is a searchable artifact that the right two or three people per repo can find when they need it, and the scoreboard we would put on the wall after three months is one contributor whose two-day, ten-PR pass through a single repo still makes up our entire human merge history, one stranger who picked up a fingerprint protocol exactly where our notes left off, and seven real bug reports against a travel app that made it better for the next person. The 2008 version of this promise was “patches welcome” at the bottom of a SourceForge page, which meant nothing because nobody could build the project and nobody could see whether a patch would ever land; the 2026 version is a public repo with CI that runs on external PRs and a merge history anyone can audit, and the difference shows up precisely in whether contributor number one ever comes back for PR number ten. Ours did, and we will keep writing the check.
If you are running one of these and something misbehaves, file the issue. The queue is short, the read rate is one hundred percent, and the response rate is now a matter of public record.