What to know before contributing or suggesting ideas…
muOS is a custom firmware designed with purpose. It is not just another RetroArch launcher, not a rebadged distro, and definitely not a clone of anything else out there (that we know of). We care about practicality, predictability, and performance so if you’re joining us to help build, tweak, or suggest changes, there are a few ground rules worth knowing first.
These aren’t “guidelines” in the cOrPoRaTe sense. They are how we keep the system lean, fast, and consistent across devices. Whether you’re submitting a pull request, working on an app, or just spitballing ideas in the community. Have a read of these first. It’ll save everyone time.
muOS will never be about flashy graphics or animations
We care about performance, not eye candy. Animated backgrounds and other fluff are already deprecated and will be removed in upcoming versions if not already done so. If it costs speed or battery for aesthetics, it’s not staying.
muOS is not based on any existing distro
We didn’t fork Debian, we’re not using Ubuntu (eurgh yuck!). We are essentially built upon the Buildroot system. We made everything from the ground up, including our frontend, backend, toolkits, and startup system. Expect unique logic and zero shortcuts.
Code reviews can be brutally honest…
If your code is sloppy or careless, expect it to be called out. But if you show effort, communicate your intent, and explain your ideas, you’ll get support. It’s not personal, it’s standards. So don’t go telling us how we’ve implemented something wrong or blatantly tell us to do something better, use your words be polite. Talk shit, get hit.
Don’t add unnecessary shit
If you’re submitting something like a Pull Request (PR) to one of our repos, it should do something. Apps, scripts, content packs. No fluff, no placeholders, no vague promises.
Everything must have a clear purpose!
Create something people can use. That means an actual application, a close to POSIX compliant script (we can be a bit loose here!), or something someone can load and try. Not “ideas” or incomplete fragments, be realistic.
muOS is fast because it’s lean
Speed and predictability matter more than features. If a new feature adds bloat, breaks the flow, or slows things down it’s not going in. Think about how it works, explain your changes, and ensure it is tested.
No optional dependencies
We don’t include the kitchen sink of libraries “just in case”. If your app, PR change, or whatever, needs something weird, bundle it yourself or trim it back. We won’t burden the whole system for a single use case.
UI/UX logic must support most supported devices
If you’re feeling adventurous and making a frontend change have a think about how it improves the user experience, check the flow, is it easy to get to and understand, etc. If it’s your own app then you go for gold.
Scripts must be POSIX “compliant”
No bash shortcuts, no GNU-only syntax. If it can’t run on BusyBox, it doesn’t belong. However in saying that sometimes a little stray from POSIX is a-okay. We also have toybox available for those offhand little quirks for specific tasks.
muOS is not trying to be Android or other CFW
We are not here to copy anyone. We are definitely not trying to replicate how other systems behave. If your mindset is “how do I make this like xyz” you’ve missed the entire point of muOS.
This is not your average Linux playground. We’re here to change up the CFW ecosystem and try to start building something custom from the ground up, and we expect contributors to understand and respect that.