Code Is Not Evidence: Reflections from the Automotive Open Source Summit 2026

Last week Tymaton attended the Automotive Open Source Summit 2026 in Starnberg, hosted by the Eclipse SDV Working Group — a day that confirmed how quickly open source is becoming the default foundation of the software-defined vehicle.

With the industry's Memorandum of Understanding for an automotive-grade open source ecosystem now counting more than 30 signatories, and Eclipse S-CORE heading toward its first full release, the alignment in the room was unmistakable.

For us, the summit was highly productive. We had substantive conversations with OEMs, Tier-1 suppliers, and open-source project stewards — and one theme surfaced in nearly every one of them: open source communities produce code, not certification evidence.

That is not a criticism. It is a structural reality. A shared, automotive-grade stack solves the duplication problem brilliantly. But when an OEM or supplier takes that stack into a production program, ISO 26262 obligations don't transfer with the repository.

The HARA, the safety requirements and traceability, the safety case, and the certification-grade evidence remain the adopter's responsibility — and today that work is still done largely by hand, by a scarce pool of functional-safety engineers, over months.

This is exactly the layer Tymaton was built for. As an autonomous functional-safety engineer, Tymaton automates the safety-judgement work around whatever stack a team adopts — open source or proprietary — producing auditable, certification-grade artifacts with a human firmly in the sign-off loop. We don't compete with the stacks; we make them certifiable in your program.

The conversations in Starnberg validated that framing, and several are already continuing. If your team is adopting open-source components in a safety-critical program and asking how to turn that code into evidence an assessor will accept — that is precisely the question we answer.