Legacy OEM Software Strategy: Why Most Are Still Three Years Behind Tesla

**Tesla**'s software update cycle runs every 4–8 weeks. Navigation updates, FSD improvements, new vehicle features — they arrive over-the-air, without dealer involvement, often overnight. In the same period, a **Ford** F-150 Lightning owner might receive one software update that requires a dealer visit to apply. A **Volkswagen ID.4** owner in 2023 reported needing a dealer appointment to fix a software bug that had been patched in European markets six months earlier.

This is the software gap. It's real, it's measurable, and it's not primarily about talent.

## The Numbers

| Metric | Tesla | Average Legacy OEM |
|--------|-------|-------------------|
| OTA update frequency | 4–8 weeks | 6–18 months (dealer visit) |
| Number of ECUs per vehicle | ~3–5 central compute units | 50–100+ separate ECUs |
| In-house software engineers | ~5,000–8,000 (est.) | 500–2,000 (est.) |
| Software supplier dependency | Primarily in-house | 60–80% outsourced to Tier-1s |
| FSD/AD development model | End-to-end neural network, in-house | Primarily Tier-1 supplier (Mobileye, Bosch) |

The ECU count difference is the foundational issue. A modern legacy vehicle has between 50 and 100+ electronic control units — separate chips from separate suppliers, each running separate software stacks, connected by CAN bus and LIN bus communication protocols that were designed in the 1980s and 1990s.

---

## Why the Architecture Matters

Tesla designed its vehicles from the start around a central compute model. Three or four high-performance computers handle what 70+ ECUs handle in a typical legacy vehicle. This isn't just tidier — it means software can be updated centrally, tested against a unified hardware target, and deployed without coordinating across a dozen suppliers.

A legacy OEM updating a feature that touches, say, the climate control, the infotainment display, and the adaptive cruise control system is updating code that runs on three different ECUs from potentially three different suppliers — each with their own software validation requirements, their own hardware abstraction layers, and their own release cycles. That's before the OEM's own testing protocol.

The result is that even when a legacy OEM identifies a software fix, the cycle from identification to customer deployment is measured in months, not weeks.

---

## The Counterintuitive Part

The gap isn't primarily about how many software engineers each OEM employs. It's about **contract structure**.

Legacy OEMs spent decades offloading software development to Tier-1 suppliers — **Bosch**, **Continental**, **Aptiv**, **Visteon** — under multi-year agreements where the supplier owns the software intellectual property embedded in their hardware. The OEM buys the ECU as a unit: hardware and embedded software bundled together, with limited ability to update software independently.

Breaking those contracts to reclaim software ownership — building internal teams to replace supplier-embedded code — costs more than the software itself. The liability clauses, the warranty obligations on existing vehicles, the regulatory certification costs for modified systems: these are contractual and legal barriers, not engineering ones.

**Volkswagen** learned this directly. Its CARIAD software unit, formed in 2020 to consolidate all VW Group software development in-house, had 10,000+ employees by 2023 and had cost approximately €3 billion before significant structural changes were implemented. The ID.3 and ID.4 shipped with known software issues that took years to fully resolve because the organizational architecture wasn't ready for the development approach the ambition required.

---

## Where the Gap Is Narrowing

Some legacy OEMs have made genuine progress.

**Hyundai/Kia** ships the E-GMP platform with a central domain controller architecture — fewer ECUs, more centralized compute — and has demonstrated OTA update capabilities across powertrain and ADAS systems. The IONIQ 6 has received meaningful feature updates without dealer visits.

**BMW** has deployed OTA updates for some systems, including its iDrive infotainment and ADAS features, through its 9th-generation OS. The scope is narrower than Tesla's but broader than most peers.

**Mercedes-Benz** launched MB.OS (Mercedes-Benz Operating System) with the aim of unifying vehicle software across domains by 2025, targeting OTA update capability for major vehicle systems.

None of these have closed the gap. What they've done is acknowledge the architecture problem and begin restructuring for it.

---

## The Three-Year Claim

Is "three years behind" accurate? Let's be specific about what it measures.

In FSD feature capability: **Waymo** is arguably ahead of Tesla for fully autonomous operation, and **Mobileye**'s Chauffeur system is competitive. In terms of consumer OTA update frequency and scope, most legacy OEMs are 3–5 years behind current Tesla capability. In terms of vehicle-defined-by-software architecture — where software capabilities meaningfully determine vehicle value post-purchase — most are further back than that.

The number isn't precise. It's directionally correct.

---

## The Verdict

The software gap between **Tesla** and legacy OEMs isn't a talent gap — it's an architecture and contract gap that was built over decades of supplier relationships. Closing it requires restructuring vehicle electrical architecture, renegotiating or replacing supplier agreements, and rebuilding internal software organizations. That's a 7–10 year project, not a hiring sprint.

The OEMs that will narrow the gap fastest are the ones that accepted the architectural problem earliest — which mostly means the ones that watched Tesla for long enough and started building before the pressure became acute.

Most started too late.

Legacy OEM Software Strategy: Why Most Are Still Three Years Behind Tesla

// COMMENTS

ON THIS PAGE