Software Defined Vehicles
Interview with Michael Plagge, Eclipse Foundation
Open Source in the Automotive Industry
Open Source is fundamentally changing software development in the automotive industry. Michael Plagge from the Eclipse Foundation explains in an interview why active participation determines influence, innovation, and long-term success.
The automotive industry is undergoing a transformation: With increasing digitalisation and the software-defined vehicle, new development paradigms are coming into focus - especially Open Source. While open software has long been standard in many industries, there is still hesitation and scepticism in the automotive world. Yet open-source models offer enormous opportunities for efficiency, innovation, and collaboration across company boundaries. But what is needed for the transformation to succeed? What role do standardisation, backend infrastructures, and corporate culture play?
We spoke with Michael Plagge, Vice President Ecosystem Development at the Eclipse Foundation, about this. In the interview, he provides insights into the current state of the open-source movement in the automotive sector - and explains why collaborative development has more future than isolated silo thinking.
Mr Plagge, you are Vice President Ecosystem Development at the Eclipse Foundation - an organisation strongly associated with the topic of Open Source. Would you describe yourself as an advocate of Open Source?
Michael Plagge: No, that would be saying too much. I'm not a missionary or an ideologue. I don't see open source as an end in itself, but as a tool - a pragmatic approach to solving certain challenges more efficiently. For me, it's not about making everything open, but about working together on solutions where it makes sense, establishing standards, and reducing complexity.
Standards are often seen as the key to interoperability. What role do they play in this context?
Standards are important, no question. But they often only bring indirect value. What is much more important to me are concrete implementations. Because standards alone do not solve a problem - they must also be actually used and brought to life. When we talk about software in the automotive sector, we don't need ten different implementations of a standard, but ideally two or three that really work. It's like in the cloud world: Kubernetes prevailed because it was the functioning implementation - not because it was the standard first.
In the automotive industry, software is also about safety. How do safety and security look in this context?
These topics are important, but today they are largely a "commodity". Many Asian manufacturers have simply bought the relevant know-how - and very specifically. Sometimes we still overemphasise the topic, although it has long been a hygiene factor. That means: It must be there, but it is no longer a unique selling point.
Generally speaking: How far has the automotive industry come with open source - and where is it heading?
I see four typical phases: First comes rejection, then interest, followed by initial contributions - and eventually open source becomes part of a company's strategic core. Many are currently between phases two and three. Some OEMs and suppliers are actively contributing, others are still observing. But it is clear: Those who only consume will not be able to have a say in the end.
What does this mean for business models, especially for suppliers?
Open Source does not destroy business models - it changes them. The service share increases, and the mere licensing of code loses significance. Anyone who still believes today that they can differentiate solely through proprietary software has not understood the change. Open Source also helps to reduce the massive complexity in software development. And that is vital for survival - many in the industry may be facing a 'Nokia moment', but still say: 'Oh, it won't be that bad.' But that's exactly what other industries once thought.
So is it not enough to just build brilliant software?
Unfortunately, no. Brilliant software alone is not enough if it is not scalable, maintainable, or interoperable. Open Source is not part of the problem here - but part of the solution. It is also about topics like the Software Bill of Materials. Many companies still lack an overview. Even purchasing departments often do not know what they are actually buying - let alone how expensive software really is.
Is there a mismatch between investments in hardware and software?
Absolutely. There is often an attempt to save on hardware - without realising that this leads to higher costs for software later. If I install cheap control units today, I prevent more powerful software from running on them tomorrow. This is short-sighted - and a real brake in the long term.
The software-defined vehicle is always dependent on backend systems. What risks does this entail?
The dependency is real - and that makes the system vulnerable. The example of Fisker shows what can happen when the connection to the backend is disrupted. Suddenly, nothing worked anymore. Anyone who takes SDV seriously must consider backend resilience. This is not a nice-to-have, but indispensable.
How does the Eclipse Foundation view Open Source in general? Are there principles?
Yes, we have four principles and three central pillars. The pillars are: a clear licensing model, a transparent collaboration approach, and a neutral governance model. And with us, it applies: Those who contribute the most also have the most say. We don't want to be a platform for people who just shout "I want, I want!" - but for those who say: "I do." Control is not gained by wanting, but by doing. Of course, theoretically, an outsider can also take over a project - but if a company considers it important, then it must also get involved.
So, what would be your appeal to the industry?
Embrace Open Source. Not because it's currently en vogue - but because it is strategically necessary. Those who still believe they have to build everything themselves today will lose control tomorrow. It's not about whether you use Open Source - but how actively you participate in it.
This article was first published at all-electronics.de
