Guix (and Guile's) promise, and how to (hopefully) get there

[Christine Lemmer-Webber]

Hello, hello!  Thanks for starting this thread, Ekaitz, and it's nice to
see the comments which have rolled in so far.  We were talking about
this thread on the daily Spritely engineering call and Dave went over
what he had already said and I went on a long ramble of opinions, and
juli and Dave said "well you really ought to say that on the list", so
here I am, laying out my thoughts and opinions.


On the challenges and opportunities we face
===========================================

I want to open with saying that despite the challenges, I remain in
belief that Guix is one of the most promising and hopeful projects in
the entire FOSS space.  Guix starts with good technical foundations and
good community, and the areas for potential in terms of how many issues
Guix solves that *nobody* else in the space is as well poised to take on
continues to astound me.

Of course, having potential and achieving potential are two different
things, and I do think Guix has become somewhat stagnant, but not fully.
The current trajectory is not particularly good, but we could steer the
ship in ways that could be wonderous.  Let us not waste our potential.


On the challenges of being a contributor, in particular
=======================================================

Consider this almost a subsection of the previous; it's large enough to
also precede the rest.  We're seeing a lot more interest in Guix these
days I feel, but also less contributors "sticking around".  I haven't
done any metrics or comparisons, this is a gut sense.  But I have talked
to many people who have wanted to contribute to Guix, and we've
certainly had many mailing list threads about it, and we know the
following is true:

 - If you aren't yet a maintainer today, it's hard to gain commit
   access, and it's hard to feel empowered
 - The barrier to entry to participation is high; you have to not only
   learn emacs and so on, but you also have to learn to navigate mailing
   list structures which seem foreign to most young people.  Only FOSS
   oldtimers feel immediately at-ease with the mailing list flow (and
   actually many of us old-timers don't feel that comfortable thesedays
   either).  This isn't great.
 - Even if you pass those thresholds, even if you get a patch to the
   mailing list, what's the #1 complaint in Guix?  That patches aren't
   being reviewed and aren't making it in.  Alas.

I think we're seeing some promising potential here around the move to
teams, but I haven't been following that closely.  Let's mostly
acknowlede that we're not doing good here, and we need to do better.
We're seeing enthusiasm that isn't translating to participation because
people are feeling disempowered and that's no good.

Okay, it's time to start talking about what we can do.


On Guix, on GNU, on institutional housing
=========================================

Let me open my suggestions with the most controvercial, so those who
would be so upset with me leave the conversation early.  Guix is
allegedly a subproject of GNU, but this is mostly in name only (and with
a small amount of not very reliable institutional support) and it's time
for this connection to go.

I feel sad to make this argument myself, because I *am* one of the
people who believe that GNU is incredibly important from a historical
perspective, and that this is underrecognized and underappreciated.  But
let's be frank: GNU's reputation is in the toilet, and Guix's own
reputation is not boosted but tinged presently by association.

You've seen the trope in movies, and it's one in reality too: "I can fix
him!" the heroine thinks, and ultimately, she cannot fix him.  The
audience knows it, why do we not know it, as those playing the heroine's
role?  GNU's leadership is too stubborn and hopeless to be brought in a
more positive direction.  Many people here have tried, and I too tried
to participate in GNU to bring it to a more positive direction, but
ultimately I have come to the conclusion that this is a hopeless effort.
It's time to move on.

I think what we can do is carry the parts of GNU that *are* good, that
*are* important historically, and bring them with us.  A commitment to
free software is good.  Guix should remain a pure distribution; it is
far easier to add impurities to an impure system than to remove them,
and Guix has gone to great efforts to be built on pure foundations, and
we should preserve that.  Much of GNU's tooling (not all of it, but much
of it) is also good, and we should carry that with us where appropriate
as well.

There's an obvious candidate with the Guix Foundation, and I think this
is the right choice.  I have some experience with US-based nonprofits if
you'd like to talk about finding a US-based home as well.  Perhaps
moving away need not be done all at once, but I believe it should be
done.  I lay this out first, because I believe it impacts other aspects
of this writeup, even though I think it is not the most critical.



On leadership, on governance
============================

This leads to an immediate followup question: what is and should be the
governance and leadership structure of Guix?  I think there's a general
feeling that there's stagnation and that things can't be done because we
need a robust and non-heirarchical decisionmaking structure, but also we
kind of don't have that, and so nothing is happening.

I consider myself a "practical political anarchist"; I'm unhappy with
the beauraucracies of the world and would like to see us do better in
supplanting them, but the irony is that trying to produce flat
structures of governance sometimes results in *more* beauraucracy
and stagnation entering a system.  So okay, let's talk about what we can
do in the meanwhile.

I think there's a lot we can do to iterate towards more cooperative
governance structures, but in the meanwhile, we need to get un-stuck.
And I think the right answer is an ironic one: I think the shortcut is
to put Ludovic, with substantial support, as a kind of "chief visionary"
of the project.

Ludovic is probably reading this and dreading these very words I am
putting down and that is *exactly* why he is a good candidate.  The
right people for leadership are often not those who want power, but
those who are worried about the consolidation of power, who ironically
are the best to put in the role.  Every time there has been a major
source of disagreement, it's usually Ludovic stepping in and giving his
opinion that sets everything back to right.  And I know Ludovic is
deeply concerned about embracing that, and is far too well aware of the
problems of Founders Syndrome etc, and that's partly why I trust him in
this role.  I have already said "ironic" in this section three times,
so I won't say it again, but you get the point.  The fact that Ludo ends
nearly every email with "WDYT?" says an enormous amount about how he
gathers consensus, which is really important, and one of the reasons
he's a trusted steward of the project.

(I feel a lot of affinity towards this personally.  I am the Executive
Director of my organization, but I would actually rather be on the
engineering team, and indeed I tried originally to arrange things so
that would be the case, but as you can see, well, now that's not the
case.  So it goes, I have traded my preference for hacking for building
out opportunities to have other people be able to hack on the things I
wish I was instead by providing the relevant structure.)

Personally I tend to look at three projects in terms of how they are
governed, and I have modeled a lot of the vision of Spritely off of
these three orgs, and I think some amount applies to Guix, but not all
of it:

 - Debian has the most successful example of an actually
   democratically-run organization in FOSS of all times.  This has not
   removed the challenges of governance, because if you know someone
   involved in Debian governance, you probably also know someone who has
   experienced serious governance burnout.  But it's still the best
   example we have, and if that's where we want to go with Guix, it's
   worth learning from Debian.  But Debian also moves very slowly, and
   that's one thing that won't improve under this model.  It's still
   probably worthwhile, though.

 - Linux is the most well known example of a start-topology model, and
   actually I'm not a huge fan of the project or its leadership and
   *certainly* not the communication culture that has been historically
   associated with the project, but I think, awkwardly, we can paint
   things as a "Linux to Debian pipeline" trajectory in my proposal.
   What Linux does have very well though is a lot of people successfully
   contributing and getting their code in, while being supported in the
   process.  One interesting thing also about Linux is that there's an
   institutional home with the project leader being paid, and comments
   on that particular leader aside, I think that's important for
   avoiding burnout.  The real big lesson for Linux is the history of
   "Linus Doesn't Scale" and its aftermath: I *am* actually suggesting
   both having more central vision, but also recognizing that the
   central vision 

 - Blender is actually the project I think is most interesting of all
   (well, maybe more for Spritely than for Guix, but it is interesting
   to some degree).  It has a nonprofit side at its heart (Blender
   Foundation / Blender Institute), and also has a more experimental
   usage-production driver on the side (the Blender Studio, which makes
   free cultural production artifacts which shape the software itself).
   Blender also has had a strong amount of vision/leadership, and I
   think in this way also has no small amount of Founder's Syndrome to
   work through (but it *has* been working through it afaict), but also
   has a large number of volunteer and paid contributors who don't work
   for the organization itself.  (The ways it runs its community
   meetings is also interesting, but this is an aside.)

What I think would be best for Guix is a bit of all three of these.  In
In the immediate, I think Guix already has a strong community, though
it's a community people are having trouble "getting into".  But its
community is its first and most important, and *must be preserved and
fostered*.

I am just vaguely remembering my Philosophy 101 stuff, but I there's a
part in The Republic where they're saying something like "Nobody who
wants power should be trusted with power, and the people who should be
put in power wouldn't want to do so, so in a just society, instead of
people vying for power, they should be putting the people who don't want
to be but are properly qualified in power."  In the short term, I think,
and it does not have to be necessarily a BDFL way, that it would be good
to see Ludovic be appointed more as "Chief Visionary" and so I am
probably, somewhat unwillingly on his part for all the right reasons,
pushing him forward into the spotlight in that role.  However, I think
Ludovic really needs support, and it may take some time to arrange this,
but I think it would be good to make sure that he can remain full time
focused on this.  More on that later.

So let's say Christine's proposal for Guix is the "Linux to Debian
pipeline".  I'm saying that somewhat jokingly, but I think it's a useful
framework to think about.  I would also like to see more Blender'y
aspects, but let's expand on that in the "paid opportunities" section
later.  I am not in earnest suggesting a return to a "true BDFL" type
model; it may be mostly that I am saying that it's actually quite
reasonable for Ludo to not be shy about chiming in.  For years, Python
had both an RFC process and also had Guido playing a stronger leadership
role.  It was good that he scaled back from it, but in the intermediate
term while ramping up community ownership over the project, it was very
helpful to have both.

But really, even asking for more confidence in Ludovic's leadership, I
say that because I know Ludovic cares about *empowerment* of
contributors, which is the most important thing.  My favorite Debian
Project Leader, Stefano Zacchiroli, once said something like: "Debian is
not a meritocracy, because meritocracies do not exist.  However, Debian
is run by the people who step up and make things happen, so Debian is a
do-ocracy."

It's not all on Ludovic or the present maintainers or anyone
individually; we should all feel empowered to make Guix into the
beautiful system we want it to be.

(Also, if you have never read the origin of the "Bikeshed story", please
do so now: https://shed.bike/ )


On infrastructure
=================

A lot of the concerns recently have been "what's the back of the
envelope math to keep Guix going infrastructure-wise and uhoh wow this
looks like a lot".  I think that's the reality we're in for the present,
though I think that we have some opportunities to change the landscape.

We have a number of people involved in the project with a background in
P2P tech.  This is something I would like Spritely to be more involved
in with cooperation with Guix; I think we can get to the point where
there's less assumptions about a centralized approach to package
distribution at all.  We aren't there yet, but it should be a priority.
At the very least, we already have a content-addressed
system... ignoring the trust issues of substitutes, even a naive
approach to sharing source packages should be quite feasible in a
peer'ish way.  I think Goblins could provide a nice transport-agnostic
foundation for unlocking content-addressed package distribution, but
anyway.

But we aren't there.  In the meanwhile, investing in the infrastructure
approaches we have does make sense.  However I'd consider centralized
package distribution, and building, should be something we consider
"aspirationally part of the future-past".

Regarding what to do in terms of "are we built entirely on mailing
lists", etc: I do think we need to build more infrastructure, but this
isn't entirely on Guix.  Truth be told the mailing list structure is a
barrier but isn't the biggest barrier... the biggest barrier is that
contributors drop out from lack of getting their patches reviewed and
accepted.  So in a way, this isn't actually the biggest priority;
helping get to better patch review is.


On paid opportunities
=====================

One clear way in which patch review could be improved is by paying
someone to do full time patch review.  There are two challenges here:
how to allocate the funds, and whether or not this would decrease the
motivation of other contributors.

In my opinion, the most important things to spend money on are things
that are important but otherwise would not get done in a project.  In
Guix, that's patch review.  The problem with patch review is that it's
boring comparative to authoring packages; unless someone comes in with a
patch you really *want*, it's hard to be motivated to review patches.
Certainly some members of our community do so, but not at the level that
would be good, and also not with those same community members being
committers who are able to help those patches get upstream.

I don't think it would be the case personally that nobody else would be
motivated to review patches if we had someone working full time on patch
review; for me, I'd be delighted to see more happen, and I think I would
find Guix even more exciting to participate in.  I don't think that a
bounty type system or other type of retrospective payment system would
help.  I think someone needs to be paid to do this, as part of their
job.

But there's an interesting phrase there, "as part of their job".  The
Linux kernel has primarily people working on it "as part of their job",
but also many volunteers.  Nobody seems afraid that people will stop
being interested in working on the Linux kernel.  Similaly for Blender,
there is a core group of developers working on Blender for the Blender
Institute, but what's interesting is that many of the people working on
both Linux and Blender are not working for the "home" organization
(though certainly some are), many are working for other companies that
use said projects.  But some people do indeed work for the home
organizations of Linux and Blender, particularly on either core work or
on important work that isn't exciting enough to volunteer on.

But speaking of satellite organizations with paid contributors, well,
*you*, dear reader, may be able to help make this possible!  If you work
at an existing organization, one easy path is to make the bold choice to
say "Guix is the best way to solve this problem", should you have the
authority to do so, and in that way prioritize using and also advancing
Guix in that domain.  "guix deploy", for instance, could use a lot of
love, and an organization choosing to use "guix deploy" for devops could
really unlock a lot of work.  And if starting a new organization which
is fairly Guix unrelated but you're in charge of choosing what tooling
to use, why not choose Guix?  Push for "guix shell" for development
environments (well, we'd do a lot better here if we had MacOS support),
push for Guix on your servers, etc cetera, et cetera.  Even without Guix
being at the center of your org, by relying on it, you can find time to
improve it, and at least find time to find all the things that need
improving. ;)

But maybe, if you are so inclined, you could be even bolder, because I
actually believe Guix could be a key foundation for several really
interesting companies:

 - You could ship laptops pre-configured with Guix on them.  (Maybe even
   the MNT Reform Next as a foundation would be really promising; I have
   high hopes.)  Guix could be used to produce a system image that you
   can blast across said laptops.  The biggest challenge actually would
   be updating the system; we need something like the synaptic package
   manager so that non-schemers can update their system.  But holy moly
   I am sick of buying laptops for people and having them be just as
   afraid to upgrade them as I am afraid to upgrade computers I have
   with imperative systems, and where things go badly they can't roll
   back.  Look unto System76 and what they have done with PopOS on top
   of Debian; something like that with Guix would be more than welcome.

 - You could run a hosting service company for end-users which you
   deploy with Guix.  It could even have a web interface with simple
   drop-down selections of which services the user wants (you could even
   use Hoot for the frontend UI), and it could compose system
   definitions *programmatically* based on the selections which users
   make.

 - You could do the same as above but for businesses.

 - You could sell -- bear with me here -- IoT'ish type devices which the
   system images for the devices are programmatically generated by Guix
   and rolled out on microsd cards.  Look, this isn't my market, I
   dunno.  It feels like there's something here though.

 - For that matter, you could choose to use Guile and Guix as the
   default ecosystem for a startup.  Go get that lush Silicon Valley
   venture capital money and roll around in it (or eat instant noodles)
   and build the next hype train product that someone would have built
   on top of Rust, but build it on top of Guile instead.

Okay, and here's the one that I really think is quite possible:

 - You could build an open source competitor to Cloudflare Workers and
   AWS Lambda on top of Guile and Guix and Spritely's stuff.  Yes, I
   think this is possible, and I suspect there's money in it.

The point here is that by choosing to integrate Guile and Guix and etc
into your place of employment, you can help the ecosystem, even without
being a paid contributor from a central Guix Foundation home.  And this
is actually really good and healthy to have these kinds of things happen
and it's the type of reason that Python and Rust have *such good
ecosystems around them*.  Schemers, and Guile people in particular for
being such principled FOSS people, tend to be somewhat allergic to being
in such positions, but grab some antihystamines, because a few research
labs (I'll consider Spritely one of those) can't be the only ones
pouring resources into Guile and Guix.

Though oh yeah, you can absolutely use Guile and Guix in an academic
context too.  More of that!


On Guix and Guile
=================

Guix can't succeed unless Guile succeeds.  I'm proud to be part of
Guile, and I'm glad Spritely is pouring resources into Guile (and our
funders as well, indirectly) and Hoot and etc.  But we can't do it
alone.

Most of the concerns that reflect on Guix in this article are true for
Guile too, even more so.  Guile needs a lot more support.  I hope we can
see it happen, but I'm afraid it's another email, another chain of
thought.  But probably enough could be recycled from the above.

I think Guile actually has a lot of promise which has been being
realized recently, though.  Guix brought the initial life to Guile
which, for instance, allowed Spritely to be bold enough to choose Guile
as its foundation (of course we dabbled in Racket initially; I am glad
we landed in Guile-land again).  We have to do a lot to make Guile more
accessible and better maintained.  I think Hoot will help a lot with
that; I've also been impressed with a lot of the work that Andrew Tropin
has done, but there's a lot more in general.

I think, to return to Stefano's quote above, Guix and Guile and etc are
at their best when they're a "do-ocracy, lead from good vision".  I
talked about Ludovic's role a lot, but actually it's everyone's role.
But we should aim for less bikeshedding and more action.  How do we make
things move forward?

Money is one thing.  It isn't the only thing.  But it does help.

But really, most especially, we need to think about: "what will help us
move forward?"  We have good people, we have a wonderful project.  Let's
help people feel empowered, let's make things happen.

 - Christine