The clusterf*ck of automotive software and the true cost of ownership

Back in 2020 Herbert Diess said that Volkswagen would develop 60% of its software themselves by 2025 - or to put it into Christian Senger's words

We can and we want to develop our software platform ourselves.

Jim Rowen of Volvo pointed to the underlying problem in an interview in 2022

Today,?software is decentralized in a lot of black boxes, and we buy it from suppliers based on specifications, but when we want a change and you have to talk to suppliers, it is too slow.

Just recently, Jim Farley's interview on Fully charged pointed in the same direction:

We farmed out all the modules that control the vehicles to our suppliers because we could bid them against each other. [...] The problem is that the software is all written by 150 different companies and they don't talk to each other. [...] One-hundred-fifty completely different software programming languages. All the structure of the software is different. It's millions [of lines] of code.

He then draws the conclusion that

That's why [..] we've decided [...] to completely in-source electric architecture. [...] To do that you need to write all the software yourself.

We must fix the supply chain indeed. I would differentiate on the trend of in-sourcing of software though.

Let's look at this in a bit more detail. The reasoning does make sense. In the age of the software-defined vehicle, as an OEM you must be able to change the software. You cannot rely on aligning 150 suppliers to make software changes. From a legal perspective owning the software (in the sense of intellectual property) gives you the right to change. Still, also organizationally you must be capable of changing the software. Writing the software, no doubt, gives you the operational capabilities to change the software.

But is this the only way to achieve the goal of being able to change the software? The underlying question actually is that of freedom and capability to perform changes. This is actually not a question of owning IP.

The key questions to answer are

• Do I really care about the intellectual property? Is having public ownership (as in open-source) ok as it prevents being legally dependent on a single supplier? Is proprietary ownership of a group of suppliers sufficient to prevent vendor lock-in? Is it sufficient if the interface specification is public IP so that other parties can provide compatible solutions?
• What is the governance of the software? Do I need to decide which features become part of the software or is it sufficient if I passively participate in the development? Is it sufficient if I can contribute? Do I only need to prevent exclusive governance through a single company? Is the right to fork sufficient to ensure my freedom to change in the future?
• Do I need to be able to make contributions myself or is it sufficient if I do not rely on one single supplier to make changes? Does my organization require the capabilities to make a change or is it sufficient if a number of organizations are capable of doing so?

You notice that the questions are mainly focused about the freedom to act rather than the questions of intellectual property.

In the end it boils down to the question of what degree of control you want to exert and what the associated cost is.

The argument that reliance on proprietary software for business-critical operation must be avoided at all cost, does not reflect reality for most companies (also in automotive). Microsoft products like Windows, Office, and Teams are embedded into many business critical processes, yet this dependence is largely accepted by organizations, despite the fact that you cannot influence the features of the software or participate in the development. You do not even get to see the source code.

But even for solutions that are built on open-source you sometimes only get the illusion of the freedom to change. Most solutions of the big hyperscalers are built on open-source. You can built an organization that is capable of using or even modifying the technology. Yet, building the infrastructure, financing the organization to operate the infrastructure, and maintaining the infrastructure can be prohibitively expensive that you see yourself in a vendor lock-in despite everything being open-source.

It is indeed a question of which properties of which assets do you really care about. Do you care about defining and developing the features so that no one else can use the same features because they differentiate you? Do you care about not ending up in a vendor lock-in? Do you care about time-to-market and introducing the changes that you need when you need them but you do not care whether anyone else might use them?

(To my knowledge) no company chooses to develop and maintain (!) an own Linux distribution for their own end-customer visible functionality. For good reason. Because the effort for development and maintenance is high. You need to pick you battles. If you want to introduce new features through software, you cannot buy ECUs as black boxes with the software baked into it. You need need to be specific about which degree of control you want to have about which software asset. For some you want to have exclusive control, for some you only care about openness and stability of interfaces, for some you want to prevent relying on a single company to perform changes. The important point is where you see your own value.

The true cost of your software is determined through

• cost of development
• cost of maintenance
• cost of the organization with the expertise to change the software
• cost of operation

and when your goal is to avoid excessive dependencies you have different options that come with different cost.