### What do you need?

# Summary

First off let me say that I think the concept of Omarchy (and Omakub as the original project) are both fantastic. Opening up the world of Linux to people coming from other OSes in a very reasonable, manageable and approachable way is something DHH, basecamp, and the community as a whole have done a great job at.

There are people that have provided feedback in various forms (X, reddit, localized talk - discord/interpersonal etc.) that share a common theme regarding the `opinionated` nature of Omarchy. (Yes, despite it being quite clearly labeled as such on the landing page "Beautiful, Modern & Opinionated Linux by DHH".)

I have a proposal that aims to address this; and in the process should also make Omarchy itself more maintainable, both for basecamp as an Org, and the general community as changes are being made and it finds its place among the various ways people install and enjoy Linux systems.

I'll tackle this in two sections, one that addresses the community feedback component, and the other that addresses growth and maintainability.

## Community Feedback

To ensure we're on the same page as we go through the below points I want to set out some terminology - regardless of if you (yes you, reader) consider them the same as what's below this is what's being used. (Your own definitions are yours, and you can share them, but this is how the terms are being used here.)

- **`Distro`/`Distribution`** - Is a fully packaged, deploy-able Linux system that comes complete _with_ its own package repository setup. A good example is that of say, `CachyOS` - it shares functionality for all its components alongside the standard `Arch Linux` options, and adds its own components via the CachyOS repositories, making certain software obtainable via it, over other sources.

- **`Dotfiles`/`Dotfile Repo`** - A prepackaged set of dotfiles (configurations residing under the `~/.config/*` directory) that are either designed to be used in part, or in whole. That's either A) a baseline for someone to begin modifying and creating their own setups with a handful of common packages pre-configured or B) a full 'ready-to-go' setup that contains a fully functional desktop setup (These are more common in systems that opt to use something such as QuickShell, or even the Nix environment to a degree).

(These aren't exhaustive, but they'll suffice here.)

With that out of the way - I want to discuss where Omarchy 'stands' in relation to the above definitions; and to a degree, offer a solution that finds an amenable middle-ground - maintaining an `opinionated` configuration and install (which does; and would continue to, lean closer to a `Dotfiles` - 'ready-to-go' setup), while still being possible for those who wish to use it as a baseline for their own setup (Easing the various pain points - like Nvidia, MacBook drivers/setup and various other fiddly parts) to still have a use-case for it without impacting improvements and iterations (both community and DHH/basecamp based).

**Feedback I've seen so far seems to center around a couple of main points**:
1. **"It's too opinionated"**
2. **"Updates change things that directly affect me, and I have no _proper_ say in it".**
3. **"Certain ways in which Omarchy does things aren't 'right' on a Linux system".** (package management, system configuration etc.)

The point of a 'ready-to-go' set is that it _is_ opinionated; that's not to say that it can't _also_ be flexible in that regard. These things are not necessarily in opposition to one-another.

### Solution?

Moving 'Omarchy' from what appears to currently lean towards a `Dotfiles` - 'ready-to-go' setup to something that more closely resembles that of an actual `Linux Distribution`, albeit still with a solid 'foot on the other side' in the `Dotfiles` category.

By this I mean moving packages, _and_ their configurations to a centralized repository-like setup and having the installer(s) (whether that's the ISO installer, or the post-install scripts for manual setup) pull these down. Similar to how other `Distros` do, with the addition that they come with configurations too.

### Benefits

_Feel free to simply skim the dot points below - Paragraph post-dot is expanded context/reasoning._

- **Easier to distribute** - Versioned software + configurations in one place. Added benefit that users can add/remove individual items as they see fit.

This makes it easier to distribute (both versioned software & configurations). Having packages (programs, or rather PKGBUILD files) in a central repository, while allowing the user to choose between versions (perhaps a configuration cannot be updated due to using a feature that's been removed in a `*-git` release that the user wishes to pull down - they're now in control of how they want to do this).

- **Configurations included™** - Moving per-application packages _and_ configurations to a single request makes management easier for the end-user, and more native than how we're doing so via migrations and other small scripts. Plus the flexibility it brings.

Packaging the configuration _alongside_ the packages in one central repository also means that installing and uninstalling the package (presuming they're tracked) should also be able to clean up after itself, removing said pre-configuration(s) and leaving the user to either freely reinstall either the omarchy-specific packages along with the configurations (and by extension 'reset' only a specific package if they break something and wish to revert to a default state), or to install stock/bare-bones versions directly via pacman/yay/paru and configure their own settings from scratch for that specific program/application.

- **Pick and choose** - Alongside the above point, if user's break a config and want to 'revert' it, they can easily do so via a native package manager, and for those that wish to extensively modify existing programs, replacement with a stock copy becomes easy.

**The above provides a solution to points numbered**:

1. Offering the 'un-opinionate' on a per-package basis, 
2. Opt into, and out of, potential breaking changes - which often are expressed as complaints about something breaking, when in actuality it's about a fundamental workflow change such as keymappings/keybinds differing between versions.
3. Ensures that purists that prefer the use of pacman/yay/paru to manage their system can maintain this fact - and/or existing scripts that they've written still work, given the effort they've likely put in to creating them (system upgrade routines etc.). It also opens up the avenue to have pull requests for changes more neatly organized and tracked as various changes are contributed. (Over the usage of migrations, using versioned package numbers, optionally splitting between (package ver |configuration ver) as a possibility).


(To address point 3 personally; yes, I'm in the camp of: `curl X | sh` is generally a frowned upon practice. It has the potential to break many things on Linux as a whole, let alone on a rolling distribution. Keeping things synced up across a multitude of packages that are mostly dynamically linked is also an important aspect to consider here.)

Beyond addressing ongoing community feedback, this approach would also support Omarchy's long term growth and adoption (including retained users).

## Growth and maintainability

The above point(s) directly tie into the ability for the project to continue its growth trajectory as becoming a go-to within the ecosystem. DHH has expressed the desire to support as large/wide a set of systems as possible - this means ensuring compatibility across generations upon generations of various architecture(s) and hardware.
The most maintainable way I can (personally) see this happening is addressing the move of packages to a base repository structure sooner rather than later as it avoids the potential for large-sized bash scripts to grow out of hand and become a pain for maintenance or simplification down the line.

The use of `migrations` I'll admit is actually quite interesting and may be something I myself consider implementing in places - however I just cannot get on-board with it when it comes to such a scale (distribution wise, and eventual scope of the end-game for the project). After all, we already have a way (many actually) to perform what migrations functionally are at their core, which is replaying historical changes.

## Conclusion

I invite the community to provide feedback on the topic, and chime in with either their own pain points, or ways this can be improved. It's only a quick write-up after having seen community feedback in multiple places and coming to the conclusion that there _is_ a solution in here that strikes a comfortable middle-ground for both sides of the "I want an 'opinionated' yet 'un-opinionated' but 'ready-to-go' yet 'customizable-to-my-own-liking'" groups.