Re: Enterprise Guix Hosting?

[Phil]

Hi Ludo,

Comments inline.  I'm also aiming to be at the Guix 10 Year thing in
Paris - sadly only for the Friday, so happy to discuss this informally
there too!

Ludovic Courtès writes:

> Hi Phil,
>
> Phil <phil@beadling.co.uk> skribis:
>
>
> From your experience, would you say that persuading was hard primarily
> because Guix was unknown (to them), or because getting started is
> difficult?

It's a bit of both, in the commercial space there are some mundane
practical concerns.  One example would  be when 2 companies security
audit each other before using each other's services.  If you're using a
prebuilt image of a well known OS, served by AWS or Azure, then the
reality is that this is often easier for a security team to tick this off as
a known platform - for no other reason than they've seen it before.
Auditing Guix isn't impossible but it can lead to more questions, simply
because of lack of familiarity.  This can be somewhat mitigated by using
Guix as just a package manager on top of a foreign distro, but this
doesn't fully harness the potential of Guix, so it's a trade-off.

Internally speaking the lack of familiarity wasn't as much of a barrier.
Python is the main language where I work, so I sold it as a better version
of Virtual Environments - which work for all languages not just Python.
There was an significant initial effort from me and my team to convert
all the current venvs to Guix packages and integrate it with the various
Runtimes and IDEs we use, but once we'd done this, people were largely
happy to transition.  I did have to do some tutorials and write a bit of
documentation that meant people could start using Guix without really
getting into the details of what Guix is doing.  My argument to most
developers was, "you don't really know all the details of how virtual
environments work, so why do you care about Guix's internals?".  Most
happily accepted this argument, providing you give them good docs on how
to use Guix in the workplace.

Whilst I like Guix's own documentation, some developers did feedback to
me that it was to complex for people who just wanted to get-on and use
Guix, rather than setup, understand and maintain Guix.  So this is the
area I ended-up documenting - "Guix Up-and-running for Python
Developers". One day I'd like to publish it properly, but it's very much
a WIP at the moment!

One advantage I did have is that I rewrote the CI/CD system
to work around Guix, and the old system was showing it's age, so people
were happy to trade Python venvs, for a better build and deployment experience.

We now have 5 developers working at least part of the time writing
Guix packages, or tweaking small bits of the Guix core code (I keep
meaning to make more of an effort to get our efforts back into Guix
proper!).  As more developers slowly try-out more advanced stuff in Guix
this number is growing, and most developers that invest the time end up
liking Guix - so I think there's plenty of hope to grow it further!

>
> Personally I think we need to make Guix approachable to a wide audience,
> meaning not just developers—that goes beyond your target audience, let’s
> be ambitious!  I’d like to think that ‘guix install’, ‘guix shell’, and
> the likes have a rather low barrier to entry to someone who’s use the
> command line before, but I’ve also seen newcomers confused because
> “environment variables are hard” and get in the way.

Yep I do review how Guix is being used at work, and occasionally do find
people using it in weird and wonderful ways.  All I do is build up my
documentation so we have a cookbook like format which covers recommended
ways for developers to do things, and things for them to avoid doing too!

Environment variables can be a common one, when people fiddle with their
PYTHONPATH in their code, or .bashrc, and this can have knock-on issues
with Guix.  Best practice documentation helps with this.

>
> Are there any takeaways from your experience in terms of UX/UI
> improvements we could work on?

3 things which lowers the barrier to entry in my experience commercially
would be:

- Push button WSL support (I know this has some momentum eg
  https://lists.gnu.org/archive/html/guix-patches/2022-08/msg00945.html).
  At the moment I tend to use a custom image I made which is just WSL on
  top of Ubuntu.  I have made it work with busybox, but it's not yet
  robust enough to wheel out over the enterprise like this.
- Perhaps a set of videos aimed directly at converting a vanilla Python
  environment into one running in Guix.  Try to entice the communities
  off their current tooling by making it as easy as possible to switch.
  I even went as far as writing a requirements file to guix package
  converter at work to help with this.
- Excellent Javascript support would help.  I'm aware of some of the
  difficulties this presents Guix, and am not a fan of npm, etc - but
  it's so often used by developers I think not having support for it is
  always going to be tricky to sell to a wider audience.

>
> Thanks,
> Ludo’.