Eclipse SDV

Eclipse SDV is a working group of the Eclipse Foundation, launched in 2022, that develops open-source software building blocks for the software-defined vehicle. Members include major OEMs, Tier 1 suppliers, chipmakers and cloud providers; contributors range from Bosch and Continental subsidiaries to Microsoft and automotive startups.

The premise is that large parts of the vehicle software stack are non-differentiating — every OEM needs them, none wins customers with them — so sharing the engineering cost in open source frees investment for the layers that do differentiate. Where most automotive consortia publish specifications, Eclipse SDV’s unit of output is working code under open-source licenses, developed in public under the Eclipse Foundation’s governance and intellectual-property rules.

What Eclipse SDV produces

The working group hosts dozens of projects across the stack: in-vehicle runtimes and middleware, vehicle abstraction layers, developer tooling, simulation, and fleet connectivity. A few illustrate the range:

• Eclipse Kuksa provides an in-vehicle data broker built on the COVESA Vehicle Signal Specification, giving applications a standard way to read and write vehicle signals.
• Eclipse uProtocol, contributed by General Motors, defines a transport-agnostic communication protocol for software components in and around the vehicle.
• Eclipse S-CORE is an effort to build a safety-capable core software stack for high-performance ECUs — the most ambitious project, because it targets territory where certified commercial platforms have traditionally been bought, not shared.
• Eclipse Leda packages components into a Linux-based distribution so developers can try the stack without assembling it themselves.
• Eclipse OpenSOVD implements service-oriented vehicle diagnostics, the standards track intended to succeed classic UDS for high-performance computers.
• SDV Blueprints combine projects into end-to-end reference use cases — fleet management, orchestration, safety scenarios — to show the pieces working together.

Project maturity varies widely, from incubation-stage code to components with serious industrial backing, and the portfolio changes as projects are added, merged or retired.

Who is behind it

The Eclipse Foundation — the organization long known for the Eclipse IDE and for hosting Jakarta EE — provides the legal and governance frame: vendor-neutral ownership, defined IP provenance, open project governance. That frame is a large part of the appeal for automotive companies, which need certainty about license hygiene before code can approach a production program. The working group is funded by its members, who steer strategy, while each project retains its own committers and technical decision-making. European industry and policy circles have pointed to Eclipse SDV as a model for pooling non-differentiating engineering, and the group’s center of gravity is visibly European, with active communities in Asia and North America.

How it fits in the landscape

The recurring confusion — COVESA vs Eclipse SDV vs SOAFEE vs AUTOSAR — resolves by asking what each body ships:

• Eclipse SDV ships open-source code for the stack.
• COVESA ships data standards; Eclipse SDV projects like Kuksa are among the main open implementations of COVESA’s VSS.
• SOAFEE ships an architecture for cloud-native automotive compute; Eclipse SDV components can be the workloads that run inside a SOAFEE-style environment.
• AUTOSAR (Classic and Adaptive) ships platform specifications implemented by commercial vendors.

The sharpest boundary question is with AUTOSAR: projects like S-CORE aim at layers adjacent to what Adaptive platform vendors sell, and the two organizations have publicly framed their relationship as cooperative — shared members, complementary scopes — while the market quietly tests whether open-source stacks can meet safety requirements at commercial-platform level.

Adoption reality

As of 2026, the honest picture is broad membership, growing code, and thin confirmed production deployment. Several projects are used in development toolchains, prototypes, blueprint demonstrations and hackathons; the step into type-approved series vehicles is slower, because automotive software must clear safety, security and liability hurdles that open-source governance alone does not answer. This is the normal trajectory for infrastructure open source — Linux took years to move from servers into cars — but it means membership rosters and press activity should not be read as vehicles on the road running this code. The commercial tension is real too: for suppliers whose business is selling exactly the components the group commoditizes, contributing is partly defensive, and not every member’s engagement runs deeper than a logo.

What to watch

Eclipse SDV functions as a signal of where the commodity line sits: components that land there are ones the industry has collectively decided not to compete on, which reshapes supplier business models built on selling exactly those components. The bellwether is S-CORE — if a safety-relevant open-source core stack reaches production in vehicles from more than one OEM, the commodity line moves decisively upward, with consequences for every vehicle OS program and platform vendor. Watch also whether OpenSOVD becomes the reference diagnostics implementation for high-performance ECUs, and whether the group’s blueprints start appearing as the basis of actual OEM procurement rather than demonstrations.