Re: Enterprise Guix Hosting?

[Yasuaki Kudo <yasu@yasuaki.com>]

Hello Phil!!!

What you wrote makes so much sense and sounds very familiar because I had similar discussions with my partners at our worker coop!

Sometime soon perhaps we can discuss in a video chat or something?

Our idea is at the coop is that we want to develop software development acceleration tools, and a major part would be container-less software provisioning so that composition would not mean more and more layers of technical debt...

We would like to do this alongside our regular paid software development for existing clients.  Once we have acquired enough scripts, knowhow and the enthusiasts among our colleagues, we can spin it off and sell it as a service/consultation! (software will stay as Libre and Free - enterprise users would not be interested otherwise )

BTW, I am probably the least technical person within the IT side of our coop - my other partners are pretty high level experts 😄

-Yasu

> On Aug 14, 2022, at 18:53, Phil <phil@beadling.co.uk> wrote:
> 
> 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’.
>