Determinate Nix 3.0

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?

19 Likes