Open Source Summit India 2026

Bare-metal developers pride themselves on simplicity, control, and understanding every line of code. Then along comes Zephyr—with device trees, Kconfig, west, and layers of abstraction—and suddenly, even blinking an LED feels complicated. So… is Zephyr actually scary?

In this talk, we take a practical and honest look at why Zephyr often feels overwhelming to bare-metal developers, what’s really going on under the hood, and whether that complexity is justified. Through side-by-side comparisons and live examples, we map familiar bare-metal concepts to their Zephyr equivalents and uncover where the fear comes from—and where it disappears.

This isn’t a “Zephyr is better” talk. It’s about understanding trade-offs, choosing the right tool, and making the transition without losing your mental model.

By the end, you’ll see that Zephyr isn’t replacing bare metal—it’s structuring the complexity you were already managing.

Zephyr is officially 10 years old and many silicon manufacturers are moving towards it as a de-facto RTOS. With over 3000+ contributors and 15,000+ commits per release, Zephyr is one of the fastest moving open source RTOS projects today.
Linumiz is a software partner with silicon manufacturers like Infineon and Texas Instruments, maintaining open source downstream Zephyr releases for their customers. This involves backporting bug fixes, security fixes, rebasing, and moving to new release cycles to keep up with Zephyr's upstream development pace.
In this talk, I will walk through how we manage these downstream releases and cope with upstream pace - what works, what doesn't, and what product developers should keep in mind when building long-term products on Zephyr.

Ten years ago, the Zephyr Project set out to build an open, scalable real-time operating system for connected and resource-constrained devices. Today, Zephyr powers a rapidly growing ecosystem spanning IoT, industrial systems, automotive platforms, and edge computing.

This session celebrates Zephyr’s first decade and explores what has driven its success—from technical architecture and open governance to a vibrant global contributor community. Drawing on insights from a new Linux Foundation Research study, the discussion will highlight key milestones, ecosystem growth, and the forces shaping Zephyr’s future.

In this session, we’ll explore:

-The Zephyr features that are most valued
-How open collaboration accelerates RTOS innovation
-Growth of the global Zephyr developer ecosystem
-Real-world Zephyr practitioner use cases & insights

Key questions:
-How is Zephyr being used across embedded products?
-What are the defining features of Zephyr that have contributed to its adoption?
-What are the attributes of the Zephyr community that contribute to the project's growth and health?

Cameras are no longer just for pictures, they are now real-time data pipelines that send information to ISPs, NPUs, and control logic. This is because edge AI is becoming a most wanted vision systems. Zephyr is good at deterministic embedded control, but AI-driven camera workloads need new architectural features like zero-copy buffer sharing, accelerator coordination, bounded latency, metadata synchronization, and controlled backpressure.

This talks about what needs to change in Zephyr's camera and driver architecture to make AI vision work in the real world. Based on our experience with Linux media pipelines and setting up embedded cameras, we look at where traditional RTOS-style camera models fail and what simple abstractions are needed to make them work without adding too much complexity.

The goal is not to make Linux features equal, but to make the architecture better. This includes designing pipelines, structuring buffer ownership, making streaming states more predictable, and making things easier to see. The goal is to keep Zephyr lightweight while also allowing robotics, industrial, and mission-critical systems to work with the next generation of AI cameras.

This session compares how camera support is built in the Zephyr Project and in the Linux kernel camera subsystem.

Zephyr focuses on real-time behavior, low memory usage, and simple system design, making it suitable for small, low-power vision devices. Linux, through frameworks such as Video4Linux2 and the Media Controller subsystem, provides a more structured and scalable approach capable of handling complex camera pipelines, multiple cameras, and advanced processing.

The session examines architectural trade offs between the two camera subsystems, comparing their design approaches and highlighting differences in driver structure, pipeline design, and overall system integration. It also explores how Zephyr’s camera architecture can evolve to support more advanced and scalable vision needs, moving closer to Linux capabilities.