Hi, > Rather, this is a way to allow us to work full-time contributing. The > idea is that paid projects, training, support, etc., will help > improve Guix and Guile for everyone, while also supporting us to do > more of the work we already love to do.
As I understand it, there is a lot of potential in Guix for commercial work: - Everything in Guix makes it easy to verify that the result of a work is trustworthy: it's fully free and has a community behind that hopefully reviews contributions, it accepts new packages easily, the machine definition of a VM or a package definition can easily be read by less technical people, even if it was hard to write in the first place. - It is possible to package once and deploy everywhere and the abstractions in Guix allow to take that to the next level if necessary (cross compilation, more VM providers, run on more operating systems through virtualization, etc). For running on other operating systems, Ubuntu/Canonical has a VM system that is called multipass that integrate seamlessly with nonfree operating system terminals, so it might be possible to use that somehow, either with Ubuntu images (apt install guix) or if cloud-init is integrated in Guix at some point to also support nonfree operating systems. It might also just be possible build the 'guix' command for nonfree operating systems and have the daemon run in a VM somehow to be able to increase "the market share" of such cooperative. But as I see it, Guix also has some fragility and limitations that can limit a lot the market share and makes all that harder more complicated to pull off: - Clients need to be aware of Guix somehow and know a bit about it to be confident in using it somehow (instead of "Debian" for instance). Part of the scientific world seems to be aware at least. - There is currently no stable branch of Guix, and some packages might need maintenance, especially since laws/regulations like the CRA. So the question is if organizations are willing to pay for regular maintenance on top of a rolling release somehow. Though to be fair I'm unsure if it's a real issue as Q/A could probably also be improved as here Guix also has a lot of potential. For instance marionette can spawn full blown VMs, so even services can be tested. This could be leveraged to reduce the cost of maintenance hopefully to something acceptable (basically have package that do not break or are fixed rapidly, even with a rolling release models, for paying customers). So you could have a model where you are paid to do packaging and tests that go with it and then rely on a monthly/yearly subscription to run the official test suite and react when the the packages under subscription break. As I understand there are already rules not to break other people's packages in the manual anyway (in the section about sending patches), so we probably have all the building blocks here. - Guix also needs to keep being as friction-less as possible to install and probably improve in this area. Right now there are discussions on getting rid of the Debian package, so if that happens it would have cascading effects that would make 'guix' integration with a lot of things much more difficult, which complicates things a lot for the adoption of Guix for clients inclined to pay for commercial support. Here it would be best to find ways to not only keep the Debian package, but in the long run also manage to fund (maybe through clients) improvements in making Guix also work more easily on Fedora, with just docker pull, making guix pull faster, etc. As I understand (from feedback we got in a Guix monthly even in Paris), this could help the scientific world adopt Guix more which could then potentially bring more clients. Working on a scientific paper would be as simple as 'apt install guix && guix pull (and wait) && guix time-machine --commit=v1.4.0 -- shell <packages> -- command'. This looks easier than learning to create a DockerFile for instance. And then Guixotic could probably be contracted to package this or that dependency (either for 1 paper or with maintenance in mind) and/or make sure this important package does not break. Denis.
pgpi8BfAsOh3O.pgp
Description: OpenPGP digital signature
