Adapted from the talk by Hisao Munakata, Senior Director, Renesas Electronics Corpat – All Member Meeting, Tokyo, Japan, May 13–14, 2026
Watch the video: https://youtu.be/CmFJMy6uch8?si=ppfJK9NlhMUeNtoB
TL;DR
The automotive industry treats open source as a product option rather than a strategic partnership, creating a “wait and see” culture that leaves it badly exposed as SDV complexity grows. Drawing on 35 years of public Linux kernel release data, Munakata maps the exact same integration crisis the Linux community faced in the v2.4/v2.6 era — and shows how four structural changes solved it. The lesson for automotive is not to “assemble” open source components, but to actively collaborate in building and maintaining them.
Introduction: the cultural bottleneck in automotive engineering
Open source software is everywhere. But within the automotive sector, it is still largely treated as just another procurement option — an alternative to a commercial product, evaluated on price and ease of integration rather than engaged as a long-term collaborative infrastructure.
Munakata frames the problem clearly: in IT, cloud infrastructure, and manufacturing, companies already understand that they cannot survive without contributing to open source communities. In automotive, the majority are still watching from the sidelines.
This is not just a cultural lag. It produces real costs: duplicate R&D across OEMs and Tier-1 suppliers, fragmentation of integration efforts, and an inability to benefit from the maintenance and security infrastructure that active community participation provides.
Make or Buy or Collaborate
For decades, corporate software strategy offered a binary: Make (in-house R&D, full IP control) or Buy (third-party vendor, faster to market). Munakata argues that a third option has become essential: Collaborate.
Collaborate means jointly developing OSS components — including differentiating ones — in partnership with other companies and communities. The goals are technology neutrality, shared long-term maintenance costs, and avoiding the risk of duplicate development across the industry.
At a recent COVESA conference, Munakata heard a variation of this framing presented as “Make or Buy or Assemble.” He was, in his own words, “very very shocked” — not because the three-option model was wrong, but because “Assemble” implies a passive, commodity relationship with open source: pick up components, integrate them, ship. More than 50 people were in the room, and no one raised a hand to challenge it.
For Munakata, the distinction matters enormously. Assembling open source treats it as a product. Collaborating on open source treats it as shared infrastructure you help build and maintain. The automotive industry’s failure to grasp this difference is the root of the integration problems it now faces.
Context: SDV is automotive’s Linux wild days
Software-Defined Vehicles are forcing automotive teams to simultaneously integrate technologies that have never coexisted before: ECU consolidation into centralised compute zones, container orchestration, hypervisors and virtualised real-time environments, end-to-end autonomous driving pathways, OTA update infrastructure, and the shift from CAN to Ethernet-based networking.
If this feels unprecedented, Munakata argues, it is not. It is the exact situation the Linux kernel community faced during the v2.4 to v2.6 transition.
During that period, massive architectural overhauls were injected in parallel: the O(1) scheduler, a virtual memory rewrite, kernel preemption, a complete block layer rewrite, the driver model, kobject/sysfs, and module system changes. Development branches were effectively unstable weekly snapshots. Release intervals had a standard deviation of 27.21 days for the early 2.6 series — sometimes a release came in 14 days, sometimes 107. There was no predictability.
“I think we are in the exact same situation right now.”
How the Linux community solved it: four structural changes
Between roughly 2003 and 2011, the Linux community transformed from this chaos into one of the most reliably-releasing large software projects in the world. Munakata identifies four mechanisms that made this possible.
1. Distributed ownership
Patches from 2,000+ developers now flow through 1,000–1,200 driver and file maintainers, then through 100–200 major subsystem maintainers, before reaching linux-next and Linus’s tree. Each level owns its code quality. A developer typically rewrites their patch five to seven times through the review process — even experienced contributors rewrite at least three times. This distributed accountability is what keeps quality consistent at scale.
2. Staged integration (the mm-tree legacy)
The transition began with Andrew Morton’s mm-tree. Morton was initially responsible only for memory management, but Linus asked him to act as a pre-validation gate — merge patches from maintainers, test them together, and filter before anything reached Linus. This was manual, human-operated gatekeeping. Git later enabled every subsystem to have its own equivalent — distributed, automated, scalable. Today, linux-next serves this function at the top of the hierarchy.
3. Automated validation
Git did not just replace CVS. It fundamentally changed the validation model: each party in the hierarchy can independently test and validate before passing code upstream. Combined with CI/CD infrastructure, this means regressions are caught at the lowest possible level. Automated testing absorbed the quality burden that previously required human gatekeepers like Morton.
4. Time-based release engineering
The shift from feature-based to time-based releases is perhaps the most important change. The merge window opens for two weeks after each release; the remaining six to eight weeks are validation-only. If a feature misses the window, it waits for the next cycle. This creates the predictability the data shows: the v6–v7 series has a release interval σ of just 2.83 days. Releases consistently land on Sundays, US Pacific time.
Munakata’s explicit point: time-based periodic release does not exist in the automotive industry. The implication is clear — it needs to.
The data: statistical proof of stabilisation
Munakata’s talk is built around public kernel release data from LWN.net and kernel.org, and the numbers are striking.
| Metric | v2.6.27 (Oct 2008) | v7.0 (Apr 2026) | Change |
| Code size (LOC) | 9.0M–10.0M | 39.6M | ~4x |
| Active contributors | 1,109 | 2,362 | ~2.1x |
| Development period | 88 days | 63 days | 28% faster |
| Release interval σ (2.6 whole series) | 23.6 days | — | High volatility |
| Release interval σ (v6–v7 series) | — | 2.83 days | Near-perfect stability |
Source: LWN.net kernel release database (https://lwn.net/ksdb/releases/) and kernel.org
Code grew 4x. Development time got shorter. Release cadence became almost metronomically predictable. This is what structured community governance achieves at scale.
Companies that contributed to v7.0 include Intel, AMD, Google, Red Hat, Qualcomm, NVIDIA, NXP, Renesas, and many others — direct competitors collaborating on shared infrastructure. That is what “Collaborate” looks like in practice.
Conclusion: AGL has the opportunity to bring these lessons to automotive
Munakata’s conclusion is direct. The automotive industry is currently at its Linux 2.4/2.6 moment. The challenge is not software size — it is integration scalability. Linux solved this over 20 years through distributed ownership, staged integration, automated validation, and time-based release engineering. AGL has the opportunity to bring exactly this playbook into the automotive design cycle.
The practical implication is straightforward: automotive software teams need time-based periodic releases. Not feature-driven, not reactive — committed to a schedule, with a defined merge window, a validation-only period, and the discipline to defer what doesn’t fit. That cadence, more than any single technology choice, is what turned Linux from a chaotic development effort into the most reliably maintained large codebase in the world.
Get involved
💬 Join the AGL community on Discord: https://discord.com/invite/ZztCaVeQVG
🔗 Automotive Grade Linux: https://www.automotivelinux.org
🔗 Download the talk slides: link
🔗 AGL All Member Meeting Europe 2026 (Berlin, Sept 30–Oct 1): https://events.linuxfoundation.org/agl-amm-europe
