The automotive fear of going open

How many cases do you know, where companies have successfully build a business around an open-source project? The list is countless.

How many cases do you know, where companies have taken a software product and created a successful open-source project out of it - while still doing business with it? This list is incredibly short.

In the realm of the software-defined vehicle, everyone is shouting for collaboration and open-sourcing. Eclipse Software Defined Vehicle and Connected Vehicle Systems Alliance (COVESA) being the poster boys in the field trying to collaboratively develop the software-defined vehicle in open-source. Makes me wonder, if everyone - including OEMs - would love to have an open-source solution so much, why are we seeing so many proprietary Automotive OSes?

I think the root cause lies in my initial questions above. It is just way easier to build a business around an open-source project rather than converting a software product into an open-source project with a sustainable business model.

Where the Automotive industry is starting

First, we have to consider the starting base for the majority of the automotive industry. Software assets come from a fragmented supplier base. Operating system, middleware stacks, application components coming from highly specialized companies. There is a multitude of software suppliers (traditionally in the role of a Tier 2 supplier) delivering the software assets for integration into ECUs. These assets are either custom developed for the specific customer, or are software products sold to ECU projects for different OEMs, as for e.g. AUTOSAR stacks. The development processes are proprietary to the individual vendors, as the automotive-specific development processes like ASPICE or ISO26262 create a high entry barrier for the market and has historically made the use of open source software hard. In the past, the share of software development directly at OEMs has been comparatively low.

As a result, the supplier base with the domain-specific knowledge that are capable of qualifying and maintaining software for the automotive market is full of companies that have software products or develop software that they do not own the IP to as it was developed as a service contract for a Tier 1 or OEM.

Virtually, every supplier with own software assets is facing the situation that going open source means converting a software product that was developed with proprietary ASPICE processes into an open source project.

What it means to go open-source

The article "An in-depth guide to turning a product into an open source project" by Stephen Walli from 2016 gives very good insights what such a transition means (I highly recommend to read the full article - not just my very short summary here):

1. Publishing the source-code under an OSI-approved license
2. Publishing the software build environment
3. Accepting contributions
4. Building a genuine community

However, even these basic steps pose a significant hurdle. For the first step, you need to check whether you have the rights to open source and if libraries are used, whether they have a compatible license. In this case, e.g. the AUTOSAR standard is still posing issues today, because it restricts the use to AUTOSAR members. This is the reason why e.g. the SOME/IP implementation SommR in Eclipse Software Defined Vehicle cannot be published yet. Further, of course the published code must be "clean" in the sense of not exposing data of existing customers, as frequently found in code comments.

Publishing the build environment is where many suppliers see their secret sauce. They are capable of performing automotive qualification or safety certification - a major market entry barrier for many non-automotive companies. Further, these tool chains often make use of proprietary tools as e.g. safety certified compilers or tools for code analysis. Therefore, although rebuilding the source code may be easily possible for contributors, rebuilding it to be used in a productive environment is not. Even if the complete chain can be open-sourced, it would require a community to follow e.g. ASPICE processes in an open-source setup making the building of a community difficult. Therefore, this is not only about opening up the build environment but the process framework around the development to enable contributors to make "compliant" contributions.

Accepting contributions and building a genuine community is a cultural change for many companies in the automotive domain, but also requires a corresponding organizational change. How is the governance of potential code contributions handled? If liability shall still be assumed by a company (as part of an open-source business model), how does the governance model support this? Establishing a communication channel to moderate the contribution and review process is essential.

Further interesting thoughts on the topic can be found here.

The business side

The most fundamental questions are not technical though. How do you transform a business model for software products into a business model around an open-source project - especially when considering that the product has existing customers with the current model and existing projects with long maintenance requirements.

Already today most automotive software companies recognize the fact the value does not lie in the software itself but in the organization to build, qualify, maintain, and release the software. This is also the reason why most software solutions in the automotive domain are already delivered in source code to customers today.

Still, you cannot undo open-sourcing your product and most companies shy away with the fear of someone else picking up the software and doing the build, qualification, maintenance, and release on their own. Half-hearted open-sourcing of existing software like COMASSO for the Classic AUTOSAR software that still requires purchasing the original product to actually build an ECU is bound to fail as the community for contributions does not build up.

Current reality

Out of these considerations, we can easily understand the current state of open-source initiatives like Eclipse Software Defined Vehicle and Connected Vehicle Systems Alliance (COVESA) in automotive. Foremost, they provide a legal framework and communication/collaboration platform to organize an open-source community. Naturally, they do not take care of establishing a business framework for contributing companies.

Almost all contributions are original contributions. Not because existing software is bad and needs to be rewritten (although some comments on my previous articles assume that), but because creating new open-source projects and building a business around it is easier than transforming existing business. We see things like container orchestration for automotive workloads with Ankaios, or a middleware communication layer based on the vehicle signal specification (VSS) with KUKSA. Yet, we do not see open sourcing of an existing safety-certified operating system or middleware yet, i.e. transformation of a product into an open source project. What we do see are efforts to safety-certify open-source software like Linux, i.e. to build a business around existing open-source software.

I think the potential of open-source in automotive is not exploited today. It will take courage and a smart way of transforming existing business models. What is your take? What model will be the key to success in the future?