RFC: Project BootELEC

    RFC: Project BootELEC – A Unified Hardware Enablement Base for LibreELEC and Its Forks

    Summary

    This proposal suggests creating a new project to separate hardware enablement and device boot efforts from LibreELEC (and all of its forks) into one shared dependency. The goal is to reduce duplicate efforts in supporting hardware, enable faster and better hardware support, and give userland-focused developers freedom from low-level hardware concerns. By decoupling these layers, the hope is to enable collaboration across several communities and still allow each developer and hobbyist to concentrate on what they love and do best.

    Background: Duplication of Effort in Hardware Enablement

    LibreELEC and its many derivatives (CoreELEC, Lakka, ROCKNIX, probably a hundred others) have all forked to pursue different goals or support specific hardware. While this forking is a natural part of open-source development, it has led to parallel work on the same problems:


      [] Bring up bootloaders and firmware for target devices
      [] Integrate kernel patches and device drivers
      [] Maintain device trees and configurations

    Multiple teams (often solo developers) are solving identical hardware challenges independently. This results in:

      [] Slower updates across forks

      [] Inconsistent feature support (e.g., HDR, Wi-Fi chips, display orientation)

      [] Volunteer burnout and abandoned projects due to maintenance overhead


    Forks happened for good reasons. But now we can work smarter—together. By unifying the hardware layer, we reduce redundant work and improve the experience for developers and users alike.


    Proposal: Introducing Project BootELEC - not just a distribution, but an open source collaborative effort to enable custom firmware

    BootELEC is a unified hardware enablement and boot environment that underpins LibreELEC and its forks. It includes:

      [] Bootloaders & Firmware: U-Boot, EFI, etc.

      [] Kernel & Drivers: Mainline or BSP kernels with labeled support status

      [] Device Trees & Board Support: All initialization code in one place

      [] Low-Level Services: Ensure a fully initialized, standardized hardware state before userland boots

    Meanwhile, the userland (LibreELEC, Lakka, etc.) would continue to focus on:


    • [] Launcher applications (Kodi, ES-DE, Steam, etc.)

      [] User-level software, services, and add-ons

    • UI/UX customization

    BootELEC is distribution-agnostic—a shared, modular foundation that every project can depend on without losing identity or independence.

    Benefits of BootELEC

      []🛠 Unified Hardware Support: Enable a board once in BootELEC and reuse it everywhere. This saves developer time and immediately benefits all forks.

      []⚡ Faster Device Support: New devices get day-one support in every distro that builds BootELEC.

      []🎨 Freedom for Userland Devs: Focus on UX and features, not drivers or SoC quirks.

      []🤝 Community Collaboration: Shared ownership across distros, building a stronger ecosystem together.

      []🧩 Modularity: Debug faster, update independently, version cleanly.

      []🔄 Easier Backports: Features and fixes become easy to share across distros.

      []📜 Leverage GPL Source: Vendors release BSPs under GPL—BootELEC becomes the one place to integrate and clean them.

      []👨‍💻 Hobbyists & Pros Alike: Everyone benefits. Solo devs get help, companies reduce cost, and the community gains.

    Implementation Overview

      [] BootELEC can be built standalone or included as a package.mk dependency

      [] Userlands only need to build BootELEC once, then overlay their GUI

      [] Device-specific boot requirements (Pi, EFI, Rockchip, etc.) handled within BootELEC

      [] Clear init handoff to userland (e.g., via switch_root)

      [] Separate versioning for BootELEC and userland

      [] Easy to include via submodule or existing buildsystem tooling

      [] Optional CLI-only BootELEC image for debugging and bring-up work

      [] Shared menu/action directory for device- or distro-specific options


    Potential Challenges


    • [] Governance: Could use GitHub, Discord, or Reddit to coordinate and vote

      [] Scope: Clearly define what’s “boot/hardware” vs “userland”

      [] Kernel Variants: Support both mainline and BSP when necessary

      [] Adoption: Emphasize BootELEC is a tool, not a takeover

    • Transparency: Ensure BootELEC is invisible to users unless troubleshooting


    Call for Feedback & Participation

    Your insight is critical. We invite:

      []LibreELEC & fork maintainers: Can this cleanly integrate into your current workflow?

      []Hardware devs: Would one upstream make your life easier?

      []Manufacturers: Would you contribute your board support to BootELEC?

      []Users & Hobbyists: Would this help you support more devices?

    Let’s begin with a proof of concept—split out the hardware layer, test it, and get a second distro running on it. Then iterate and expand.


    Conclusion

    Project BootELEC is about empowering the open source community, reducing burnout, and multiplying impact. It doesn’t replace LibreELEC or its family—it amplifies all of them by creating a shared foundation for them other forkers to contribute hardware support to.

    LibreELEC was born from collaboration. Let’s extend that spirit and remove the single biggest roadblock to forks and innovation: duplicated hardware support.

    I’m excited to hear responses. I hope you are too.

    Thanks for reading—please share your feedback and ideas. Let’s make BootELEC real.

    Thoughts summarised from private chat with core team members:

    It doesn't make sense for LE to ceed control and its apex position. Our buildsystem is designed around our own needs, follows our own schedule, and is managed to our own standards. Our core team is small and focussed on contributing to LE, and multiple contributors flag themselves as less likely to remain engaged with the project if focus or effort levels are notably changed. Carving up the buildsystem in the way you've described is overwhelmingly seen as a compromising move.

    Over the last decade we expended considerable effort to move away from vendor codebases. They are static which causes long-term package management issues as the needs of upstream Kodi and core packages like kernel and u-boot continously move forwards. They inherently accumulate ever-more technical debt over time as there is nowhere to offload and upstream changes to. Creating a pseudo-upstream target solves that issue for downstream forks and the forks of forks, but will progressively complicate the pseudo-upstream fork. Having worked for years towards eraditcating that problem from our codebase, LE does not want to be the pseudo-upstream target, or to be downstream from that pseudo-upstream target. If the community wants to support a device that has no upstream support, our belief is the community should focus on upstreaming support, which benefits the entire Linux ecosystem not just the audience of *ELEC projects.

    The group of interested parties you foresee harmoniously working together on a common mission contains specific people who we collaborated with in the past, and would never want to interact with again. It also includes groups we already have an excellent relationship with, who choose to keep a level of downstream independence even when they openly recognise working with us more directly would reduce their own effort. They value being able to do what they want, however they want, whenever they want.

    We are already broad collaborators: our Slack instance is ~20% regular contributors and 80% external folk we share interests with. We intentionally keep Slack invite-only to force separation from end-user support and to ensure it remains a polite and productive workspace. We will continue to invite and focus on people we established a positive rapport with.

    We are not against structural buildsystem changes that improve downstream coexistence. We are not against accepting more distribution/project/device targets; adding things that are not always built is nothing new. However long-term maintanability always trumps short-term demand, so there will be limits on what we accept, and for larger changes we will need to trust the contributors. Rather than tackle large impossible topics, people need to focus on smaller code problems and technical details. We know there are issues downstream, but we don't spend our lives poking around in other peoples problems so we do not understand specifics. As the saying goes: If you need to eat an Elephant, do it one bite at a time.

    Hi!

    Thank you for your thoughtful and considerate response

    There are a few concerns expressed that I would like to address because your response is very different from my reality, and why I had hoped to have an open dialogue in the form of chat (and preferably with developers and not so public but it is what it is)

    I do ultimately accept your decision and will not respond again unless requested, but please consider the following.

    —

    I am a professional developer and systems administrator with over 20 years experience in the enterprise (primarily *nix servers and appliances) engineering field. This is not relevant, but maybe you will have a different opinion about how valid my suggestions could possibly be knowing I am not just a random child shouting from the internet.

    I recently bought cheap Chinese handheld gaming devices for my 4 children, and to get them all to have the same GUI experience, I needed to find the source code of several different firmwares and patch them together. No big deal, I got them all running, it’s within the wheelhouse of my expertise anyways, and everything is fine. But in the process of going through the source, I learned a lot and noticed many things, and I started a dialog with the creator of the firmware.

    To address your concerns. The only practical changes I expect were one more package.mk and some files would migrate to sources/BootELEC, and changes to code in that subdirectory would need to be pushed from that subdirectory, but everything else, the actual working environment and process of working on it / with it would not change much. The needed modifications to get from LibreELEC today and the BootELEC I envision is not a lot of code and more just setting up the repositories and moving files.

    I did not expect LibreELEC (nor any fork) to be forced to contribute to, release, nor support any devices you were not already planning to, BSP or otherwise. You would work only on devices you plan to support, and you would only build images you plan to release

    I envisioned BootELEC would consist of branches, and any devices without mainline support or any build issues would be locked to an unstable branch—unable to be merged to stable. In order to build a device with BSP, you’d need to intentionally checkout an unstable branch.

    Just like Ubuntu does with Debian, forks could build an unstable branch to support early adopters, but I assumed LibreELEC wouldn’t release LibreELEC images built with an unstable BootELEC branch nor flag off every missing kernel feature. Whatever devices are being added are not supported by LibreELEC until or unless they reach mainline stability and LibreELEC bumps the package version.

    I did, however, expect devices to potentially get mainline support faster, if developers (not necessarily your developers, just developers in general, like me) could use BootELEC unstable to quickly bootstrap a terminal and dogfood a new device to speed up HWE efforts by being able to run commands on-device and do some config updates in-place with something like VI or NeoVim. We have also seen when popular-enough projects are faster/easier to contribute than torvalds/linux, they can become a very successful and useful path for mainline contributions.

    This idea was never about LibreELEC ceding control at all, it was only about establishing a consortium of similar communities whose only goal would have been to consolidate redundant coding efforts to a centralized repository. Not to create work, but reduce it for everyone.

    As a staple of the FOSS community, I must admit I felt like I got punched in the stomach when your very first argument was that protecting your “apex position, dominance, and control” over the market is more important than supporting open source projects. Welcome to 2025, I guess.

    Thank you for your time and response.

    Maintaining our apex position is about keeping the power to shepherd limited resources and control our workload, not to dominate others, there's no agenda for that. The same cannot be said for some of the downstream elements of our ecosystem.

    I'm home again from Tuesday so if you're around in evening hours (GMT+4) ping IRC and we can chat.