Every time someone makes this point, I will keep making the same point right back: you just did.
(If this is going to digress the conversation, let’s take it to a separate Discourse topic please.)
9 Likes
I see it as both, in a way? More a way to create a convenient jumping off point that could feed into more contribution. But, yeah, ultimately it needs to be fixed at layer 8.
2 Likes
The thing is, that appearance isn’t wrong - people and organizations are correct to be skeptical of Nix as a project right now, because we have an awful lot of governance problems that have remained unaddressed for many years, and that are causing very real churn and burnout among contributors.
I do not think it is a good thing to try and present things as being rosier than they are; it does a disservice not only to those people and organizations being misled by such an effort, but also to the existing community which will collectively be held responsible for that dishonesty, fair or not.
27 Likes
This. So much this.
I have stopped recommending Nix to organizations that I work with, because I know for a fact they’ll run into issues that are indefinitely blocked by governance, and I’ll be the one held accountable. I have also started to actively discourage individuals from trying Nix, because I know for a fact they’ll run into issues that are indefinitely blocked by governance, and I don’t want them to experience the absolute misery and despair of trying to get anything done about them.
Rather than trying to look good, we need to solve the problem that has been going on for years. Using a coat of paint over the absolutely rotten fundamentals will not help with that. And neither have the last 100 posts, consisting mostly of sealioning, concern trolling, strongly rejecting the notion that there is a problem to begin with, and pondering what happens years from now - while we are in emergency right now.
15 Likes
Because Eelco called it “Nix”, not “CppNix” or anything else. It’s simply just known as “Nix”. The way I’ve seen many folks call “Nix” as “CppNix” makes it seem like it’s lesser despite it being the official & original implementation.
3 Likes
The reason people have been calling it CppNix when referring only to the implementation is that, otherwise, it would be confusing because the name Nix means:
- The language
- The CLI
- The ecosystem
- And vaguely refers to the package set and individual packages
It is out of practical necessity when communicating to be able to say “the original Nix implementation that exists at nixos/nix and is written in CPP,” but that is a mouthful. It is a bit like if Linus Torvalds named the OS kernel Linux, and systemd was also called Linux, and the ini format was also called Linux. There is no reasonable way to refer to just one without clarifying. Whether it is NixCLI, CppNix, NixOG, or any other name, that would be preferable over the current naming. Other pieces like the language being termed NixLang would also be helpful.
26 Likes
Worth noting it doesn’t really matter what who named what. Insistence on dogma is rarely a good response to a call for pragmatic solutions to real-world challenges.
5 Likes
Back during the governance bootstrapping discussions, we had a thing going where long discussions would periodically get recaps written up and posted so that newcomers wouldn’t need to scroll through quite so much (and also so the rest of us could get a better picture of what had been covered already). I liked this, and have been keeping notes on the various threads at play here, so here is my attempt at a mid-level summary of the last 220 posts, ‘the good parts’.
If you believe you’ve been quoted out of context or otherwise inaccurately unfairly represented, please DM me and I will be happy to edit this record to reflect your true intent. Similarly if you think my POV has caused me to omit an important and on-topic part of the discussion, or if I just plain made a mistake (been doing a lot of quick copy-pasting these last few days!).
DetSys statements
- The initial post [1]
- ‘we will be making [lazy trees and parallel eval] available to users in the very near future’ [7]
Complaints about DetSys
Accusations that Eelco is intentionally holding back upstream Nix: [5, 8, 17, 35, 56]
- @jade: ‘it looks bad for the [Nix] project lead to be employed [selling packaging] while the default packaging is as poor as it is.’ [16]
- @piegames: ‘[Eelco on the Nix team] is an intolerable conflict of interest to me.’ [27]
- @KFearsoff: ‘You [implied: Eelco] could take responsibility […] and actually take it [flakes] to completion without dismissing valid issues as “not a bug”.’ [86]
- @TLATER: ‘It’s hard to look at this and not feel like detsys’ business model is shooting nix in the foot and selling you solutions to problems they are causing’ [173]
- Dissenting posts:
- @uep: ‘a commercial distribution with paid support can potentially try out some of those features sooner, precisely because there is paid support to deal with all the late loose ends that are required for stabilisation.’ [18]
- @rhendric: ‘The natural response to [feeling out of control of which features get merged] is an independent fork’ [41]
- @rhendric: ‘Would you leave those PRs open in the upstream project, and continue to push to them as recently as three days ago [if you wanted to suppress them]?’ [66]
- @ppenguin: ‘So supposing that DetSys would “just want to get things done” first of all, and worry about everything else later, I can understand how things are like they are.’ [117]
- @grahamc: ‘Eelco has been ready for flakes to be stable for years. He’s been internally advocating for us to release Determinate Nix 3 with the experimental flag removed for a long time now.’ [118]
Concerns that, intentional or not, the effect will be that upstream Nix gets less development if DS fills gaps with their solutions
- @doronbehar: ‘However, with Nix and with DS, it is not clear exactly what is the business model and how is this aligned with the community model.’ (And several more useful questions in this vein.) [23]
- @TLATER: ‘In other words, detsys have successfully subverted community efforts by offering something that they are uniquely placed to sell, and thereby halted natural sprouting of grassroots efforts’ [173]
- @delroth: ‘the net effect is that this might have reduced interest in developing an open source alternative as it would just be “a second open source system doing the same thing” when Flakehub eventually became open source.’ [179]
Claims that this is a de facto ‘open core’, and that’s bad: [8, 109, 185, 188]
- @nyanbinary: ‘DetSys brands their fork “stable/enterprise,” creating a two-tiered system with commercial incentives.’ [56]
- Dissenting posts:
- @crertel: ‘time-honored way of helping industry adoption’ [10]
- @max: ‘what Determinate Systems is doing here is effectively acquiring financial means to develop Nix further […] my favorite way of monetizing FOSS development’ [46]
- @rhendric: ‘the fact that Nix and DNix are not controlled by the same entity is an important difference here’ [66]
Claims that DetSys is doing an EEE: [47, 54, 55, 56, 171]
Brand confusion between Nix and Determinate Nix
- @kranzes: ‘we got det nix 3 before nix 3’ [entirety of post] [24]
- @nyanbinary: ‘I have seen people confused thinking this was Nix 3.0 when it’s not.’ [35]
- @rhendric: ‘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.’ [45]
- @samueldr: ‘Determinate Systems, even though it might not be the intent, are now using the lack of trademark surrounding Nix to cause confusion’ [127]
- Dissenting posts:
- Relevant: Nix Foundation lacks a trademark policy [36]
Assertions that DetSys should use the word ‘fork’ to describe Determinate Nix: [2, 27, 35, 67, 113]
- @KFearsoff: ‘The only project I know where it is considered acceptable to develop patches and features out-of-tree and call your project a “distribution” (that would necessarily be “downstream”) is Kubernetes. k3s, k0s, minikube and others - call themselves “distributions”. I don’t know how that came to be, but it is an extremely abnormal practice.’ [121]
- Dissenting posts:
- @grahamc: ‘we won’t describe our downstream distribution as something it isn’t’ [114]
- @grahamc: ‘it is a downstream distribution. There are many examples of exactly this pattern: distributing a patched version of an upstream project and call it “CompanyName Project” […] One prime example of this is Linux itself!’ [133]
The Nix team is blindsided by Eelco’s lack of transparency: [31, 40]
Disputing the honesty of DetSys
- @ElvishJerricco: ‘So creating features in your distribution that are not acceptable upstream is disingenuous.’ [11]
- @cafkafk: ‘they unironically gaslight you’ [25]
- @samueldr: ‘you had spent a long time ghosting me. […] So I’ll continue having my doubts about the veracity of your communications.’ [125]
- @TLATER: ‘the sometimes self-contradicting messaging around all this makes it hard to trust anything they are saying’ [173]
- Dissenting posts:
Complaints that DetSys software is not open source enough: [158, 166, 167]
What to do about flakes?
- @SergeK: ‘call it a “make one to throw away” project […] I think should start phasing Flakes out’ [71]
- @polygon, @dschrempf: ‘No.’ [72, 73]
- @RaitoBezarius: ‘It [a phase out] doesn’t mean breaking Flakes for end users in the process.’ [75]
- @waffle8946: ‘I (and others) more or less had the same complaints about flakes 2 years ago, and it seems we are no closer to actually solving them.’ [80]
- @KFearsoff: ‘Flake code can’t even be called a “mess” - it is of very low quality, absurdly tightly coupled and prone to breakage on sight.’ [86]
- @RaitoBezarius: ‘This [issues with the design of flakes] is why we are calling on NOT steamrolling [flakes] even though it WAS steamrolled in the past. We all want some form of hermeticity of evaluation and dependency management, but as I said: this requires HARD work.’ [98]
- @grahamc: ‘I literally do not care at this point if the decision is flakes or not flakes. My users do care, though, so I am delivering what they are begging for.’ [129]
Steering Committee response
Calls for action
For others
- DetSys to voluntarily rename Determinate Nix [45, 71, 109, 119, 130, 136]
- DetSys to add an SC/Foundation board observer [157]
For us, restrictive
- Eelco to leave the Nix team [27, 32, 123]
- Nix Foundation to get a trademark policy [36, 41, 71, 109]
- Ban DetSys from NixOS community spaces [121]
- ‘meaningful, restrictive solutions’ [183]
For us, constructive
- Upstream Determinate Nix features to Nix [28, 29, 49, 53]
- Help out with Nix [70, 106]
- Fund development of community-oriented implementations of the problems DetSys is solving in a business-oriented way [175, 178]
- Mentor more Nix contributors [175]
- Make Nix merges less regulated [204]
- Give Nix accessible extension points [210]
93 Likes
Verse deleted at request. I am unhappy, but I oblige.
My points, in a less elegant way:
- FlakeHub should be open sourced if DetSys is acting in Nix’s interest. It adds a guarantee that there will not be ‘user capture’.
- FlakeHub should be open sourced if DetSys is acting in it’s own interest. It makes security audits easier and vulnerability disclosures more streamlined. One of it’s major clients is a defence contractor, so I imagine this is a priority.
- I have seen people argue that flakes are interdependent across the codebase and that the implementation is fragile in places. This is seemingly the opposite of what Mr. Christensen has claimed, so I ask that there be some kind of open and objective test of which claim is right. I think a 3rd party contractor could serve this role.
Oh, and there should be some deadline to all of this, with some kind of constructive actions taken, and it should be soon. Matter of days, not months.
6 Likes
Natural language, such as English, is highly dynamic. It constantly evolves to the needs of those using it. If a word refers to too many different concepts that need distinguishing, people will find different words for those different concepts to distinguish them.
In the beginning, there was only “Nix”. It referred to the language and the package manager and the code base and even the package set, and it was fine. As the project grew, the words differentiated. For example, the increased usage of Nix outside of NixOS necessitated separating the concepts of “Nix” and “NixOS”, which is reflected in these distinct words.
Now, with there being at least three different Nix implementations, we suddenly need to distinguish between “a” Nix implementation and “a specific Nix” implementation. Tvix and Lix are the names of Nix implementations, but this leaves a naming collision for “Nix” to be resolved.
You can find this disingenuous all you want, it won’t change the hard truth that people need words to express concepts and if the ones they have aren’t sufficient then they’ll simply make up new ones. Which words get adopted is an inherently anarchistic process that boils down to memetics mixed with a bit of social dynamics.
I think in the beginning, people started to call then-Nix “EelcoNix” or variations thereof, which quickly died out for various reasons (notably that the word was used with a derogatory connotation). “CppNix” won the memtic game against “EelcoNix” and “Nix”. So if you don’t like the word “CppNix”, stating why you don’t like it won’t help your cause for the reasons I laid out. Instead, you must propose and establish a new name that one-ups “CppNix”.
Personally, I’ve started using “orig Nix” instead of “CppNix” after the recent discussions, simply because I prefer it and people still understand what I mean. Feel free to join me, or to bring your own proposal to the table.
20 Likes
I’m constantly surprised by this response. Is it because folks badly want to use it, but won’t because it isn’t open source? Surely it isn’t considered a threat: very few people in the foss ecosystem use/depend on it!
I usually just let these points go, but what the heck. I’ll share why this point doesn’t hold water for me, or most other companies. I appreciate what you’re trying to do, but there might be more effective avenues of persuasion. Customers have never audited or asked to audit the source code. They care more about audited compliance like SOC2, FEDRAMP, etc. Many of these compliance audits care more about documented policies, and evidence of implementation.
Please, Mr. Christensen wasn’t even my father!
3 Likes
Perhaps a policy from Determinate Nix on a maximum amount of time they’ll allow a feature to be “DNix exclusive” could help here.
Problem: Lazy trees in DNix, but only a draft in Nix repo. Status unclear.
Solution: Determinate Nix guarantees to demonstrate their commitment to contributing upstream by setting a deadline of X weeks/months to get the PR equivalent to active code in DNix. X hours will also be used to discuss change requests and get the PR merged. Past X hours spent, from the DNix point of view the PR could stall indefinitely and they have no commitment to finish the PR.
I think the problem is leaving the “commitment to upstream” blurry while features not yet in CPPNix get put into DNix and are used to improve the DNix brand at the cost of CppNix.
2 Likes
I don’t have a stake in this, except that I’d like to have some of these features in Nix too. But… why would they agree to such deadlines? Determinate Nix is open source, people can take the features and add them to upstream Nix if they want to? The LGPL does not have an obligation to present changes as a PR.
It’s their business, they can do what they want, just like the community can decide not to include Determinate Nix in nixpkgs [1]. I am sure that Determinate Systems would benefit from upstreaming changes to avoid diverging too much (making rebases harder).
Lazy trees in DNix
As far as I understand, they are not in Determinate Nix either, just announced as an upcoming feature.
[1] The only possible pressure that can be applied to companies is a trademark policy, which requires that Nix is a trademark that is unambiguously held by the NixOS Foundation, which (IANAL) in many countries implies actively defending the trademark. Since Determinate Nix Installer has been used for a while already as a product name, I guess (again IANAL) it’ll be pretty hard to defend by now.
5 Likes
This is again, a technical solution. A technical solution here will not be a fix for the social problem we have.
As @rhendric has noted, DetSys (Eelco) has been doing some work upstream, but the PR is in draft (parallel eval) so it can’t be merged.
The social solution is to increase communication and clarity, perhaps by having a roadmap and perhaps by having the original author of the PR clarify what is going on.
It would be beneficial to the community for DetSys to make it more clear what is going on, but judging by the blog post and Graham’s communications here, that won’t happen.
IANAL either, but my understanding is that once the foundation applies for a trademark, DetSys can offer prior art that the foundation has never tried to have nor defend a trademark for “nix” etc, and it’d be difficult to get said trademark now. And given Graham’s responses on this thread, I’m willing to be that Detsys would challenge the trademark in order to preserve their use of it in their product.
Almost as if Eelco’s inaction on this front a the (former) leader has lead to his company being able to exploit the lack of trademark for their own gain. hm.
7 Likes
Second time you’ve asserted this ‘can’t’ be done, and in context I don’t know if you mean technically or socially.
Technically, maybe one can’t click the GitHub button to merge the PR, but one certainly can merge the branch manually with Git, or open a second PR with the same content. @crertel already made this point, to which you responded that you ‘don’t need a git tutorial’, so if this is what you mean why do you keep saying this?
Socially, you’ve said that you’d ‘consider it rude’ to move forward on this without Eelco’s blessing… is that why you say this ‘can’t’ be done while the PR is in draft? But if Eelco is the problem in your eyes—and from the rest of your message, that seems to be the case—why get hung up on that point of protocol? Either this is more important than him, in which case let’s do it if there are no other obstacles, or it isn’t, in which case why are you arguing for throwing him out over it?
This is sadly my understanding as well, and it’s why I asked Graham about conditions under which he would rename Determinate Nix voluntarily. From PMs I think the SC may be planning for some sort of negotiation about it, which seems like a better path than legal saber-rattling, because I don’t think our hand is good here.
9 Likes
Highlighting this for emphasis.
The articulated problem was “Hey, we can’t merge/update the draft PR because we don’t own it”, and I (after having to refresh myself on how to do this, because I hadn’t had to do this myself in a few years) found the solution to the technical problem and shared the workaround. The technical problem articulated is both solvable and solved. We don’t have to be helpless in the face of mere technical problems.
Again highlighting for emphasis.
If the problem is that a contributor is blocking, the solution is to work around them and get unblocked.
We don’t need to tar and feather them, we don’t need to ban them, we don’t need to write long screeds about who did what to whom on account of why…we just need to solve the technical problems. Bonus: this applies in perfectly amicable cases as well–if somebody needs a break, gets sick, or whatever, it’s the same sort of problem.
The thing I’m concerned about is that, even if a magic genie came along and granted the wish to move the contributor and his company to another realm or fix the naming collision or whatever, there’s not a Day 2 plan to then get us any closer to parallel evaluation, nixd cron garbage collect, or whatever else it is that theoretically is being down downstream that we really want.
There’s certainly not a plan to clear up the backlog of issues (3k+) or PRs (300+) on the nix language, to make the codebase easier to hack on, or to expedite the review process for new contributors.
All of the effort and ink spilled in attacking the founder of the language and his commercial venture does not at all help solve the very real technical issues that the project is facing.
I’m not asking anybody here to reconsider if the beef is legitimate–I’m simply asking for acknowledgement that hey, there are more pressing concerns and the current strategy ain’t working to fix them.
4 Likes
I totally agree that clarification would be helpful. I just don’t see why DetSys would commit itself to:
because either they are motivated to upstream improvements and than the answer would be as soon as we can and after that it’s up to how quickly the community can integrate it. Or the answer is we don’t want to put in the work and then promising a set time frame will only lead to disappointments.
Secondly, I think that it’s asking to much for a company to commit to timelines for ‘free work’. It’s something that a paying customer can ask, but volunteer work is often on a best-effort basis.
Again, I completely agree that clarifying what the policy is in general and the plans with regards to the particular PR would be very helpful.
1 Like
Socially: its a problem. My assumption is that others (and the only others that really matter are those on the SC and others actually working on Foss Nix) are still trying to salvage the relationship, thus merging his PR would not be a great move.
Technically: sure, grab his commits from his PR or the commits from dix and merge them if they’re of good enough quality.
Legally: Yes we can grab commits and merge them. AGPL and all.
In my mind it is, but it isn’t my call, that’s why I spend time discussing here; it’s what I can do.
I never argued this, but I am deeply unhappy with this blog post, specifically blaming upstream, as I’m sure you know, is extremely problematic in many ways.
It’s not “free work” though and the benefits of upstreaming work are numerous and known at this point. And it is their own stated goal to both upstream and be a “downstream distribution” and “not a fork.” Is holding them to what they say important?
6 Likes
If we’re looking for prior art of how always dropping gigantic PRs from a company isn’t the most sustainable practice, ZFS development may be worthwhile to look at. Notably, ZFS encryption had engineers from Datto PR the entire implementation. It got fairly well tested at the time, but still had various bugs that are still being ironed out, but also has been difficult to find maintainers for as time has gone on.
There are parts of the discussion here about the sustainability of gigantic company-endorsed contributions to a community maintained C codebase that feel similar. Whether “don’t do it” is the correct answer is unclear, but I’m not exactly sure how to make it sustainable either.
On technical and social problems, and solving things at the right layer
Sure, it’s important to not confuse social solutions with technical ones. I think it’s important to mention that there are technical solutions focused on reducing the number of barriers to entry that allow us to merge more optimistically though, which is socially beneficial.
by-name in nixpkgs is one such solution, by virtue of the fact that people can use the mergebot instead of waiting on lengthy reviews, which is a technical solution that results in less pending PRs. The social solution is “get more people able to merge” but this obviously may not scale to all software in nixpkgs here.
In reality, there are solutions in the middle, between “nix merge bot for plugins” and “ridiculous review times” like maintaining plugins in nix-community, or something. Not exactly a binary choice, even from a social problems standpoint.
9 Likes
Those issues are not technical, buy social. And they all share a common denominator - project culture, and less broadly - the still-present cultural bits that founders have instilled, enforced and defended.
This is a good example. Though, the large disparity between what companies consider “done” and what openly governed communities consider “done” has been consistently and repeatedly brought up since the beginning of the thread. Not sure why we need to relitigate this.
RFC 140 is one of the best RFC we had: it was excellently written, and people very quickly unanimously agreed that it’s very good. The only point of disagreement was naming, and it was unanimously decided to be pretty insignificant.
And then Eelco came during FCP, and said he’s going to block people’s work on implementation because he doesn’t like the name. Despite not having been involved with Nixpkgs for years. If I had two paragraphs to describe the issue we as a community are dealing with, I would write this and previous paragraph verbatim.
I recommend reading the full discussion around naming in RFC 140. It’s a perfect demonstration on how Eelco has been continuously blocking efforts in the community. Perhaps, if we haven’t lucked out with finding by-name which apparently pleased Eelco, RFC 140 wouldn’t have been done to this day.
7 Likes