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

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

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

[Ekaitz Zarraga]

Hi Christine,

I think you very well said here.

My original discussion wanted to tackle several points, some of them you 
very well mention here:

- There's already people getting paid for working on Guix, and that is 
not a problem at the moment but we could do it better.

- If there's any commercial application for Guix that would be an 
interesting source of energy (people and money). Maybe some people from 
the community could start that.

EXTRA: maybe the Guix Foundation could offer some of that! They have 
machines, they collect money for Guix stuff, they have the social 
structure, they are legally registered and they can get payments. That 
could be an interesting source of income, combined with selling the very 
cool stickers they sell.

- Governance is important, and we are in a position where there's no 
governance because we all are too cautious about it, to the point 
nothing is really done.

- We all are looking to Ludovic to be our leader here, and he factually 
is. Probably the best one we could have.

There are some points I think you miss here though, and I think they are 
important.

- In a project like Guix money is not only important, but structural. We 
are not just software. We have many machines running (sometimes poorly), 
and I don't like to talk too much but a big part of it as far as I know 
is running in somebody's basement. That person has been in the border of 
a burnout for long, as long as I know. I don't want to push anyone to 
air details about their personal economy but that thing is expensive, 
and *I*, Ekaitz, don't feel comfortable having people doing things they 
don't want to just because they feel some moral obligation to the 
project. As I said, in the original thread: we have been asking for too 
much from some people, for too long.

- This comes to Ludovic too. I wouldn't like to be in his position 
because there's pressure on him. It's too easy for people to point to 
him and say: "Ludo, what should we do? Ludo, you are the leader! We'll 
follow you". Again, we are asking too much from some people.

Instead, I advocate for sharing the load. I'm a small guy, I can't lift 
a lot of weight, but with some responsibility I think I could help. I 
didn't do much in the last years, but I think it was honest, and that's 
what I believe we should do more.

About GNU, the FSF and so on, I don't think we should drive our 
decisions out of _image_ or _reputation_. There should be only one 
criterium to follow in the current situation we have: is it useful for 
us or not. I don't think image really matters.

Being brutally honest here, if any of that mattered we all would be 
wearing a suit in the Guix Days and FOSDEM, and probably we would be 
afraid to come out as we really are. That's not what I saw when I was there.

I try to be human, and that's what triggered all this conversation. I'm 
the less corporate friendly guy you could ever find but I do care about 
people: those who feel helpless and those who feel they have to help, 
even if they are tired.

I think we need a proper structure, or at least make the structure 
obvious. I shared this problem in the Guix Days: we have a social 
structure, but it's not explicit. We have all these implicit rules of 
this person and this other one and who should you ask for something and 
who not, but that's really hard to grasp if you come from the outside.

This whole thing looks like an uncoordinated mess, but that's not what 
we are. We are functioning set of humans, that work together extremely 
well taking in account the low effort we put on the coordination. I 
don't want to change that, I think it's marvelous, but I think we could 
do more with less, without burning down people in the process.

So, I focused the thing on the money not because I think we should make 
this more corporate or anything, but because the only people who don't 
care about the money is those who have it. I care about those who don't 
have it, and want to make this thing great, and I care about those who 
are running out of it, just for keeping this thing from falling apart.

So governance and all that, yes, we should solve that, but I don't want 
to that conversation to be so long and so ineffective we don't pay 
attention to the actual goal: giving a hands to our friends that might 
be struggling a little bit now while we are talking.

So, in summary. You bring interesting ideas to the table, and I'm more 
than happy to discuss them, and take part in some. But I'm more for 
action in the short term, and I have questions that might help to trace 
a path to follow:

- Do we need independent funding so we can pay for our machines and 
maintenance?
- Is the Guix Foundation the way to do it?
- Does GNU, or the FSF, have some role on that?
- Can we improve anything relieving weight from the shoulders of some 
people instead of putting even more on them?
- Would having more committers help relieve some of the weight?
- If so, should we propose commit access to people, instead of waiting 
them to propose themselves?
- Should we ease the process of becoming a committer?


What do you think?

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

[Suhail Singh]

Christine Lemmer-Webber <cwebber@dustycloud.org> writes:

> That patches aren't being reviewed and aren't making it in.  Alas.

We have ~45 authorized contributors.  Based on the manner in which these
contributors were added, I believe they have reasonable trustworthiness
to uphold the goals of Guix.  However, I do not believe that said level
of trust is needed for _all_ changes.

Specifically, the bulk of patch submissions in Guix deal with packages.
Barring some core packages, perhaps Guix would be better served by
splitting other packages into a separate channel.  The organization and
management of said channel could be optimized for tracking upstream as
closely as possible.  OpenSUSE's Factory model with OpenQA comes to mind
[1].

#+begin_quote
  The core of Factory is divided into two rings (0-Bootstrap,
  1-MinimalX). Ring 0 contains packages that form the most basic,
  minimalist system that can compile itself. On top of that Ring 1 adds
  what's in the default installation of the two primary Desktops. All
  other packages are not part of a ring.
#+end_quote

Orthogonally, the project would IMO also benefit by having automated
testing to ensure that the combination of packages work well together.

As things stand today, the incentives for those without commit access
are such that it makes better sense for them to focus on their own
channels.  This is a shame.

-- 
Suhail

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

[Ludovic Courtès]

Hi!

Before I reply to Christine’s insightful message, here’s my
Chief Visionary *cough* view on the questions you ask:

Ekaitz Zarraga <ekaitz@elenq.tech> skribis:

> - Do we need independent funding so we can pay for our machines and
>   maintenance?

We have enough money, about 50k€ currently at the FSF plus a couple
thousand € at Guix Foundation⁰.

⁰ There’s a ledger at
  <https://framagit.org/guix-europe/guix-europe/-/blob/main/accounting/accounting.ledger>
  but I don’t remember how to get the balance with the ‘ledger’ command.
  :-)

> - Is the Guix Foundation the way to do it?

It is one way to do it, yes.

> - Does GNU, or the FSF, have some role on that?

GNU isn’t a legal structure, it “doesn’t exist” so to speak.

The FSF reimburses when we send them invoices; Guix Foundation can pay
services, hardware, etc. directly, which is more convenient.

My preference would be to have a single structure, to improve legibility
and simplify things, and that structure would not be the FSF.

> - Can we improve anything relieving weight from the shoulders of some
>   people instead of putting even more on them?

Yes!  Committers can review code; people interested in governance can
help with the next steps, in particular the RFC process at
<https://issues.guix.gnu.org/66844>; sysadmins/devops/hackers can help
with the infrastructure¹; and so on.

These are some of the thankless tasks that are key to a healthy project
and where we must ensure a fair distribution of work to avoid burnout.

¹ https://lists.gnu.org/archive/html/guix-devel/2024-05/msg00183.html

> - Would having more committers help relieve some of the weight?

Only if they participate in code review.

> - If so, should we propose commit access to people, instead of waiting
>   them to propose themselves?

We should.  I think maintainers started doing it?

> - Should we ease the process of becoming a committer?

Do you think the process is difficult?  Or intimidating maybe?

Ludo’.

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

[Ludovic Courtès]

Hello Christine!

Thanks for your thoughtful message and for the good vibes!  It’s great
to be able to count on the support and advice of an experienced leader.

There are many things in your message, let me reply selectively.  :-)

Dave and you mention that you perceive Guix as “on the decline” or
“stagnant”.  According to Git and <https://openhub.net/p/gnuguix>, the
number of contributors is stagnant indeed, which I think comes from a
number of factors, primarily: not enough review work is done by
committers, as you wrote, and tooling (qa.guix) *and the folks taking
care of it* have a hard time keeping up.  I also think co-maintainers
could have been stirring it up more than that.

Email may be an additional factor but, as you write, not the main one—we
have no shortage of patches coming in!


Regarding GNU, I tend to view it as a somewhat secondary issue, which
doesn’t mean it should be neglected, but it’s perhaps less of a priority
than the other topics.


So, governance.  When I started the project, I thought that it will have
been successful if I can quietly leave it and it keeps going; in that
sense I was so happy when I left the maintainer collective!

I’m not the only one who can do so, but I can certainly use my “social
capital” to support initiatives and help make progress on governance
matters—I spent time recently defining the roles and responsibilities of
teams, and I plan to spend time to help shape the RFC process proposed
last year: <https://issues.guix.gnu.org/66844>.

But I also want to leave enough room to everyone.  As you and Ekaitz
wrote, each one of us can step up and take part in this work; some have
experience with governance (be it for free software projects or for
unrelated non-profits), others have energy and are willing to learn…
And there’s also lots of non-governance work to do.  Let’s all do what
we can to shape this project and keep it moving!

I’m sympathetic with what Ekaitz wrote: we must take care of one another
and not put too much burden on the shoulders of any single person.

Ludo’.

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

[Juliana Sims]

Hey y'all,

Ekaitz, thank you for opening this thread. RIP your inbox.

I think this thread demonstrates in itself one of our biggest issues. A 
few folks have mentioned it indirectly. I'll be direct. We can't stay 
on topic.

So once again, Ekaitz, thank you for clarifying what this discussion is 
supposed to be about. In the context of consensus decision-making, this 
is part of what's called facilitation, and it's absolutely vital if we 
want to use a consensus decision-making model for governance. I think 
we absolutely can do that if we just use the tools others have built 
for making consensus work -- like the idea of facilitators.

But I digress.

After that preface, I'm going to respond specifically to the points 
Ekaitz highlights as the topic of this thread.

 > - Do we need independent funding so we can pay for our machines and
maintenance?

I don't know the details of cost and source off the top of my head 
(they were recently summarized in another thread), but my instincts are 
screaming, "Yes!" I'll return again to this later, but we should be 
paying people to do systems administration work because systems 
administration is boring and tiring after a while. Above all, no single 
individual should have to carry the weight of paying for our servers.

 > - Is the Guix Foundation the way to do it?

Again, I don't know enough to say with certainty, though most likely. 
Because...

 > - Does GNU, or the FSF, have some role on that?

...Guix should break with GNU and the FSF. Moreso the FSF, but the two 
are irrevocably intertwined in the public conscious -- which is the 
primary reason Guix needs to break away. To avoid relitigating what has 
been litigated more than sufficiently already, the FSF made a bad 
political move that has destroyed its social capital and, as a 
side-effect, its financial capital as well. Even if it can help us with 
funding, it shouldn't. (More on why in a bit.) In terms of extant 
infrastructural support, from what I can tell, the FSF gives us hosting 
for a simple website, an ancient git forge, and mailing lists. While I 
can't speak to mailing lists, I can speak to websites and git forges. 
Given the incredible complexity of our existing CI and QA 
infrastructure, putting up some HTML and having a gitolite service 
running on a machine are comparatively no effort. I suspect the mailing 
list -- after migration -- would be the same, though I reiterate my 
ignorance here.

To forestall misunderstanding, I absolutely do *not* mean that Guix 
should compromise on free software. Guix's greatest strength is that it 
is an uncompromisingly idealistic and principled project. If we change 
anything about our stance on non-free software, it should be that we 
add a single sentence to the manual informing people about the 
well-known and well-supported channel providing non-free firmware, 
followed immediately by a disclaimer that we neither endorse nor 
support non-free software, and that's *all*. Official Guix channels 
should never knowingly ship non-free software, nor should we ourselves 
provide instructions on installing, configuring, or using non-free 
software itself -- we should just point people to the place that does.

Why, though, should we go through the effort of migrating our mailing 
lists, domains, etc. just because it won't add *that much* more work? 
This is a big and important question. The short answer is, the FSF is 
radioactive, and we're getting sick from it.

Let me be frank. I promote the heck out of Guix. I've shilled Guix to 
more people than I can count, from professional systems administrators 
at internationally-acclaimed universities to hobbiest hackers in the 
most obscure corners of the internet, and everywhere in-between, all of 
whom are incredibly capable, knowledgeable, passionate programmers, and 
some dozens of whom are free software hackers. The main turn-off people 
cite to me is our association with GNU. As a particularly poignant case 
study, in conversations with someone who has contributed significantly 
to Guix on my recommendation and did not stay around, the primary 
complaint was not the email-based workflow (which was noted as unusual 
but not overwhelming), but that the GNU affiliation *makes them feel 
uncomfortable in our community*. They haven't told me of negative 
interactions with members of the Guix community; the GNU affiliation 
alone was enough. If we recognize that there is not enough growth in 
effort going into the project, we should address the primary reason 
we're not getting new people to bring more effort: GNU.

 > - Can we improve anything relieving weight from the shoulders of some
people instead of putting even more on them?

I think so. As I noted above, if we break with GNU, I am highly 
confident we will see an uptick in new contributors, at least some of 
whom can help there. In the longer-term, we absolutely need to pay more 
people to do systems administration for the Guix project. If we start 
paying people, those are the people we should pay first. Our patch 
throughput doesn't matter if we don't have servers to distribute those 
patches to users.

 > - Would having more committers help relieve some of the weight?

Perhaps? This could allow more experienced contributors to focus on 
less-supported areas (sysadmin, for example) and help the overallow 
distribution of labor as a result. The issue is less the number of 
committers than the number of *commits* by relation to the patch 
backlog. To that end, any changes related to committers should focus on 
increasing patch throughput. In particular, we should focus on adding 
contributors who want and are able to help with specifically patch 
review. Indeed, my inability to commit (pun not intended) to patch 
review is the only reason I haven't put myself forward for commit. 
(Though I am working towards giving myself the time for patch review in 
the near-ish future.)

 > - If so, should we propose commit access to people, instead of 
waiting them to propose themselves?

Yes, and, to reiterate, we should prioritize committers who want to 
focus on patch review. This doesn't mean we *only* grant commit to 
people who want to review patches, but there should be a clear 
expectation of patch review for any new committers. Committers who see 
someone consistently providing good patches and/or review should be 
able to propose that person to the other committers.

 > - Should we ease the process of becoming a committer?

No, with one exception. If the committers discuss among themselves and 
feel that someone is making consistently helpful, quality contributions 
to Guix, but they haven't contributed 50 patches yet, they should be 
allowed to offer that person commit. For self nomination, nothing 
should change. Guix should not compromise on its ideals. We need people 
with a demonstrated dedication to those ideals screening others for the 
same dedication before entrusting them with material power in the 
project. Our current process seems well-suited for this end.

That's all I have to say at the moment.

As a final note, I want to highlight the amazing work from Arun Isaac 
and Chris Baines. While I know y'all have been working hard on Guix for 
a long time, I've paid the most attention to y'all's work this year, 
and from what I've seen, y'all have been kicking ass. You've made it so 
that the contributor workflow is not a meaningful point of weakness 
anymore. Thank you both.

Best,
Juli

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

[Ludovic Courtès]

Hi,

Suhail Singh <suhailsingh247@gmail.com> skribis:

> Specifically, the bulk of patch submissions in Guix deal with packages.
> Barring some core packages, perhaps Guix would be better served by
> splitting other packages into a separate channel.  The organization and
> management of said channel could be optimized for tracking upstream as
> closely as possible.  OpenSUSE's Factory model with OpenQA comes to mind

That’s an idea worth considering in the long term, but it’s very tricky:
how do we decide what gets in?  do we go as far as moving packages from
Guix proper to another channel?  how do we transition?  what API
compatibility guarantees do we make?

> Orthogonally, the project would IMO also benefit by having automated
> testing to ensure that the combination of packages work well together.

One can have their channel under continuous integration with Cuirass for
instance; it works well for this job.

> As things stand today, the incentives for those without commit access
> are such that it makes better sense for them to focus on their own
> channels.  This is a shame.

Yeah.  Having lively channels outside Guix is not necessarily a bad
thing though.

Ludo’.

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

[indieterminacy]

On 2024-10-26 18:40, Suhail Singh wrote:
> Christine Lemmer-Webber <cwebber@dustycloud.org> writes:
> 
> ...
> 
> Specifically, the bulk of patch submissions in Guix deal with packages.
> Barring some core packages, perhaps Guix would be better served by
> splitting other packages into a separate channel.  The organization and
> management of said channel could be optimized for tracking upstream as
> closely as possible.  OpenSUSE's Factory model with OpenQA comes to 
> mind
> [1].
> 
> #+begin_quote
>   The core of Factory is divided into two rings (0-Bootstrap,
>   1-MinimalX). Ring 0 contains packages that form the most basic,
>   minimalist system that can compile itself. On top of that Ring 1 adds
>   what's in the default installation of the two primary Desktops. All
>   other packages are not part of a ring.
> #+end_quote
> 

Having explored the ecosystem of certain tools (what is a dependency of 
other dependencies),
I have wondered about how this plays out in terms of governance 
(particularly priority or emphasis).

For instance, many tools eventually have a requirement for Perl - given 
that eventually a supporting tool may provide a need for its regex or 
build qualities.
Now, its quite likely that the version for Perl is not an inhibitor for 
other tooling to increment as versions.
However, I do not know whether this (or similar tools) are articulated 
in a centralised and documented environment.
(I do read references conversationally from this ML from time-to-time, 
especially when discussing packaging for specific languages - but such 
fleeting opinions are not necessarily the same as a dedicated resource 
with a uri to point to).

Practically speaking, is it worth each team concretely highlighting 10 
core tools to prioritise and maximise documentation and policy for?
As well as 3 tools which their circle creates, that are important for 
other tools in other team circles?

Such a procedure may allow more of a tracking over time of changes of 
priority, as well as a better attempt at gauging how such priorities are 
being treated.

> Orthogonally, the project would IMO also benefit by having automated
> testing to ensure that the combination of packages work well together.
> 
> As things stand today, the incentives for those without commit access
> are such that it makes better sense for them to focus on their own
> channels.  This is a shame.


On the topic of cloud/service type activities, Im still intrigued by the 
allure of Guix wrt forge services.

While I understand Arun Isaac may have other/greater priorities than to 
focus entirely on his guix-forge project,
I have wondered about having Guix/Guile being considered a column in the 
code forge domain:
https://git.systemreboot.net/guix-forge/about/

After all, if something  can be configured once in Guix it can be spun 
up, and reproduced in a sustainable and functional way -- this should be 
a point of distinction for this community.
If enough hackers control the form of how code is stored and transmitted 
then many points of concern could melt away.
Positions such regarding centralisation or decentralisation of package 
definitions or regarding (Neo) AI would reconfigure if Guix had more 
sway over forges.


JM

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

[Andy Tai]

With due respect, I disagree with that.

Guix recent years has seen growing interests and contributions, so
many patches that the they are not reviewed or processed in a timely
manner.   This is with affiliation with GNU.  I contributed to Guix
because it is GNU.

In fact I just contact the FSF about contribution to Guix with small
donations periodically. I am in the US and financially contribution to
the FSF is tax deductible and the FSF has a better track record of
efficient use of contributions than most other non profits (as
regulated by the US Government Internal Revenue Service).  Financially
many free software nonproifts are having issues (per recent article in
lwn.net) and the FSF is in better shape than these (with questions on
their abilities to raise income and expenses) in that article.  So it
is not clear where the FSF lost its financial capital.

So my observation is inconsistent with what Juliana wrote in this part.

On Sat, Oct 26, 2024 Juliana Sims wrote:
>
> ...Guix should break with GNU and the FSF. Moreso the FSF, but the two
> are irrevocably intertwined in the public conscious -- which is the
> primary reason Guix needs to break away. To avoid relitigating what has
> been litigated more than sufficiently already, the FSF made a bad
> political move that has destroyed its social capital and, as a
> side-effect, its financial capital as well. Even if it can help us with
> funding, it shouldn't.
>
> I think so. As I noted above, if we break with GNU, I am highly
> confident we will see an uptick in new contributors, at least some of
> whom can help there.

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

[Ekaitz Zarraga]

So,

On 2024-10-26 22:22, Ludovic Courtès wrote:

> We have enough money, about 50k€ currently at the FSF plus a couple
> thousand € at Guix Foundation⁰.

So we rely on the FSF for the funding, mostly.

I don't want to discuss if we want to separate ourselves from the FSF or 
not, but in the end, if we want to be independent we should control 
where is the money coming from. Can the FSF cut the funding?

In any case, I think the money should be employed on keeping the 
substitutes, the CI and so on. That is important, because a great 
package manager that is unreliable easily becomes a poor package manager.

Having a reliable Guix is good for everything. And many of us are 
developers, and don't like to do the reliability work.

I could also think about the ramifications of the thing, the people who 
control the machines control everything and they might become evil and 
be too powerful. But it's a risk I think we should take.

We have people that have been thanklessly doing this job for very long 
time, I don't expect them to become bad actors. If they didn't break 
after so long... I think they proved themselves.

> 
> ⁰ There’s a ledger at
>    <https://framagit.org/guix-europe/guix-europe/-/blob/main/accounting/accounting.ledger>
>    but I don’t remember how to get the balance with the ‘ledger’ command.
>    :-)
> 
>> - Is the Guix Foundation the way to do it?
> 
> It is one way to do it, yes.

Should we invest on making it **The Way**?

>> - Does GNU, or the FSF, have some role on that?
> 
> GNU isn’t a legal structure, it “doesn’t exist” so to speak.
> 
> The FSF reimburses when we send them invoices; Guix Foundation can pay
> services, hardware, etc. directly, which is more convenient.
> 
> My preference would be to have a single structure, to improve legibility
> and simplify things, and that structure would not be the FSF.

I can agree with that. I don't dislike the FSF specially but I prefer to 
be more independent. What I do like is the principles we share with the 
FSF, and having a different financial structure should not change that. 
I think we all agree on the fact that Guix should continue to be a Free 
Software distribution.

>> - Can we improve anything relieving weight from the shoulders of some
>>    people instead of putting even more on them?
> 
> Yes!  Committers can review code; people interested in governance can
> help with the next steps, in particular the RFC process at
> <https://issues.guix.gnu.org/66844>; sysadmins/devops/hackers can help
> with the infrastructure¹; and so on.
> 
> These are some of the thankless tasks that are key to a healthy project
> and where we must ensure a fair distribution of work to avoid burnout.

I like that.

> 
> ¹ https://lists.gnu.org/archive/html/guix-devel/2024-05/msg00183.html
> 

That link is lost in the ML, shouldn't all that list be somewhere in the 
Guix manual so we can understand the whole picture of Guix?
Maybe with an explanation about how these parts interact with each other?

I think we should add something like that in "Contributing to Guix" part 
of the manual.

>> - Would having more committers help relieve some of the weight?
> 
> Only if they participate in code review.

I'm not very good at it. But I'd like to help.

>> - If so, should we propose commit access to people, instead of waiting
>>    them to propose themselves?
> 
> We should.  I think maintainers started doing it?

Maybe we should do it more.

> 
>> - Should we ease the process of becoming a committer?
> 
> Do you think the process is difficult?  Or intimidating maybe?

Yes.

I think it's intimidating because for some it's hard to take 
responsibility. I feel way more comfortable as an outsider. Also, I 
don't consider I deserve to be a committer or anything like that. I 
don't know how to deal with that. I approached you and told you I 
thought it was time for me to help, some of you agreed and when the 
process started to take long I preferred to let it cool down.

I feel like I'm asking for too much. IDK.

I think it would be more encouraging if it was proposed to people, and 
not the other way around. Making people ask for it may make them think 
twice and be cautious. Proposing them may make them feel encouraged and 
wiling to demonstrate they deserved the "price".

I don't know. I don't like the process, that's for sure. But I don't 
know because of my personal case was weird or in general. I also saw 
some people saying their request was delayed and so on. The current 
process generates some awkwardness we could ease.

> 
> Ludo’.

In the end Ludovic, if I may:

0. Is the donate page in guix.gnu.org up to date? Maybe we should make 
sure it is, and maybe include the Guix Foundation?

1. Adopt an RFC process. I think it's valuable.

2. Decide if we want to invest on the Guix Foundation:
   - What is the status of it? Is it a fully functional organization?
   - Can we use the Guix Foundation for, for example, Tax exempt 
donations in the EU? And the US? Maybe some famous streamer could use 
their platform to make fundraisers for the Guix Foundation. (see what 
the Zig Software Foundation does)
   - Could we use the Guix Foundation to make a minimal Business (I hate 
that word) model to make a Guix-based product to get funds to improve 
Guix itself? Say, make a Guix hosting service? Currently most of us are 
throwing money to corporations for our small servers and would be happy 
to redirect that to something we love, while also having a great Guix 
based workflow.
   - Or maybe some of us could make that model and donate all or part of 
the profits to the Guix Foundation? (I think owning the hardware helps a 
lot)

3. Once we have money we can use, choose some people to maintain the 
infrastructure and pay them.
   - Can we really afford our machines? (are we paying for all of them? 
what are we going to do with the ones that are in a basement somewhere?)
   - Is Guix sustainable?

4. Maybe decide if we want to have paid maintainers/security-maintainers 
or committers (or teams!).

5. Relieve weight from people that have too much on their shoulders. I 
won't name names, but some of you are in the border to the burnout.
   - How could the rest of us mitigate that? Maybe it's time to speak 
and ask for help.

6. Propose more committers. Encourage committers to review patches, and 
also non-committers! (Steve, you are doing a valuable thing)

7. Add documentation about Guix's infrastructure to the Contributing 
section of the manual, so anyone can pay attention to that part of Guix 
too. I'll try to do that myself, if someone else is committed to commit 
it ;)

Those points we could act on in the short/mid-term, or at least give us 
some direction.

What do you think, am I missing something?
Maybe some of the calls to action you don't like? Are they practical enough?

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

[Ekaitz Zarraga]

Hi Juliana,

I like some of the points you do here: we should encourage committers to 
review patches, and give commit access to those that are focused on that.

On the other hand, I disagree with your message about GNU and the FSF.

First, I don't think the sentiment you describe about GNU and the FSF is 
universal. It's probably biased by the people you interact with and the 
country you live in. That's not something for me to criticize,  you have 
your views and they are valid, the problem with your argument is the 
same I find with the "let's use a Git forge, that'll give use many new 
contributors!".

It's just really hard to measure.

I wish being a GNU project was the only problem Guix had. The sad truth 
is we'd probably had the same conversation if the project was just Guix, 
with no GNU and no FSF support involved. Furthermore, we'd probably be 
in a worse position, at least economically speaking.

I understand the recent news make us be a little bit heated about the 
FSF and so on, but I don't think it's a central matter of this discussion.

It's probably going to encourage a division in the community as many 
members are here **because** this is a FSF endorsed distribution. Being 
a GNU/FSF project still means a lot to many, and when it comes to the 
free software purism, those acronyms still have some credibility.

Maybe without those we'd be just empty. We don't know. So I prefer to be 
more cautious with the arguments.

Thanks for highlighting the work of these community members and for your 
thoughts.

Ekaitz

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

[Suhail Singh]

Ludovic Courtès <ludo@gnu.org> writes:

>> Specifically, the bulk of patch submissions in Guix deal with packages.
>> Barring some core packages, perhaps Guix would be better served by
>> splitting other packages into a separate channel.  The organization and
>> management of said channel could be optimized for tracking upstream as
>> closely as possible.  OpenSUSE's Factory model with OpenQA comes to mind
>
> That’s an idea worth considering in the long term, but it’s very tricky:
> how do we decide what gets in?

Gets into what?

Ring-0 is defined by minimality and ability to compile itself.  Ring-1
could correspond to the packages included in the default Guix system
installation.  Everything else could go in a single separate channel
(say, guix-extras), while Ring-0 and Ring-1 remain within the main
'guix' channel.

> do we go as far as moving packages from Guix proper to another
> channel?

That is what I was proposing, yes.  With this other channel being
included by default in %default-channels.

> how do we transition?

This is the only possibly "tricky" part, but it's more complicated than
"tricky" as long as we don't require there to be a seamless automated
upgrade from current monolithic guix, to this future version where a
large number of packages reside in a separate channel.

> what API compatibility guarantees do we make?

We could start by making the same ones we do today.

>> As things stand today, the incentives for those without commit access
>> are such that it makes better sense for them to focus on their own
>> channels.  This is a shame.
>
> Yeah.  Having lively channels outside Guix is not necessarily a bad
> thing though.

Not necessarily, no.  However, if these aren't channels that are widely
known, then the experience for new users is worse.

-- 
Suhail

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

[indieterminacy]

Hello Ekaitz,

On 2024-10-27 02:01, Ekaitz Zarraga wrote:
> Hi Juliana,
> 
> I like some of the points you do here: we should encourage committers 
> to review patches, and give commit access to those that are focused on 
> that.
> 
> On the other hand, I disagree with your message about GNU and the FSF.
> 
> First, I don't think the sentiment you describe about GNU and the FSF 
> is universal. It's probably biased by the people you interact with and 
> the country you live in. That's not something for me to criticize,  you 
> have your views and they are valid, the problem with your argument is 
> the same I find with the "let's use a Git forge, that'll give use many 
> new contributors!".
> 
> It's just really hard to measure.
> ...

I think a useful measurement of any community is the diversity within 
it.

One of the lessons I had in my local hackerspace was that the lack of 
diversity in it meant that there were less social safeguards. Over time 
the range of voices deteriorated, which meant it was harder for me to 
protect against bad behaviour - let alone to have protections myself 
once a minority there ran out of other people to bully and belittle.

While my own exiting was not quiet, the silence of others staying away 
or avoiding can be real loud. From (eventually!) noticing that genders 
and behaviours were better represented in other hackerspaces, its 
evident that people are capable of operating away from clusters which 
appear unwelcoming or behave unwelcoming.

During one hackerspace conference at another location, the delight at 
seeing better gender representation to an old friend was met with a 
comment about the toxicity at the place I frequented. Repeating that 
delight to a fellow board member at min, I was meant with a dead eyed 
look -- ultimately indicitive of the true antagonistic behaviour of this 
individual.

Its really pleased me to see increasing diversity among the attendees of 
Fosdem and Offdem in Brussels across the years (which I ascribe not only 
regarding the mainstreaming of IT but the enabling behaviours of 
technologies such as the Fediverse). Its not a question of assaging 
guilt but (given the spread of talent and potential that exists across 
people) that libre technologies deserve greater access to people capable 
of making small and significant improvements to the world.

Its not for me to wade into the particulars about concerns about GNU as 
a project of humans doing things together.
However, it is a point of concern where there is such a volume of people 
with strong reservations about themseves or others operating in a safe 
or respectful way. It would of course be nice that such things are 
unfounded, though from afar Im not confident any of that has been well 
handled. It all feels very limiting.

Ultimately, its 2024. If its the case that a community group is still 
resembling the configuration of a Steven Levy history of MIT hackers 
then its time for either more significant internal reforms or 
alternative institutions.

Kind regards,


Jonathan

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

[Ekaitz Zarraga]

Hi,

On 2024-10-27 11:00, indieterminacy wrote:
 > I think a useful measurement of any community is the diversity within it.

I do think we are a pretty diverse group.

But it all comes to what you consider diverse. Some people brought this 
conversation during the Guix Days, probably ignoring the fact that we 
had people coming from all over the world. I don't know what was their 
definition of diversity at that moment.

On the other hand, we have something in common, so it's really hard to 
be diverse in the broad sense. Should we include people that like 
proprietary software, too? Those are also people, and I'm sure they 
would feel uncomfortable between us.

This is not to say we shouldn't try to make things better and more 
welcoming, of course we should. But I don't think "diversity" actually 
means that much as a measure because I don't think it's an absolute 
concept and I think it's very easy to misunderstand.

On the other hand, I don't think we can change the world deeply. If in a 
community women are not allowed to use computers, people coming from 
that community are less likely to be women, and Guix is just suffering 
the symptoms of the problem. It's not in Guix hands to go there and fix 
the problem (I wish we could!).

I think the kind of diversity we can try to encourage is the one we 
have, and it's actually working quite well: we share our opinions, and 
they very different from one to another and point out when we think 
something is not right.

I don't think we are acting like a cult.

But that's just my opinion, which is also not very relevant. In the end 
it all comes to the same point I mentioned in my original email: it's 
really hard to measure.

And with hard to measure I mean:

- How do you measure if Guix is diverse enough? Is there a universal 
diversity scale? Does a high diversity according to whatever scale we 
use ensure Guix is going to be in a better shape?
- And for the GNU/non-GNU issue. Can we know before taking a decision if 
it's actually going to bring more contributors to the project?
- Same with the Git Forges. We have been discussing this for long, but 
using, say, GitLab is going to impact on the amount and quality of the 
contributions to Guix?

I don't think software projects are a comfortable place for people to 
join and have fun, feel included or fulfill any social needs they may 
have. That's not their goal. They can be fulfilling, but that's not the 
main goal of the thing. (it might be the goal of a hackerspace)

The goal is to make great software, and that, weather we like it or not, 
is an extremely elitist thing. Most of the people in the universe are 
not able to make good software. Most of us studied in good universities, 
have a computer available at any time and have free time to spend here 
writing tremendous walls of text. Or even more, we have had the 
privilege to be taught that diversity is important.

I'm not saying this has to be an uncomfortable place (in fact, the goal 
of the original thread is to make it more comfortable), but we shouldn't 
forget why we are here.

And some of the proposals I mentioned come from a good heart, I can 
agree with them and I appreciate, but in the end it's not clear that 
they are going to help us with our mission: bring the greatest software 
to the people, so they enjoy their computing freely. That's why I try to 
be cautious before taking a decision in those lines.

The good part is we can still make friends and all.

Ekaitz

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

[indieterminacy]

Hi,

Thanks for that eloquent and considerate reply.

I reckon in many respects the Guix community is fighting the good fight.

In some respects, your referring back to hackerspaces reinforces my 
feeling that that is an example where they need greater attention (and 
that our onus is not to solve all problems).

At our end I think more pressure and greater expectations should be made 
wrt GNU.
Its good that there have been statements made in the past, these types 
of things should be expanded upon.
It would be a shame for GNU to decline into a perjorative - this would 
have consequences for us too.

Personally, I dont understand why the FSF site is so poorly functional - 
its login system feels like an arcane pattern that doesnt work for my 
annual edit to attend Guix Days.

Practically speaking, I think Efraim's suggestion to be ideal.
Putting funding in place for those deserving to attend an activity but 
who would otherwise struggle is proportionate and egalitarian.

I would extend this and like the Guix Foundation to assist with visa 
applications if this would expediate attendance from abroad.

Kind regards,


Jonathan



On 2024-10-27 11:47, Ekaitz Zarraga wrote:
> Hi,
> 
> On 2024-10-27 11:00, indieterminacy wrote:
>> I think a useful measurement of any community is the diversity within 
>> it.
> 
> I do think we are a pretty diverse group.
> 
> But it all comes to what you consider diverse. Some people brought this 
> conversation during the Guix Days, probably ignoring the fact that we 
> had people coming from all over the world. I don't know what was their 
> definition of diversity at that moment.
> 
> On the other hand, we have something in common, so it's really hard to 
> be diverse in the broad sense. Should we include people that like 
> proprietary software, too? Those are also people, and I'm sure they 
> would feel uncomfortable between us.
> 
> This is not to say we shouldn't try to make things better and more 
> welcoming, of course we should. But I don't think "diversity" actually 
> means that much as a measure because I don't think it's an absolute 
> concept and I think it's very easy to misunderstand.
> 
> On the other hand, I don't think we can change the world deeply. If in 
> a community women are not allowed to use computers, people coming from 
> that community are less likely to be women, and Guix is just suffering 
> the symptoms of the problem. It's not in Guix hands to go there and fix 
> the problem (I wish we could!).
> 
> I think the kind of diversity we can try to encourage is the one we 
> have, and it's actually working quite well: we share our opinions, and 
> they very different from one to another and point out when we think 
> something is not right.
> 
> I don't think we are acting like a cult.
> 
> But that's just my opinion, which is also not very relevant. In the end 
> it all comes to the same point I mentioned in my original email: it's 
> really hard to measure.
> 
> And with hard to measure I mean:
> 
> - How do you measure if Guix is diverse enough? Is there a universal 
> diversity scale? Does a high diversity according to whatever scale we 
> use ensure Guix is going to be in a better shape?
> - And for the GNU/non-GNU issue. Can we know before taking a decision 
> if it's actually going to bring more contributors to the project?
> - Same with the Git Forges. We have been discussing this for long, but 
> using, say, GitLab is going to impact on the amount and quality of the 
> contributions to Guix?
> 
> I don't think software projects are a comfortable place for people to 
> join and have fun, feel included or fulfill any social needs they may 
> have. That's not their goal. They can be fulfilling, but that's not the 
> main goal of the thing. (it might be the goal of a hackerspace)
> 
> The goal is to make great software, and that, weather we like it or 
> not, is an extremely elitist thing. Most of the people in the universe 
> are not able to make good software. Most of us studied in good 
> universities, have a computer available at any time and have free time 
> to spend here writing tremendous walls of text. Or even more, we have 
> had the privilege to be taught that diversity is important.
> 
> I'm not saying this has to be an uncomfortable place (in fact, the goal 
> of the original thread is to make it more comfortable), but we 
> shouldn't forget why we are here.
> 
> And some of the proposals I mentioned come from a good heart, I can 
> agree with them and I appreciate, but in the end it's not clear that 
> they are going to help us with our mission: bring the greatest software 
> to the people, so they enjoy their computing freely. That's why I try 
> to be cautious before taking a decision in those lines.
> 
> The good part is we can still make friends and all.
> 
> Ekaitz

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

[paul]

Hi Ekaitz,

On 10/27/24 11:47, Ekaitz Zarraga wrote:
> Hi,
>
> On 2024-10-27 11:00, indieterminacy wrote:
> > I think a useful measurement of any community is the diversity 
> within it.
>
> I do think we are a pretty diverse group.
>
> But it all comes to what you consider diverse. Some people brought 
> this conversation during the Guix Days, probably ignoring the fact 
> that we had people coming from all over the world. I don't know what 
> was their definition of diversity at that moment.
I can't talk for the people you mention, but usually by diversity one 
means social diversity, it meansco-existence of different social groups 
within a given setting.
> On the other hand, we have something in common, so it's really hard to 
> be diverse in the broad sense. Should we include people that like 
> proprietary software, too? Those are also people, and I'm sure they 
> would feel uncomfortable between us.
For sure they would, but "proprietary software user" is not a social 
group, so they would not be meaningful in a measure of  the Guix project 
social diversity.
>
> This is not to say we shouldn't try to make things better and more 
> welcoming, of course we should. But I don't think "diversity" actually 
> means that much as a measure because I don't think it's an absolute 
> concept and I think it's very easy to misunderstand.

I am not an expert but there are many social scientist that are, for 
sure for them social diversity is a pretty clear concept since they 
sometimes have to measure it for their research work.

While for sure all your points about care, overwork and burnout are 
valid, I believe the fundamental problem to be of governance. To make 
Guix better software (there is scientific consensus that diverse 
communities have better governance, it is easy to find), we should find 
out more about how to measure social diversity and take concrete actions 
towards making the Guix community a more diverse one.

At last, image is fundamental otherwise big corporations wouldn't spend 
so much to try to do whatever-washing, getting distance between us and 
GNU/FSF would concretely help very much with diversity.

Thank you all in the Guix community for your awesome work so far,


giacomo

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

[Ekaitz Zarraga]

On 2024-10-27 19:12, paul wrote:
> Hi Ekaitz,
> 
> On 10/27/24 11:47, Ekaitz Zarraga wrote:
>> Hi,
>>
>> On 2024-10-27 11:00, indieterminacy wrote:
>> > I think a useful measurement of any community is the diversity 
>> within it.
>>
>> I do think we are a pretty diverse group.
>>
>> But it all comes to what you consider diverse. Some people brought 
>> this conversation during the Guix Days, probably ignoring the fact 
>> that we had people coming from all over the world. I don't know what 
>> was their definition of diversity at that moment.
> I can't talk for the people you mention, but usually by diversity one 
> means social diversity, it meansco-existence of different social groups 
> within a given setting.

But what is a social group?

>> On the other hand, we have something in common, so it's really hard to 
>> be diverse in the broad sense. Should we include people that like 
>> proprietary software, too? Those are also people, and I'm sure they 
>> would feel uncomfortable between us.
> For sure they would, but "proprietary software user" is not a social 
> group, so they would not be meaningful in a measure of  the Guix project 
> social diversity.
If you go to the wikipedia definition of it, it says social groups come 
in myriads of sizes and varieties, and its definition is pretty loose:

   In the social sciences, a social group is defined as two or more 
people who interact with one another, share similar characteristics, and 
collectively have a sense of unity.

Proprietary software user is not a social group, but two proprietary 
software users that are Apple fanboys is.

So, what you propose that is very well defined I don't think it's 
totally true, at least not to the extent that is going to let us take 
accurate and predictable decisions.

>> This is not to say we shouldn't try to make things better and more 
>> welcoming, of course we should. But I don't think "diversity" actually 
>> means that much as a measure because I don't think it's an absolute 
>> concept and I think it's very easy to misunderstand.
> 
> I am not an expert but there are many social scientist that are, for 
> sure for them social diversity is a pretty clear concept since they 
> sometimes have to measure it for their research work.


As I know, few social concepts are really measurable in terms an 
engineer would feel confortable with. I'm open to be educated in the 
subject, but if someone has a proper measure for diversity in a 
community that is not affect by bias and is applicable to us and can do 
a good prediction on how investing everything on it can really change 
the quality of the software we produce and the quality of life of the 
ones who produce it, please let me know.

Until we have it, we are just talking about things we don't know, and 
I'm not interested on that kind of conversation.

 >
 > While for sure all your points about care, overwork and burnout are
 > valid, I believe the fundamental problem to be of governance.

We can agree with this. Most of our discussion goes in this direction.
But just that is not enough to change things.

 >  To make
 > Guix better software (there is scientific consensus that diverse
 > communities have better governance, it is easy to find), we should find
 > out more about how to measure social diversity and take concrete actions
 > towards making the Guix community a more diverse one.

What is "better" governance?
That's what we are trying to define here I think. A governance that fits us.

With the social diversity here we can't really do much, as I said. Every 
day I work in Guix with people from many different backgrounds and 
ideas, but still we are always going to be people that likes computers 
and share some cultural aspects like talking in English, for example.

Again, this is a futile conversation because there's not much we can do 
and those who push the debate on this direction don't really have 
specific proposals: just throw more diversity to the thing.

That's not the solution to everything.

Mostly, because as we didn't measure (and it's not clear yet that is 
measurable), we might be trying to solve a problem we don't have, that 
we cannot fix, or that is inefficient to tackle due to other reasons.

And also, there's only so much diversity we can throw to this, and it's 
not clear to me that we didn't peak on it already.

 >
 > At last, image is fundamental otherwise big corporations wouldn't spend
 > so much to try to do whatever-washing, getting distance between us and
 > GNU/FSF would concretely help very much with diversity.

Big corporations also spend a lot of money lying to you, selling you 
things you don't need, lobbying to governments and so on, and I wouldn't 
say any of those are a good thing.

They need the image to do those things. We are not a corporation. We 
don't sell things. We don't lie, we convince.

I don't think we can compare to that.

If we consider the image is important, as you suggest, we should also 
remember the GNU and the FSF have also a reputation. We could decide to 
reject that with the promise of more diversity, but we didn't make sure 
yet diversity is the only thing we need.

Let's remember the FSF still pays most of our bills. Regardless this 
might be a good argument or not, I don't feel comfortable risking all 
our financial stability for a promise that we would be more diverse 
(while still being a super-niche project written in a weird programming 
language almost nobody uses), even more when nobody can prove that 
diversity is our only issue.

Many people on this project have tried to change GNU from the inside and 
are very critical with the FSF (see the https://gnu.tools/). I think 
that's also a good way to do things, changing them from the inside. 
Fixing them for all our friends. Honestly, the argument of getting 
distance with GNU and the FSF is too simplistic to be taken seriously.

Again, this discussion as interesting as it might be for the very long 
term, is uninteresting to me because it won't produce any practical output.

 >
 > Thank you all in the Guix community for your awesome work so far,

Thank you for sharing your thoughts. I might sound a little bit harsh, 
but it's not on purpose.

Ekaitz

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

[Thompson, David]

On Sun, Oct 27, 2024 at 3:13 PM Ekaitz Zarraga <ekaitz@elenq.tech> wrote:
>
> Many people on this project have tried to change GNU from the inside and
> are very critical with the FSF (see the https://gnu.tools/). I think
> that's also a good way to do things, changing them from the inside.
> Fixing them for all our friends. Honestly, the argument of getting
> distance with GNU and the FSF is too simplistic to be taken seriously.

Changing GNU/FSF from the inside has been a losing strategy for at
least a decade, as a conservative estimate. Nothing has meaningfully
changed for the better and the situation continues to deteriorate both
socially and infrastructurally. Many have tried to reform GNU, all
have failed. Some burn out and never return. Those that remain choose
to inhabit the fringes; projects that are historically GNU but in
practice are no longer concerned with the project as a whole (Guile
and Guix, for example.) We unsubscribe from gnu-prog-discuss and move
on. Thinking that GNU can be changed at this point is what is truly
too simplistic to be taken seriously. The GNU brand is and has been a
net negative for Guix. Juli did a great job describing why in an
earlier message. Every conversation about Guix I stumble upon online
inevitably derails into a negative discussion about GNU and it's hard
to break through the noise to explain that Guix is really cool,
actually. It's not priority #1, but we gotta eschew GNU.

- Dave

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

[Ekaitz Zarraga]

On 2024-10-27 22:31, Thompson, David wrote:
> On Sun, Oct 27, 2024 at 3:13 PM Ekaitz Zarraga <ekaitz@elenq.tech> wrote:
>>
>> Many people on this project have tried to change GNU from the inside and
>> are very critical with the FSF (see the https://gnu.tools/). I think
>> that's also a good way to do things, changing them from the inside.
>> Fixing them for all our friends. Honestly, the argument of getting
>> distance with GNU and the FSF is too simplistic to be taken seriously.
> 
> Changing GNU/FSF from the inside has been a losing strategy for at
> least a decade, as a conservative estimate. Nothing has meaningfully
> changed for the better and the situation continues to deteriorate both
> socially and infrastructurally. Many have tried to reform GNU, all
> have failed. Some burn out and never return. Those that remain choose
> to inhabit the fringes; projects that are historically GNU but in
> practice are no longer concerned with the project as a whole (Guile
> and Guix, for example.) We unsubscribe from gnu-prog-discuss and move
> on. Thinking that GNU can be changed at this point is what is truly
> too simplistic to be taken seriously. The GNU brand is and has been a
> net negative for Guix. Juli did a great job describing why in an
> earlier message. Every conversation about Guix I stumble upon online
> inevitably derails into a negative discussion about GNU and it's hard
> to break through the noise to explain that Guix is really cool,
> actually. It's not priority #1, but we gotta eschew GNU.
> 
> - Dave

Hi Dave,

I know the gnu.tools have failed to reach their goal, but it should help 
to tell those who don't like Guix just because of the ties to GNU that 
our way to GNU is a little bit different that the one they may not like. 
In any case, it wasn't the main point of my argument.

I don't find Juli's explanation to be universal, neither yours. We all 
know how the drama is handled in the GNU/Linux world: everybody is 
wiling to be heated about things and choose sides. But in the end of the 
day all those heated arguments really mean anything? I don't think so.

The online environments we take part in (yours and mine have some 
overlap) are very biased. VERY.
I think you are underestimating what GNU and the FSF mean to people. 
More specifically, what they mean to people that is part of Guix.

At this very moment, we just cannot cut ties to the FSF as far as I 
understood.

I don't know if cutting ties with GNU would change anything in that 
regard. But as you say, it's not the priority number 1. And we don't 
know for sure, because it's really hard to know, that is actually going 
to fix anything.

As said, it's just your feeling and your anecdotal experience. Andy Tai 
already has spoken to say he contributes to Guix because it is GNU and 
donates to the FSF because he considers it's the foundation that makes 
the greatest use of the money. That is also valuable, and I think you 
are not being considerate enough with people like him.

What kind of diversity are we looking for then?

I also believe promises are meaningless. People that are currently part 
of Guix are already with us, you are proposing something that might 
bring new people, at the cost of some we already have. It doesn't feel 
like a good deal to me.

And in any case, I don't think we are in a position to take a decision 
like this right now. Maybe investing more on the Guix Foundation is a 
good way to enable this kind of decision in the future.

I don't want this to take over the original goal that I had so from now 
I'll focus only on what we can do.

Of course, feel free to continue this line of discussion.

Just let me remind you all: I started this to take more care of each 
other and make sure Guix is sustainable.

Please, let's not forget that.

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

[Suhail Singh]

"Thompson, David" <dthompson2@worcester.edu> writes:

> Changing GNU/FSF from the inside has been a losing strategy for at
> least a decade, as a conservative estimate. Nothing has meaningfully
> changed for the better and the situation continues to deteriorate both
> socially and infrastructurally.

Since I am unaware, for my awareness (and the awareness of others in a
similar situation), could you please describe what specific attempts at
social and infrastructure changes were attempted, but were unsuccessful?

> Juli did a great job describing why in an earlier message.

Perhaps Juliana's message made sense to those already aware.  To those
unaware, such as myself, what I got was that FSF made some "bad
political move" and said move seems to have resulted in FSF being
considered toxic by some people - to the point where simple association
with it or GNU is sufficient to cause discomfort.

If everyone whose opinion is relevant (I am not a committer, so perhaps
I am intruding) is already aware of what's being discussed above, please
ignore my message.  However, I am having difficulty forming an informed
opinion based on the details that have been shared so far.

-- 
Suhail

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

[paul]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

Hi Ekaitz,

Social diversity not being an engineering problem is really my point. The point is not to have diversity reach a certain numeric threshold but strive to be as socially diverse as possible I believe.

We don't need an unit of measure to be sure of analyzing diversity without bias, we need to ask experts in the field of social sciences. Outreachy is a good example and we collaborated in the past, maybe they could give us some tips.

At last, in my opinion, better governance means governance that enables the project to reach our vision faster or at all. For sure diversity is not enough without at least some structure, but for sure structure is not enough as well.

Cheers,

giacomo



[-- Attachment #2: Type: text/html, Size: 803 bytes --]