Ecosystems and organizations

Historically, automotive open source involved differentiating and integrating generic community software such as Linux kernels. Automotive organizations rarely led projects targeting the industry’s unique needs for functional safety, regulatory compliance and long-term maintainability.

Open source releases from OEMs and Tier1s such asHalo OS, RHIVOS, Corbo Linux and CTRL OS, which attempt to provide safety-compliant alternatives, are also significantly changing the landscape of solutions available to OEMs.

Apart from open source releases, a strategic pivot appears on the horizon, with OEMs and Tier 1s now collaborating within foundations through a governed framework (Eclipse S-CORE). New initiatives like this are engineered from inception for in-vehicle safety, security and hardware integration, marking a shift from passive consumption to automotive-driven open source creation that reflects a deeper ecosystem maturity. The Eclipse S-CORE project is showing early traction, attracting collaborations across the value chain with code contributions from various organizations.

We are truly excited about these trends, but we also see challenges for these projects to thrive:

• A lack of focus: There appears to be a desire to tackle many topics at the same time. While there’s nothing wrong with having a long-term vision, there’s a risk of getting stuck with too many loose ends. Practicing the Unix philosophy of “Do one thing and do it well” might help to create traction.

• Build an active community: Unlike widely adopted open source projects, automotive software has a niche user base of in-vehicle software developers. This makes it harder to cultivate an active, engaged community to support the project’s success.

• Creating ‘automotive-grade’ software: Adhering to industry-specific standards is a hurdle for open source automotive projects, and they must establish an approach for creating software that’s easily certifiable. Interesting approaches can be found from  Ferrocene and the Trustable Software Framework promoted by Codethink.

Addressing these challenges will be essential for the success of any automotive open source project.

Many automotive manufacturers are vertically integrating their development processes and creating everything in-house, including custom operating systems, without establishing common industry standards or collaborating with partners. This approach leads to fragmentation where each OEM develops its own proprietary OS, reinventing the wheel for basic car functions that could be standardized across the industry.

This custom OS approach forces core component manufacturers such as Infineon, Qualcomm and NVIDIA to develop generic hardware solutions instead of creating tailored, optimized solutions for automotive applications. When each OEM implements different operating systems and interfaces, semiconductor companies must design chips that can support multiple OS variants and communication protocols, leading to over-engineered, more expensive hardware that lacks optimization. This fragmentation increases costs throughout the supply chain while reducing the potential for specialized automotive features and performance optimizations.

Open-source approaches and industry collaboration — such as COVESA, Eclipse SDV, the AUTOSAR Rust working group, ASAM eV and RISCV international — offer better alternatives for standardization. By working together on common platforms and interfaces, organizations across the industry can reduce development costs, improve software quality and enable faster innovation.

digital.auto is a community-driven initiative that connects OEMs, suppliers, startups and developers to accelerate SDV innovation. It provides a digital-native, agile alternative for automotive software development, offering a cloud-based, use case-driven platform that aligns closely with modern developer expectations. 

With a safe, open and fast environment to simulate, prototype and validate new mobility services and SDV features, developers and automotive organizations benefit from:

• Interoperability: Standards and open APIs to connect diverse components in the SDV stack.

• Use-case-driven co-creation: Rapid experimentation with real user validation, not just engineering assumptions.

• A cloud-based playground: A virtual space to model, prototype and test SDV use cases instantly, without waiting for hardware.

• dreamKIT hardware: Plug-and-play hardware for SDV prototyping, bridging the gap between cloud simulation and in-car testing.

• Bring your own device: The ability to add connected hardware using standard APIs for validation in real-world scenarios.

Some automotive organizations focus their SDV strategy primarily on user experience, screens and app stores while neglecting the underlying real-time software infrastructure, testing capabilities, and overall product lifecycle management. This infotainment-limited approach constrains the full potential of SDV transformation.

When SDV strategy is limited to infotainment, organizations miss opportunities to use software to improve vehicle performance, safety systems and operational efficiency. They also fail to build the robust testing infrastructure and development processes needed for reliable vehicle software. This narrow focus can lead to fragmented development efforts and missed opportunities for comprehensive vehicle optimization across all systems.

A successful SDV strategy demands a comprehensive approach spanning the entire vehicle software ecosystem. OEMs must invest in real-time software capabilities for safety-critical systems, strong testing frameworks for vehicle-wide validation, and lifecycle management tools that support continuous software evolution. This holistic investment will enable OEMs to unlock the full potential of SDVs beyond infotainment features.

Automotive manufacturers are increasingly taking control of software development. This change is directly linked to more centralized electrical/electronic (EE) architectures which consolidate functionality into a few high-performance computers (HPCs).

By owning the software of the core ECUs, OEMs have more control over the functionality where lower-level ECUs expose the capabilities and data of sensors and actors. The goal is to accelerate feature development, reduce the communication overhead of working with external suppliers, and support the creation of hardware-agnostic software.

The path to in-house software development is different for new and traditional car makers. Digital-native OEMs have the advantage of a greenfield approach, building their entire strategy around in-house development. In contrast, traditional OEMs are disrupting their longstanding relationships with tier one suppliers, causing friction. In addition, the strategy of some OEMs to concentrate software development in new organizational units has shown mixed results and led to significant course corrections.