I really want to think the best of DetSys, and I use some of their work and love it. Some people who work at DetSys have been prolific contributors in the Nix community as long as I can remember. I also understand the urge (and precedent, within the Nix community) to go off and build your own thing to experiment.
But I think with the general pain and anxiety many longstanding community members are feeling over increasing commercial investment in Nix as well as the whole design and rollout of flakes, more upstream-first development would go a long way (as would quickly making good on statements of interest to upstream these features).
I know folks have anxieties about commercial investment, and anxieties about developing flakes. Whenever we hit bugs in flakes, we go work upstream to fix them. We do this rather often :).
I won't try to persuade you one way or another on commercial investment other than it is here with or without DetSys, and we've released a rather large suite of tools to make using Nix more pleasant and all but one (flakehub's backend) is free and open source. I feel that is a good way to go!
I also think developing features and improvements to Nix outside of it is a good way to prove out ideas that can be eventually merged in to core. We don't _want_ to be solving the version on the server, but I'm rather sure it would have taken months if not years to get an experiment merged. And for good reason: we all want to make sure what goes in to Nix is solid.
> I also think developing features and improvements to Nix outside of it is a good way to prove out ideas that can be eventually merged in to core.
I think it definitely can be. Naturally, more DetSys code and ideas that go through that whole journey, the more likely Nixers will be to reflexively trust the company when it comes to new projects. I'm optimistic that that can turn out well.
> we've released a rather large suite of tools to make using Nix more pleasant and all but one (flakehub's backend) is free and open source. I feel that is a good way to go!
I think open-core and proprietary services based on F/OSS can be an effective business model that helps get valuable open-source work done.
For me, Red Hat's model and Qt-style dual licensing are even more attractive because they are based on comprehensive F/OSS licensing.
That said, companies have to figure out licensing strategies that make sense for them and the particular markets and software they're dealing with. I don't begrudge, e.g., Determinate Systems or Cachix or Hercules taking up strategies that involve proprietary services because I've seen people involved with all three companies continue to make important contributions to Nix, Nixpkgs, and F/OSS tooling in the ecosystem that's about more than just plugging into those services. That signals good faith engagement to me.
But seeing stuff like version management get handled in bespoke ways in proprietary services like FlakeHub or at Flox when it remains unaddressed in Nix itself naturally raises an alarm, though.
> We don't _want_ to be solving the version on the server,
I feel like that's good sense architecturally.
Seeing this problem solved in Nix itself will help establish a record and reputation.
But I think with the general pain and anxiety many longstanding community members are feeling over increasing commercial investment in Nix as well as the whole design and rollout of flakes, more upstream-first development would go a long way (as would quickly making good on statements of interest to upstream these features).