Determinate Nix 3.0

So you think it’s fine that DetSys can unilaterally declare Flakes to be ‘stable’ and bypass the Nix development process? Does upstream Nix then have to fall in line and support whatever DetSys decide what ‘stable’ is because DetSys decided that an unstable feature in a project that they don’t own is now stable?

6 Likes

If they make their own thing, why is it not fine if that thing has whatever bells and whistles they want it to have (modulo software licensing concerns)?

‘Have to’ in what sense? I don’t think they ‘have to’ in any legalistic interpretation. Nix is Nix. It’s not clear to me whether the Nix team or the Steering Council de facto has final say over what the Nix implementation has to do with respect to flakes, but either way, it’s that entity’s decision regardless of what DetSys does.

There’s overlap between DetSys and the Nix team, yes. But if DNix didn’t exist, that overlap would still be influencing the Nix team’s decisions. If they’re in charge and we don’t like their decisions, that’s the problem and DNix is an irrelevant distraction. If they aren’t in charge, they aren’t in charge so who cares?

8 Likes

What’s your take about the fact they explicitly state that it is not a fork, and effectively names it “Nix 3.0”?

19 Likes

My take is it’s cringe.

Re Nix 3.0, to the extent that they’re using the word Nix in a way that would violate our hypothetical trademark policy, they should not do that.

Edit: On reflection, I would like to say something stronger. The branding ‘Determinate Nix 3.0’ in particular is very likely to cause confusion among people who might think that it is in fact the next version of Nix. Intentional or not, that’s bad for the community regardless of the presence of an enforced trademark policy. Pulling PR stunts with your version number is one thing, and calling your downstream project ‘Company Name Upstream’ is another, and each of those to me are like, eh, not great but whatever. The combination is worse because of the anticipated consequences for people who are not actively following the details of what’s going on. Please rethink one or both components of this, DetSys.

18 Likes

I strongly agree with rhendric. If I’m reading the blog post correctly, what Determinate Systems is doing here is effectively acquiring financial means to develop Nix further by fleecing corporations^W^W Providing Reliable Enterprise-Grade Features to their customers (which is my favorite way of monetizing FOSS development). The ideal series of events would be:

  • Determinate Systems gets a whole bunch of money from their customers
  • Pours that money into finishing all those stalled PRs
  • Packages those features up in a nice bundle so their customers can test-drive them and provide feedback
  • The resulting code can be merged into Nix, if it’s good
  • We finally have lazy trees and all that stuff

Am I missing an obvious catch here? When FlakeHub happened, the problem was that instead of bringing semver to Nix, Determinate Systems made a proprietary, server-side semver resolver. When they made determinate-nixd, the problem was that instead of building those improvements into Nix, they instead wrote a separate proprietary daemon that interacts with Nix. I don’t see how something like that could happen here. Are they going to redesign flake schemas so that they’re somehow only usable on MDM-enrolled macOS devices?

The announcement is written in corpospeak, which is quite offputting to me and evidently a terrible way to address this community. It takes a bit of mental effort to untangle said corpospeak to come to the conclusions I’ve made above. Either way, I’m not here to use Determinate Nix, I’m here to use Nix, and I am happy about anyone working to contribute to Nix.

29 Likes

Then I guess you understand the main reason a major component about the outrage: they’re not just shipping more value to customers. They are effectively making themselves the next version of Nix.

While a lot of people would be frustrated or annoyed if they had made those changes in an explicit fork with a distinct identity, they did not.

Putting my FUD foraging equipment on, this is looking like the last E in the infamous set of three Es. They’ve embraced Nix. They’ve extended Nix already (with the value proposition). Now they are actively extinguishing the upstream Nix project by making fetch happen themselves Nix 3.0, the next version of Nix.

No amount of platitudes in the form of PR-like word salads excuses this overt attack against the self-determination of the Nix project.

32 Likes

To me this perfectly demonstrates why a conflict of interest is such an issue, you’re damned if you do and damned if you don’t

11 Likes

This sounds like a very nice sequence of events. My concern was around a possible less ideal series of events, involving nix and downstream determinate nix diverging significantly, which would fragment the ecosystem in a very harmful way. Perhaps some reassurance from determinant systems about relationship they intend to have with with upstream (“ideal set of patches in determinate nix is 0” is unrealistic given different decision making structures) could help here?

6 Likes

This doesn’t look like an EEE to me because an essential component of the second E is using new features that competitors can’t support to create interoperability pressure for end users. For example, Google pushes novel web APIs that other browsers don’t have the bandwidth to support (or that are mostly only beneficial to Google), which results in some web pages working only in Chrome, which (the important part) forces end users to use Chrome if they want web pages to work. This is different than merely competing on features that the end users directly care about—using Chrome because you think it’s faster or looks nicer. That sort of competition is much less insidious, and that’s what it seems to me that DetSys is doing here.

If DNix merely outcompetes Nix on features, that doesn’t stop a minority market segment who are unconvinced by DNix’s value proposition from continuing to get value out of Nix. If DNix changed the game so that Nix was no longer usable, then I would be just as upset as you seem to be. But I don’t see any evidence of that yet. If DetSys is EEEing, they’re still on the first E.

9 Likes

You having to argument “oh no it’s not true EEE because look one bit doesn’t match the common definition” says a lot about the overall situation

8 Likes

I don’t think I’m nitpicking; I think this ‘one bit’ is the central issue with EEE!

3 Likes

To preface my comment, I’ve never been an active community member, nor have I been an active voice on this platform. Neither am I a good enough C++ developer to judge the quality of code contributions.

That said, I would take a more conservative stance here than others, and if Determine Systems intends to upstream (most of) their work, I think it would be very welcome in the project. As far is I understand, we are doing a lot of work with a small amount of people. We are after all, trying to change the world, by changing the way software is built. No easy feat.

I understand that this project being suddenly announced might come across as hostile or seen as a form of takeover to core contributors, however seen the way Eelco has been treated by the community as the initial “creator” of Nix, I don’t feel we should be quick to blame and point fingers. I personally also would be hesitant to communicate directly with the Nix community myself in that position.

In short, I think, we should focus on the good side, and not only the bad.

11 Likes

Given their historical precedent with other projects that max had mentioned above, I would not be very surprised to start seeing some expressions that only work with detnix. It’s not even hard to do so, either, just add a single builtin, it will break on a nix impl that doesn’t support it.

EDIT: and they are already putting flakehub-dependent content into the nixos org, see

5 Likes

Not sure why you’re defending, on a self-selected technicality, a VC company making hostile moves against the Nix project, and the NixOS community, but I’ll bite.

EEE is not a strictly defined term. There is no such thing as ISO-EEE. It necessarily is open to interpretation, even in its original sense. And always has been.

This description you’re using here is a pretty narrow selection of the meaning of Extend. Not only that, but the situation around the competitors not having the bandwidth to support the new features? That’s the last E, that’s Extinguish, not Extend.

With EEE, you have to look at the broader picture. At the whole services offered by the company. That includes the extra services, and also the proprietary additions “around” Determinate Nix

Even with the narrow definition that this would be about abusing a position of power, and “push[ing] novel [features] that other [competitors] don’t have the bandwidth to support”, this is what is happening even in the narrow definition of Determinate Nix 3.0[sic]. The experimental features will be pushed onto customers, put into a shape that fits Determinate Systems’ goals, and other Nix implementation either having to stay incompatible with the fork from the company founded by the upstream project’s founder, or having to stick to their choices.

To recap,

Embrace is self-descriptive here.

We already had Extend via the added hosted services around the Nix ecosystem (some planned did not ship), the additional features around enterprise deployments, and finally the “minor” differences in the default config from Determinate Nix, from before this announcement.

This announcement, taken at face value, assuming every word means exactly the platonic definition, without having a “between the lines” to read from, would be at worst more of the Extend phase.

I don’t think there is anyone disagreeing that Determinate Systems have been Extending Nix and the broader Nix ecosystem.

And here’s where this is interpretation on my part. FUD. The Extinguish phase is now officially started. We are seeing the company taking its privileged place to define what Nix 3.0[sic] is. Whether only through its appropriation of the version number, or through its explicit goals of shipping features before they are done, and deciding their form for when they are done.

(I’m not sure how taking the lead on the learning resources should be considered here. It definitely has already been used to push their agenda.)

NOTE: I am not saying that they have succeeded in the latter E.

Hopefully the Nix project and community is strong enough to again take a stand against the bullying from Determinate Systems, and to continue with their plans toward a good Nix next.0.

Even though I did leave the community (even if it’s not obvious from my apparent lack of ability to let go) I do not want the Nix, Nixpkgs and NixOS projects to fail. It would be a loss to everyone. Whether or not other alternatives exist.


(And obviously, this is all my interpretation of the situation, coming from years of interaction with the different parties involved. Some private, some personally experienced, and some from their continued public actions. I am not speaking in any official manner for anything or anyone else than myself personally.)

17 Likes

This framing is misleading in my opinion. This isn’t about impatience; it’s about the future of Nix and preventing commercial control. Furthermore, there aren’t just “three options” like you point out, that’s a false dilemma. The real true option is community consensus, honoring open governance. It takes longer, but it’s more sustainable for both us and DetSys.

The assertion that “DNix is open source” is a half-truth in my eyes. While some components may be available, the determinate-nixd daemon remains closed source. This is a textbook example of an open core model, leveraging the goodwill of the community while locking down core functionality for commercial gain.

Furthermore, the linked PRs paint a clear picture of Determinate Systems’ strategy. Actively developing key features (like flake-schemas and configurable-flakes, and in the case of configurable-flakes there’s no PR even open upstream yet!) in their commercial fork while allowing those same features to stagnate upstream isn’t a coincidence. It’s a calculated move to incentivize users, especially businesses, to adopt their proprietary solution.

Acting like that this is just another fork like the such of Lix ignores network effects and the huge resource imbalances between the projects. DetSys brands their fork “stable/enterprise,” creating a two-tiered system with commercial incentives.

Examine the linked PRs! Features like flake-schemas are stalled upstream while actively developed and pushed in their commercial fork. This isn’t just negligence, it’s putting profit over community benefit.

Calling community concerns “fear” and “silly” is dismissive and completely misses their legitimate criticisms. We want a community project, not a corporate project, shall I remind you that this was one of the points bought up in the Save Nix Together letter? Additionally, Eelco Dolstra’s position as both the co-founder of Determinate Systems and a prominent member of the Nix team creates an irreconcilable conflict of interest. He has a massive, disproportionate amount of power.

If this model continues forward. This creates a harmful loop of ‘trust’ and closed “open-source” products with nothing but downsides for the community as a whole.

I also want to agree with what the other says that this looks like a case of EEE to me.

  1. Embrace: Integrate into the Nix ecosystem.
  2. Extend: Introduce proprietary features in a commercial fork.
  3. Extinguish: Make the community version less attractive
14 Likes

I’ll begin with a more general point, though I intend to take your comment @rhendric point by point.

Your comment describes “DNix” (as you have so labeled it) as a business necessity. Whether or not that’s true I think it doesn’t matter. A FOSS community should not care about the financial needs of a business. In fact, that business should adjust their behavior for our lack of caring about their financial needs.

No. I care not for DetSys’s financial desires. That you seem to prioritize this over the health of open source Nix itself is tremendously frustrating.

Let’s get on to the point by point.

Then you should partake in the discussion and improve the situation, not go rogue and make something of your own.

Like I said, your business is nothing against the FOSS community we live in.

Your revenue is not my problem.

No? I think we all want to see Nix improve not for the sake of change but for the sake of improvement.

You’re clearly referring to Lix, though you refuse to name it. This fundamentally misunderstands why Lix exists. It’s not because Nix doesn’t do what people want; it’s because its development is too frustrating.

Yes. Correct.

This is in direct contradiction with:

Fundamentally, if there is no consensus about the design of flakes, DNix cannot ship a stable version. Just because DetSys likes their version doesn’t mean they’ve established stability.

How about the fact that it’s not an agreed upon standard?

Graham criticized this very thing, and for the wrong reason. https://x.com/grhmc/status/1889450632857395336

He criticized the use of a Nix fork, but in a jurisdiction that has no concern for the source version of Nix. No, Nixpkgs cannot ship an entirely different source of Nix to its users, for the obvious reasons that Graham pointed out. But changing what Hydra uses isn’t changing what Nixpkgs ships to its users.

Ok, let’s talk about it.

And we as a FOSS community have no obligation to care about what they want their customer experience to be.

As if they should hold priority over the SC? Absolutely not. DetSys is secondary to the SC, as far as the FOSS Nix community is concerned. (It’s “committee”, btw)

Is a natural response the right choice? It’s natural to feel fear. It’s natural to react aggressively. It’s natural to want to hurt people. But we all know these natural reactions aren’t how we should act. Does DetSys know that?

I don’t agree. Making a new fork is not taking control. Making a new fork is lying to people about which source version is the most important. Control remains in the NixOS/nix repo. What changed is what DetSys is trying to tell people.

I think that’s a good point and I think I agree.

As I think I’ve demonstrated, this is not a priority of our FOSS community. We needn’t care for their incentives.

Feels like shifting goalposts.

That would be nice, yes.

This feels like distracting from the problems with your argument.

10 Likes

@samueldr, @nyanbinary, @ElvishJerricco, I appreciate all three of you and will respond individually, but I want to start with this bit that all three of you touched on:

I would like to believe that we can have more nuance here than ‘with us or against us’. I would like to be operating in an environment where if A and B are having an argument, and I express disagreement with part of B’s argument, it doesn’t mean that I think A is entirely in the right or that none of B’s concerns are valid.

To be absolutely explicit about my loyalties:

  • Hard yes to community over corporations.
  • I have no financial interest in DetSys, I don’t use their products, and I have no other connection to them that I think could be construed as a conflict of interest.
  • My primary goal in engaging this thread is to frame the parts of the argument that can be addressed by the SC and cut them off from the parts of the argument that seem to be mostly unproductive and reflexive corp-bashing (and I know those aren’t the words you’d use to frame that, and I’m not sure I’m right and you’re wrong—I am being transparent so nobody accuses me of not naming what I’m thinking!). I think if the SC gets involved and if we the community let them cook, the situation can change—we could get an explicit trademark policy, and we could get something other than the uncomfortable status quo for flakes in Nix. Outcome not guaranteed, but I think both of those things are even less likely if the SC doesn’t get a good handle on what needs addressing because the conversation is so all over the place.
19 Likes

Folks, if you’ve gotten to this point, please take a step back. This thread is not productive. No minds are changing and there is nothing to discuss that hasn’t already been discussed ad nauseam. If you find yourself wanting things to be different then go make that change. Contribute to the kind of Nix ecosystem you want there to be. Shouting past each other has gotten us nowhere in the past and this thread could continue for the calendar year and remain heated.

28 Likes

I just watched the very fresh discussion with Kelsey Hightower on Planet Nix. His advice for the Nix community was to find a way to allow companies to plug in and extend the ecosystem, like Kubernetes did with Custom Resource Definitions. Otherwise a thin team has to solve so much more, and that scales poorly.

Maybe Determinate Nix is not going about it the right way and Nix is so much at the core that this advice does not apply. But I think Kelsey had a very good point in general. Does it apply here though? At least I think it is worth pondering.

12 Likes

If I can’t tell DetSys what they’re doing wrong then I have no idea how to be productive.

17 Likes