Open Source Summit + Embedded Linux Conference North America 2026

For more than 15 years, Qualcomm’s been actively involved in a range of Open Source ecosystems. Until recently, some parts of our development were handled behind closed doors, with contributions coming later and upstream enablement sometimes being limited. We tried various projects and partnerships to push things upstream sooner, but it wasn’t until lately that we truly made a complete shift.

Over the past 18 months, we’ve totally revisited our approach—moving an entire Linux product development ecosystem, with hundreds of contributors, from a private downstream setup to a full-blown Open Development model. This wasn’t just a surface change: it meant overhauling how our engineers work, syncing up our internal systems with open practices, and fundamentally changing the way our developers connect and collaborate.

In this session, we’ll share what made this transition work for us—including how we managed to weave our internal systems into Open Source workflows, encouraged developers to embrace new ways of thinking, and built scalable processes that can handle all sorts of Linux ecosystems and distributions.

Embedded Linux debugging has always required difficult trade-offs. Flash storage constraints on target devices force teams to strip debug symbols from most binaries, leaving developers unable to debug critical applications without finding symbols elsewhere.

This presentation examines our transition from limited, on-target debug symbols to comprehensive debuggability across all binaries and build types. The key insight: while flash is expensive on embedded targets, centralized storage is cost-effective and scalable.

We adopted elfutils debuginfod to build enterprise-scale debug infrastructure integrated with our CI/CD pipeline. This has allowed us to host debug artifacts for every binary produced by continuous integration, enabling engineers to debug any component from any build, using standard tools like GDB, without manual symbol management.

This talk covers our journey towards using debuginfod, the architectural decisions we made that allowed debuginfod to scale, integration strategies with the Yocto build system, and the impact on engineering productivity. Attendees will gain practical insights for implementing similar solutions in their organizations.

In this session, I’ll share practical lessons learned while architecting, building, and supporting a production media system running on custom hardware using open source systems :

Yocto for a customized OS;
GStreamer for media pipelines;
PulseAudio for audio routing;
BlueZ for Bluetooth integration;

This session is relevant because while projects like Yocto, GStreamer, PulseAudio, and BlueZ are powerful individually, integrating them into a production-ready system on custom hardware exposes complexities rarely covered in documentation. Sharing hard-earned lessons helps the ecosystem build more reliable open systems.

Main Points:
- System Overview : Hardware Constraints
- Yocto Custom OS Tradeoffs : Layer Strategy, Packet Selections, Reproducible Builds, Field Updates and Support
- Gstreamer : Pipeline design patterns, Handling dynamic audio devices
- PulseAudio & Bluez Integration
- Field Support and Long Term Maintenance : Logging Strategy; Remote Diagnostics, Managing Updates

Attendees will walk away with concrete integration patterns, design considerations for long-term maintainability, and insights that help when building real-world media systems on embedded Linux.

Building an embedded product on top of a large Open Source codebase like WPE WebKit is only the first step. The real challenge is keeping its quality stable as thousands of lines evolve and hundreds of changes land every week across multiple platforms.

In such an environment, errors and regressions are inevitable. What matters is detecting them quickly, understanding their impact, and reacting before they propagate further. This talk focuses on the engineering work that makes this possible, an effort that is essential yet often invisible.

Using WPE WebKit as a case study, we will explore how quality becomes a continuous engineering effort rather than a final validation phase and how CI and QA infrastructure, testing strategies, and processes (e.g. stabilization windows) sustain upstream development while supporting downstream deployments. We will show how these feedback loops reinforce each other and why aligning upstream and downstream processes is critical to keep quality stable over time.

This talk targets engineers, maintainers, and technical leaders working on large Open Source projects, as well as teams building products on top of them who need to sustain quality at scale.

With regulatory deadlines regarding Software Bill of Materials (SBoMs) in place, and more on the horizon (such as the CRA), it is important to ensure that you can comply with the requirements that are stipulated. Fortunately, Yocto has a robust and comprehensive SBoM generation integrated into it, which can aid in ensuring compliance. In this talk, Joshua will provide information and tips about how to configure your Yocto builds for compliance with several of the different SBoM standards.

In automotive software development—such as IVI (In-Vehicle Infotainment) software—many layers of the supply chain are involved, including automotive OEMs and Tier‑1 suppliers. Automotive OEMs, in particular, are required to manage a complex and multi‑layered software supply chain under strict safety and regulatory constraints.

To evaluate supply chain security efforts within software development, we have been conducting a feasibility study on applying SLSA, a supply chain security framework being developed by the OpenSSF.

In this session, we will share insights gained through our validation of SLSA adoption and discuss approaches to supply chain security in large-scale software development projects such as AAOS.