(i'm on the flox team): A major point of feedback we got from non-Nix users were that they wanted something similar to other package managers. So we looked at the primary differences and focused on designing a user experience with few show-stopping blockers for initial adoption. The goal is to guide people into the declarative side and a gentle introduction to the Nix language and ecosystem.

> Even as a NixOS daily driver, I'm having a hard time understanding how Flox is more than a few shell aliases and a hosted backend.

That's exactly how this started, to "smooth out the rough edges" of Nix. Some of our changes are also being up-streamed into Nix itself, so these aliases and the wrapping can become thinner over time and we can turn our focus to the feature sets that enterprises and organizations want. We are still iterating on:

- easy access to semantic versions - access to a Catalog where each package is known to be built and cached - opinionated nix expression structure - make it easier for users to publish their own software for others to re-use - CLI interface provide interaction with the user - platform native installers (no more `curl | sh`) that use the upstream installer under-the-hood

As a teaser for things on our road-map: - imagine writing a Nix expression that is as simple as a Dockerfile - easy access to transforming your environments, packages, and derivations into different formats - opt-in centralized management of environments - visibility into the environments used by team members and colleagues - optimize AllTheThings(tm)

The most important thing to note is that this is our foray into developing flox in the open and we value all the feedback, thoughts, and especially criticisms.