@grahamc Okay, so first off: thanks for responding and addressing some of the concerns. Being on the receiving end of the stonewall treatment has been nothing short of awful, so I appreciate that you took an effort to change that behavior, and I hope it’s not a one-time offer.
I’ll offer my opinions as someone who’s been criticizing DetSys approach for a while, and I’ll refrain from personal jabs or arguments in bad faith as a token of gratitude for taking the time to respond. I’ll offer my counters not in the order you made your points, but in order that makes for the best critical piece that I can currently muster.
Please respond to my arguments wholeheartedly and without omitting crucial pieces. If you don’t have much to add to something I say, just say “yes” or “no” - that is much better than staying quiet on it.
Yes, I would. I’m of the opinion that what stands behind the frustration and complaining are valid concerns that stay unaddressed. When I see someone cry out in frustration - I’m curious what happened there, what they are unhappy about, why they don’t feel heard.
Of course, when you get some expertise on the topic, you know the common pain points. You also often get to make decisions. Some may align with problems people cry out about, and some may not. Sometimes it is for the better, sometimes it is not. It’s part of human communication, which is hard, and I also ignore some complaints from time to time. Can’t please them all when you have limited resources.
That said, I would quite definitely engage in the “mud slinging” and try to understand where I’m wrong and what people are concerned about, when my repeated attempts at addressing their criticism over the years failed, and the frustration only got worse.
This has been the exact opposite of my experience. People greatly appreciate honesty. People don’t appreciate being dismissed or screwed over. When you are brutally honest, you tell people upfront that they’re not a priority: and that often makes them angry, and you start to wonder that maybe it would’ve been better to let them stay in the dark. But if that becomes a major problem - I feel this is more of a management and prioritization problem, rather than honesty problem.
A large reason as to why, IMO, is that you don’t address the criticisms spoken out. You either stay silent - or fail to address the point made.
You often say that, but what does this actually mean? I haven’t found any editor notes, any glossaries, or FAQs addressing what is a “downstream distribution”. More importantly - I don’t see any of those answering what’s the difference between “downstream distribution”.
Going by conventional wisdom, by impression is that “downstream distribution” refers to artifacts produced compiled with some additional options, and sometimes small patches, to reach some specific goal related to distribution. Examples I can think of: JDK with FIPS enabled for compliance, Debian packages that have specific rules on packageset and compilation, and software compiled with hardened memory allocators for security.
Notably, DetNix doesn’t simply do that: it also includes many very large patchsets, like parallel-eval, lazy-trees, and flake-schemas. Those are major features, developed out-of-tree, and also submitted upstream. This very much coincides with what “fork” means, except that the last part is optional.
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.
If you still insist on saying “downstream distribution” - please, do the responsible thing and put a disclaimer in any nook and cranny that explains what you mean by “downstream distribution”, what you consider a “fork”, and how your definitions differ from commonly understood ones. Because currently - you are just causing a lot of confusion for people by using words to mean things very different from what people usually expect.
It is, like, a good practice to agree on the meanings of the terms before you use them. It’s common in tech, and it’s required in research. And considering that confusion that was caused by you not doing that was spreading for years - please make it a high priority issue and resolve it decidedly.
Your workflow works quite poorly for that. You submit gigantic patches that provide an E2E feature. They are plainly impossible to comprehensively review and test by upstream. This has been brought up a lot of times in lazy-trees and parallel-eval, by Nix contributors and Nix Team members alike. It is also hard to trust your internal code review and testing - you include a whole bunch of other patches that can make things harder to verify, and it is unreasonable to expect upstream to also follow your internal development, anyway.
This is not the case of the upstream being uncooperative - your development workflow just doesn’t work for how a collaborative and open project is developed, at all. Break down your patches into small reviewable pieces, focusing on one small thing at a time - and I’m sure you’ll see so much more success in getting things actuall merged.
Actually, Lix already uses the “small reviewable pieces” strategy with great success. It also doesn’t have a bunch of issues that have plagued upstream for years (some of which directly caused by Eelco). But perhaps more importantly, AFAIK, Lix and Nix teams do try their best to cooperate on important matters - security issues, long-term flake plans, some features and bugfixes. These’s a lot of bad blood there - but both teams still try to cooperate and account for each other’s cultures.
So far, your actions have been very unsuccessful in doing that. So far, things have been getting progressively worse every time you take action. Pethaps it’s time to reconsider how you go about those actions?
I am not sure how your “fame” (from what timeframe, and amongst who?) is relevant here, to be honest
The problems in the community that you’ve outlined are indeed very, very bad. They haven’t appeared overnight, and they go to years of continuous stonewalling of valid concerns. Failure to address them, which repeats again is again, is why I stopped recommending Nix Project to individuals and organizations. I once held thought of doing some business based on Nix Project, and now this haunts me in nightmares.
There are ways to resolve it more gracefully than you do, though. There is political way in the Nix Project - that hasn’t been particularly effective so far. There’s Lix way - a bunch of people, many of whom do Nix for a living, forked the project in hopes of building a better community and structure with less problems from the ground-up. It is too late to suggest leaving Nix completely - but you can still make your fork more of your own thing, independent from upstream. There are even precesents for legally protecting GPL code from “leakage”, if you are concerned about that. Which I wouldn’t, seeing that many patches you already include have gigantic size that is impossible to re-integrate into upstream in short time.
There actually is, for some things. Last I checked lazy-trees - it basically came down “this is impossible for us to review, break it down”. Same for parallel-eval. Issues concerning flakes stagnate, sure - but there is a truly vast amount of related issues that need solving, some of which were already mentioned in this thread.
This is exactly what I’ve already mentioned in my previous post and in this post regarding your priorities and development process being decidedly different from what upstream has.
This will sound hostile, but I do not currently know of a more neutral way to phrase this. Still, I want you to hear me out. I wear my opinion on my sleeve that the “hard decision” that I consider best is to exclude DetSys from the community. This will, of course, be unpleasant to you, but I still want to ask this question out of principle, to better see what common ground and disagreements are there. If Nix Project decides that the “hard decision” to be made is to exclude DetSys from the community, will you support it?
Actually, it can. And Lix people have, on many occasions, suggested renaming Nix to CppNix, to get rid of some terminology confusion and to emphasize the culture shift that happened. What Lix can’t do is decide on Nix’s name, because it doesn’t have the authority to do that.
I’m not trying to one-up you: the difference here is crucial. Lix people haven’t “ordered” anyone - they gave feedback and made a request, and were refused. Nix community offered feedback and made a request to change DetNix branding. It is up to you to comply with the request - or dismiss it. Community is not being unreasonable here, at all.
And the whole reason there is even a conversation here is because NixOS Foundation hasn’t registered a trademark in time. This is just a fact. Had there been a trademark, your “Determinate Nix” branding would be very dangerously close to breaking the law, and NixOS Foundation could choose to resolve the conflict in court, using their lawful rights. I haven’t seen any symptoms of a controversy around trademarking in Nix community, and I have seen strong support for it, so I would assert that had NixOS Foundation had more time and resources, it would be able to register the trademark a while ago, which would objectively prevent you from taking up “Determinate Nix” branding to begin with - there would be no discussion here to begin with.
I don’t do that to intimidate you or threaten legal action - I don’t have the authority to do that, and there’s no legal action to take when there’s no trademark, anyway. I am merely explaining how we got to the point where we have this discussion. Please, do not exploit the fact that Nix is not trademarked due to the organizational issues for the sake of your project. This doesn’t make you look any more trustworthy.
Sorry, I don’t understand what you mean here. Please rephrase.
I think Eelco gave extremely conflicting signals on this one. He developed the feature - and then opened the RFC. He addressed some feedback - and not the other. He agreed in the RFC process that flakes aren’t ready - and still pushed to merge flakes under a feature flag. He closed the RFC as “rejected” due to flakes not being enabled by default and “not being ready” - but also haven’t followed up with other RFCs to solve this mess.
Frankly, due to this history of constantly going back and forth on the decision to be made, bouncing between steelmanning and compromising, and failure to address the consequences of that, which caused such a huge mess to begin with - I don’t think Eelco’s opinion on the matter has any value at all.
And besides, the flakes question isn’t about Eelco to begin with - it is a question about the community at large. It is why the RFC was needed to begin with. Said community and RFC were severely damaged by Eelco acting very irresponsibly around it.
I’m not trying to dig up skeletons from the closet to shame somebody - I am trying to demonstrate that none of the problems around flakes that we see to this day are accidental or made-up. All of them, to this day, go back to that hellish RFC. This is a community problem that you can’t just ignore or dismiss. If you want to move forward without addressing those issues or helping the comminity figure this out - please commit to your fork, call it such, and then you are completely free to do so. But urging the community to ignore those unresolved issues for the sake of progress is very irresponsible, unless you successfully argue and convince the community that your approach at least does more good than harm, and preferrably - actually solves existing and very important issues.
Lix team has committed to their way of solving the problems, which is incompatible to how Nix community does things, by forking the project and doing their own thing. This is a very tall order, and I don’t suggest everyone who’s unhappy about anything to just “fork it, lol”. But you do have to compromise somewhere - you either commit to tolerating the community’s ups and downs, or you do your own thing. If you insist on doing things your way, without accounting for how community works at all - then I suggest fully committing to the fork instead of keeping up the appearance of cooperating with the upstream.