Standing on the Shoulders of Giants - why we need Open Source in Automotive

In a letter of 1675, Isaac Newton explained: "if I have seen further [than others], it is by standing on the shoulders of giants". This metaphor and idea, that innovation is based on the visible and invisible work of great brains before, is many centuries older - and more current as ever.

In this years #ELIV conference at Bonn (the biggest conference on automotive E/E and software in Germany, organized by the VDI Wissensforum GmbH ), the all-determining topic was #OpenSource.

Open Source is not a new achievement. On the contrary - when the first software was created in the 1950s and 60s, it was almost exclusively freely available, as it came mostly from academic researchers. It was only with the commercialization of software in the 1970s that the aspect of IP protection vs. "free" or "public domain" access and collaboration became more relevant. Richard Stallman's GNU (a type of UNIX operating systems) was published with a new type of license model, and the GNU General Public License (GPL) became a prototype for many to follow.

In 1998, the term Open Source was introduced by the founders of the Open Source Initiative (OSI): Eric S. Raymond, Bruce Perens and Tim O'Reilly. They wanted to focus on the more pragmatic approach of such software, rather than relying on what might be a morally charged free software idea. They describe open-source software as an advantageous development model, although the question of whether software should be open-source is a purely practical and not an ethical question. The importance of the development paradigm is reflected also in combining the "free" and "open" aspects as “Free and open source software” (#FOSS).

Today, the "open" movement became like a Swiss knife for a manifold of knowledge creation fields.

And this picture is of course also part of a license - you know, all that small printed things you never read...

Three Myths about Open Source

Myth #1 - Open Source is idealistic free love

At a first glance, one could think that "open" means: it's a gift to everyone, and anyone can grab it, use it or change it, for the better good of mankind. There's this type of idealistic "openness", but there are many constellations where a much more sophisticated setup is needed.

Different frameworks have been established to define very specific licenses, and they range from "all free" to "almost not free".

Let's have a look on some of the most important frameworks anc concepts- it's a zoo...

• Proprietary Licenses: Not free at all. Each SW comes with a famous "EULA" - the end user license agreement which nobody ever has read. It describes the rights and duties, and mostly also restricts the field of use.
• Creative Commons (CC) is a NGO offering many different types of licenses which are widely used for music, pictures and similar artifacts, where questions like remixes or modifications are important. Find a good summary on all CC licenses here. Different options can be combined to control the level of usage and change, but also the commercialization or reflow into the community.

BY: give credit - this work is done "by ..."
SA: you must share adaptions under the same license
NC: for non-commmercial use only
ND: no derivatives or adaptions of the work are permitted        

• Public Domain: All free, the most open one. This is realized for example in the CC (Creative Commons) license as "CC 0 (zero)" type.
• Copyleft and permissive Licenses: When there is a "copyright", there is also a "copyleft", true? The word is a hint on restrictions how to use modifications of the original work. Typical open source license frameworks are defining a manifold of specific aspects in detail to enable the wished collaboration model, somewhere between restrictive and open. Apache, Eclipse Public License (EPL), MIT, Berkeley SW Distribution (BSD-3) and GNU Public License (GPL-3) are among the most widely used.

• So which license to choose? It depends on mainly two things. First, the associations or platforms you will to distribute and share your IP use are mostly constraining or pre-defining ground rules which fit to their organizational model. And second, it depends on what you want to achieve - let's have a look on this later.

Myth #2 - Open Source is done by nerds in their free time

Well, there is (nerds as well as free time). But relevant work needs relevant time, and many open source projects are massively funded by commercial organizations which built their business model on the distribution or adaption of open source. Don't believe that Linus Torvalds, the mastermind behind Linux and main contributor until today (2% of the code are coming from him personally, which is huge), is a poor guy.

Perhaps, the opposite is true: Open Source works great, if there is a business model behind it for its contributors - then it's sustainable. Often, those business models are not straight, but hidden: Someone who takes care of bundles and maintenance, developing services and applications on top or adapting the open source stack to specific needs.

#3 - Open Source is a free lunch

So, open source developers - the givers - need to pay their rent. But open source is also needs resources and attention on the takers' side when used. The first reason is obvious: it needs to be adopted, integrated into the product, it needs to be tested and maintained.

The second reason relates more to the community in which open source is created. The overall deal of releasing IP into the wild needs to be positive for all stakeholders, and therefore many open source projects are governed in initiatives of companies with fitting and common interests.

In the Automotive context, one of the most promising is currently the Eclipse Software Defined Vehicle working group. Driven by Automotive OEMs and suppliers, their mission is naming key characteristics of many other initiatives, too, much different from the closed-shop governance within automotive so far.

The Software Defined Vehicle Working Group is a no consensus driven, code first Community, with the scope of building Open Source automotive grade Software to be used in series production. 

The Working Group aims for success by selecting robust, sustainable, well engineered Projects. It derives specifications from Open Source Projects which have demonstrated broad adoption and real world use. Our community is unique, as it includes software engineers and developers as well as senior architectures and business leaders.        

Some trigger warning for homegrown Automotive people:

"No-consensus driven" means: This is not the typical way of "We found a working group. Then we align on our requirements and define a standards. After only 5five years, we start the first thoughts about implementation." Whoever wants to contribute can do so, and it is ok to have duplicates or contradicting contributions.

"Code first": No, we do not go down the waterfall - we start with code. This shall accelerate the way to concrete and useful products, but does not take away the need of getting solutions for requirements, and not vice-versa.

So, if OEMs and suppliers want to benefit from initiatives as Eclipse, they need to establish stable alliances of like-minded peers that search for a balanced and sustainable contribution and engagement.

Open Source and Automotive - a dream team?

The ELIV conference at Bonn has shown: OEMs and their suppliers have understood that more commonalities and re-use is urgently needed. The many initiatives are proof for this:

• Eclipse Foundation could offer an umbrella for collaboration on FOSS as discussed above.
• Connected Vehicle Systems Alliance (COVESA) , the successor of the GENIVI alliance, focuses especially on data and functional interfaces
• AUTOSAR is not open-source so far, but indicates they are thinking about it, even if the legal construct of AutoSAR will make this challenging
• Digital.Auto and others are offering additional pieces on prototyping, development tools and others.

The key question: How to converge this zoo of initiatives into a critical mass?

OEMs need now to decide how they want to open up their strategies and architectures. Suppliers need to find their place in a much more complex business model, and finding new revenue streams if software is coming from the OEM or open source. And the initiatives need to overcome their silos and start working on cooperation and convergence.

Make, buy - or cooperate and follow. This means smart decisions outside the comfort zone.

Example: The Mercedes-Benz FOSS Manifesto

The Mercedes-Benz AG - FOSS Center of Competence and the CIO,

RESOLVED to incorporate Free and Open Source Software in our daily software development to improve the quality of our software as well as the speed of delivery,

DESIRING to be an active member in Open Source communities to benefit company, employee, and customer,

CONFIRMING the will to pave the road for their realization,

HAVE DECIDED to establish these FOSS guiding principles:

Company Principles

C1. Mercedes-Benz shall support and encourage its employees to use, contribute to, and create FOSS projects both in Open and Inner Source endeavors. [Encourage FOSS]

C2. Mercedes-Benz shall allow the appropriate time for its employees to participate in FOSS activities. [Facilitate FOSS Participation]

C3. Mercedes-Benz shall encourage and facilitate learning and advancement of its employees through FOSS activities. [Advancement through FOSS]

C4. Mercedes-Benz shall promote visibility in Open Source communities. [FOSS Visibility]

Employee Principles

E1. An engineer shall look for Open and Inner Source alternatives before writing custom code or using proprietary alternatives. [Prefer FOSS]

E2. An engineer shall strive to be active in the Inner Source communities. [Active FOSS Citizen]

E3. An engineer shall contribute to Open Source projects within the scope of his or her day-to-day work. [Contribute FOSS]

E4. Any employee shall always act responsibly in Open and Inner Source communities, with care and respect in both content and communication, in order to uphold a positive image for both himself / herself and the company. [Responsible FOSS Citizen]        

So, why should they all do this? Let's ask GPT-4 for a summary.

Integration and Cost Efficiency

1. Cost Reduction: Automotive manufacturers and suppliers leverage FOSS to reduce software development costs. By utilizing open-source tools and libraries, they can avoid the high costs associated with proprietary software licenses.

2. Faster Development Cycles: The availability of pre-built open-source software components accelerates the development process, enabling quicker time-to-market for new vehicle models and features.

Collaboration and Innovation

3. Community Support: Developers in the automotive sector benefit from the vast communities surrounding popular open-source projects. These communities provide valuable resources, including documentation, forums, and mailing lists, facilitating knowledge sharing and problem-solving.

4. Continuous Improvement: Open-source software is continuously updated and improved by the community, ensuring that the automotive industry has access to the latest features, security patches, and performance enhancements.

Standards and Interoperability

5. Adherence to Industry Standards: Many open-source projects in the automotive domain focus on implementing industry-standard protocols and interfaces, ensuring interoperability between different vehicle components and systems.

6. Open Platforms: FOSS encourages the adoption of open platforms, promoting standardization across the industry. This is crucial for areas such as autonomous driving, where interoperability and data sharing are vital.

Security and Reliability

7. Security Audits: The transparent nature of open-source software allows for thorough security audits, helping to identify and mitigate vulnerabilities in automotive embedded systems.

8. Proven Reliability: Many open-source software components have been widely used and tested across various industries, proving their reliability and stability, which is critical for safety-critical automotive applications.

Customization and Control

9. Flexibility: FOSS provides automotive manufacturers with the ability to customize software according to their specific requirements, offering a level of control that is often not possible with proprietary software.

10. Ownership of Modifications: When modifications are made to open-source software, the automotive company can retain ownership of those changes, although they may choose to contribute them back to the community.

Challenges and Considerations

11. Licensing Compliance: Automotive companies must be vigilant in complying with open-source licenses, ensuring that they meet all obligations, such as distributing source code when required.

12. Integration Challenges: While open-source components can accelerate development, integrating them into a cohesive system can be challenging, requiring expertise and resources.

13. Long-Term Support: Unlike proprietary software, open-source projects may not always offer long-term support, which can be a concern for automotive manufacturers that require long product lifecycles.

Let's work on sharing & collaboration

All appeals for more cooperation have been made. Now we have to put our heads together and form solid alliances. The running initiatives, but also the activities of the European Commission and others build solid and compliant platforms to engage and align.

If we want to align 20 different solutions, it's not helpful to found 21 initiatives to try so.

So let's talk - we are active partner for OEMs, suppliers and initiatives and will drive for a more sustainable future Automotive software landscape.

Dennis R?hr?Marcel Friebel?Fran?ois BARTHET?Jakub Borowczyk?Timo Dieringer?Deepti Bhutani?Celil Ayd?n?Christian Neidel?Dr. Marco Langerwisch?Juergen Reers?Hans Loes?Philip Dorn?Daniel Tatomir?Modar Horani?Amarnath Bharadwaj?Cristian Cuna?Martin Thiede?Wiktor Walczak?Joris Bauer-Ludwigs?Jan Evers?Verena Aulenbacher?Raffaele?Menolascino?Wolfgang K?cher?Gerd Schaefer?Liam Friel?Dominic Craciunescu?Dule Petkovic?Milica Ruvidic?Hendrik Dettmering?Benno Stützel?Bettina Blum?Dharanisha Siddalingaiah?Marcus Hammes?Jonas Kampik?Darani Yogalingam

Kristin Ofer

#SDV #SWdefinedVehicle #FOSS #OpenSource #EclipseFoundation