* Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-25 12:58 ` Thompson, David
@ 2024-10-26 13:48 ` Christine Lemmer-Webber
2024-10-26 14:49 ` Ekaitz Zarraga
` (2 more replies)
0 siblings, 3 replies; 35+ messages in thread
From: Christine Lemmer-Webber @ 2024-10-26 13:48 UTC (permalink / raw)
To: Thompson, David; +Cc: Ekaitz Zarraga, guix-devel
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 13:48 ` Guix (and Guile's) promise, and how to (hopefully) get there Christine Lemmer-Webber
@ 2024-10-26 14:49 ` Ekaitz Zarraga
2024-10-26 20:22 ` Ludovic Courtès
2024-11-01 17:03 ` Attila Lendvai
2024-10-26 16:40 ` Suhail Singh
2024-10-26 21:12 ` Ludovic Courtès
2 siblings, 2 replies; 35+ messages in thread
From: Ekaitz Zarraga @ 2024-10-26 14:49 UTC (permalink / raw)
To: Christine Lemmer-Webber, Thompson, David; +Cc: guix-devel
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?
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 13:48 ` Guix (and Guile's) promise, and how to (hopefully) get there Christine Lemmer-Webber
2024-10-26 14:49 ` Ekaitz Zarraga
@ 2024-10-26 16:40 ` Suhail Singh
2024-10-26 22:07 ` Ludovic Courtès
2024-10-26 22:28 ` indieterminacy
2024-10-26 21:12 ` Ludovic Courtès
2 siblings, 2 replies; 35+ messages in thread
From: Suhail Singh @ 2024-10-26 16:40 UTC (permalink / raw)
To: Christine Lemmer-Webber; +Cc: Thompson, David, Ekaitz Zarraga, guix-devel
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 14:49 ` Ekaitz Zarraga
@ 2024-10-26 20:22 ` Ludovic Courtès
2024-10-27 0:38 ` Ekaitz Zarraga
` (2 more replies)
2024-11-01 17:03 ` Attila Lendvai
1 sibling, 3 replies; 35+ messages in thread
From: Ludovic Courtès @ 2024-10-26 20:22 UTC (permalink / raw)
To: Ekaitz Zarraga; +Cc: Christine Lemmer-Webber, Thompson, David, guix-devel
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’.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 13:48 ` Guix (and Guile's) promise, and how to (hopefully) get there Christine Lemmer-Webber
2024-10-26 14:49 ` Ekaitz Zarraga
2024-10-26 16:40 ` Suhail Singh
@ 2024-10-26 21:12 ` Ludovic Courtès
2 siblings, 0 replies; 35+ messages in thread
From: Ludovic Courtès @ 2024-10-26 21:12 UTC (permalink / raw)
To: Christine Lemmer-Webber; +Cc: Thompson, David, Ekaitz Zarraga, guix-devel
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’.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
@ 2024-10-26 22:02 Juliana Sims
2024-10-27 1:01 ` Ekaitz Zarraga
0 siblings, 1 reply; 35+ messages in thread
From: Juliana Sims @ 2024-10-26 22:02 UTC (permalink / raw)
To: ekaitz; +Cc: guix-devel, suhailsingh247
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 16:40 ` Suhail Singh
@ 2024-10-26 22:07 ` Ludovic Courtès
2024-10-27 1:33 ` Suhail Singh
2024-10-26 22:28 ` indieterminacy
1 sibling, 1 reply; 35+ messages in thread
From: Ludovic Courtès @ 2024-10-26 22:07 UTC (permalink / raw)
To: Suhail Singh
Cc: Christine Lemmer-Webber, Thompson, David, Ekaitz Zarraga,
guix-devel
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’.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 16:40 ` Suhail Singh
2024-10-26 22:07 ` Ludovic Courtès
@ 2024-10-26 22:28 ` indieterminacy
1 sibling, 0 replies; 35+ messages in thread
From: indieterminacy @ 2024-10-26 22:28 UTC (permalink / raw)
To: Suhail Singh
Cc: Christine Lemmer-Webber, Thompson, David, Ekaitz Zarraga,
guix-devel
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
[not found] <mailman.1757.1729980481.21403.guix-devel@gnu.org>
@ 2024-10-27 0:05 ` Andy Tai
0 siblings, 0 replies; 35+ messages in thread
From: Andy Tai @ 2024-10-27 0:05 UTC (permalink / raw)
To: guix-devel, Juliana Sims
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 20:22 ` Ludovic Courtès
@ 2024-10-27 0:38 ` Ekaitz Zarraga
2024-10-29 23:04 ` Ludovic Courtès
2024-10-28 10:09 ` Andreas Enge
2024-10-28 10:20 ` Andreas Enge
2 siblings, 1 reply; 35+ messages in thread
From: Ekaitz Zarraga @ 2024-10-27 0:38 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Christine Lemmer-Webber, Thompson, David, guix-devel
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?
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 22:02 Juliana Sims
@ 2024-10-27 1:01 ` Ekaitz Zarraga
2024-10-27 10:00 ` indieterminacy
0 siblings, 1 reply; 35+ messages in thread
From: Ekaitz Zarraga @ 2024-10-27 1:01 UTC (permalink / raw)
To: Juliana Sims; +Cc: guix-devel, suhailsingh247
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 22:07 ` Ludovic Courtès
@ 2024-10-27 1:33 ` Suhail Singh
0 siblings, 0 replies; 35+ messages in thread
From: Suhail Singh @ 2024-10-27 1:33 UTC (permalink / raw)
To: Ludovic Courtès
Cc: Suhail Singh, Christine Lemmer-Webber, Thompson, David,
Ekaitz Zarraga, guix-devel
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 1:01 ` Ekaitz Zarraga
@ 2024-10-27 10:00 ` indieterminacy
2024-10-27 10:47 ` Ekaitz Zarraga
0 siblings, 1 reply; 35+ messages in thread
From: indieterminacy @ 2024-10-27 10:00 UTC (permalink / raw)
To: Ekaitz Zarraga; +Cc: Juliana Sims, guix-devel, suhailsingh247
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 10:00 ` indieterminacy
@ 2024-10-27 10:47 ` Ekaitz Zarraga
2024-10-27 11:39 ` indieterminacy
2024-10-27 18:12 ` paul
0 siblings, 2 replies; 35+ messages in thread
From: Ekaitz Zarraga @ 2024-10-27 10:47 UTC (permalink / raw)
To: indieterminacy; +Cc: Juliana Sims, guix-devel, suhailsingh247
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 10:47 ` Ekaitz Zarraga
@ 2024-10-27 11:39 ` indieterminacy
2024-10-28 9:43 ` Ricardo Wurmus
2024-10-27 18:12 ` paul
1 sibling, 1 reply; 35+ messages in thread
From: indieterminacy @ 2024-10-27 11:39 UTC (permalink / raw)
To: Ekaitz Zarraga; +Cc: Juliana Sims, guix-devel, suhailsingh247
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 10:47 ` Ekaitz Zarraga
2024-10-27 11:39 ` indieterminacy
@ 2024-10-27 18:12 ` paul
2024-10-27 19:13 ` Ekaitz Zarraga
1 sibling, 1 reply; 35+ messages in thread
From: paul @ 2024-10-27 18:12 UTC (permalink / raw)
To: guix-devel
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 18:12 ` paul
@ 2024-10-27 19:13 ` Ekaitz Zarraga
2024-10-27 21:31 ` Thompson, David
` (2 more replies)
0 siblings, 3 replies; 35+ messages in thread
From: Ekaitz Zarraga @ 2024-10-27 19:13 UTC (permalink / raw)
To: paul, guix-devel
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 19:13 ` Ekaitz Zarraga
@ 2024-10-27 21:31 ` Thompson, David
2024-10-27 22:19 ` Ekaitz Zarraga
` (2 more replies)
2024-10-27 23:42 ` paul
2024-10-28 9:53 ` Ricardo Wurmus
2 siblings, 3 replies; 35+ messages in thread
From: Thompson, David @ 2024-10-27 21:31 UTC (permalink / raw)
To: Ekaitz Zarraga; +Cc: paul, guix-devel
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 21:31 ` Thompson, David
@ 2024-10-27 22:19 ` Ekaitz Zarraga
2024-10-27 22:22 ` Suhail Singh
2024-10-28 10:07 ` Ricardo Wurmus
2 siblings, 0 replies; 35+ messages in thread
From: Ekaitz Zarraga @ 2024-10-27 22:19 UTC (permalink / raw)
To: Thompson, David; +Cc: paul, guix-devel
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 21:31 ` Thompson, David
2024-10-27 22:19 ` Ekaitz Zarraga
@ 2024-10-27 22:22 ` Suhail Singh
2024-10-28 10:12 ` Efraim Flashner
2024-10-28 10:07 ` Ricardo Wurmus
2 siblings, 1 reply; 35+ messages in thread
From: Suhail Singh @ 2024-10-27 22:22 UTC (permalink / raw)
To: Thompson, David; +Cc: Ekaitz Zarraga, paul, guix-devel
"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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 19:13 ` Ekaitz Zarraga
2024-10-27 21:31 ` Thompson, David
@ 2024-10-27 23:42 ` paul
2024-10-28 9:53 ` Ricardo Wurmus
2 siblings, 0 replies; 35+ messages in thread
From: paul @ 2024-10-27 23:42 UTC (permalink / raw)
To: Ekaitz Zarraga, guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 11:39 ` indieterminacy
@ 2024-10-28 9:43 ` Ricardo Wurmus
0 siblings, 0 replies; 35+ messages in thread
From: Ricardo Wurmus @ 2024-10-28 9:43 UTC (permalink / raw)
To: indieterminacy; +Cc: Ekaitz Zarraga, Juliana Sims, guix-devel, suhailsingh247
indieterminacy <indieterminacy@libre.brussels> writes:
> 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.
When we published https://gnu.tools/ it was our conviction that GNU is
what we make of it, because it is little more than a name for a set of
goals and an inspiring retelling of history (up to the mid-1990s
perhaps). Turns out that in practical and concrete terms "GNU" means
very little to the supporters of projects associated with GNU. This is
why there hasn't been more activity concerning the GNU Assembly: there
is little to be *done* collectively.
The GNU Assembly could continue to ignore Stallman's attempts to
micromanage, continue to publish rebuttals whenever his tonedeaf or
harmful actions draw attention, but ... it's so self-defeating to define
oneself merely in opposition to Stallman's missteps.
As a *project* GNU does not exist.
--
Ricardo
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 19:13 ` Ekaitz Zarraga
2024-10-27 21:31 ` Thompson, David
2024-10-27 23:42 ` paul
@ 2024-10-28 9:53 ` Ricardo Wurmus
2024-10-28 10:01 ` Ekaitz Zarraga
2 siblings, 1 reply; 35+ messages in thread
From: Ricardo Wurmus @ 2024-10-28 9:53 UTC (permalink / raw)
To: Ekaitz Zarraga; +Cc: paul, guix-devel
Ekaitz Zarraga <ekaitz@elenq.tech> writes:
> Let's remember the FSF still pays most of our bills.
I think clarification is required here: the Guix project receives
donations, including a single very large donation. Most of these
donations were received because of Guix's participation in an FSF
program (an agreement for the FSF to handle donations and to send annual
fundraiser emails drafted by us, in exchange for a cut), so the FSF
currently holds these funds for us. When we want to use these funds we
send them invoices and get reimbursed --- this is our money, not theirs.
The statement "the FSF pays our bills" could be understood as the FSF
actively sponsoring the project. This is not true. The only direct
sponsorship from the FSF is in the form of hosting Savannah, debbugs,
and the mailing list.
--
Ricardo
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-28 9:53 ` Ricardo Wurmus
@ 2024-10-28 10:01 ` Ekaitz Zarraga
0 siblings, 0 replies; 35+ messages in thread
From: Ekaitz Zarraga @ 2024-10-28 10:01 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: paul, guix-devel
On 2024-10-28 10:53, Ricardo Wurmus wrote:
> Ekaitz Zarraga <ekaitz@elenq.tech> writes:
>
>> Let's remember the FSF still pays most of our bills.
>
> I think clarification is required here: the Guix project receives
> donations, including a single very large donation. Most of these
> donations were received because of Guix's participation in an FSF
> program (an agreement for the FSF to handle donations and to send annual
> fundraiser emails drafted by us, in exchange for a cut), so the FSF
> currently holds these funds for us. When we want to use these funds we
> send them invoices and get reimbursed --- this is our money, not theirs.
>
> The statement "the FSF pays our bills" could be understood as the FSF
> actively sponsoring the project. This is not true. The only direct
> sponsorship from the FSF is in the form of hosting Savannah, debbugs,
> and the mailing list.
>
Hey Ricardo,
Thank you for clarifying this! Very important!
Now I have a better understanding. And this enables further discussion
in many ways.
Now the next question would be if we are ready to make that money
handling job. We have the Guix Foundation, if we invest more on it, it
would work!
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 21:31 ` Thompson, David
2024-10-27 22:19 ` Ekaitz Zarraga
2024-10-27 22:22 ` Suhail Singh
@ 2024-10-28 10:07 ` Ricardo Wurmus
2 siblings, 0 replies; 35+ messages in thread
From: Ricardo Wurmus @ 2024-10-28 10:07 UTC (permalink / raw)
To: Thompson, David; +Cc: Ekaitz Zarraga, paul, guix-devel
"Thompson, David" <dthompson2@worcester.edu> writes:
> 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.
I want to note that this is not a singular experience. I see myself in
the above text. There are many such stories.
There are many reasons for this, but the fact that GNU is what
contributors make of it cuts both ways. The extremely uneven
distribution of authority and public perception also means that even a
sizable group of reformers (like https://gnu.tools) is virtually
powerless to reform GNU in any *meaningful* sense.
Ironically, I *don't* think the association with GNU will remain a
negative in the long run, but that's only because I think GNU's overall
relevance is only going to continue to shrink. Perhaps one day only the
projects associated with the GNU Assembly will remain as visible
representatives of GNU.
--
Ricardo
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 20:22 ` Ludovic Courtès
2024-10-27 0:38 ` Ekaitz Zarraga
@ 2024-10-28 10:09 ` Andreas Enge
2024-10-28 10:20 ` Andreas Enge
2 siblings, 0 replies; 35+ messages in thread
From: Andreas Enge @ 2024-10-28 10:09 UTC (permalink / raw)
To: Ludovic Courtès
Cc: Ekaitz Zarraga, Christine Lemmer-Webber, Thompson, David,
guix-devel
Am Sat, Oct 26, 2024 at 10:22:09PM +0200 schrieb Ludovic Courtès:
> ⁰ 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.
> :-)
Security by obscurity ;-)
Clone the git repository and change into the accounting subdirectory,
or download just the file. Then
guix shell -C ledger -- ledger -f accounting.ledger balance
Right now the first line says
€2534.65 Assets:Bank
Andreas
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 22:22 ` Suhail Singh
@ 2024-10-28 10:12 ` Efraim Flashner
2024-10-28 14:07 ` Suhail Singh
0 siblings, 1 reply; 35+ messages in thread
From: Efraim Flashner @ 2024-10-28 10:12 UTC (permalink / raw)
To: Suhail Singh; +Cc: Thompson, David, Ekaitz Zarraga, paul, guix-devel
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
On Sun, Oct 27, 2024 at 06:22:46PM -0400, Suhail Singh wrote:
> "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.
Some of the problems are that it's been the same problems for years. As
David Thompson said, and others too, trying to reform the FSF from and
the GNU project from the inside has been a losing battle for at least 10
years now. Because it's been so long people normally just hint at it,
since it always leads to strong feelings.
The problem is RMS. The incident Juliana is referring to is when he
appointed himself back onto the board of the FSF a few years ago.
To phrase it diplomatically, it is not his Free Software positions that
give people pause. I will not try to list or go into detail the
different reasons people don't want to associate with him, but I will be
explicit that it is not because of his stance on Free Software.
If you (or others!) have questions I can try to answer them off-list.
--
Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 20:22 ` Ludovic Courtès
2024-10-27 0:38 ` Ekaitz Zarraga
2024-10-28 10:09 ` Andreas Enge
@ 2024-10-28 10:20 ` Andreas Enge
2 siblings, 0 replies; 35+ messages in thread
From: Andreas Enge @ 2024-10-28 10:20 UTC (permalink / raw)
To: Ludovic Courtès
Cc: Ekaitz Zarraga, Christine Lemmer-Webber, Thompson, David,
guix-devel
Am Sat, Oct 26, 2024 at 10:22:09PM +0200 schrieb Ludovic Courtès:
> > - Can we improve anything relieving weight from the shoulders of some
> > people instead of putting even more on them?
> Yes! Committers can review code
Typo? "Non-committers" can review code!
Right now when going through the green dots at
https://qa.guix.gnu.org/patches
to see whether I could push any of them, I realised that, for instance,
it would be helpful if someone I trust (that is, have seen around the
project) had checked the licenses of packages submitted by a new person.
Or, had looked at this enormous patch with 20 commits of new rust packages
and confirmed that they are okay.
Some people do, and make the green dots turn dark green, and I am grateful
for their help. Shout outs to Nicolas Graves and Steve George (and sorry
to those I am forgetting).
Andreas
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-28 10:12 ` Efraim Flashner
@ 2024-10-28 14:07 ` Suhail Singh
0 siblings, 0 replies; 35+ messages in thread
From: Suhail Singh @ 2024-10-28 14:07 UTC (permalink / raw)
To: Suhail Singh; +Cc: Thompson, David, Ekaitz Zarraga, paul, guix-devel
Efraim Flashner <efraim@flashner.co.il> writes:
> The problem is RMS. The incident Juliana is referring to is when he
> appointed himself back onto the board of the FSF a few years ago.
Thank you for clarifying.
> To phrase it diplomatically, it is not his Free Software positions that
> give people pause. I will not try to list or go into detail the
> different reasons people don't want to associate with him, but I will be
> explicit that it is not because of his stance on Free Software.
So if I understand correctly, for some people an association with FSF
and GNU is indiscernible from an endorsement of RMS's opinions and
actions that are distinct from his stance on Free Software. Whereas for
others the association with FSF and GNU is about an endorsement of Free
Software ideals.
Without going into matters such as how widespread or
worthy-of-mitigation a problem this is, i.e., whether or not something
_should_ be done about this, I am left wondering why a simple disclaimer
such as below wouldn't be adequate (assuming it's deemed
worthy-of-action by the maintainers):
#+begin_quote
While the Guix project supports the Free Software movement and in
those matters is aligned with the ideals of the FSF, we do not
(necessarily) condone nor support the opinions of all members,
especially on unrelated matters. Specifically, we do not approve nor
support RMS's views on matters distinct from his stance on Free
Software.
#+end_quote
If the issue isn't simply about clarifying what the Guix project
supports or doesn't support, but rather about the public's perception of
it, I sincerely hope the maintainers give some thought to what
constitutes "reasonable" vs "beyond reasonable" before making a
decision. For instance, should support for Emacs be dropped because
it's related to RMS? What if someone states that the support for Emacs
makes them uncomfortable? What if 10 people state that?
These are difficult questions indeed, but in my opinion these questions
are necessary to consider (and in the interest of transparency,
important to make opinions on them explicit), before deciding on a
course of action. Otherwise, we run the risk of trading-in conviction
for our beliefs for, possibly, short-lived public approval.
--
Suhail
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
@ 2024-10-28 16:33 spacecadet
2024-10-30 23:43 ` Tomas Volf
0 siblings, 1 reply; 35+ messages in thread
From: spacecadet @ 2024-10-28 16:33 UTC (permalink / raw)
To: guix-devel, juli
> 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*.
Since this argument is based off personal anecdote, I want to add my voice to that;
if guix split from GNU and the FSF I would become equally hesitant to continue using and contributing to it.
Endorsement and ties to these projects comes with a guarantee of freedom, which is important beyond anything else.
If we're all in it for the same purpose, why split over petty differences in personal opinions unrelated to those goals?
You can't please everyone and proposing that guix cut ties with the two biggest players in the free software world would alienate
more people - and more relevant people - than it would appease.
This seems like a poorly evaluated proposal and standpoint that should be scrutinized and reconsidered.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-27 0:38 ` Ekaitz Zarraga
@ 2024-10-29 23:04 ` Ludovic Courtès
0 siblings, 0 replies; 35+ messages in thread
From: Ludovic Courtès @ 2024-10-29 23:04 UTC (permalink / raw)
To: Ekaitz Zarraga; +Cc: Christine Lemmer-Webber, Thompson, David, guix-devel
Hi,
Ekaitz Zarraga <ekaitz@elenq.tech> skribis:
> 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.
To be clear, the FSF is not sponsoring Guix or funding its development;
it is acting as a fiscal sponsor (read: a bank) here.
[...]
>>> - 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**?
My personal take: yes, we should do that.
> 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?
I have reservations regarding #3: we have enough money for machines but
not for people, and we’re not set up to pay people apart from
bounties/stipends maybe.
But really: all good directions to invest in and points to address,
I agree!
Ludo’.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-28 16:33 spacecadet
@ 2024-10-30 23:43 ` Tomas Volf
2024-11-02 10:21 ` Steve George
0 siblings, 1 reply; 35+ messages in thread
From: Tomas Volf @ 2024-10-30 23:43 UTC (permalink / raw)
To: spacecadet; +Cc: guix-devel, juli
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]
Since we are putting personal anecdotes onto the pile...
spacecadet <spacecadet@purge.sh> writes:
>> 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*.
>
> Since this argument is based off personal anecdote, I want to add my
> voice to that; if guix split from GNU and the FSF I would become
> equally hesitant to continue using and contributing to it.
I do not want to speculate on what I would do in case of such a split,
but at the end of the day the GNU and FSF "brand" is why I am here
today.
Few years (oh boy the time does fly) back when I was deciding what weird
thing I should learn next, both Nix and GNU Guix were considered. While
most of my friends recommended Nix, after some cursory research I
decided to go with GNU Guix, to a large degree due to the perceived
"guarantees" provided by both the GNU and FSF brands.
Would I make the same choice today even on purely technical points?
Probably. But I sure did not know enough to make qualified decision as
a new potential user back then.
If such split would to happen, it would be great to have a better
justification than "it makes some people uncomfortable". Because the
split (at least if not justified enough) would *also* "make some people
uncomfortable" (well, at least me).
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-26 14:49 ` Ekaitz Zarraga
2024-10-26 20:22 ` Ludovic Courtès
@ 2024-11-01 17:03 ` Attila Lendvai
2024-11-01 21:14 ` Ekaitz Zarraga
1 sibling, 1 reply; 35+ messages in thread
From: Attila Lendvai @ 2024-11-01 17:03 UTC (permalink / raw)
To: Ekaitz Zarraga; +Cc: Christine Lemmer-Webber, Thompson, David, guix-devel
> 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.
this sounds an awful lot like 'the end justifies the means'.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Do not fear your enemies. The worst they can do is kill you. Do not fear friends. At worst, they may betray you. Fear those who do not care; they neither kill nor betray, but betrayal and murder exist because of their silent consent.”
— Bruno Jasieński (1901–1938)
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-11-01 17:03 ` Attila Lendvai
@ 2024-11-01 21:14 ` Ekaitz Zarraga
0 siblings, 0 replies; 35+ messages in thread
From: Ekaitz Zarraga @ 2024-11-01 21:14 UTC (permalink / raw)
To: Attila Lendvai; +Cc: guix-devel
On 2024-11-01 18:03, Attila Lendvai wrote:
>> 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.
>
>
> this sounds an awful lot like 'the end justifies the means'.
>
Thanks for the very constructive participation.
This is what encourages people to understand each other and push
together to make great things together.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Guix (and Guile's) promise, and how to (hopefully) get there
2024-10-30 23:43 ` Tomas Volf
@ 2024-11-02 10:21 ` Steve George
0 siblings, 0 replies; 35+ messages in thread
From: Steve George @ 2024-11-02 10:21 UTC (permalink / raw)
To: spacecadet, guix-devel, juli
On 31 Oct, Tomas Volf wrote:
(...)
> I do not want to speculate on what I would do in case of such a split,
> but at the end of the day the GNU and FSF "brand" is why I am here
> today.
>
> Few years (oh boy the time does fly) back when I was deciding what weird
> thing I should learn next, both Nix and GNU Guix were considered. While
> most of my friends recommended Nix, after some cursory research I
> decided to go with GNU Guix, to a large degree due to the perceived
> "guarantees" provided by both the GNU and FSF brands.
>
> Would I make the same choice today even on purely technical points?
> Probably. But I sure did not know enough to make qualified decision as
> a new potential user back then.
>
> If such split would to happen, it would be great to have a better
> justification than "it makes some people uncomfortable". Because the
> split (at least if not justified enough) would *also* "make some people
> uncomfortable" (well, at least me).
(...)
That's definitely achievable. The most well-known example is Debian's Social Contract:
https://www.debian.org/social_contract
As Christine said Debian as a project can be a bit special cased, I continue to be very impressed by the work Gentoo did (as a much smaller team). They picked up the Social Contract idea:
https://www.gentoo.org/get-started/philosophy/social-contract.html
With both, these days we'd probably separate 'how you behave' (code of conduct) from 'what we do' but it's nicely short and to the point.
Hope that's food for thought
Steve / Futurile
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2024-11-02 11:59 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.1757.1729980481.21403.guix-devel@gnu.org>
2024-10-27 0:05 ` Guix (and Guile's) promise, and how to (hopefully) get there Andy Tai
2024-10-28 16:33 spacecadet
2024-10-30 23:43 ` Tomas Volf
2024-11-02 10:21 ` Steve George
-- strict thread matches above, loose matches on Subject: below --
2024-10-26 22:02 Juliana Sims
2024-10-27 1:01 ` Ekaitz Zarraga
2024-10-27 10:00 ` indieterminacy
2024-10-27 10:47 ` Ekaitz Zarraga
2024-10-27 11:39 ` indieterminacy
2024-10-28 9:43 ` Ricardo Wurmus
2024-10-27 18:12 ` paul
2024-10-27 19:13 ` Ekaitz Zarraga
2024-10-27 21:31 ` Thompson, David
2024-10-27 22:19 ` Ekaitz Zarraga
2024-10-27 22:22 ` Suhail Singh
2024-10-28 10:12 ` Efraim Flashner
2024-10-28 14:07 ` Suhail Singh
2024-10-28 10:07 ` Ricardo Wurmus
2024-10-27 23:42 ` paul
2024-10-28 9:53 ` Ricardo Wurmus
2024-10-28 10:01 ` Ekaitz Zarraga
2024-10-24 22:08 Discussion on Guix funding // future Ekaitz Zarraga
2024-10-25 12:58 ` Thompson, David
2024-10-26 13:48 ` Guix (and Guile's) promise, and how to (hopefully) get there Christine Lemmer-Webber
2024-10-26 14:49 ` Ekaitz Zarraga
2024-10-26 20:22 ` Ludovic Courtès
2024-10-27 0:38 ` Ekaitz Zarraga
2024-10-29 23:04 ` Ludovic Courtès
2024-10-28 10:09 ` Andreas Enge
2024-10-28 10:20 ` Andreas Enge
2024-11-01 17:03 ` Attila Lendvai
2024-11-01 21:14 ` Ekaitz Zarraga
2024-10-26 16:40 ` Suhail Singh
2024-10-26 22:07 ` Ludovic Courtès
2024-10-27 1:33 ` Suhail Singh
2024-10-26 22:28 ` indieterminacy
2024-10-26 21:12 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).