Nexus SDV Platform Raises a New Question for OEMs: Which Software Is Still Worth Building?

Google Cloud and Valtech Mobility have publicly released the open-source core of the Nexus Software-Defined Vehicle (SDV) platform, making the framework available after introducing the project in late 2025. Nexus is not a production-ready vehicle software platform, but a modular reference implementation that connects Android Automotive OS (AAOS) with Google Cloud services. Manufacturers can deploy it alongside existing environments to develop cloud-native back-end functions without designing every architectural component independently. Google positions the framework to support telemetry management, Gemini-enabled services, and software lifecycle operations across fleets consisting of tens of millions of connected vehicles. Production deployment, systems integration, cybersecurity, regulatory compliance, and validation remain the responsibility of each Original Equipment Manufacturer (OEM).

Nexus joins several collaborative initiatives addressing different layers of the SDV stack. Eclipse SDV, Eclipse S-CORE, SOAFEE, COVESA, and AUTOSAR target separate technical requirements, but share an interest in reducing repeated work on software that every manufacturer needs. Nexus contributes at the cloud-to-vehicle implementation layer, adding another practical framework to an industry already reconsidering how much common infrastructure must be developed independently.

For much of the previous decade, automotive software strategies emphasized greater proprietary ownership throughout the vehicle. Control over the stack promised faster innovation, closer integration, and stronger product differentiation. That ambition has grown harder to sustain as software programs expand, cybersecurity obligations intensify, certification requirements increase, and development schedules contract. Engineering capacity remains finite, forcing manufacturers to examine which areas genuinely justify separate internal development.

A large share of vehicle software addresses problems that are substantially similar across competing programs. Middleware, communication protocols, signal abstraction, back-end connectivity, telemetry handling, runtime services, and portions of the software lifecycle rarely determine why a customer chooses one vehicle over another. Maintaining separate versions of these capabilities consumes technical resources that could support customer-facing innovation. Collaborative development allows manufacturers to share that burden without treating every layer of the stack as interchangeable.

Proprietary software remains essential where it shapes the product. Cockpit experiences, vehicle behavior, Artificial Intelligence (AI) functionality, energy management, digital services, customer data strategies, and brand-specific applications continue to influence product identity and long-term competitiveness. Shared foundations can limit duplicated implementation work, but they do not remove the need for integration, validation, cybersecurity, system optimization, or lifecycle support. The value lies in reallocating effort, not in surrendering architectural responsibility.

Adoption will vary across regions and manufacturers. European OEMs have strong incentives to collaborate as they manage legacy architectures, extensive supplier networks, and demanding regulatory obligations. Many Chinese manufacturers retain wider internal control where close hardware-software integration supports rapid feature deployment and distinctive digital experiences. These approaches are not mutually exclusive. Most OEMs will combine shared components with proprietary development according to their product strategy, technical capabilities, and available resources.

Nexus is valuable as evidence of a wider change in software investment priorities. OEMs must determine which capabilities deserve scarce internal resources and which are better sourced from collaborative projects without weakening product differentiation. Those decisions will influence development speed, lifecycle cost, and platform flexibility well beyond the relevance of any individual framework.

For automakers:

• Define differentiation before defining ownership. Vehicle behavior, cockpit experiences, AI functionality, digital services, and customer ecosystems warrant proprietary investment when they directly influence how customers perceive and use the vehicle.
• Adopt collaborative software where the underlying problem is shared. Common infrastructure should reduce repeated implementation work and shorten vehicle programs without restricting differentiation elsewhere in the architecture.
• Evaluate software across its complete lifecycle. Integration, validation, maintenance, certification, supplier coordination, and future platform migration may outweigh the original development expense when determining whether a capability should remain internal.

For software suppliers and cloud providers:

• Compete on implementation quality above the shared layer. Reference architectures create limited value without migration tools, interoperability, validation support, documentation, and reliable lifecycle maintenance.
• Help OEMs convert shared software into shorter development programs. Developer productivity, AI-enabled services, platform management, and customer-facing applications will carry greater value than foundational code alone.

Software ownership should follow product strategy and engineering economics, not an assumption that internal development is inherently superior. Manufacturers that separate common technical requirements from genuine sources of differentiation can direct limited resources toward the functions that customers notice, while retaining control over the quality and behavior of the complete vehicle.