Open Source in der Autoindustrie: Werkzeug, nicht Wunder

Die Automobilindustrie befindet sich im Umbruch: Mit der zunehmenden Digitalisierung und dem softwaredefinierten Fahrzeug rücken neue Entwicklungsparadigmen in den Fokus – allen voran Open Source. Während offene Software in vielen Branchen längst Standard ist, herrschen in der Automobilwelt noch Zurückhaltung und Skepsis. Dabei bieten Open-Source-Modelle enorme Chancen für Effizienz, Innovation und Kollaboration über Unternehmensgrenzen hinweg. Doch was braucht es, damit die Transformation gelingt? Welche Rolle spielen Standardisierung, Backend-Infrastrukturen und Unternehmenskultur?

Darüber haben wir mit Michael Plagge, Vice President Ecosystem Development bei der Eclipse Foundation, gesprochen. Im Interview gibt er Einblicke in den aktuellen Stand der Open-Source-Bewegung im Automotive-Sektor – und erklärt, warum gemeinsames Entwickeln mehr Zukunft hat als abgeschottetes Silodenken.

Herr Plagge, Sie sind Vice President Ecosystem Development bei der Eclipse Foundation – einer Organisation, die stark mit dem Thema Open Source verbunden ist. Würden Sie sich selbst als Verfechter von Open Source bezeichnen?

Michael Plagge: Nein, das wäre zu viel gesagt. Ich bin kein Missionar oder Ideologe. Ich sehe Open Source nicht als Selbstzweck, sondern als Werkzeug – als einen pragmatischen Ansatz, um bestimmte Herausforderungen effizienter zu lösen. Für mich geht es nicht darum, alles offen zu machen, sondern dort, wo es sinnvoll ist, gemeinsam an Lösungen zu arbeiten, Standards zu etablieren und die Komplexität zu reduzieren.

Standards gelten oft als Schlüssel zur Interoperabilität. Welche Rolle spielen sie in diesem Zusammenhang?

Standards sind wichtig, ohne Frage. Aber sie bringen oft nur einen mittelbaren Mehrwert. Was mir viel wichtiger ist, sind konkrete Implementierungen. Denn Standards allein lösen noch kein Problem – sie müssen auch tatsächlich genutzt und mit Leben gefüllt werden. Wenn wir im Automotive-Bereich über Software sprechen, dann brauchen wir nicht zehn verschiedene Implementierungen eines Standards, sondern im Idealfall zwei oder drei, die wirklich funktionieren. Das ist wie in der Cloud-Welt: Kubernetes hat sich durchgesetzt, weil es die funktionierende Implementierung war – nicht weil es zuerst der Standard war.

In der Automobilbranche geht es bei Software aber auch um Sicherheit. Wie sieht es da mit Safety und Security aus?

Diese Themen sind wichtig, aber sie sind heute auch weitgehend „commodity“. Viele asiatische Hersteller haben sich das entsprechende Know-how schlicht eingekauft – und zwar sehr gezielt. Bei uns wird das Thema manchmal noch überhöht, dabei ist es längst ein Hygienefaktor. Das heißt: Es muss da sein, aber es ist kein Alleinstellungsmerkmal mehr.

Generell gefragt: Wie weit ist die Automobilbranche beim Thema Open Source – und wohin geht die Reise?

Ich sehe vier typische Phasen: Zuerst kommt die Ablehnung, dann das Interesse, danach erste Beiträge – und irgendwann wird Open Source Teil des strategischen Kerns eines Unternehmens. Viele sind aktuell zwischen Phase zwei und drei. Manche OEMs und Zulieferer tragen aktiv bei, andere beobachten noch. Aber klar ist: Wer nur konsumiert, wird am Ende nicht mitbestimmen können.

Was bedeutet das für die Geschäftsmodelle, gerade auch der Zulieferer?

Open Source zerstört keine Geschäftsmodelle – es verändert sie. Der Serviceanteil steigt, das reine Lizenzieren von Code verliert an Bedeutung. Wer heute noch glaubt, sich allein über proprietäre Software zu differenzieren, hat den Wandel nicht verstanden. Open Source hilft auch, die massive Komplexität in der Softwareentwicklung zu verringern. Und das ist überlebenswichtig – viele in der Branche stehen vielleicht vor einem „Nokia-Moment“, und sagen aber noch: „Ach, so schlimm wird’s schon nicht.“ Doch genau das dachten andere Branchen auch mal.

Reicht es also nicht, einfach nur brillante Software zu bauen?

Leider nein. Brillante Software allein genügt nicht, wenn sie nicht skalierbar, wartbar oder interoperabel ist. Open Source ist hier kein Teil des Problems – sondern ein Teil der Lösung. Es geht auch um Themen wie die Software-Bill-of-Materials. Da fehlt vielen Unternehmen noch der Überblick. Selbst Einkaufsabteilungen wissen oft nicht, was sie da eigentlich alles einkaufen – geschweige denn, wie teuer Software wirklich ist.

Gibt es da ein Missverhältnis zwischen Investitionen in Hardware und Software?

Absolut. Es wird oft versucht, an der Hardware zu sparen – ohne zu erkennen, dass das später zu höheren Kosten bei der Software führt. Wenn ich heute günstige Steuergeräte verbaue, verhindere ich morgen, dass leistungsfähigere Software darauf läuft. Das ist kurzfristig gedacht – und langfristig ein echter Bremsklotz.

Das softwaredefinierte Fahrzeug ist auch immer abhängig von Backend-Systemen. Welche Risiken birgt das?

Die Abhängigkeit ist real – und das macht das System angreifbar. Das Beispiel Fisker zeigt, was passieren kann, wenn die Verbindung zum Backend gestört ist. Da ging plötzlich nichts mehr. Wer SDV ernst meint, muss Backend-Resilienz mitdenken. Das ist kein Nice-to-have, sondern unentbehrlich.

Wie sieht die Eclipse Foundation Open Source grundsätzlich? Gibt es Prinzipien?

Ja, wir haben vier Prinzipien und drei zentrale Säulen. Die Säulen sind: ein klares Lizenzierungsmodell, ein transparenter Kollaborationsansatz und ein neutrales Governance-Modell. Und bei uns gilt: Wer am meisten beiträgt, hat auch das meiste Mitspracherecht. Wir wollen keine Plattform für Leute sein, die nur rufen „Ich will, ich will!“ – sondern für die, die sagen: „Ich mach.“ Kontrolle bekommt man nicht durch Wollen, sondern durch Tun. Natürlich kann theoretisch auch ein Außenstehender ein Projekt übernehmen – aber wenn es einem Unternehmen wichtig ist, dann muss es sich auch einbringen.

Was wäre also Ihr Appell an die Branche?

Stellt euch auf Open Source ein. Nicht, weil es gerade en vogue ist – sondern weil es strategisch notwendig ist. Wer heute noch glaubt, alles alleine bauen zu müssen, wird morgen die Kontrolle verlieren. Es geht nicht darum, ob man Open Source nutzt – sondern wie aktiv man sich daran beteiligt.