OSS + ELC EU 2026

At balena, a 6 person team maintains 1 distro meta for 80+ boards across multiple Yocto versions. This talk unpacks the layer layout that make this level of scale possible.
Maintaining one distro across multiple architectures and vendor BSPs is, above all, a separation-of-concerns problem. Centralizing every board in one BSP layer, forking vendor trees, or splitting repos without clear boundaries each trades one pain for another: merge hell or upgrade paralysis when vendors move at different speeds.
Yocto's layer model is built for it but the boundaries are easy to miss. I learned it the hard way: managing boards from several vendors in a single BSP works at first, then fails to scale.
During the session, you'll learn:
- How to structure distro logic, version-specific, board and vendor layers
- Anti-patterns from real projects
- Strategies for on-boarding new hardware boards without duplicating distro logic or getting blocked by a lagging vendor BSP
You will leave with a concrete layout to evaluate against your own BSPs and enough pointers using balenaOS’s oss repositories as a reference implementation to start migrating toward a maintainable global BSP.