Our Zephyr Journey: From Newcomers to Project Members

This month, Croxel became an official member of the Zephyr Project, the open source real-time operating system (RTOS) hosted by The Linux Foundation. It is funny how the announcement fits in one sentence, yet the path to it took years, and the tireless work of incredible professionals.

Where we started

When it first started around 2016, Croxel was a small team building connected products for a few clients, and like most embedded teams, we lived inside whatever software development kit the chip vendor shipped. Every new project meant new tools, a new way of configuring hardware and, too often, drivers we had already written once for a different chip.

We knew that our way of working could not scale. Every hour spent rebuilding the same foundation was an hour not spent on the problem our client actually hired us to solve. That is when we started looking for a solution, and in 2019 we found Zephyr.

The decision to go deep

Our first Zephyr projects were a real learning curve: device tree, Kconfig and a build system that felt unfamiliar after years of vendor tools. But the more we used it, the clearer the choice became.

Zephyr gave us a common foundation that did not belong to any single silicon vendor. Hardware described once could move between architectures. Drivers, subsystems and the Bluetooth stack were maintained in the open by a community of companies and engineers, instead of being rebuilt in private by each of them.

Luis Ubieda, our Lead Firmware Engineer, put our thinking into words in early 2024, in an article we called “The Linux for MCUs”. Embedded development needed a shared foundation to build on, the way the rest of the software world already had one, and Zephyr was the strongest candidate.

Soon enough we made it a deliberate choice. Zephyr would not be one tool among many. It would be a core skill for the whole firmware team, something we understood from the inside.

Becoming a part of the community

Going deep meant going upstream. We wanted to know where we could learn and help, and the community responded. Our first contributions were small fixes we found while working on client projects, the kind of thing you can patch locally and forget about. However, we chose not to forget about them. Each one went through community review, and each review taught us something about how the project works and what good Zephyr code looks like.

Over time the contributions grew. Our engineers joined the Sensors and Bluetooth working groups. Then came the talks. All in all the community gave us a better way to work, and showing up was the obvious way to return the favor.

What it changed for our clients

The most practical result of all this happens far from conference stages. We have brought medical wearables, environmental monitors and deployed device fleets onto Zephyr. We have moved devices already in the field onto new Zephyr firmware over the air, without a single recall.

Knowing the codebase from the inside changes how those projects go. When we hit a bug in Zephyr itself, we can fix it at the source and send it upstream, so our client does not carry a private fork through every future release. When a client asks whether a platform decision will hold up for years, we can answer from what we see in the project every week, not from a datasheet.

Becoming members

Joining the Zephyr Project as a member was the natural next step in our path. It puts our company behind the project our clients’ products depend on, and it gives us an opportunity to voice our thoughts and share our vision for the project with a seat on the Technical Steering Committee (TSC). We see that as a responsibility to take part: to review, to listen, and to bring the perspective of the product teams we work with every day. We’re glad to be a part of the conversation.

Thank you

To the Zephyr community, the working groups, the meetup organizers and everyone who stayed to talk after a session: thank you for making this an open project in practice, not only in license.

To our clients, who trust us to build their products on an RTOS some of them were hearing about for the first time.

And to the Croxel team, who did the work, one review comment and one rewritten driver at a time: this membership is yours.

Just the beginning

Membership is not the finish line. It is the point where our commitment becomes official and our responsibility grows. There is more to contribute, more to learn and more teams to help build products on a foundation they can count on for the long term.

If you are building on Zephyr, or wondering whether you should, we would love to talk. You can read more about how we work with Zephyr at croxel.com/zephyr-rtos.