Interview with Michael Plagge, Eclipse Foundation
Open Source in the Automotive Industry
A conversation with Michael Plagge, VP Ecosystem Development at the Eclipse Foundation, about the reality behind open source, the true challenges in automotive software - and why control without participation doesn't work.
Eclipse Foundation
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.
About the Eclipse Foundation and the SDV Working Group
The Eclipse Foundation is one of the world's leading open-source organisations with the aim of advancing vendor-neutral software solutions for industrial use. With over 375 member companies - including industry giants like Bosch, Mercedes-Benz, Cariad, and SAP - it provides a neutral framework for the development of open-source technologies based on transparent governance and shared values.
A central project in the automotive sector is the Software-Defined Vehicle (SDV) Working Group. Its goal: the development and promotion of open-source implementations for key SDV components - from middleware to cloud connectivity to safety-critical functions. Instead of isolated proprietary developments, the group focuses on collaboration in the non-competitive areas of the software stack. Following the principle: "We develop together what no one can do better alone."
The SDV Working Group is guided by nine clear principles - including "Code first", interoperability, reusability, and a clear commitment to production readiness. Projects within the group are self-managed and follow the meritocratic approach: those who contribute the most have a say. The governance structures of the Eclipse Foundation ensure reliability, transparency, and scalability.
Technologically, the group relies on modern development paradigms - such as containerisation, modular architectures, and CI/CD approaches - and actively works to transfer open-source specifications into international standards, as demonstrated by the ISO/IEC 202376:2023 (Sparkplug) standard.
With this initiative, the Eclipse Foundation aims to actively shape the transformation of the automotive industry - and help it master the increasing software complexity in terms of innovation, efficiency, and future viability.
This article was first published at all-electronics.de