Since I happen to have been doing the pointing-out in the past: The reason why I didn’t get to that yet is that I’m trying to get a few days offline at the moment, and I also only learn about such things as they get published.
While the foundation board did not yet manage to register a trademark or establish a policy, there’s a draft that I think is good enough as a stopgap. Even without legal leverage, collectively we should be able to clearly sanction inappropriate use of the name and visual identity.
In this case, in my humble opinion, calling something “Determinate Nix” is not enough of a distinction from the original project. What I find especially problematic is that, in the latest article on the website at the time of writing, some links labeled with just “Nix” point to the “Determinate Nix” page, and that it’s not clear whether the “Determinate Nix Installer” installs the original Nix or “Determinate Nix”. The heading says “Install Nix” but the command line example sets the --determinate flag. This to me clearly violates the requirement to avoid misleading the audience.
A more distinctive name, at the very least one that does not contain “Nix” as a standalone word, unambiguous communication what the installer installs, and not conflating the Determinate Systems distribution with upstream Nix in the wording and link labels would fix the issue. (By the way, I appreciate that you eventually adapted the wording where you recommended using flakes and the experimental CLI.)
I can’t observe any sort of special treatment, to be honest. Of what sort would that be, and by whom?
As noted by @ron in the other thread, Eelco is still making payments on behalf of the foundation, which is crucial for operating things such as Summer of Nix. Transition of responsibilities is happening, however slowly, and I didn’t notice any other involvement.
But all that is off topic. Because apart from the issues with branding, I think it’s actually great news that there’s yet another product that fills the needs of people who strike different trade-offs than many of us here. I’m confident this has the potential for a win-win situation, as long as we don’t confuse or mislead our audiences and make sure upstream is healthy.
I discussed this with @grahamc at the past two NixCons.
I’ve been advocating for a clear split between what’s libre and what’s proprietary, because the needs and abilities of the different groups of producers and consumers of software are so different.
Proprietary additions do not need to take away from upstream, to the contrary: They can provide a source of income for authors, and absorb a chunk of feature requests that wouldn’t fit upstream anyway; independent groups can also move more quickly and explore the solution space to common problems. Conversely, upstream can focus on stability and standardisation; it’s a very different kind of work that also needs to be done, and it can mesh nicely if we’re deliberate about it.
More special-purpose products downstream and less ambitious expectations to what upstream can (or should) provide would be a relief for maintainers and allow us to focus on substance rather than presentation.
I’d love to see Nix become more of a “library” (minimal, composable building blocks that aim for maximal control), and downstream distributors providing “frameworks” (battries-included scaffolds for gluing together domain-specific solutions that aim for maximal velocity). I’m fine with Nix being “boring” in the sense that it’s a tool for creators rather than an application for users (who may actually care about something else entirely). I’d even go as far as saying that if Determinate Systems buys into flakes so much that they’re willing to guarantee stability, and they and their users are fine with the trade-offs involved, it may as well be a downstream-only feature.
All we need for a more than just peaceful coexistence of different actors in the ecosystem are strong lines of communication. So I think it’s just right that we all keep talking to each other, here or wherever.
