LinearB vs DX (2026): Telemetry or Sentiment?

TL;DR: This is the cleanest philosophical fork in the whole category. LinearB measures what your systems recorded: git and tracker telemetry, banded against a live 8.1M-PR benchmark cohort, with gitStream automation acting on PRs. Published pricing, self-serve. DX measures what your developers report: the DXI, a 14-item survey composite from the team that authored the DORA and SPACE research, benchmarked against 800+ orgs. Quote-only, and now owned by Atlassian. Telemetry can't see morale; surveys can't see the queue. Both are Gartner MQ Leaders, both keep undisclosed models inside headline numbers, and neither claims a reproducible re-run. Cited throughout, as of July 2026.

Disclosure before anything else: we build Busfactor, a competitor to both vendors on this page. The comparison below holds to strict rules because of that, not despite it: every load-bearing claim links to the vendor's own material, DX's unpublished pricing is never guessed at, and each side's genuine advantages are granted in full. Our own argument appears only in the labeled final section.

Two theories of measurement

LinearB's theory: the truth is in the exhaust. Cycle time, pickup time, PR size, and deploy frequency, computed from git and tracker events, compared against 8.1M+ PRs from 4,800 teams banded Elite/Good/Fair/Needs Focus, and acted on via gitStream automations (review routing, labels, auto-approval). Surveys exist in the product, but telemetry is the spine. (For the metrics themselves, our DORA explainer covers what these measures do and don't capture.)

DX's theory: the truth is in the developers. The DXI is a composite of 14 standardized Likert-scale survey items covering drivers like deep work, iteration speed, release ease, and code maintainability. It is computed, per DX's own material, as a mean of driver sentiment scores, benchmarked against a claimed 800+ organizations and 40,000+ developers. Around it sits Core 4, DX's productivity framework - now common procurement vocabulary - which deliberately blends three collection methods: system metrics, self-report, and experience sampling. Notably, half of Core 4's key numbers are perceptions by design (the DXI itself, perceived rate of delivery, perceived software quality). This is the survey-science lineage productized: the DX team's research pedigree runs through DORA and SPACE, and in September 2025 Atlassian bought it for ~$1B.

Neither theory is wrong. Telemetry is blind to morale, clarity of direction, and the docs nobody can find; surveys are blind to the review queue at 2 a.m. and drift with mood and response rates. The buying question is which blindness you can afford. (For what survey instruments can and can't carry, see our guide to developer experience metrics.)

Where LinearB beats DX

• System-of-record numbers. When you need to know pickup time on Tuesdays or which repos' PRs stall, telemetry answers with events rather than recollections. Always-on, no survey fatigue, no response-rate asterisk.
• The live git benchmark. In-product comparison against 8.1M+ real PRs is a different artifact than survey-percentile banding: it benchmarks what teams did, not how they felt.
• gitStream acts on the work itself, routing, labeling, and auto-approving PRs. DX measures and recommends; it doesn't touch the PR.
• Transparent buying. Published prices, a 45-day self-serve trial. DX is quote-only with one-year contracts and a sales-led proof-of-concept motion.

Where DX beats LinearB

• The standard and the science. DX authored the frameworks the rest of the category implements; even rival vendors ship "roll out DX Core 4" support. If your board asks for "the industry-standard developer-productivity measure," DX literally wrote it.
• The survey benchmark. A claimed 800+ orgs / 40k+ developers behind DXI percentile comparisons. That is survey benchmarking at a scale no telemetry vendor's survey add-on approaches.
• Seeing the invisible. Deep-work interruptions, unclear direction, documentation pain, cross-team friction: real productivity drains that leave no git trace. DX's instrument is built for exactly these; LinearB's surveys are an accessory.
• Research honesty worth quoting. DX's own AI measurement material warns that acceptance-rate metrics are flawed and pegs realistic AI productivity gains at "5-15%, rather than 50-100%," the most candid number in a hype-saturated market.
• Distribution. Post-acquisition, DX rides the Atlassian estate. That's not a product feature, but it decides real procurement outcomes.

What both keep undisclosed

Symmetry the marketing on either side won't volunteer, all from their own material:

• LinearB: the AI-assisted classifier is a confidence threshold over an undisclosed model. The default moved from 50 to 25 in June 2026 per their release notes, retroactively changing what earlier adoption charts meant. gitStream's estimated-review-time label is likewise an undisclosed ML model.
• DX: the headline translation - one DXI point saves 13 minutes per developer per week - rests on an internal regression whose derivation is not published; AI-driven time savings in their framework are self-reported; and the mechanics of their AI Code Insights attribution are not publicly disclosed.
• Both: ship LLM chat/MCP layers with no quote-only guarantee, hold 2026 Gartner MQ Leader placements, and make no reproducibility claim anywhere. And credit where due, both publicly warn against weaponizing individual metrics; DX's Core 4 paper explicitly cautions against targets on per-engineer speed metrics.

Who should pick which

Adjacent matchups: LinearB vs Swarmia for the self-serve telemetry flank, LinearB vs Jellyfish for the finance flank, and Swarmia vs Jellyfish for the capitalization face-off.

The third architecture (ours, labeled)

The labeled pitch. The fork above offers you two kinds of unverifiable: a telemetry number with a tunable, undisclosed classifier inside it, or a survey number that is, by construction, an average of feelings translated to minutes by an unpublished regression. Both vendors are honest enough that this isn't hidden. It's just not fixable within either architecture.

Busfactor is built on the third architecture: telemetry-first like LinearB, but with zero models in the metric path. Every number is quoted from your actual rows, AI attribution counts only deterministic evidence with blind spots disclosed, and exports print their provenance (run id, engine version, ruleset version, content hash) so a re-run reproduces the bytes. Where DX hands you percentiles of sentiment and LinearB hands you bands and dashboards, Busfactor hands you a graded verdict: findings with receipts, drains priced in your currency, and a payback estimate on every fix. Per-developer pricing, self-serve, no seat minimums and no seat cap.

The direct head-to-heads, concessions included: Busfactor vs LinearB and Busfactor vs DX.