Johan Thelin has seen automotive software from nearly every angle: as an embedded engineer, a startup founder, an architect at MBition building Mercedes-Benz's next-generation cockpit platform, and now as a product manager for the Open SDV Platform at WirelessCar. He also organizes foss-north, an annual open source conference in Gothenburg. We sat down with him to talk about why automotive software lags, what open source really requires, and where the industry is finally starting to move.

‍

Let's start with backing up the picture - why is automotive software so hard to get right?

The problem is scale and distribution, but also organizational. OEMs were designed to procure hardware - buying an ECU and a function, with no real software ownership. That means nobody has been pushing for harmonization, nobody was building shared infrastructure, and every supplier delivered their own software stack. The result is an enormous web of ECUs talking to each other just to produce a single function.

SDVs (Software Defined Vehicles) is the industry's recognition that this has to change. Flatten the architecture, centralize computing, and software as a natural way to implement things rather than an afterthought in a mechanical and electrical design.

‍

Let’s talk about open source in automotive. What are the real opportunities and challenges?

The opportunity is building shared infrastructure, the non-differentiating pieces that everyone needs but nobody should have to build alone. The blocker is that OEMs haven't yet accepted that they need to be the ones writing and maintaining that shared infrastructure. Buying software as part of a hardware package versus taking ownership of open source requires different skill sets.

"Only about 5–10% of what makes a car unique is genuinely differentiating. The rest could be handled by open standards and a shared infrastructure. Keeping everything automotive-specific locks out competition and lets traditional suppliers remain relevant."
‍

There's also a cultural challenge. Open source works best when someone scratches their own itch and shares the solution. In automotive, the pattern has been to pay for open source through consortium memberships, which means nobody is really motivated by the problem. You technically get open software that, in practice, behaves like proprietary software.

The other piece is what I'd call the requirement disease. If you put down 10,000 requirements, open source can't win. Not because it doesn't solve your problem, but because it wasn't built around your requirements document. The shift has to go from specifying solutions to specifying what problem is to be solved.

Is the toolchain side a separate challenge, or the same problem in a different form?

The same root problem. Closed standards mean closed input data, which means only a handful of specialized tools can operate on it. Small user base, expensive licenses. The tooling never reaches the seamlessness you get in the broader software world.

Testing is particularly painful in automotive. A lot of the validation happens manually, late in the process, on a full car. By then, you can't fix problems. You can only work around them. Left-shifting testing is essential, but it requires abstractions that automotive has historically refused to build. The industry is catching up, but slowly.

‍

You've helped large organizations to adopt open source. What's the most common mistake?

Treating open source like a supplier relationship. You engage a community as a buyer: you expect deliverables, you file requirements, you escalate issues. But open source doesn't work that way. You're part of a community, not a customer of one.

The "not invented here" reflex needs to change, too. The car has been a status symbol; the idea that everything about it should be custom, should be yours. That made sense when the car was the center of the user's world. Today, the user's phone follows them everywhere. The car is one node in a mobility experience.

‍

Is the industry actually changing?

It is - slowly at first, then we’ll see it all change at once. The clean-slate players moved fast first. Legacy OEMs are big boats to turn, but once they start turning, they're also very good at building things at volume. SDV is pushing centralization, which naturally creates the conditions where a common software stack makes economic sense. The open source alliances are more genuinely open than they used to be. And more OEMs are starting to understand that being the integrator of a software platform, not just the buyer of hardware, is actually a competitive advantage, not a cost center. That mindset shift is the real unlock.

‍

About Johan Thelin
Johan is currently the Product Manager for the Open SDV Platform at WirelessCar, founder of Koderize, and organizer of the foss-north open source conference in Gothenburg. He is the author of The Foundations of Qt Development and has spent over two decades building teams and platforms at the intersection of embedded systems, automotive, and open source. Connect on LinkedIn.

‍

[nfobox]

FAQ - OPEN SOURCE IN AUTOMOTIVE

What is an OSPO and why do automotive companies need one?

An OSPO (Open Source Program Office) is the internal function that governs how a company uses, contributes to, and releases open source software. For automotive OEMs, it provides the structure needed to move from passive consumers of open source to active participants: managing license compliance, contribution strategy, and community engagement in a coordinated way.

What does "left-shifting testing" mean in automotive software development?

An OSPO (Open Source Program Office) is the internal function that governs how a company uses, contributes to, and releases open source software. For automotive OEMs, it provides the structure needed to move from passive consumers of open source to active participants: managing license compliance, contribution strategy, and community engagement in a coordinated way.

What is the difference between a software-defined vehicle (SDV) and a traditional vehicle architecture?

In a traditional vehicle, software is distributed across dozens of separate ECUs, each tied to a specific hardware component. A software-defined vehicle centralizes computing into fewer, more powerful units and separates software from hardware — making it possible to update, reconfigure, and extend vehicle functions over time, much like updating an app on a phone.

[/nfobox]