I am willing to give you the benefit of the doubt and try to clear things up.
As I understand it, everyone’s concerns are less about the original nix itself going closed source and more over Determinate Systems making their own version, Determinate Nix, using exclusive features and vendor lock-in to make it the de-facto dominant implementation of nix, and taking that closed source.
This is a well-known anticompetive strategy called Embrace, Extend, Extinguish (EEE for short).
there’s no hint that they will close the source of their fork, IMHO. My worries are that an user that wants to use the the facto stable flakes in his company has to explain his colleagues that such key feature « it’s usable even if it’s still experimental, and no it’s not going away anytime soon, it has been there for five years and there’s a ton of stuff around that uses it » and hope that the community will stop such sterile flame threads and come to a practical reasoning on the present and future of Nix. Or in alternative he can use Determinate Nix which comes from the inventor of Nix that gave it as free software since twenty years, maybe more… I would gladly advise my peers to use NixOS/Nix, but it’s becoming a more difficult argument year after year, It’s sad… so much energy spent on hate… why can’t we just accept what Determinate has done? I’m sure they have done that because the industry (and probably a good part of the other users as well) asks for it (and flake seems the almost correct answer to the pinning of dependencies and de-aggregation of Nix resources) and there’s no clear solution from the community as whole.
BTW, It seems to me that to have some confrontation we cannot put all the open issues on the table every time… there’s no way to come to an agreement in such way. In light of that it seems to me that post that bring in the flakehub or other stuff should not have space here… I never used flakehub, isn’t it just an optional web service around flakes, but I repeat I never used it even if I’m using tens or hundred of flakes since the feature was added to Nix…
Because there was an RFC on what to do about the flake stabilization that ended up with a fairly reasonable roadmap. It’d be nice if this could actually be followed, as the community agreed on it in the way that things about this ecosystem are agreed on.
Detsys neglected to even comment on this RFC, despite their heavy involvement (not even a “nah we don’t like this”, just radio silence for months) and then a week later publically posted something along the lines of “ok flakes are done now”. This is the same thing all over again.
Flakes still have many glaring issues, and the community generally believes stabilization shouldn’t happen as-is. Newer users are blindly using them without understanding the remaining issues, a number of which will need breaking changes to the format.
By forking nix in a way that can well confuse people as to what the “real” nix is, and calling it the much-awaited 3.0, there will be plenty of people who don’t see the difference and start using it. Everyone else will have to follow suit and implement the same spec to maintain parity to what is marketed as the nix, with its known issues. Cue all the complaints about breaking changes and instability in what will be the de-facto nix a year or two down the line - or, more likely, the current limbo continues and flakes never see a satisfactory implementation, because any work on them is hamstrung by all this crap.
This is harmful to the project, and detsys have been doing this for years at this point - undermining and bypassing community efforts. The community is understandably upset.
Flakehub is the perfect microcosm to showcase the problem.
It’s abusing the free-form nature of input URLs to sneak a version compatibility syntax - a feature that is needed, especially for commercial use, even if simpler use cases don’t run into it as much - into nix in a proprietary way. There were proposals for a proper syntax in flakes for this, one of the many remaining issues that impact stabilization of the flakes feature. Detsys originally said they’d still be looking to push a format like this into nix, and have apparently since changed their mind. It’s yet another instance of community efforts being undermined, and in this case in fact being replaced with a proprietary solution.
A competing FOSS web service would likely not be hard to build, and I doubt detsys hold patents, but it’s needlessly centralized and therefore requires hosting capacity, making it difficult for newcomers to compete - replacing a central entity is hard, since it requires existing users to switch, see the quagmire of centralized social media (e.g. twitter, facebook, youtube) for why this is bad for consumers. The syntax itself is also suboptimal because it abuses the URL syntax instead of allowing structured objects.
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 - people will just use flakehub instead of contributing to the spec, and the flake syntax stagnates with a suboptimal, proprietary fix exclusively controlled by detsys standing in for a proper solution.
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, and the sometimes self-contradicting messaging around all this makes it hard to trust anything they are saying.
Thankyou. This is an excellent way of concisely phrasing how a lot of people feel, and the source of a lot of the tension.
It’s good and fair that the community can express this distrust. There are other good examples through this thread, too.
At this point, can I suggest that unless you have something genuinely and interestingly different to add, we consider the problem to have been well covered, and from here on concentrate less on repeating grievances and distrust, a bit less on telling others what to do, and more on reaching consensus about possible solutions and standards.
Thanks, this is the closest anyone has yet come to making an actual case for how we got from ‘DetSys releases a thing, take it or leave it’ to ‘the open source nature of Nix is under attack’.
So if I understand correctly, the problem for us to solve is: how do we encourage investment in community-oriented solutions when companies are motivated to produce and market other solutions that might, simply by existing, relieve some of the pressure that would otherwise drive people to make community stuff?
One class of solution is to yell at the companies until they stop making the solutions they’re motivated to produce. I’m not holding my breath for this one, y’all. (In the spirit of @uep’s post, though, I’m not trying to tell anyone else not to pursue this—just expressing my reluctance to put my own efforts behind it, given how unlikely I think it is to change the leopard’s spots.)
Instead of using the stick on the companies, can we use the carrot on the community?
How about establishing a development fund for some of these hard problems?
How about (not the first to suggest this, I’m sure) spinning up mentorship programs to get more Nix contributors? I’d be happy to participate in that, both as a learner and as someone who could teach some of the very few things I’ve learned while hacking on it.
I think you’ve really hit the problem on the head there; the issue is less with detsys, and more with the nature of incentives of profit-oriented companies in FOSS spheres. Plenty of projects go this way, and frankly, I have sympathy, detsys are a relatively small fish trying to compete with some really big ones who can always choose to swoop in and eat their lunch.
Stallman would definitely laugh and tell us he told us so, so I suppose the less easily dismissed alternative to shouting at detsys could simply be to move to guix instead.
In terms of nix, though, I think the core problem remains leadership, rather than lack of contributors. There are a lot of people here, the summer of nix exists, and I’m aware mentorship and hacking sessions are happening. Yet nix remains understaffed, much more so than nixpkgs. I think we need ways to focus community efforts in core design directions, rather than try to just get more people doing stuff.
At the core of the disagreements with detsys lies the flake spec. Clearly a lot of the community wants to see flakes happen too, so I believe this tension can be resolved amicably, and it would be very healthy for the project, resolving a lot of its problems in the court of public opinion. I think the best way forward is to push for the work outlined in RFC136 to actually happen, at least at a measurable pace. Not a lot has happened in the three years this has been decided on.
How does one organize this? How do you get people over the doorstep to feel entitled and capable of contributing such important - and sensitive - work? Are the lix/tvix folks doing work on this front we could point people to? Is RFC136 itself too ambitious and inherently doomed, and ultimately the real underlying problem?
I believe the primary issue with RFC 136 is that it does not actually address the design of flakes, instead opting to push it off to later community consensus/another rfc which has seemingly yet to happen.
As @rhendric said, simply fund that work to be done by professionals with relevant experience. I estimate that cost to be somewhere on the order of 500k EUR/year for 2-3 years to make a tangible difference, i.e. a couple of full-time engineers who know what they’re doing.
If you compare that to Determinate Systems’ original funding or the amount of skill and effort put into Lix so far, this is about what to expect from Nix if we had that.
I’ve helped raise (and spend) roughly half of that over the past 2 years, but due to particularities of how that funding works it wasn’t and still isn’t possible to focus it (exclusively or at all) on well-understood core problems, and I feel it every day. Collectively all volunteers already contribute in-kind at least an order of magnitude more, but on very different things mostly outside of Nix itself, and with barely any coordination. This is why the pace is glacial. Everyone who works with me knows this is not for a lack of trying.
Remote source management (one issue flakes tries to solve) is only a small part of those core problems, the installer is also one, evaluation performance and caching, code organisation and information architecture, tooling support, security updates, contributor workflows, and even seemingly unrelated things such as how budgeting and accounting inside the organisation works. Those things need to be thought through and built to last.
You will notice that @grahamc and his team are addressing exactly those items, but independently, and he repeated in this thread once again that it’s to work around a lack effective and timely decision-making upstream.
I attribute this situation to a lack of a sustainable business model (i.e. a deliberate handling of revenue and spending) for the foundation and, for what business model there is, a lack of consistent execution. This can be fixed in a straightforward fashion with the right investments (and I’ve made several proposals only recently). One barrier to that, as I’ve experienced in the past, is simply trust: there are risks to take.
The community put trust in the steering committee to make the right decisions, and this is great because finally there’s no ambiguity over who’s in charge. Clearly — and this was to be expected from a group of 7 volunteers — they’re bottlenecked on execution. Who would you give that authority to execute?
It’s a bit misleading to mention this without at the same time mentioning that the duo of Eelco and Graham were pretty much “the Nix community’s de facto steering committee”, at least until 2022. At least that’s my view from someone who was lightly involved in the community at that time (and who had to suffer the consequences of their disappearance in 2023/2024). And whether they want it or not, I believe that gives them a big responsibility in the leadership vacuum that’s only getting slowly resolved now. You can argue it wasn’t their problem to resolve, they don’t owe the community anything, and that’s fair - that still doesn’t mean they didn’t cause the problem. Coming back and justifying their actions as DetSys later by saying “the community can’t agree on anything” feel either oblivious to me at best, hypocritical at worst.
Well, for example by holding corporate actors responsible when they openly the community “oh don’t worry Flakehub might/will become open source” then going back on that months-to-years later after the community has started using their product. Argue all you want about whether “they just left the option open” or whatever, 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. DetSys could have been clearer about their plans and weren’t. They didn’t make an announcement when they decided that FH would be closed-source only, people had to explicitly ask them about it and it was in fact quite tricky to get a proper answer about it for a while.
It’d be great if you could show me this adoption, because so far my data shows it has been rather meagre!
I think first of all we should make clear our attitude towards companies participating in the relevant ecosystem.
When they actively participate in the development of our community projects, make large donations, cultivate talents who contribute to our community, and, most basically, maintain a kind and considerate approach, we should also promote them on the homepage, help display their products within an appropriate scope, and pay more attention to their needs.
But when some companies do not respect us, for example, by making a lot of unnecessary requests for their own needs without providing sponsorship, forcibly adding additional features, or even making unfair publicity for their products against ours, we can of course also criticize their behavior in our public channels and restrict their members from leading our projects.
I don’t think the complete ban is reasonable and enforceable, although it may express the strong feelings in the community. We have no obligation to investigate the background of our contributors, and I don’t think it is wise to let some opponents outside the community make another big news, which will very likely cause others to doubt our impartiality. Of course this does not mean doing nothing, but we may not necessarily do things in an extreme way, but we will definitely make things convincing.
Certainly, the SC should really do something this time. Rather than avoiding conflicts, it should quickly establish prestige in the community to improve its ability to handle such incidents. Some members have obviously raised doubts about SC’s execution capabilities, and tolerating such doubts is obviously not conductive to the unity of community.
A big part of this is the license. Though I’ll just address this here, I really liked your other suggestions too and think they’re good to talk about separately.
Nix is licensed under the LGPL, which naturally resists capture of an open source project. (Note that Social Architecture was brought up in the State of the Union keynote at Planet Nix and is a really relevant read here, check it out).
Directly from there:
This is how I construct the open source projects I start, and it’s the requirement for any community I join. Your right to make money does not include the right to use my work in a competing product, unless that’s reciprocal.
We simply won’t have a proprietary version of Nix because the LGPL is a reciprocal license. If you change the code, you have to give the change back to the community, even though you can link something that’s not open source against it. That’s how the license works.
Ensuring that nixpkgs has the same guarantee while not retroactively asking for consent is left as an exercise to the reader.
Something that stands out to me, both in this discussion and in prior governance conversations, is that a number of people are extremely reluctant to ever proactively prevent anyone from doing anything, and instead choose to varyingly ask people (often implicitly) to “trust the actor/process” or “compete harder”. This is not a sustainable approach.
If the envisioned bad outcome truly is unlikely to happen, then explicitly forbidding or preventing that outcome should be a no-brainer. Instead we end up dancing around the issue and arguing for months, with ultimately nothing happening, all the while the problematic process in question continues to take place unimpeded (and all too frequently results in exactly the envisioned bad outcome).
The trust you are asking people to have is not there. It is not going to be there either, no matter how convinced you, personally are that the actor in question has good intentions. You cannot build on trust that doesn’t exist.
Likewise, you can call for ‘competition’ all you want (whether phrased in business terms or in terms of “funding community work instead”, which boils down to the same thing in the end), but none of that is going to fix the very real practical problems that prevent such ‘solutions’ from actually working out. If this approach worked, we wouldn’t have been seeing a constant string of governance problems for the past many years. So clearly it doesn’t.
So can we just cut to the chase and actually talk about meaningful, restrictive solutions to these issues, without constantly terminating the useful parts of the discussion by trying relitigate “is it our place to do anything at all”? And can people finally learn to get over their emotional discomfort with telling someone (or being told) “no”?
This is not in response to any one particular post, but a general request to all involved.
I want to highlight this and amplify it, since it’s important.
It should not be a surprise that DetSys (or Lix, to use another historical example) have opted out of that process.
I also think it’s telling/interesting that the Foundation is not a sustainable business model: that being the case, it might make more sense to organize things and encourage norms that make it easier for people to try things and get things done (regardless of who they are or who they work for)–increase the appetite for taking risks, increase the ability of new people to try out things without needing signoff by greybeards, and decrease the amount of hostility and gatekeeping from people who are invested in the various long-running culture wars and grudges here.
While it is always great to cultivate more good, you also need to stomp out the bad. If you allow the bad to continue to fester, it’ll continue to grow. Both needs to be done, not one or the others.
What we have now is open core upstream nix. I don’t know if you all have ever used other things that have gone open core, but it is generally a net loss for the community. Open core nix is not an existential threat or something that may materialize, it is already here.
How is it open core, exactly? It might help to lay out that case, since it is a very frequently repeated talking point that seems to be taken on faith by now.
Nothing I’ve seen has forced me (or any number of folks at other companies) to use DetSys.
I think there’s some confusion here between Determinate Nix (LGPL) and Determinate Nixd (I’m pretty sure this is proprietary, but could be wrong) which would explain the concerns about Nix moving towards an open-core model
There are now features in Determinate Systems fork that are not present in upstream nix (parallel eval). I am talking ccpnix, not their extra daemon. That is open core, most of the project’s features are open, and a few are reserved to make the corporate product more attractive.
I am not sure where you are getting the idea of “force” from. That is not part of what I’m talking about.
I am certainly not confused. There are features in DS nix that are not in upstream. I’ve been around Free Softare long enough to know that “we totally intend to upstream that” is not to be trusted, ever. They can however gain some trust by actually making it happen. In the case of parallel eval, the PR seems stalled, and rather than unstall it, DS has done their own thing.
Okay, but there’s a PR open right here with that feature, if I’m not mistaken. And, that code is LGPL (from their repo).
So, again, I don’t quite see the problem–if Nix is slow to adopt something there’s LGPL code and a PR open for, that’s not really on DetSys, right?
Technically the PR is still in a draft state so Nix can’t merge it, and it was marked as a draft by Eelco yet is somehow ready for DetNix now.
Granted, I still don’t see how this is evidence of Nix going open core, but that doesn’t mean I like this situation.