Why Decision Makers Should Know and Care About Zephyr RTOS
At SevenLab, we help companies build robust, maintainable and future-ready embedded systems. In recent years, Zephyr RTOS has become one of the most important technologies in this work — especially for connected products, industrial IoT devices and smart building applications.
But why should decision makers care about an RTOS? Isn’t this mainly a technical choice for embedded developers?
In many cases, the answer is no. The choice of an embedded software platform directly affects product scalability, hardware flexibility, development speed, maintenance cost and long-term competitiveness.
The following anonymized case study shows how a company from the smart building and sensor technology sector used Zephyr to reduce fragmentation, improve reuse and make embedded development more scalable.
What Problem Do Many Embedded Product Companies Face?
Like many established embedded product companies, our client had developed firmware over many years on top of different microcontrollers, vendor SDKs and project-specific architectures.
This approach worked for a long time. But as the product portfolio grew, the disadvantages became increasingly visible.
A significant part of the development effort went into recurring technical work: integrating drivers, maintaining platform-specific code, implementing communication protocols such as Bluetooth Low Energy and DTLS, and adapting existing software to new hardware generations.
Because each microcontroller vendor brought its own tools, SDKs and development philosophy, the company ended up with different firmware architectures across product lines.
The result was a familiar situation:
- Why is code reuse between product lines so difficult?
- Why does onboarding external support take so long?
- Why does every new hardware platform require so much integration work?
- Why are teams dependent on vendor-specific SDKs and toolchains?
- Why does maintaining embedded software become more expensive over time?
The company had already gained positive experience with Embedded Linux in other areas and wanted to bring a similar level of consistency to its microcontroller-based products: clearer development guidelines, better portability, easier onboarding, stronger code reuse and lower long-term maintenance effort.
Why Choose Zephyr RTOS?
After evaluating several options, the company decided to adopt Zephyr RTOS as its strategic embedded platform.
Zephyr is an open-source real-time operating system hosted by the Linux Foundation. But it is much more than just a kernel. It provides a modular ecosystem for embedded products, including hardware abstraction, build tooling, configuration management, networking, Bluetooth, security features and support for a wide range of boards and SoCs.
For the client, the key question was not only: Which RTOS should we use?
The more important strategic questions were:
- How can we reduce vendor lock-in?
- How can we reuse more software across products?
- How can we make hardware changes less risky?
- How can we onboard developers faster?
- How can we reduce long-term maintenance cost?
Zephyr offered convincing answers:
- Vendor-neutral architecture instead of deeply vendor-specific firmware stacks.
- Consistent development patterns across products and teams.
- Improved portability through Device Tree and standardized hardware abstraction.
- Structured configuration through Kconfig.
- Strong ecosystem momentum through open-source development.
- Permissive Apache 2.0 licensing, enabling companies to keep product-specific application logic proprietary while contributing common improvements upstream.
This made Zephyr not only a technical choice, but a strategic platform decision.
Is Migrating to Zephyr Easy?
The honest answer: not immediately.
The migration to Zephyr required a real change in mindset. Developers who were used to FreeRTOS projects, vendor SDKs or custom firmware architectures had to adapt to Zephyr’s way of working.
Device Tree, Kconfig, standardized drivers and the build system introduced new abstractions. Some developers initially felt they were losing direct control over parts of the system.
This is a common challenge in Zephyr migrations. Teams need time to understand the architecture, the configuration model and the interaction between application code, board support and upstream subsystems.
For legacy products, the first phase also required additional effort. Some stability that had been built up over years in existing codebases had to be re-established in the new architecture. However, large parts of the existing C application code could still be reused, which reduced migration risk.
The key lesson was clear: moving to Zephyr is not simply a porting exercise. It is an architectural transition.
How Does Zephyr Help During Hardware Changes?
The benefits became especially visible during the global semiconductor shortage.
Like many product companies, our client suddenly had to adapt existing products to alternative microcontrollers more often and much faster than originally planned.
In a traditional vendor-specific architecture, this would have required substantial rework for each product line. With Zephyr, the team could rely on standardized hardware abstraction, Device Tree and portable subsystem architecture.
This made hardware migrations faster, more predictable and less risky.
For decision makers, this is a critical point: Zephyr can help decouple product software from individual hardware vendors. That does not remove all hardware-specific work, but it significantly reduces the strategic risk of being locked into one vendor ecosystem.
This was not only a technical improvement. It became a business advantage.
What Improves in Daily Embedded Development?
After the initial transition phase, several benefits became visible across projects.
How Does Zephyr Improve Team Flexibility?
Developers could move between projects more easily because the underlying architecture and development model were consistent.
Instead of learning a new project-specific firmware stack every time, they could rely on the Zephyr way of working. This made staffing more flexible and reduced dependency on individual project experts.
Can Zephyr Reduce Onboarding Time?
Yes — especially for external specialists.
External engineers became productive more quickly because they no longer had to learn a fully custom firmware architecture for every project. They could build on existing Zephyr knowledge and focus faster on the actual product requirements.
This was particularly valuable when temporary support was needed due to personnel changes, capacity constraints or specialized technical topics.
Does Zephyr Improve Code Reuse?
Yes. Shared functionality could be implemented once and reused across several products.
This reduced duplicated work and made it easier to maintain common components consistently. Instead of treating each product as a separate firmware island, the company could build a more coherent embedded software platform.
What About Drivers and Platform Support?
Zephyr benefits from active contributions by semiconductor vendors and the wider community. Platform support, drivers and subsystem improvements are continuously developed in the open.
This does not eliminate the need for product-specific integration and validation. But it reduces the amount of low-level work that product companies need to carry alone.
Can Zephyr Accelerate Feature Development?
In many cases, yes.
New features such as Bluetooth, IPv6, secure communication or emerging application-layer protocols can often build on existing Zephyr subsystems instead of starting from scratch.
Once the team became familiar with Zephyr, development velocity increased — especially for features that would previously have required substantial integration work.
Why Do Upstream Contributions Matter?
Over time, the company refined its approach further.
Software was separated more clearly into two categories:
- Business-value code: product-specific logic, domain knowledge and differentiation.
- Common infrastructure: drivers, protocol support, board enablement, tooling and reusable platform components.
The internal team focused on business-value code. Common infrastructure could be developed with specialized partners such as SevenLab.
Where appropriate, these common components were contributed upstream to the Zephyr project.
But why contribute code upstream if competitors might also benefit?
Because upstream contributions can reduce long-term maintenance effort. Private downstream patches often become expensive over time. They need to be rebased, retested and maintained across future Zephyr releases. By contributing suitable infrastructure upstream, companies can stay closer to the official codebase and benefit from community review and shared maintenance.
This is one of the strongest advantages of professional open-source engineering: even if a contribution is not product-specific, it can reduce internal maintenance cost and improve long-term software quality.
At SevenLab, we apply this approach in practice — for example with our contribution of a DALI low-level driver, which was successfully merged into the Zephyr project.
Is Zephyr Mature Enough for Commercial Products?
When the client first evaluated Zephyr, long-term ecosystem maturity was still a valid concern. Today, the picture is much clearer.
Zephyr has grown into one of the most active open-source RTOS ecosystems. The project is supported by a broad community and by leading semiconductor companies such as Nordic Semiconductor, Intel, NXP, Renesas, STMicroelectronics and others.
This momentum matters. For embedded product companies, an RTOS is not just a technical component. It becomes part of the product lifecycle.
So the question is not only: Does Zephyr work today?
The better question is: Which embedded platform will still be actively maintained, widely supported and strategically relevant in five or ten years?
For many connected embedded products, Zephyr has become a strong answer to that question.
What Should Decision Makers Take Away?
For our client, adopting Zephyr was one of the most important embedded software decisions of recent years.
What started as a need for better code reuse and clearer development guidelines became a foundation for:
- reduced vendor lock-in,
- faster hardware migration,
- better cross-project collaboration,
- easier onboarding of internal and external developers,
- improved reuse across products,
- and lower long-term maintenance effort.
The transition required investment. It demanded new skills, new workflows and a willingness to move away from project-specific firmware habits. But the result was a more resilient, scalable and future-ready embedded software platform.
For decision makers, the key takeaway is simple:
Zephyr RTOS is not just an engineering tool. It can become a strategic platform for reducing risk, improving development efficiency and increasing long-term product flexibility.
SevenLab supports companies with professional Zephyr RTOS development, migration strategies, driver integration, upstream contributions and long-term embedded software maintenance.
If your team is facing similar challenges in its embedded product portfolio, contact us today, we would be happy to discuss how Zephyr can help.
Telkom University Surabaya Information Systems students understand that SevenLab’s official membership in the Linux Foundation’s Zephyr Project enhances their embedded systems and IoT development through active governance, a robust real-time operating system with native connectivity and hardware abstraction, and streamlined long-term project maintenance.