Eclipse SDV: Moving from Vision to Release

The CES 2026 Eclipse SDV Executive Breakfast was not a place to ask “What is possible?” It was a place to confirm “What are you actually going to ship?” The fact that the MoU has entered a second-generation expansion phase and gained more signatories is not a simple update to a list of names. It is a declaration that, within the collaborative framework called Eclipse SDV, the industry intends to push S-CORE forward as a common platform that can go into products. When alignment on definitions, openness of code, and integrated releases converge on a single destination - “ship the platform” - SDV open source moves out of the realm of vision and into a product timetable.

By | Sang Min Han (Han) han@autoelectronics.co.kr
한글로보기



CES schedules contain hundreds of sessions, and many of them are designed to demonstrate “what is possible.” Faster computing, more sophisticated features and behaviors, flashy demos, smoother future scenarios. But the Eclipse SDV Executive Breakfast on the morning of January 7 was different. It was about what will actually be delivered next. The moment open source becomes meaningful in automotive is not at the moment of vision - it is at the moment of release.
On that day, Eclipse and the VDA officially framed the MoU for an Automotive-Grade Open Source Software Ecosystem as entering a second-generation expansion phase. This expression does not refer to a single project such as S-CORE. It is closer to an umbrella vision: turning automotive-grade open source into an operating system that includes governance, verification, compliance, and commercialization. The official announcement spoke of expansion in terms of numbers and names. What was explained more directly on the ground was why this expansion is needed now, and how far the industry is willing to build common foundations such as S-CORE under that umbrella. SDV open source is now moving past the stage of “introduction” and into the stage of shipping a platform.
One distinction must be made upfront. Eclipse SDV is the collaborative framework where stakeholders agree on what to build together and push it forward. Eclipse S-CORE is the core outcome produced within that framework: it aims to unify multiple SDV-related open-source projects into a single reference stack and tooling environment, so that automotive development organizations can bring it into product development as an automotive-grade common platform. The day’s discussion did not stop at “open source is needed.” It converged on “ship the platform” precisely because S-CORE exists as a tangible deliverable.


 

  “We’re going to talk about the second generation of the MoU now. Since VDA representatives and the media are here today, we’ll also take a moment to go over what Eclipse SDV is overall.”
This was said by Ansgar Lindwedel, Director of Ecosystem Development for the SDV ecosystem at the Eclipse Foundation. It was not a mere greeting. This was less a stage to introduce SDV and open source as “new technology,” and more a stage to align meanings - to ensure the industry uses the same words with the same intent. If definitions wobble, collaboration wobbles. If terminology wobbles, platforms wobble. That is why the starting point was not promotion but definition.
Lindwedel did not describe SDV as a list of features. He organized the transition from a hardware-defined vehicle to a software-defined vehicle into stages. The vehicle becomes connected, updatable, and upgradable. In the next stage, the platform refreshes capabilities regularly, and third parties can develop technology on top of it. The final stage is the completion of the platform. In other words, the essence of SDV is not “a catalog of advanced functions,” but an updatable operating model and platformization that pulls in third parties.
There are already many attempts to define SDV, and different definitions are moving in parallel. That is why how to combine those definitions matters. Making the industry think of the same object when it says “SDV” is the starting line of collaboration.


  After laying the groundwork of definitions, the question immediately moved to why: “So why Eclipse SDV?”
Here, Lindwedel’s tone changed sharply. He started with the choices the industry has repeated over the past few years.
The industry built its own OS and middleware - OEMs and many suppliers alike stacked their own software layers. The result was fragmentation. When the foundational layer is broken into pieces, innovation does not happen above it; instead, the same problems are solved again and again by each player. And the phrase that captured that situation was blunt:
“This… doesn’t make sense. Why are we doing this?”
What he connected next was not technology but resources. Engineers who can properly build automotive software do not “grow on trees.” The moment scarce talent is trapped in duplicating foundations, time and money evaporate at the bottom layer. The objective therefore becomes simple: instead of increasing isolated and fragmented proprietary solutions, build an integrated foundation and move faster.
A way of building and using together. The problem is that this approach requires “agreement.” Moving like a joint venture means starting with legal agreements, and those agreements can take years. The market will not wait. That is why open source emerges as a method of starting now instead of waiting for agreement. It is not idealism; it is a practical mechanism to reduce the cost of agreement and redundant competition, and to move scarce engineering talent upward into differentiating domains.
Here the strategic implication becomes visible. While Tesla and Chinese OEMs push software operations with speed and scale, traditional OEMs cannot replicate the same velocity due to safety requirements, regulations, supply chains, and organizational structures. Yet if everyone insists on building OS and middleware alone to the end, developers remain trapped in redundant work in non-differentiating areas. What S-CORE offers is not “the one right answer,” but an alternative path: lay a minimum common foundation together to secure speed. Each company keeps its differentiating areas, while building non-differentiating foundational software jointly and accelerating release cadence.
   

Lindwedel’s way of describing achievements in 2025 was also striking. He did not simply say “membership increased.” He focused on where the community expanded, which projects actually gathered people, and what was visible in public repositories.
On expansion, he emphasized that while Europe was central in the beginning, Asia saw meaningful progress.
In particular, he mentioned the Korean community meetup and expressed appreciation for LG’s support in organizing the event. In open-source collaboration, speed ultimately depends on people and participation. Geographic expansion becomes contributor expansion—and contributor expansion becomes faster code and faster releases.
Sangyong Lee, Vice President of LG Electronics, said:
“In an SDV environment, a critical challenge is how to safely orchestrate mission-critical systems. To address this, we will strengthen our engagement through technical advisory participation and code contribution.”
And Sookyung Jung, Vice President of Hyundai Mobis, said:
“SDV is not about simply adding more software; it is a transformation that requires a new level of expertise spanning the entire vehicle. We believe this expertise creates far greater value when shared across the industry than when kept independent.”
The 'new project' Lindwedel highlighted was Eclipse OpenSOVD.
This diagnostics project, initiated from Mercedes-Benz, gathered more than 100 participants globally at kickoff and is building an open - source SOVD stack based on ISO 17978 ( SOVD standard ). Its output will eventually flow into S-CORE and become part of the common platform.
“One last point is important. Everything we’ve shown so far is in public repositories. Anyone can check the code and contribute if they want.”
In open source ecosystems, statements like this are a unit of trust. It cannot be just 'good intentions' - there must be visible code.
And all of these on-site narratives converge on S-CORE. S-CORE is described as a 'middleware for in-vehicle high-performance computing,' a stack intended to fix a common middleware layer by bundling fragmented technologies into an integrated release.
S-CORE began in late 2024 to early 2025 together with Bosch - ETAS and others, starting from five companies and expanding its contributors. What mattered most was that the first 0.5 release was delivered in November 2025. It moved from possibility to operation.




S-CORE is framed not as a community stack but as an “automotive-grade core” because it is compressed into the concept of a common safety-qualified core stack. In other words, it is a declaration that the core stack is designed under the assumption that it can go into real vehicles, with functional-safety certification and cybersecurity regulatory compliance in mind, leveraging industry standards such as AUTOSAR and COVESA. Not “good code,” but a foundation that runs in reality.
Mike Milinkovich, Executive Director of the Eclipse Foundation, argued that what makes this “automotive-grade” possible is not primarily technology, but governance and accountability structures. If multiple companies build and operate the same code together, “goodwill” is not enough; there must be processes and rules defining who verifies what, maintains what, and proves what. The keywords he used for 2025 - trustable and compliance - are the language that brings open source into the product development lifecycle. As regulations such as the CRA require due diligence and attestation for open-source components, compliance stops being a checklist and becomes a variable that reshapes development methods.
That is why the ThreadX functional-safety certification case is not a slogan of “open source works too,” but a signal that an operating model connecting open source with certification processes has started to run. The slides’ emphasis on EU Commission support and the background described by VDA as “set in motion” point in the same direction. Ultimately, S-CORE is not the output of a “good community,” but a platform engineered to satisfy the conditions of regulation, certification, and commercialization.


 
After Milinkovich’s “institutional language,” the VDA’s “industry language” followed.
Dr. Marcus Bollig described this MoU expansion as a “substantial extension,” summarizing its motivations and goals as speed, resilience, and quality.
Speed means developing the platform once through a code-centric approach. Resilience reflects an expectation that open source will be more robust and sustainable. Quality refers to improving verification, security, and reliability, and combining expertise across the ecosystem. The important point is that these three words were used not as a “value declaration,” but as management language that touches cost structure and development processes.
Another striking element was how stakeholder impacts were framed not as sacrifice but as “each party’s benefit.” OEMs reuse existing platforms and gain a shared foundation for collaboration; Tier-1s develop once and reuse; software vendors provide services to more customers; service providers scale across stakeholders. This ecosystem is not designed as “some lose while others win,” but as a structure with distributed participation incentives.
Finally: 40% effort reduction, 30% shorter time-to-market. These numbers are repeated not as promotion but as a joining logic. The core is not reducing features, but reducing redundant foundation development and the cost of integration and verification. Not value rhetoric, but calculation. Not mood, but model. These numbers functioned as an industrial answer to the question, “Why collaborate now?”


 
“Shipping a platform is never a light task. It’s easy to point out what’s missing, but when you release a platform people intend to put into products, an open-source initiative becomes real.”
Taking the microphone again, Milinkovich pinned the 2026 goal to this single sentence: not a “nice-looking roadmap,” but releasing a platform that can actually be used. The air in the room returned to reality.
It was in the same context that he immediately welcomed Traton. The phrase “software-defined vehicle” rather than “software-defined car” draws a line: this collaboration is not confined to passenger cars. The moment commercial vehicles are included, SDV open source expands from a vehicle-type issue into an operating model for the entire industry. Once a platform is shipped, the scope of organizations and business models built on top of it expands as well.
In this context, Stefan Teuchert, Senior Vice President at Traton, said:
“As a truck OEM, we own the entire software stack - from the vehicle to the cloud. Under a new SDV platform and a tight SOP schedule, we hope this community will make us faster, and we are willing to contribute what we have.”
The 2026 schedule that followed was not merely an event calendar. Open Community Experience (OCE) and the automotive track (OCA) in Brussels in April were positioned as places where developers and architects align technically around “what to build next and how to integrate it.” The Automotive Open Source Summit (AOSS) in Starnberg in June becomes a stage to re-confirm progress in the language of industry. It is not only the platform builders who must prepare, but also the people who must put the platform into products.


  At the end of the event, Lindwedel suddenly shifted to something very practical: where can Eclipse SDV be seen at CES? The routes were shared - sessions related to the Trustable Software Framework, booths where S-CORE demos run, invitation-only rooms. Infineon demos and connections to Microsoft’s booth were part of the same framing. The message was simple: they did not come to explain concepts - they came to show what is already running.
The last act was a group photo. It looked like a convention, but it mattered. As existing and new signatories stood on stage together, the image captured a declaration: an industry that had been building platforms separately was now saying it would share the same floor. In an industry that requires collaboration, photos often become evidence.



  SDV open source becomes persuasive not through vision but through the execution sequence: aligning definitions, opening code, releasing integrated stacks, and shipping a platform.
Lindwedel defined SDV in stages so the industry could use the same word to mean the same thing. The question “Why Eclipse SDV?” descended into the reality of fragmentation and developer scarcity, and S-CORE is an attempt to fix that reality with a shared foundation. Milinkovich added the language of regulation, certification, and commercialization, showing that this collaboration is shifting from a gathering that shares code into an industrial system that builds products. The VDA anchored the motivation in the numbers 40/30. Not slogans, but calculation.
That is why the convergence on “ship the platform” as the 2026 goal felt inevitable. SDV open source has entered not a “movement,” but the timetable of product development. Today’s expansion simply means more companies have stepped onto that timetable.

AEM(오토모티브일렉트로닉스매거진)

---