How many cases do you know, where companies have successfully built a business around an open-source project? The list is countless.
How many cases do you know, where companies have taken a software product and created a successful open-source project out of it – while still doing business with it? This list is incredibly short.
In the realm of the software-defined vehicle, everyone is shouting for collaboration and open-sourcing. Eclipse Software Defined Vehicle and Connected Vehicle Systems Alliance (COVESA) being the prime examples in the field trying to collaboratively develop the software-defined vehicle in open-source. Makes me wonder, if everyone – including OEMs – would love to have an open-source solution so much, why are we seeing so many proprietary Automotive OSes?
I think the root cause lies in my initial questions above. It is just way easier to build a business around an open-source project rather than converting a software product into an open-source project with a sustainable business model.
Where the Automotive industry is starting
First, we must consider the starting point for most of the automotive industry. Software assets come from a fragmented supplier base with operating systems, middleware stacks, application components coming from highly specialized companies. There is a multitude of software suppliers (traditionally in the role of a Tier 2 supplier) delivering the software assets for integration into ECUs.
These assets are either custom developed for the specific customer, or are software products sold to ECU projects for different OEMs, as with AUTOSAR stacks. The development processes are proprietary to the individual vendors, as the automotive-specific development processes like ASPICE or ISO26262 create a high entry barrier for the market and has historically made the use of open-source software hard. In the past, the share of software development directly from OEMs has been comparatively low.
As a result, the supplier base with the domain-specific knowledge capable of qualifying and maintaining software for the automotive market is full of companies that have software, or develop software products which they do not own the IP for, as it was developed as a service contract for a Tier 1 or OEM.
Virtually, every supplier with their own software assets is facing a similar situation; going open-source means converting a software product developed with proprietary ASPICE processes into an open-source project.
What it means to go open-source
The article “An in-depth guide to turning a product into an open source project” by Stephen Walli from 2016 offers very good insights into what such a transition means (I highly recommend to read the full article – not just my very short summary here):
1. Publishing the source-code under an OSI-approved license
2. Publishing the software build environment
3. Accepting contributions
4. Building a genuine community
However, even these basic steps pose a significant hurdle. For the first step, you need to check whether you have the rights to open-source and if libraries are used and whether they have a compatible license.
For example, the AUTOSAR standard is still posing issues today, because it restricts the use to AUTOSAR members. This is the reason why the SOME/IP implementation, SommR in Eclipse Software Defined Vehicle, cannot be published yet. Further, of course the published code must be “clean” in the sense of not exposing data of existing customers, as frequently found in code comments.
Publishing the build environment is where many suppliers see their secret sauce. They can perform automotive qualification or safety certification which represents a major market entry barrier for many non-automotive companies.
These tool chains often make use of proprietary tools such as safety certified compilers or tools for code analysis. Therefore, although rebuilding the source code may be easily possible for contributors, rebuilding it for use in a productive environment is not. Even if the complete chain can be open-sourced, it would require a community to follow ASPICE processes in an open-source setup, for example, making the building of a community difficult.
Therefore, this is not only about opening up the build environment but the process framework around the development to enable contributors to make “compliant” contributions.
Accepting contributions and building a genuine community is a cultural change for many companies in the automotive domain, but this also requires a corresponding organizational change.
This brings us to the point of governance over potential code contributions. If liability shall still be assumed by a company (as part of an open-source business model), how does the governance model support this? Establishing a communication channel to moderate the contribution and review process is essential.
Further interesting thoughts on the topic can be found here.
The business side
The most fundamental questions are not technical though. How do you transform a business model for software products into a business model around an open-source project, especially when considering that the product has existing customers with the current model and existing projects with long maintenance requirements?
Already today most automotive software companies recognize the factor of value does not lie in the software itself, but in the organization to build, qualify, maintain, and release the software. This is also the reason why today most software solutions in the automotive domain are already delivered in source code to customers.
Still, you cannot undo open-sourcing your product, and most companies shy away with the fear of someone else picking up the software and doing the build, qualification, maintenance, and release on their own.
Half-hearted open-sourcing of existing software like COMASSO, for the Classic AUTOSAR software that still requires purchasing the original product to actually build an ECU, is bound to fail as the community for contributions does not build up.
Current reality
Out of these considerations, we can easily understand the current state of open-source initiatives like Eclipse Software Defined Vehicle and Connected Vehicle Systems Alliance (COVESA) in automotive. Foremost, they provide a legal framework and communication/collaboration platform to organize an open-source community. Naturally, they do not take care of establishing a business framework for contributing companies..
Almost all contributions are original contributions. Not because existing software is bad and needs to be rewritten, but because creating new open-source projects and building a business around it is easier than transforming existing business
We see things like container orchestration for automotive workloads with Ankaios, or a middleware communication layer based on the vehicle signal specification (VSS) with KUKSA. Yet, we do not see open-sourcing of an existing safety-certified operating system or middleware yet, i.e., transformation of a product into an open-source project. What we do see are efforts to safety-certify open-source software like Linux, for example, to build a business around existing open-source software.
I think the potential of open-source in automotive is not exploited today. It will take courage and a smart way of transforming existing business models. What is your take? What model will be the key to success in the future?
Related content:
EB corbos Linux – built on Ubuntu: Your open-source operating system for HPC
Getting started with EB corbos Linux SDK – Webinar
You’ve recently downloaded EB corbos Linux – Built on Ubuntu. Excellent! Now what?
We’ve got you covered. Mark your calendar for September 29th and register for our upcoming webinar. In-house expert and Automotive Technology Director, Ryan Goff, walks you through the first steps of working with EB corbos Linux – Built on Ubuntu, and guides you through using some of the fundamental tools and documentation necessary to get started.
