The industry has converged hard: one version control system, a handful of hosting platforms, and one review workflow. That convergence is worth understanding because it explains where the pain is. When everyone runs Git, hosts on a forge, and gates merges behind pull-request review, the review step becomes the shared constraint. This note maps the market share, the startup defaults, and the mechanics of the bottleneck that sits on top of all of it.
The version control landscape is a near-monopoly
Git won. Stack Overflow’s 2025 Developer Survey puts Git at 93.9% of professional developers. The alternatives survive in specific niches, not general use:
- Perforce (Helix Core) — centralized, commercial, dominant where repositories hold huge binary assets. Game studios are the canonical case: roughly a quarter use Perforce or similar specialized systems, while most of the rest run Git with the Large File Storage (LFS) extension. The draw is handling multi-gigabyte art and build artifacts that Git’s model handles badly.
- Mercurial — distributed like Git, cleaner UX, but stuck near 2% share. It hangs on at large engineering orgs with legacy tooling. Mozilla, long a flagship Mercurial user, has been migrating to Git and GitHub.
- Sapling — Meta’s source control, derived from Mercurial, built to make monorepos with millions of files usable. It exists because Git’s performance degrades at that scale, not because teams reject Git’s model.
The pattern: challengers win only where Git has a concrete technical failure (giant binaries, giant monorepos). Everywhere else, the default is Git. See Stack Overflow’s survey of the holdouts for the long tail.
GitHub leads, GitLab holds enterprise ground
Git is the protocol; the forges are the businesses. The gap between the top two is large:
| GitHub | GitLab | |
|---|---|---|
| Source-code-management market share | ~38% | ~16% |
| Registered users | 180M developers, 630M repos (late 2025) | 50M registered (FY2026 earnings, Mar 2026) |
| Stack Overflow 2025 “most desired” | 59.3% | 22% |
| Stack Overflow 2025 “most admired” | 75.8% | 42.1% |
Share figures are Datanyze SCM market data; desirability figures are the 2025 survey. GitHub is roughly 2-3x GitLab on nearly every adoption axis.
The interesting split is not the top-line numbers but the positioning. GitHub owns mindshare and the open-source ecosystem. GitLab competes as the single integrated DevOps platform (SCM, CI, security scanning, deployment in one product), and it lands with enterprises: GitLab reports more than half the Fortune 100 as paying customers, and it was named a Leader in Gartner’s 2025 Magic Quadrant for DevOps Platforms. Bitbucket, third, retains share mostly inside Atlassian-heavy and regulated shops.
Why startups default to GitHub
For an early-stage startup the platform decision is dominated by one variable: onboarding cost. Every engineer already knows GitHub. The conventional recommendation is GitHub for pre-Series A teams optimizing for speed, hiring, and ecosystem access (Actions, the marketplace, Copilot, the entire open-source graph).
GitLab’s counter-pitch to startups is narrower and it is honest about it: GitLab targets regulated startups (fintech, healthtech, govtech) that will hit enterprise security due diligence early. A built-in compliance and security posture can shorten those sales cycles versus stitching together point tools. The commonly observed path is a hybrid one: GitHub for the developer workflow, bolt-on security tooling through Series A, then a consolidation decision somewhere north of 100 engineers when the integration tax becomes visible.
The takeaway for the market: startups are GitHub’s acquisition funnel. Familiarity compounds. Each cohort of developers trained on GitHub makes it the safer default for the next startup, which trains the next cohort.
Pull-request review is the shared bottleneck
Standardization has a cost. Because nearly every team gates merges behind pull-request review, the review queue is where flow stalls across the whole industry. This is the AI SDLC Bottleneck read at the tooling layer: the constraint sits at review, and the forge workflow institutionalizes it.
The measurements are consistent, though most come from engineering-analytics vendors (LinearB, Faros, Jellyfish) whose product is built on review being the measurable constraint, so read the vendor numbers as directional and lean on the independent ones (Google, Microsoft, DORA) for the load-bearing claims:
- Wait, not work, dominates. PR pickup (the idle time before anyone starts reviewing) is repeatedly identified in LinearB’s cycle-time data as the number-one contributor to cycle time, with PRs frequently sitting 4+ days before pickup. The bottleneck is a queue, not the reviewing itself.
- Benchmarks are tight. LinearB’s analysis of nearly 2,000 teams and 847,000 branches puts elite review time under 6 hours and recommends a ceiling of 12: a PR opened in the morning should be reviewed by end of day. Elite teams merge 50% of PRs within 24 hours and 90% within 48.
- Size drives everything. Best-performing teams keep PRs under ~225 lines changed; strong teams under 400. Large PRs force reviewers to parse multiple kinds of change at once, and cycle time balloons.
- It is a real tax on senior time. Google’s engineering-productivity research has put review at 6.4 hours per developer per week; Microsoft Research cites 6-12 hours in larger orgs. Review capacity is scarce and concentrated on the same senior engineers, which is exactly what makes it a constraint.
Small batches are the standard relief valve, which is why Trunk-Based Development and Work-in-Progress Limits show up as the recommended countermeasures: shrink the unit of review and cap how many reviews are in flight so the queue drains. Merge queues automate the integration side of the same problem.
AI is overloading the constraint, not removing it
The mechanism, and the current live debate: AI coding assistants attack the wrong step. They cut the cost of writing code well before they cut the cost of trusting it, so they pump more volume into a review stage that was already the bottleneck. This is the tooling-layer version of the finding in Writing Code vs. Shipping Code: AI Productivity Across Tool Generations and shows up in the DORA Metrics data.
Faros AI’s 2026 study of 22,000 developers across 4,000 teams found that teams with heavy AI use:
- created 98% more pull requests per developer,
- saw median review time rise roughly fivefold (some cuts of the data report +441.5%),
- merged 31.3% more PRs with no review at all (the queue overflowing into skipped review),
- shipped 54% more bugs per developer, with the incidents-to-PR ratio more than tripling.
Read this as association, not proof. These are heavy-AI teams observed in telemetry, not a controlled trial, and selection is the obvious confound: teams that lean hardest on AI may already ship faster and looser, skew junior, or work in different domains. What raises confidence that AI is doing real work here is that an independent source finds the same direction. The batch-size mechanism is well established: larger changesets carry more risk. Jellyfish found AI-assisted PRs run about 18% larger, and the 2024 DORA report estimated that rising AI adoption came with a ~1.5% decrease in delivery throughput and ~7.2% decrease in stability, attributing it to larger changesets landing in a review process that DORA has always shown punishes big batches. In the same report, 39% of respondents had little or no confidence in AI-generated code, which does not make review faster.
The market read: the money is flowing to code generation, but the binding constraint moved downstream to review, and generation makes it worse. The next round of tooling (AI reviewers, merge queues, review-time estimation) is aimed at the constraint rather than the already-solved writing step. Whether AI can relieve a bottleneck it created is the open question.
Try it
Measure your own review queue (1-2 hours, GitHub API + a notebook). Pull the last ~200 merged PRs for a repo via the GitHub REST API (GET /repos/{owner}/{repo}/pulls?state=closed). For each, compute two intervals: first_review_at - created_at (pickup latency) and merged_at - created_at (total cycle time), plus additions + deletions for size. Plot pickup latency and cycle time against PR size. If the research holds, you will see (a) pickup wait, not review work, eating most of the cycle time, and (b) a sharp cycle-time cliff once PRs cross ~200-400 lines. That cliff is the argument for small batches, made from your own data.
See also
- Theory of Constraints — the general frame: output is set by the single binding constraint, so throughput gains anywhere but the constraint are illusory.
- Git Forge — the platform category GitHub, GitLab, and Bitbucket compete in.
- Merge Queue — the automation that relieves the integration side of the review bottleneck.
Sources
- Stack Overflow 2025 Developer Survey — Git and forge adoption, desirability and admiration figures.
- Faros AI: More Code, More Bugs (ADTmag write-up) — the AI-volume-vs-review-time data.
- 2024 DORA Accelerate State of DevOps Report — AI adoption vs throughput and stability, batch-size mechanism.
- LinearB: Reducing PR Review Time — cycle-time benchmarks across ~2,000 teams.
- Code Review Is the New Bottleneck in AI Development (MetaCTO) — the “cheaper to write than to trust” framing.