Published
June 20, 2025
Back to the blog
Browse the blog
Delivery Failure Patterns
Open-Source Qualification in Automotive: A Critical Industry Need
The automotive industry's software-defined vehicle ambitions face a certification deadlock: companies waste resources duplicating qualification of the same foundational tools (operating systems, toolchains, LLVM) that everyone depends on, forcing costly choices between self-qualifying everything, losing competitive edge, or accepting vendor lock-in. The solution is collaborative open-source qualification of shared foundations—pool resources on non-differentiating infrastructure while competing on actual product innovation.
Reading time
2 min read
Author
Fadi Labib
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.
Regardless of your approach, you inevitably depend on foundational elements: certified operating systems, qualified toolchains, and utility libraries (STL, Eigen, etc...). This 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 benefits are transformative:
- Reduced individual qualification costs
- Accelerated innovation cycles
- Most importantly: 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
Keep reading
Related essays that extend the same thread.
•8 min read
If Cars Can Be 'Software-Defined Vehicles', Why Aren't Phones 'Software-Defined Phones'?
As carmakers announce their transformation into "Software-Defined Vehicles", a revealing question emerges: Why don't we call smartphones "Software-Defined Phones"? The answer exposes a fundamental truth about the automotive industry's struggle to catch up with technology that mobile devices mastered two decades ago. While smartphones were born in the software era, designed from inception as platforms where apps and OS updates define the user experience—traditional automakers are hardware companies desperately trying to think software-first. The "software-defined" prefix isn't just marketing; it's a need for industrial transformation, signaling a pivot that mobile companies never needed because software centricity was self-evident from their beginning. As vehicles evolve into "computers on wheels", they're essentially revealing that the SDV label represents not innovation, but an industry's public acknowledgment that its fundamental assumptions about value creation were wrong.
•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 traditional carmakers are making the same mistake Nokia made—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.