> 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

> 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.