What can you learn from a competitor's GitHub?

GitHub is the one competitor surface that engineers check constantly and go-to-market teams almost never open. That's backwards. A company's repos are written for developers, not for buyers — which is exactly why nobody thinks to sanitize them. Here are the six questions that come up every time I suggest adding GitHub to a competitive watchlist.

Does a company without an open-source product even have a useful GitHub?

Usually, yes. You're not looking for their core application — that's almost never public. You're looking for the supporting cast: client SDKs, API wrappers, Terraform providers, CLI tools, webhook helpers, docs sites, example apps, Slack and Zapier integrations.

Those repos exist to serve the product, so they move when the product moves. A new endpoint appears in the Python SDK before it appears in the changelog. A billing module shows up in the CLI two months before a pricing announcement. The support scaffolding leaks the thing it supports.

What's the highest-signal thing in the repos?

Names. Specifically, new names — a new folder, a new client method, a new enum value, a new config key.

Feature work generates vocabulary before it generates announcements, and that vocabulary is checked into version control by someone who is thinking about types, not about positioning. If a competitor's SDK grows a Workspace object where everything used to be scoped to Account, you're watching them build multi-tenancy for larger customers. Nobody wrote a blog post about it. Somebody wrote a class.

The second-highest signal is deprecation. A @deprecated decorator or a LEGACY_ prefix tells you what they've decided to stop defending, which is often more useful than what they're building. It pairs well with what their changelog is already leaking.

How do you read commit activity without over-reading it?

Carefully, because commit volume is the most seductive and least reliable metric on the page. A repo with 400 commits this month might be one engineer running a linter across the codebase. A repo with three commits might contain the entire quarter's strategy.

Read composition, not volume. Which repos are getting attention that weren't a year ago? Did the mobile SDK go quiet for six months? Did a repo that had one maintainer suddenly acquire four? Sustained multi-person attention on a previously dormant repo is a real staffing decision, and staffing decisions are the honest version of a roadmap. Cross-reference it against what their job postings say and you usually get the same answer twice.

What do outside issues and pull requests tell you?

They tell you what customers are hitting. Issue threads on a public SDK are a support queue that nobody thought to make private — with reproduction steps, company email addresses in the thread, and often a maintainer explaining exactly why the thing is hard to fix.

Look for the issues that stay open. An old, popular, unresolved issue with maintainer replies that keep saying "on our radar" is a durable gap, not a bug. Those are the ones worth putting in front of sales. A thread where three enterprise users are asking for SCIM support and getting polite deferrals is worth more than any feature comparison table you could build.

Isn't this just changelog-watching with extra steps?

It's earlier. A changelog is a publishing decision — someone chose what to say, when to say it, and how to frame it. A commit is a work artifact. The gap between the two is typically weeks and sometimes months, and that gap is the entire value.

It also survives silence. When a competitor goes quiet publicly, the repos usually don't, which makes GitHub one of the few surfaces that keeps producing signal during the periods you most want to know what's happening.

How often should you actually check this?

Not manually, and not on a calendar. This is the failure mode of every GitHub-watching plan I've seen: someone commits to a Friday review, does it twice, and abandons it because most weeks contain nothing. Then the one week that mattered goes unread.

GitHub's own watch and release notifications cover part of this for free — turn them on for the two or three repos that matter most. Beyond that, the general problem is the one Seeto exists for: it monitors public surfaces continuously and surfaces the diffs as discrete change events, so a new SDK method or a rewritten README arrives as something that happened rather than something you have to go looking for. It won't read the code for you or tell you what a commit means — that judgment is yours, and it's the part worth your time. What it removes is the checking.

The best version of this habit isn't a weekly ritual. It's a competitor shipping a Workspace object on a Tuesday, and you knowing about it on Tuesday.