← All essays
Browse the archive
Open-Source Qualification in Automotive: A Critical Industry Need
Every carmaker chasing software-defined vehicles qualifies the same foundational tools on its own: operating systems, toolchains, LLVM. The work is duplicated across the industry and none of it is a differentiator. The fix is to qualify those shared foundations together and compete on the product instead.
The Challenge
Automotive faces a fundamental bottleneck hindering SDV: qualifying and certifying software for safety-critical applications.
- Certification ≠ Quality: The industry often conflates these concepts, creating barriers to innovation. Many treat ISO 26262 certification as a guarantee of quality.
- Misuse of flexibility in standards: ISO 26262 provides mechanisms like SEooC and ASIL decomposition, but we often misuse them as workarounds due to limited collaboration.
The Dependency Dilemma
In our fragmented, non-collaborative market, developing safety-critical components as part of a larger system you don't control forces you to make assumptions about unknown system contexts. This creates a spectrum from over-engineering to oversimplification.
Whatever you choose, you end up depending on foundational elements: certified operating systems, qualified toolchains, and utility libraries (STL, Eigen, etc.). That dependency traps companies in one of three problematic paths:
- Self-qualify everything → Divert resources from product development to non-differentiating activities
- Pass responsibility to customers → Lose competitive advantage while creating integration complexity
- Rely on proprietary solutions → Accept vendor lock-in and dependency risks with outdated qualified tools
The Open-Source Solution
Other industries recognized this early and invested in collaborative qualification of foundational projects. In automotive, proven technologies like LLVM and its ecosystem, along with established libs, warrant collective industry investment.
The payoff:
- Reduced individual qualification costs
- Accelerated innovation cycles
- Most importantly: a healthier competitive ecosystem. Competition based on actual product value, not survival with outdated tools
The Path Forward
Industry-wide collaboration on qualifying foundational elements is essential for the sector's advancement. Let's compete on innovation, not on who can best navigate outdated infrastructure.
The future of automotive software depends on the willingness to collaborate on the foundation while competing on the innovation that matters
Originally posted on LinkedIn
FAQ
- Why is open-source qualification a critical need in automotive?
- Every carmaker chasing SDVs independently qualifies the same foundational tools like operating systems, toolchains, and LLVM. That work is duplicated across the industry, costs resources, and is not a competitive differentiator.
- Does ISO 26262 certification guarantee quality?
- No. The industry often conflates certification with quality, but they are not the same. Treating ISO 26262 certification as a guarantee of quality creates barriers to innovation.
- What are the three problematic paths companies face with foundational dependencies?
- Self-qualify everything, which diverts resources from product development to non-differentiating work; pass responsibility to customers, which loses competitive advantage and adds integration complexity; or rely on proprietary solutions, which means vendor lock-in and outdated qualified tools.
- What is the proposed solution?
- Qualify the shared foundations collaboratively across the industry, as other sectors did early, and compete on the product instead. This lowers individual qualification costs, accelerates innovation, and creates a healthier competitive ecosystem.
Fadi Labib runs this field lab. 15 years in automotive, robotics, and embedded systems; ESMT Berlin EMBA. I give AI real engineering problems, then check its work. More about the lab →
Related case studies
Related essays that extend the same thread
•8 min read
If Cars Can Be 'Software-Defined Vehicles', Why Aren't Phones 'Software-Defined Phones'?
Carmakers now call themselves "Software-Defined Vehicle" companies. Nobody calls a smartphone "software-defined". Phones were software-first from day one, so the label was never needed. The SDV prefix is automakers announcing they have to rebuild around software two decades after mobile did.
•6 min read
What if Google Test Didn't Exist? Chapter 1: The Hidden Economic Value
Open source software powers 96% of all codebases and would cost $8.8 trillion to rebuild, yet just 5% of developers create 96% of its value. Google Test alone saves companies billions. Imagine 2,000 companies each burning money to build their own testing framework, then to maintain it. That's billions down the drain, solving the same problem thousands of times. Meanwhile, bugs caught early save hundreds of thousands per year, and engineers get to build actual products instead of reinventing basic tools. Tech giants aren't sharing code out of generosity, they've figured out that giving away millions in development costs them less than the alternative.
•5 min read
Software Defined Vehicles? Nokia Lost to Software, Not iPhones
Nokia launched the first smartphone in 1996, 11 years before the iPhone, and had superior technology with a massive R&D budget, thousands of patents, and advanced features like GPS and 5MP cameras. Yet they failed. Why? Not because of technology, but because they couldn't transform from a hardware company to a software company. Developers abandoned them for platforms that took software seriously. Today's carmakers are repeating Nokia's mistake: spending billions on research but focusing on the wrong things, while Tesla and Chinese EVs play by software-first rules, just as Apple and Samsung did against Nokia.