Automotive Grade Linux (AGL) is an open source project from the Linux Foundation that:

• Architects, integrates, tests and release an automotive in-vehicle platform supporting a variety of architectures and hardware platforms.

• Design, develops and maintains specific automotive open source components.

• Collaborates around several additional topics that expands across different automotive domains.

Bitergia, in collaboration with Toscalix Consulting, have applied data analytics to:

• Collect, process, load and plot data generated by AGL tools (data readiness)

• Analyse and interpret the data to build a description of AGL through data (descriptive analytics)

• Showcase how data analytics principles, methods and techniques can be applied to the production of a software-defined products(SDV), in this case, to an open source product (AGL Platform)

  • The authors hope that this effort triggers conversations about applying business intelligence to the production of embedded products, in both, the open and commercial environments.

Out of the description through data of how AGL community produces the AGL Platform, 10 conclusions have been extracted, which represent the core of this report.

This study spans across:

• All AGL repositories, putting focus on the AGL Platform

  • The study focuses on the different AGL Platform’s flavors, but mostly on Unified Code Base (meta-agl) value stream.

• Two years of data: observation duration goes from 2023-06-01 to 2025-06-01

Four focus areas, with different “intensity”:

• AGL Community at organization level

• AGL activity around developing, testing and integrating code

• Two of the most relevant processes in software development and delivery:

  • Code Review Process

  • AGL Platform Delivery Process

    • AGL’s release and maintenance processes are out of the scope of this first phase of the study.

This first iteration of the study is focused on the zero and first stages of the Business Intelligence Journey: data readiness and descriptive analytics

The data sources considered have been Gerrit (SCM and code review) and Jenkins (integration and orchestration) for now. Key events at organization level and product milestones has also been considered.

This study has been carried out as a collaboration project, together with key contributors from AGL. It is done on best effort basis.

• If you want to read about the details behind this report, please check the AGL Characterization page.

• If you are a practitioner or you are simply interested in every aspect of the study, we recommend that you follow the study’s structure

• AGL is a global project where the leading geographic area is Europe, followed by Americas and Asia. Reference.

• Based on the timing of their activity and their affiliation, the representative profile of an AGL contributor is:

  • Professional, contributing part time, as part of their working time

  • Affiliated to an AGL Member organization

  • Expert, and focused on a specific field

• Konsulko, AGL’s staff and Collabora are the main organizations contributing to AGL during the observation duration time. Reference.

  • AISIN and Toyota complete the top five code contributors (organization)

  • AISIN and Virtual Open Systems complete the top five in changeset authorships.

• The AGL PLatform includes 3 “flavors” (also called distribution):

  • Unified Code Base (UCB), having meta-agl as its main repository (layer)

  • AGL Demo Platform, having meta-agl-demo as its main repository (layer)

  • AGL Development Platform, having meta-agl-devel as its main repository (layer)

• The repositories associated to each one of these flavors attract the highest levels of activity, compared to those focused on automotive software components. Reference

  • Right behind the AGL Platform repositories, the documentation repository attracts a significant number of unique authors and organizations, which is a testament of the effort put in this area by the project.

• AGL also develops automotive software components. Reference. During the observation duration time, the following automotive components(repositories) accumulated the highest levels of activity:

  • agl-compositor: customised Wayland server/compositor which is responsible for managing, combining, and rendering the graphical surfaces (windows/applications) onto the in-vehicle display(s)

  • homescreen: primary user interface launcher and application manager

• AGL triggers around 15k successful builds anually. +13k of them correspond to AGL platform flavors. Reference.

• The average build time at AGL is around 40 minutes. Reference. However, AGL Platform builds, take significantly longer on average:

  • 2:40 hours for meta-agl-verify

    2:37 for meta-agl-demo-verify

  • 3:41 for meta-agl-devel-verify

• Overall, AGL invest in builds&tests(integration) of the AGL platform, including the three flavors, across all the supported architectures, the equivalent to 8 months and 23 days per year.

• QEMU (x86 and ARM), RPi and RCar, from Renesas, are the main “hardware” platforms targeted by AGL, based on the overall assigned building resources and number of builds.

• The number of changesets, patchsets, merged commits and overall authors confirms this tendency. Reference [1][2]

• Increasing the observation duration to the rest of 2025 is required to confirm or discard this conclusion on the builds&test side.

This qualitative evidence is fully confirmed by data: the number of people involved over time, the overall number of commits, the code building activities, the activity and efficiency around code review, the performance of the delivery process…. all supports that statement. Reference.

• Time to Merge (reference) and REI (reference) metrics show this high variability affecting to the overall repositories and also to meta-agl specifically.

• This variability respond to the nature of the project and its dependencies to organization events and product milestones.

• meta-agl Time to Merge decreases over time and it is the repository that accumulates more patchsets, changesets and approvals from reviewers. Reference.

Such behavior reflects:

• AGL’s contributor profile.

• AGL’s product lifecycle: 6 months release cadence, including maintenance cycles

  • AGL platform has Yocto LTS as baseline, which also has a well-defined release cadence

• A significant effect of some trade shows and face-to-face community events: CES, Embedded World, technical workshops… Reference.

• Despite the cyclical nature, the overall trend of the delivery process performance is a slight increase over time

• This increase goes along with the increase on the amount of software shipped, which enjoys a maintenance cycle, on the complexity of the software (introduction of flutter, for instance), on an increasing amount of, or upgraded, hardware supported, etc.

• As 2025 progress, the delivery process performance is decreasing. Reference.

  • We will confirm if this is part of the cyclical behavior or a systemic improvement in a second iteration.

• AGL’s system does not have the complexity of commercial automotive IVI systems but AGL’s platform supports two architectures and several HW platforms, as well as a demo and a development platform, addressing different use cases for different target audiences, which reduces the complexity gap with commercial environments. Reference.

• The number of automotive software components included in the AGL platform is increasing overtime. The number of domains is increasing too (slowly).

• AGL pre-commit, unattended, and distributed testing on hardware part of the delivery process is mature and reliable

  • It can serve as example for those managing delivery platforms in commercial environments

• AGL’s Delivery Process is managed by 0.5 FTE, two people on average, which reflects the simplicity, stability and resilience of the production system.

You can read about these conclusions in the .pdf version of the report.

A second iteration of this study will involve:

• Expanding the observation duration up to the date that second iteration starts.

  • The goal is to provide results from the “previous quarter” or even from “the current quarter”.

• Add one more data source. LAVA and Jira are the obvious candidates.

• Consolidating the current stage of the Business Analytics Journey (descriptive analytics) and get into diagnostic analytics, the following stage of the journey

Bitergia and Agustín welcome experts on the field as well as developers inside and outside of AGL to collaborate with us in a potential second iteration

The authors of the study would like to thank AGL for trusting us on every aspect that has lead to this result. Thank you also to those contributors to AGL that have provided the time and knowledge to make this study possible.

Check additional information about Bitergia. Read this blog post to learn more about Bitergia’s effort to bring Business Intelligence to software production at scale: Advanced Data Analytics for Delivery Performance Excellence.

Check additional information about Toscalix Consulting. Read about how Agustín is collaborating with Bitergia in bringing Business Intelligence to the production of software at scale: Introduction to Delivery Performance Analytics.