Hot Takes, Lessons Learned of Open Source (OSSNA 2025)

After a successful week at OSSNA 2025, I’m now back at the office recharged with open-source vibes!

This year’s summit in the US took place in the beautiful Denver, Colorado. Being my first time in the city, I arrived a few days before in order to get used to the scenery and decompress after a few weeks nailing down the details (and demo) of the upcoming presentation. Coming from Florida, I was received with warm and dry weather, which made it perfect to walk around town, watch the Rockies play baseball and enjoy local spots in downtown.

Since Day 1 of the conference, I was surprised by the amount of people attending and willing to share their experiences after countless hours of hard work (and troubleshooting). I got a chance to meet with peers I’ve already collaborated with before as well as new folks which I look forward to do so as well.

I was also very happy to see many people attend the presentations of the Zephyr track! It is only fair to say the Zephyr community is growing and that more people are eager to hear what are the topics and use-cases Zephyr is currently used in embedded. Presentations providing practical lessons on using LoRaWAN FUOTA for in-field firmware updates, as well as Optimizations for Real Time systems, were some of the ones I found most interesting. Alternatively, there were interesting talks in the Embedded Linux track with insights on similar problems we’re facing in the Zephyr community. Again, the value in learning from each other is another key “byproduct” of Open Source.

Additionally, there were many positive remarks around Open Source and why it makes sense for companies to contribute: not focusing on the amount of money spent for work that ends up “free”, but rather looking at the benefits of collaborating with companies to make it better. The key in the value of Open Source relies on not reinventing the wheel every single time, but making a better and stronger wheel, and not having to push it down the road all by yourself.

Finally, addressing the “E-LLM-ephant” in the room: There was also a lot of AI, but not the kind you see in the news: The future of Open Source is the people who make up the community as a whole. As long as developers and contributors are put at the forefront, the ecosystem is guaranteed to continue growing: with as much or less AI as every individual finds reasonable to be productive and provide true value.

Out of everything that occurred at the conference, I bring home the following key takeaways:

Key Takeaways from OSSNA 2025

1. Learning from Linux’s Experience

Embracing open source means benefiting from other people’s experiences; it seems like improvements we’re currently looking at RTIO in Zephyr have already been explored and addressed to some extent in Linux. In that regard, I found these talks particularly valuable:

• Robin’s talk on Sensor Data Acquisition with Linux’s IIO and LibIIO
• David’s talk on Maximizing SPI Throughput in the Linux Kernel

2. Open Source is Strategic Collaboration

Contributing to open source is not “giving away” code to your competition: it’s relying on each other to maintain an optimized version of a module that otherwise wouldn’t exist. The value we get by having thousands or millions of developers use it, test it, report bugs and fix them far outweighs the cost of upstreaming it.

The idea of collaborating in the core, competing in the corners results in a much healthier and productive environment for everyone.

At a glance, the work presented by Sidd Gupta on an optimized LoRaWAN FUOTA Service could be very beneficial for the Zephyr community all in all. Hopefully we can help you get it upstreamed soon!

3. Lowering the Barrier to Contribution

We need to continue helping the community contribute: lots of people excited about the work they’ve seen in Zephyr and looking forward to being a part of it, but are not sure where to start. My quick suggestions:

• Don’t be afraid to ask for help/guidance. Read the docs and reach out if something isn’t clear. No one has all the answers and we don’t expect you should.
• Start simple. Don’t try to introduce a whole subsystem all at once. Maybe try fixing a few bugs on existing modules and work your way up.
• Be open for feedback. Especially if you’re changing existing code: be mindful of other people’s use cases as well as yours.

Looking Forward

Thanks to Croxel for sponsoring my trip to Denver and appreciate everyone who reached out at the event. Looking forward to continue contributing and learning from this amazing community!