3 ms·

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.

by grhmc 3y ago

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.

pxc 3y ago
> 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.

by grhmc 3y ago

pxc 3y ago

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