Posts by tito.me.doe

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.

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.