At Zephyr Developer Summit, I had a chat with Florian Grandel. I learned more about his journey in open source land, and how he enjoys the sense of empowerment and learning opportunities it provides.
Florian’s foray into Zephyr originated when he needed to install a CO2 sensor in his truck but couldn’t find a ready-made solution on the shelves…
Benjamin Cabé (BC): Hi Florian. Could you introduce yourself and tell us a bit about where you work?
Florian Grandel (FG): Of course! My name is Florian Grandel, and I am a freelance software developer and architect, primarily specialized in IoT topics.
BC: What’s your relationship with Zephyr, and how did you get started?
FG: I’ve been actively involved in open source for several years, and I find the sense of empowerment of being able to fix your own operating system—or any software you use, really!—quite exhilarating.
Out of personal interest and curiosity, I started exploring hardware and embedded systems, particularly for home automation, and soon realized that open-source was lacking in this area, each vendor often providing separate, proprietary, SDKs. I eventually discovered Zephyr, which was exactly what I needed.
BC: So you’re using Zephyr for home automation?
FG: Yes! As a freelancer, I often have to travel. To avoid staying in hotels, I bought a refrigerated truck. It is well insulated, and I can use it all year round. For the winter times, I initially considered gas heating but found those using it having to change gas at 3am way too often, so I decided to go with a wood-fired heating system. A friend of mine helped me install it, and cautioned me that I would need to have a CO2 sensor installed for safety reasons.
Now the thing is, carbon monoxide sensors were super easy to find: they’re cheap, battery-powered, and work really well, but I couldn’t find the equivalent low-power sensor for carbon dioxide. It was long before Covid made them so popular. So I built my own sensor, using Zephyr!
BC: That’s very cool. Could you maybe walk me through what actually made you pick Zephyr?
FG: Sure. I started to dive deeper into wireless technologies due to rising customer demands.I had some experience with aspects like Bluetooth, and even made some contributions to the Linux kernel in that area, but I wouldn’t consider myself an expert initially, so I started to educate myself about the space. Zephyr, with its native 802.15.4 stack, caught my eye, and I started to use it.
I quickly started to discover areas of the stack that could be improved, which was even more of an opportunity for me to learn more. So I started fixing small, simple issues, which helped me understand better not only the technical details but also how the community and the review process work.
BC: So you started by wanting to build your own IoT sensor and ended up actually contributing to improving Zephyr’s 802.15.4 wireless stack?
FG: That’s right! And that’s the main reason why I love engaging in open source projects: you end up learning much more than just what’s required to solve your problem. And it really empowers you.
BC: But contributing to an open source project can be a bit intimidating at first, no?
FG: Well, what I find really exciting about Zephyr, is that you don’t need to be part of a big company to be accepted. It’s less about power and more about collaboration. In my experience, Zephyr operates as a do-ocracy. Your work is immediately visible for all to see, and if it’s good, it’s accepted. If it’s not, you get a chance to learn and improve.
”What I find really exciting about Zephyr, is that you don't need to be part of a big company to be accepted. It's less about power and more about collaboration.
Florian Grandel
BC: So one needs to be open to criticism and feedback when contributing. How do you approach this?
FG: Definitely, yes. Even though you might think you’re 100% right with your approach, it’s likely that the maintainers will have a different perspective, or they might think you’re wrong simply because things weren’t explained properly or they misunderstood something… That’s why entering the process with the mindset of “I am probably wrong” is often beneficial.
When I put a lot of effort into a contribution and the first comments that come back are corrections, it can be hard, but more often than not I find myself thinking “Oh, why didn’t I think of that?”. People might have other use cases that I didn’t think about initially, and I like how collaborating in open source allows me to discuss those in the open.
BC: How long have you been involved as a Zephyr contributor? Do you remember what your first contribution was?
FG: Well, I haven’t been in the Zephyr community for a long time, and yet I can’t recall my first contributions! [laughs]. It probably was a small bug fix to an existing driver, or something like that. However, I quickly moved into the wireless area, which was my main reason for joining Zephyr in the first place.
BC: Starting with small contributions is a great piece of advice.
FG: Yes, pick something simple at first, to see how the community works. And then gradually build trust. It’s very important, I think, in an open source community. The very first comment? Everybody will be watching it very closely, but when you keep engaging, people start listening to you more, and your comments and changes become more complex, and you become more confident too.
BC: What is something about Zephyr that you really like?
FG: There are so many things that I like about Zephyr that it’s hard to choose just one. But if I had to, I’d say the vendor independence that Zephyr provides is a major advantage. Especially when you are relying on chips that might be discontinued, you feel much better if you’re on Zephyr.
The development experience is also a big plus. When you come from a firmware background and you have worked with SDKs, it feels very much close to assembly still: programming registers, very low level stuff. As a full-stack developer myself, when I use VS Code for developing my Zephyr applications, with a debug environment etc., it feels so much more productive.
Oh and driver support, of course. There are just so many drivers you would have had to write yourself before and that you don’t have to anymore.
BC: And are there any challenges or caveats you think new contributors should be aware of?
FG: You might not always get a solution that immediately works. Zephyr is still in an early stage, and probably not as mature as Linux. So you have to be prepared to do some fixes here and there, to understand the code and go deeper. The documentation might not always be perfect, but that is exactly what makes it exciting for contributors: you can make a difference!
BC: Thank you Florian, and enjoy the rest of Zephyr Developer Summit 2023!
FG: Thank you, Benjamin. ⏹
If you enjoyed this article, don’t forget to subscribe to the Zephyr newsletter to receive insightful quarterly updates about all things Zephyr! You can also follow us on Twitter and LinkedIn.