Why GitHub OAuth, Not Email — The Case for Identity-Gated Reviews

If you've searched for SaaS reviews in 2025-2026, you've seen the pattern. Five-star reviews that rhyme with each other. Strikingly similar phrasings of "this tool transformed our workflow." Reviewer profiles with one review and a name like "Sarah K." The 2023+ explosion in LLM accessibility made review-spam-at-scale economically irresistible. By 2025 the major review platforms' moderation teams were drowning.

The structural problem: email verification doesn't prove identity. It proves you control an inbox. With $5 of LLM credits and a list of disposable email providers an adversary can generate hundreds of plausible reviews per hour. Moderation can flag obvious patterns but the long tail of subtle fake reviews dilutes signal faster than humans can clean it.

A GitHub account that's 6 months old, has 8 public repositories with commits, and is a public member of two organizations cost something to create. The cost isn't zero — adversaries can build aged accounts ahead of time — but it's 3-4 orders of magnitude higher than email verification. The economics shift from "industrialized review farm" to "specialized adversary willing to invest months ahead of time."

That cost shift is the moat. We don't prevent all fake reviews. We make most-fake-reviews uneconomical.

Lose: reviewer cohort size. Most software buyers don't have GitHub accounts. Sales-led platforms (executives evaluating vendors) skew non-developer. We're explicitly not for them — GitShowcase is by-and-for developers and engineering teams. The reviewer cohort is smaller than G2's but more relevant for the audience we serve.

Gain: trustworthy signal. When you read a GitShowcase review you know the reviewer ships code. The role and stack tags are self-attested but the GitHub identity behind them is verified. The aggregate scores reflect what actual practitioners think, not what marketing teams paid for.

The serious attack vectors:

• Aged sock-puppet accounts. Build GitHub accounts now, use them in 2027. Mitigated by graph-analysis detection of structural anomalies in follow/contribution patterns.
• Compromised real accounts. Adversary takes over an established developer's GitHub account. Mitigated by requiring 2FA on review submissions and flagging review patterns inconsistent with the account's history.
• Vendor-employee reviews without disclosure. Mitigated by cross-checking reviewer GitHub org membership against the tool vendor's GitHub org.
• Coordinated organic positive reviews. An employee asks ten developer friends to leave 5-star reviews. Hard to detect technically; mitigated through editorial vigilance on suspicious score-cluster timing.

None of these are perfectly solvable. All are several orders of magnitude harder than the email-verification baseline. Over time we expect to add more layers — review velocity per reviewer, behavioral biometrics, temporal pattern detection — but the foundational change is identity-at-signup.

If you ship a developer tool: your GitShowcase reviews aren't something you can buy. They reflect genuine user experience, including critique. The pros and cons we surface come from what verified developers actually say. This is uncomfortable for vendors used to massaging review platforms — and it's the entire point of the platform.

If a review on your tool seems unfair, the dispute mechanism exists. It's public, logged, and reviewed editorially. We side with verified reviewer evidence by default; vendors can argue against specific factual errors. We don't remove negative reviews because they're negative.