Discussion on Guix funding // future

Discussion on Guix funding // future

[Ekaitz Zarraga]

Hi,

Recently I've been discussing with other members of the Guix community 
about several things we consider we could be improved.

The most important one in my opinion is the funding. I don't know (does 
anybody know?) how Guix is funded, and it worries me.

I've been funded to work on the bootstrapping part of Guix by NlNet 
grants. I've been extremely lucky, and I'm very grateful for it. And I 
tried to spread the money, paying people who deserved it.

Grants are great for specific issues, but we are not going to make Guix 
survive using only that kind of grants.

First of all, these grants don't pay much, and they are just for a year 
or so. Many of us have the technical skills to get a job that pays way 
more than a grant and is way more stable. This makes doing something 
ethical and good become a punishment, and it's forcing many people to 
choose. Most of the people don't have the privilege to choose.

Second, grants work kind of well for specific tasks, but what happens 
with the structural work? Is anybody actually getting paid for it?

Finally, grants push individuals to try to do things, but don't 
encourage collective action (also the amounts are not high enough for 
collective action). That's not necessarily bad, but those individual 
projects also drain energy from those who are structural to Guix. 
Patches have to be reviewed, and commits need to be merged.


On a side note, I think we are missing reviewers, maintainers and 
commiters, and I think that view is shared in the community. Let's use 
my case as an example: I raised my hand to become a commiter, and I 
don't know how that was lost in the mailboxes and nothing happened. At 
this moment, I don't care anymore: when I need to make a commit, I know 
there's people that trust me and I just ping them and they do it for me. 
Should I bother people try to get commit access again? My life is very 
comfortable as is... Some questions come again to my mind: Am I really 
ready for the challenge? Am I going to be a good commiter? Is it fair to 
continue like I am right now?

This issue and some others could be fixed with money. Simple, huh?

I think we should try to invest more on the people, and that probably 
means paying them for the work they do. At least to some, so they can 
invest more time and care in others.

This we can't do with grants with the NlNet flavor. We need other kind 
of approach.

Sovereign Tech Fund has a very interesting model for maintainers, but 
still lacks the ability to invest on people freely.

Many people has been thanklessly working for this project, and some will 
continue to anyway, but not having a proper funding model is probably 
keeping us in an uncomfortable situation. The lack of people is pushing 
away new people, and we are in a vicious circle where I think people 
that are less stubborn than me just go spend time on other projects.

We have had cases of people giving too much for the project for too 
long. I don't think we acknowledge that enough, and probably we should. 
We should take care of our people.


I think free software projects use to be precarious and we are too used 
to that. However, I think we should try to break with that image, and 
try to push for funding collectively, so we can cover structural costs: 
people and machines.

I think I'm just somehow sharing my will to help, and also trying to 
encourage some conversation about the funding and how we could do 
better. If anyone has ideas, please share.



On a second (and last) side note, I also discussed with some members of 
the community about the status of Guile. I may send separate email for 
that, but it would be great if we could use some of the energy we have 
to give Guile some love. We are too Guile-dependent to just let it rot.

Thanks for all you do,

Ekaitz

Re: Discussion on Guix funding // future

[Steve George]

Hi,

On 25 Oct, Ekaitz Zarraga wrote:
(...)

> I think we should try to invest more on the people, and that probably means
> paying them for the work they do. At least to some, so they can invest more
> time and care in others.
(...)

> Many people has been thanklessly working for this project, and some will
> continue to anyway, but not having a proper funding model is probably
> keeping us in an uncomfortable situation. The lack of people is pushing away
> new people, and we are in a vicious circle where I think people that are
> less stubborn than me just go spend time on other projects.
(...)

For a small project "paying people" brings up the area of contributor motivation:

1. Does funding contributors improve a project?
2. Does funding contributors motivate them?

For (1) the answering is unsurprisingly that projects can get more done if they are sustainable. Linux Foundation's contributor survey found that about 50% of contributors in FOSS are paid [1].

Tidelift have a series of surveys that are worth reading. The summary is that paid developers implement tedious but important maintenance activities like security and documentation. It confirms what we all know implicitly, if it's your personal hobby time you'll do what's fun, whereas in work we all do work that we don't enjoy but we know is necessary [2].

One concern with supporting developers is whether it demotivates them in the long-term: from intrinsic to extrinisic motivation. Basically, the answer is that pay doesn't motivate but it does 'enable' for committed contributors: the Linux foundation survey shows this, there's also various academic pieces on FOSS motivation.

> I think free software projects use to be precarious and we are too used to
> that. However, I think we should try to break with that image, and try to
> push for funding collectively, so we can cover structural costs: people and
> machines.
> 
> I think I'm just somehow sharing my will to help, and also trying to
> encourage some conversation about the funding and how we could do better. If
> anyone has ideas, please share.

Before we can discuss whether the project *should do something*, we have to know whether it actually can do something. Whether it has the structure and capabilities.

I believe the Guix Foundation (https://foundation.guix.info/) is the mechanism that can be used to raise funds for the project. 

But, I don't understand the legal and operational constraints it's operating under. For example:

- Can it accept donations from anyone world-wide?
- Can it represent the project when applying for grants?
- Are there limitations on what it's allowed to fund?
- Are there operational limitations? (banking is a problem?)

I know Simon, Tanguy, Andreas, Julien and others have worked hard on this, so that's to be appreciated.

If it's in a good place then there's lots we could do to try and attract donations and support.

It's quite hard to find European associations as a basis for comparison. But, as an example in 2023 KDE raised 450,000 Euros, and spent about 70% (3167) on paid contractors/reimbursements, with additional money spent on user/developer events and sprints. See [3]

I'm not saying Guix would be at that kind of level, but it's food for thought on what's possible!

Steve / Futurile

[1] https://www.linuxfoundation.org/resources/publications/foss-contributor-2020 (download doesn't require registration)
[2] https://blog.tidelift.com/paid-maintainers-do-more-maintenance-and-documentation-work (the full survey download is behind a registration)
[3] https://ev.kde.org/reports/ev-2023/

Re: Discussion on Guix funding // future

[Ricardo Wurmus]

Steve George <steve@futurile.net> writes:

> One concern with supporting developers is whether it demotivates them
> in the long-term: from intrinsic to extrinisic motivation. Basically,
> the answer is that pay doesn't motivate but it does 'enable' for
> committed contributors: the Linux foundation survey shows this,
> there's also various academic pieces on FOSS motivation.

Paying some people also has the potential of eroding motivation for
those who are not paid.

*Employing* people and having their salaries be paid from donations held
by a foundation is a can of worms that I personally would shy away from
opening.  An easier and less daunting way to inject monetary rewards
into volunteer-based activities is to fund awards for certain
accomplishments.  This would strip all the complications of employment
and still allow for less desirable work to be rewarded.

-- 
Ricardo

Re: Discussion on Guix funding // future

[Ekaitz Zarraga]

On 2024-10-25 11:11, Ricardo Wurmus wrote:
> Steve George <steve@futurile.net> writes:
> 
>> One concern with supporting developers is whether it demotivates them
>> in the long-term: from intrinsic to extrinisic motivation. Basically,
>> the answer is that pay doesn't motivate but it does 'enable' for
>> committed contributors: the Linux foundation survey shows this,
>> there's also various academic pieces on FOSS motivation.
> 
> Paying some people also has the potential of eroding motivation for
> those who are not paid.
> 
> *Employing* people and having their salaries be paid from donations held
> by a foundation is a can of worms that I personally would shy away from
> opening.  An easier and less daunting way to inject monetary rewards
> into volunteer-based activities is to fund awards for certain
> accomplishments.  This would strip all the complications of employment
> and still allow for less desirable work to be rewarded.
> 

Ricardo, I can agree with you but how do you reward just being there and 
doing the dirty job?

That's what worries me the most.

Re: Discussion on Guix funding // future

[Ricardo Wurmus]

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

> Ricardo, I can agree with you but how do you reward just being there
> and doing the dirty job?

For reviews, for example, one could find an arbitrary set of metrics and
hand out an award with a monetary component at an annual event.  I'm not
speaking of sustainable funding of that work, but of a mechanism to both
publicize the importance of the work and to add a social component to
recognizing it.

-- 
Ricardo

Re: Discussion on Guix funding // future

[indieterminacy]

On 2024-10-25 11:37, Ricardo Wurmus wrote:
> Ekaitz Zarraga <ekaitz@elenq.tech> writes:
> 
>> Ricardo, I can agree with you but how do you reward just being there
>> and doing the dirty job?
> 
> For reviews, for example, one could find an arbitrary set of metrics 
> and
> hand out an award with a monetary component at an annual event.  I'm 
> not
> speaking of sustainable funding of that work, but of a mechanism to 
> both
> publicize the importance of the work and to add a social component to
> recognizing it.

I suppose one could tie the concept of volunteering activity with a 
voucher system,
which could then be pooled/collected with to a Guix theme for funding.

For example, it could well be that patch reviewers have a desire to 
valorise a specific activity.
Getting a specific volume of patches signed off could reach 70% of the 
threshold.
The remaining 30% is made up from the 'circles' concerning the languages 
Foo and Bar.

... perhaps there are some anarcho-syndicalists out there who can 
recommend something more nuanced.

Re: Discussion on Guix funding // future

[Steve George]

On 25 Oct, indieterminacy wrote:
> On 2024-10-25 11:37, Ricardo Wurmus wrote:
> > Ekaitz Zarraga <ekaitz@elenq.tech> writes:
> > 
> > > Ricardo, I can agree with you but how do you reward just being there
> > > and doing the dirty job?
> > 
> > For reviews, for example, one could find an arbitrary set of metrics and
> > hand out an award with a monetary component at an annual event.  I'm not
> > speaking of sustainable funding of that work, but of a mechanism to both
> > publicize the importance of the work and to add a social component to
> > recognizing it.
> 
> I suppose one could tie the concept of volunteering activity with a voucher
> system,
> which could then be pooled/collected with to a Guix theme for funding.
> 
> For example, it could well be that patch reviewers have a desire to valorise
> a specific activity.
> Getting a specific volume of patches signed off could reach 70% of the
> threshold.
> The remaining 30% is made up from the 'circles' concerning the languages Foo
> and Bar.
> 
> ... perhaps there are some anarcho-syndicalists out there who can recommend
> something more nuanced.
(...)

There's lots of simple and light-weight methods *IF* there's an organisational structure that can do it. And really, these things don't have to be complex. 

FreeBSD and Clojurist Together are great examples of small teams that provide small grants to support work in areas. So I think there's lots of ways we could explore the territory and experiment a bit.

Steve / Futurile

[0] FreeBSD have a simple process for example - https://freebsdfoundation.org/our-work/grants/
[1] https://www.clojuriststogether.org/projects/

Re: Discussion on Guix funding // future

[indieterminacy]

On 2024-10-25 13:22, Steve George wrote:
> On 25 Oct, indieterminacy wrote:
>> On 2024-10-25 11:37, Ricardo Wurmus wrote:
>> > Ekaitz Zarraga <ekaitz@elenq.tech> writes:
>> >
>> > > Ricardo, I can agree with you but how do you reward just being there
>> > > and doing the dirty job?
>> >
>> > For reviews, for example, one could find an arbitrary set of metrics and
>> > hand out an award with a monetary component at an annual event.  I'm not
>> > speaking of sustainable funding of that work, but of a mechanism to both
>> > publicize the importance of the work and to add a social component to
>> > recognizing it.
>> 
>> I suppose one could tie the concept of volunteering activity with a 
>> voucher
>> system,
>> which could then be pooled/collected with to a Guix theme for funding.
>> 
>> For example, it could well be that patch reviewers have a desire to 
>> valorise
>> a specific activity.
>> Getting a specific volume of patches signed off could reach 70% of the
>> threshold.
>> The remaining 30% is made up from the 'circles' concerning the 
>> languages Foo
>> and Bar.
>> 
>> ... perhaps there are some anarcho-syndicalists out there who can 
>> recommend
>> something more nuanced.
> (...)
> 
> There's lots of simple and light-weight methods *IF* there's an 
> organisational structure that can do it. And really, these things don't 
> have to be complex.
> 
> FreeBSD and Clojurist Together are great examples of small teams that 
> provide small grants to support work in areas. So I think there's lots 
> of ways we could explore the territory and experiment a bit.
> 

They look like good overviews, with even Clojure being accountable 
regarding amounts.

Perhaps the Guix community is going to have to do the most complicated 
thing of all, and write about ourselves and the interesting things that 
we do.

> Steve / Futurile
> 
> [0] FreeBSD have a simple process for example - 
> https://freebsdfoundation.org/our-work/grants/
> [1] https://www.clojuriststogether.org/projects/

Re: Discussion on Guix funding // future

[Efraim Flashner]

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

On Fri, Oct 25, 2024 at 11:37:36AM +0200, Ricardo Wurmus wrote:
> Ekaitz Zarraga <ekaitz@elenq.tech> writes:
> 
> > Ricardo, I can agree with you but how do you reward just being there
> > and doing the dirty job?
> 
> For reviews, for example, one could find an arbitrary set of metrics and
> hand out an award with a monetary component at an annual event.  I'm not
> speaking of sustainable funding of that work, but of a mechanism to both
> publicize the importance of the work and to add a social component to
> recognizing it.

A similar idea would be to do an in-person event (or online) where we
would get together and spend our time working on documentation or trying
to clear out all the pending patches or something else, and then have
the funding go toward travel and lodging and food.

-- 
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 --]

Re: Discussion on Guix funding // future

[Tomas Volf]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Ekaitz Zarraga <ekaitz@elenq.tech> writes:
>
>> Ricardo, I can agree with you but how do you reward just being there
>> and doing the dirty job?
>
> For reviews, for example, one could find an arbitrary set of metrics and
> hand out an award with a monetary component at an annual event.

If being corporate drone taught me anything it is this:

  Any metric that can be objectively measured will be gamed.

Maybe that does not matter here, but I just thought it should be said.

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 --]

Re: Discussion on Guix funding // future

[Steve George]

On 25 Oct, Ricardo Wurmus wrote:
> Steve George <steve@futurile.net> writes:
> 
> > One concern with supporting developers is whether it demotivates them
> > in the long-term: from intrinsic to extrinisic motivation. Basically,
> > the answer is that pay doesn't motivate but it does 'enable' for
> > committed contributors: the Linux foundation survey shows this,
> > there's also various academic pieces on FOSS motivation.
> 
> Paying some people also has the potential of eroding motivation for
> those who are not paid.
(...)

Yes, I've heard this concern both in other FOSS communities and in Guix.

I actually haven't see any evidence that this is the case. Maybe you have?

I've been part of mixed communities where both types of contributors existed. I'm confident it can work, in the right circumstances. And as the Linux Foundation survey points out about 50% of FOSS contribution is 'paid' (through employers or directly).

In a sense we already have a small element of Guix in this already. There are a few people who've been sponsored, or work for institutions where Guix is a dependency. If there were more developers able to sustain their efforts on Guix, I'd personally be happy for them.

> *Employing* people and having their salaries be paid from donations held
> by a foundation is a can of worms that I personally would shy away from
> opening.  An easier and less daunting way to inject monetary rewards
> into volunteer-based activities is to fund awards for certain
> accomplishments.  This would strip all the complications of employment
> and still allow for less desirable work to be rewarded.
(...) 

Understood, I was not suggesting any particular mechanism. 

The're a variety of mechanisms that could be explored, if there was a method for collecting/disbursing funds, and the interest in developing sponsorship for the project.

Steve / Futurile

Re: Discussion on Guix funding // future

[Ricardo Wurmus]

Steve George <steve@futurile.net> writes:

> On 25 Oct, Ricardo Wurmus wrote:
>> Steve George <steve@futurile.net> writes:
>> 
>> > One concern with supporting developers is whether it demotivates them
>> > in the long-term: from intrinsic to extrinisic motivation. Basically,
>> > the answer is that pay doesn't motivate but it does 'enable' for
>> > committed contributors: the Linux foundation survey shows this,
>> > there's also various academic pieces on FOSS motivation.
>> 
>> Paying some people also has the potential of eroding motivation for
>> those who are not paid.
> (...)
>
> Yes, I've heard this concern both in other FOSS communities and in Guix.
>
> I actually haven't see any evidence that this is the case. Maybe you have?

I have not personally observed this in communities like ours, but I'm
not particularly perceptive and more importantly lack experience with
other communities resembling ours, so this isn't saying much.

I only know of studies of traditional "workplace" environments
(for-profit and non-profit), where wage equity and a perception of
fairness in terms of co-worker wages have a much stronger impact on
employee satisfaction and extrinsic motivation than the absolute value
of remuneration.  A stronger preference for perceived fairness with
respect to peer wages has been observed in non-profits where the level
and importance of intrinsic motivation is assumed to be higher than in
for-profit environments.

It is not clear whether these findings are applicable to our loose
organizational structure, but I found it worth mentioning.

> If there were more developers
> able to sustain their efforts on Guix, I'd personally be happy for
> them.

I would, too.

-- 
Ricardo

Re: Discussion on Guix funding // future

[Efraim Flashner]

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

On Fri, Oct 25, 2024 at 11:11:31AM +0200, Ricardo Wurmus wrote:
> Steve George <steve@futurile.net> writes:
> 
> > One concern with supporting developers is whether it demotivates them
> > in the long-term: from intrinsic to extrinisic motivation. Basically,
> > the answer is that pay doesn't motivate but it does 'enable' for
> > committed contributors: the Linux foundation survey shows this,
> > there's also various academic pieces on FOSS motivation.
> 
> Paying some people also has the potential of eroding motivation for
> those who are not paid.
> 
> *Employing* people and having their salaries be paid from donations held
> by a foundation is a can of worms that I personally would shy away from
> opening.  An easier and less daunting way to inject monetary rewards
> into volunteer-based activities is to fund awards for certain
> accomplishments.  This would strip all the complications of employment
> and still allow for less desirable work to be rewarded.

I can no longer find the reference, but Debian experimented with having
someone (or several someones, its been many years now) paid to fix
release-critical bugs before one of their releases. That release went
out about 2 months "later" than other releases, with the assumption
being that few people were willing to do the work for free that someone
was explicitly being paid for.

I'm worried about some sort of "recognition of exemplary work" pay-out,
it suggests that others' work isn't exemplary enough for recognition and
commiseration.

The best I can think of currently is to offer grants for travel to
events (FOSDEM, etc) or to help fund computers and/or office furniture
with the belief that it would make their contributions easier/faster or
more productive. With the idea of paying for things, not paying people
directly for their time.

-- 
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 --]

Re: Discussion on Guix funding // future

[Steve George]

On 25 Oct, Efraim Flashner wrote:
> On Fri, Oct 25, 2024 at 11:11:31AM +0200, Ricardo Wurmus wrote:
> > Steve George <steve@futurile.net> writes:
> > 
> > > One concern with supporting developers is whether it demotivates them
> > > in the long-term: from intrinsic to extrinisic motivation. Basically,
> > > the answer is that pay doesn't motivate but it does 'enable' for
> > > committed contributors: the Linux foundation survey shows this,
> > > there's also various academic pieces on FOSS motivation.
> > 
> > Paying some people also has the potential of eroding motivation for
> > those who are not paid.
> > 
> > *Employing* people and having their salaries be paid from donations held
> > by a foundation is a can of worms that I personally would shy away from
> > opening.  An easier and less daunting way to inject monetary rewards
> > into volunteer-based activities is to fund awards for certain
> > accomplishments.  This would strip all the complications of employment
> > and still allow for less desirable work to be rewarded.
> 
> I can no longer find the reference, but Debian experimented with having
> someone (or several someones, its been many years now) paid to fix
> release-critical bugs before one of their releases. That release went
> out about 2 months "later" than other releases, with the assumption
> being that few people were willing to do the work for free that someone
> was explicitly being paid for.
(...)

Interesting, didn't know about this, I'll see if I can find it.

Generally, I've seen the converation about "sustainability" in projects change in the last few years. The focus that 'Github Sponsors', Linux Foundation and some of the security issues brought to the issue has had an impact. This has made people much more of the need for sustainability and more likely to help out. Projects have responded - as one example, Open Collective has 2533 open source projects that are receiving donations.

> I'm worried about some sort of "recognition of exemplary work" pay-out,
> it suggests that others' work isn't exemplary enough for recognition and
> commiseration.

Yeah agreed, that wouldn't be a great idea. What the surveys say works is work that *volunteers* do not want to do, or cannot do.

> The best I can think of currently is to offer grants for travel to
> events (FOSDEM, etc) or to help fund computers and/or office furniture
> with the belief that it would make their contributions easier/faster or
> more productive. With the idea of paying for things, not paying people
> directly for their time.

Understood and seems to be a common way of supporting contributors. Both FreeBSD and KDE supported contributors computing and travel expenses.

There's other approaches that could be tried, that don't involve creating an "exemplary work" divide. I think we can be open to experimentation. It's OK to tell people we're experimenting and try things out. And, if something doesn't work try something else or decide it doesn't work in our context. If we only do the same things, in the same way, we'll get the same (reproducible?!) results ;-)

Steve / Futurile

[0] https://opencollective.com/opensource

Re: Discussion on Guix funding // future

[Thompson, David]

Hey Ekaitz,

I'm chiming in because I've been working on FOSS full-time for the
past 2 years. Maybe it will be of some use.

On Thu, Oct 24, 2024 at 6:08 PM Ekaitz Zarraga <ekaitz@elenq.tech> wrote:
>
> Hi,
>
> Recently I've been discussing with other members of the Guix community
> about several things we consider we could be improved.
>
> The most important one in my opinion is the funding. I don't know (does
> anybody know?) how Guix is funded, and it worries me.
>
> I've been funded to work on the bootstrapping part of Guix by NlNet
> grants. I've been extremely lucky, and I'm very grateful for it. And I
> tried to spread the money, paying people who deserved it.
>
> Grants are great for specific issues, but we are not going to make Guix
> survive using only that kind of grants.

I agree.  NLnet is wonderful, but it should be considered a
supplemental form of funding for very specific projects. Your
bootstrapping work and Juli Sims' Goblins+Shepherd work are great
examples. In the specific case of NLnet, its future is uncertain due
to the EU potentially defunding it. A sustainable project *must* seek
a diverse set of funding sources.

> First of all, these grants don't pay much, and they are just for a year
> or so. Many of us have the technical skills to get a job that pays way
> more than a grant and is way more stable. This makes doing something
> ethical and good become a punishment, and it's forcing many people to
> choose. Most of the people don't have the privilege to choose.

Very true. The amount that NLnet pays and the structure of those
payments means it is not an option for me as I need stable full-time
employment.

> Second, grants work kind of well for specific tasks, but what happens
> with the structural work? Is anybody actually getting paid for it?
>
> Finally, grants push individuals to try to do things, but don't
> encourage collective action (also the amounts are not high enough for
> collective action). That's not necessarily bad, but those individual
> projects also drain energy from those who are structural to Guix.
> Patches have to be reviewed, and commits need to be merged.

We have not found these "side grants", if you will, draining at
Spritely. Yes, there is review work, but it has been very manageable
and it's a great way to make progress on specific objectives that the
full-time staff cannot focus on themselves. We find interested
partners and pitch all sorts of things to NLnet and see what sticks.

> On a side note, I think we are missing reviewers, maintainers and
> commiters, and I think that view is shared in the community. Let's use
> my case as an example: I raised my hand to become a commiter, and I
> don't know how that was lost in the mailboxes and nothing happened. At
> this moment, I don't care anymore: when I need to make a commit, I know
> there's people that trust me and I just ping them and they do it for me.
> Should I bother people try to get commit access again? My life is very
> comfortable as is... Some questions come again to my mind: Am I really
> ready for the challenge? Am I going to be a good commiter? Is it fair to
> continue like I am right now?

I'd like to use this opportunity to say that the Guix project needs to
stop relying upon email for *everything*. Whom amongst us doesn't have
an overflowing inbox where they lose track of things? The email-based
patch review workflow is particularly terrible. Newcomers by-and-large
*do not* want to figure out how to send a patch over email and the
review process is extremely clunky compared to literally any Git forge
with a pull request feature. And I dare say it's inconvenient for
experienced Guix contributors, too. It drives me bonkers. The mumi
interface to debbugs makes things better, but Guix desperately needs
to leave debbugs and Savannah behind for a forge from this millenium.

> This issue and some others could be fixed with money. Simple, huh?

Piece of cake! (Fundraising is a full-time job.)

> I think we should try to invest more on the people, and that probably
> means paying them for the work they do. At least to some, so they can
> invest more time and care in others.
>
> This we can't do with grants with the NlNet flavor. We need other kind
> of approach.
>
> Sovereign Tech Fund has a very interesting model for maintainers, but
> still lacks the ability to invest on people freely.

Is the Guix Foundation (https://foundation.guix.info/) the official
non-profit for Guix? In addition to finding grants and large donors...
is there an easy way for Guix to collect donations from individual
supporters? The Guix Foundation website says they accept wire transfer
and in-person donation at events. That's cool but there needs to be a
donate button on the Guix website that makes it very easy to donate
with a credit card.

> Many people has been thanklessly working for this project, and some will
> continue to anyway, but not having a proper funding model is probably
> keeping us in an uncomfortable situation. The lack of people is pushing
> away new people, and we are in a vicious circle where I think people
> that are less stubborn than me just go spend time on other projects.

I heard some speculation that the number of new contributors is on the
decline? Is this true? I think this partly a funding/governance issue
and partly a tools issue, as mentioned above. It is simply *too
difficult* to submit a patch to Guix and it is *too annoying* to do
code review through email.

> We have had cases of people giving too much for the project for too
> long. I don't think we acknowledge that enough, and probably we should.
> We should take care of our people.
>
>
> I think free software projects use to be precarious and we are too used
> to that. However, I think we should try to break with that image, and
> try to push for funding collectively, so we can cover structural costs:
> people and machines.

💯

> I think I'm just somehow sharing my will to help, and also trying to
> encourage some conversation about the funding and how we could do
> better. If anyone has ideas, please share.

The biggest questions for me are: Who makes decisions right now? Who
is handling money? What's the overlap? I know there's a desire for
collective decision making, which is great, but *right now* I think a
smaller group of core people (Ludovic + some others) needs to put a
structure in place because it feels like nothing will happen
otherwise. A little bit of benevolent dictatorish action could really
get the ball rolling here.

For example, I periodically express that Guix should break from the
GNU FSDG and create its own guidelines. Each time I do, I'm informed
that there's no structure in place to make such a decision so nothing
changes. When the project started, Ludovic made a commitment to follow
those guidelines in order to be approved as a free distro by GNU.
Times have certainly changed, to say the least, but now that the
project is bigger it can't adapt accordingly. Ludovic recently said
the next step is to get an RFC process in place. Sure... who makes the
call on that?

> On a second (and last) side note, I also discussed with some members of
> the community about the status of Guile. I may send separate email for
> that, but it would be great if we could use some of the energy we have
> to give Guile some love. We are too Guile-dependent to just let it rot.

Definitely best for another thread, but I'll just say: I don't think
Guile has been left to rot, but things have been moving too slowly and
Andy/Ludovic are spread too thin. The Guile 3.0.10 release happened
because Spritely paid for it in the form of Andy's contractor hours so
he'd have the time to focus on it. I have told both Andy and Ludovic
that I think Guile could use at least 1 additional maintainer that is
focused on, ahem, "developer experience". Keeping up with the patch
queue, improving documentation, ease of use, etc. I'll save further
comments for a guile-devel thread, should you make one. :)

Thanks for getting the conversation started!

- Dave

Re: Discussion on Guix funding // future

[Christopher Howard]

A few thoughts, as a humble but enthusiastic guix user. I'll try to be brief:

- Having a full-time job already, I don't mind making some free contributions (patches, troubleshooting) for Guix, even if somebody else is getting paid to do it.
- I like that idea of donation money being spent to contract people to do bug killing, package maintenance, or to work on specific development projects.
- For me, it is critical that Guix remain a purist free-software project, in the way that the FSF and the GNU project promote this.
- I wonder if existing FSF systems or tooling, for their campaigns work, could be of benefit to Guix. FSF has an energetic system for campaigning for donations that seems to work pretty well for them.
- Personally, I like doing development over e-mail and debbugs, due to how this integrates well with Emacs functionality. It does not appeal to me to have to log in to some heavyweight forge Web site, through a Web browser I despise, to have to participate. I would be interested in other APIs and tools if I can utilize them all through just Emacs.

-- 
Christopher Howard

Re: Discussion on Guix funding // future

[Steve George]

Hi Christopher,

Thanks adding your thoughts, we're all trying to be "humble and enthusiastic" for Guix here!

On 25 Oct, Christopher Howard wrote:
> A few thoughts, as a humble but enthusiastic guix user. I'll try to be brief:
> 
> - Having a full-time job already, I don't mind making some free contributions (patches, troubleshooting) for Guix, even if somebody else is getting paid to do it.
> - I like that idea of donation money being spent to contract people to do bug killing, package maintenance, or to work on specific development projects.

Thanks, that's a useful to have input from our users and advocates on this topic. 

> - For me, it is critical that Guix remain a purist free-software project, in the way that the FSF and the GNU project promote this.
>
> - I wonder if existing FSF systems or tooling, for their campaigns work, could be of benefit to Guix. FSF has an energetic system for campaigning for donations that seems to work pretty well for them.
> - Personally, I like doing development over e-mail and debbugs, due to how this integrates well with Emacs functionality. It does not appeal to me to have to log in to some heavyweight forge Web site, through a Web browser I despise, to have to participate. I would be interested in other APIs and tools if I can utilize them all through just Emacs.
 
If you're interested in this topic there's quite a few different discussions in the email archive, but it's never really achieved a conclusion. There are many contributors who enjoy the current process, so I don't think anyone's proposing removing that. It's about whether the project could 'add' a forge-pr process - so it's an 'Email *and* <insert something>'. This is just background info as it's not the main aim of this thread.

Steve / Futurile

Re: Discussion on Guix funding // future

[Ekaitz Zarraga]

Hi,

We mostly agree with everything so let me focus on the points I were I'd 
like to add more.

Thanks for adding your thoughts, they are really valuable.

On 2024-10-25 14:58, Thompson, David wrote:

> I'd like to use this opportunity to say that the Guix project needs to
> stop relying upon email for *everything*. Whom amongst us doesn't have
> an overflowing inbox where they lose track of things? The email-based
> patch review workflow is particularly terrible. Newcomers by-and-large
> *do not* want to figure out how to send a patch over email and the
> review process is extremely clunky compared to literally any Git forge
> with a pull request feature. And I dare say it's inconvenient for
> experienced Guix contributors, too. It drives me bonkers. The mumi
> interface to debbugs makes things better, but Guix desperately needs
> to leave debbugs and Savannah behind for a forge from this millenium.

I don't think this is the most important part of the problem, but it's 
really hard to measure.

I think the level of technical proficiency a project like Guix demands 
is high enough to ensure that people who take part on it are able to use 
the email for their goals. It is weird for them, but I think that's 
something they can get over. (we could also discuss about English being 
a problem for most of the world, and here I am, talking in my third 
language)

In most cases I saw, just some help via IRC or email makes people send 
their first patch and feel really accomplished. (This mentoring needs 
people and time to invest)

The main problem I think comes later, when the contributor made all the 
effort to send the email and then no one answers back. If the first 
effort didn't kill the process, the lack of response murders any 
possible future contribution.


I don't want to focus the conversation on this part, the forge vs email 
(maybe there's a way to support both). What we should discuss is the 
fact that is topic is really hard to discuss or make it to something we 
can apply. Things take too much time because, in practice, I don't think 
we have a governance model.

> Is the Guix Foundation (https://foundation.guix.info/) the official
> non-profit for Guix? In addition to finding grants and large donors...
> is there an easy way for Guix to collect donations from individual
> supporters? The Guix Foundation website says they accept wire transfer
> and in-person donation at events. That's cool but there needs to be a
> donate button on the Guix website that makes it very easy to donate
> with a credit card.

A big part of this email is to try to be more clear about this. I think 
Guix Foundation is too separate from Guix, or the relation is not clear. 
How does the FSF take part in the funding? Is the Guix Foundation 
competing with it somehow or they collaborate or...?

It should be easier to access and donate to from Guix's own website.

Maybe also to accept large donations from the companies or organizations 
that need Guix to work well. I'm sure there has to be some.

> I heard some speculation that the number of new contributors is on the
> decline? Is this true? I think this partly a funding/governance issue
> and partly a tools issue, as mentioned above. It is simply *too
> difficult* to submit a patch to Guix and it is *too annoying* to do
> code review through email.

I think solving the governance issue would enable further action later.

> The biggest questions for me are: Who makes decisions right now? Who
> is handling money? What's the overlap? I know there's a desire for
> collective decision making, which is great, but *right now* I think a
> smaller group of core people (Ludovic + some others) needs to put a
> structure in place because it feels like nothing will happen
> otherwise. A little bit of benevolent dictatorish action could really
> get the ball rolling here.

Exactly. It's a really tricky situation. I think we all look to Ludovic 
when something needs to happen. And I don't think he (hi!) needs to feel 
that kind of pressure.


> Ludovic recently said
> the next step is to get an RFC process in place. Sure... who makes the
> call on that?

I think Steve is working on it on top of what Simon did, and I'm happy 
to collaborate on that.

> Definitely best for another thread, but I'll just say: I don't think
> Guile has been left to rot, but things have been moving too slowly and
> Andy/Ludovic are spread too thin. The Guile 3.0.10 release happened
> because Spritely paid for it in the form of Andy's contractor hours so
> he'd have the time to focus on it. I have told both Andy and Ludovic
> that I think Guile could use at least 1 additional maintainer that is
> focused on, ahem, "developer experience". Keeping up with the patch
> queue, improving documentation, ease of use, etc. I'll save further
> comments for a guile-devel thread, should you make one. :)

I will, but I'll send it with guix-devel included, because I think that 
as connected as both are, we should blur the line totally and take more 
part on Guile.

Your thoughts here David are a little bit biased to your position, where 
you have some of Andy's attention (you paid for it, this is also 
relevant to the topic of the email). Mine are biased to the other 
direction: in the last 3 years I had a little attention (or none) from 
Guile's side.

I ported lightening (guile's JIT, a project that is managed by Andy, 
separately) to RISC-V but I have trouble fixing a segfault it has. I 
pass all the tests but in the last 3 years I had no help with that 
segfault, and I didn't see any effort to review my changes. I'm sure 
with a little bit of help I we could make it work, as all the boring 
part is done. But here we are, still, years later.

I'm not blaming people, but this is very discouraging.

I'll open the thread. Let's see if with help we can do guile thrive as 
it deserves.

> Thanks for getting the conversation started!

Thank you for your thoughts.

Re: Discussion on Guix funding // future

[Attila Lendvai]

> > The biggest questions for me are: Who makes decisions right now? Who
> > is handling money? What's the overlap? I know there's a desire for
> > collective decision making, which is great, but right now I think a
> > smaller group of core people (Ludovic + some others) needs to put a
> > structure in place because it feels like nothing will happen
> > otherwise. A little bit of benevolent dictatorish action could really
> > get the ball rolling here.
> 
> 
> Exactly. It's a really tricky situation. I think we all look to Ludovic
> when something needs to happen. And I don't think he (hi!) needs to feel
> that kind of pressure.


this is also a chicken-egg issue: until some authority is delegated, the center will remain a bottleneck.

and this applies to a lot of things guix: from decision making to the monorepo (which is holding an ever-growing flow of boring package update commits that is crowding out guix infrastructure changes). or the single debbugs instance washing together 20.000 pending package updates, and 15 interesting discussions on how to improve guix itself (figurative numbers).

meanwhile there seems to be a growing inflow of enthusiastic and inspired users who are bombarding the castle. this shows up in various forms, like the growing patch review backlog, or the growing frustration expressed on the mailing list.

the bandwidth issue of the center won't be resolved without a way to delegate compartmentalized authority to subteams (e.g. a python channel in a separate git repo, and the gnome channel deciding which python channel commit to depend on). and god forbid, maybe even allow them to chose their preferred git forge!

i'd keep the guix core to the minimum that can bootstrap a console-only system, and then let a million channels bloom. some could be maintained or just blessed by the core team, some may merely be listed, while others ignored.

unfortunately the infrastructure would need to evolve to accommodate this (e.g. eliminate the dual registry of packages; consider promoting package definitions from being a general toplevel form in a scheme file to something a little more specific and a bit more constrained; IOW consider reifying the package database, introduce package namespaces, syntax for package lookup, etc. maybe reuse the guile module system for this, but in a less permissive way than it is currently used). this obviously needs to be well thought out, but i don't even see it considered, let alone mentioned as desirable.

a tangential to illustrate the above:

at this point i was wondering where could be the list of ideas/vision for the future of guix, to see whether such a thing was ever considered. then i found the TODO file. then i saw that it's very outdated and rather untidy. then i had an impulse to add some guix-devel archive links to the distributed substitute discussions, and also to delete or mark some entires DONE that have long been implemented. then i considered the effort it would take to send a patch, and the fact that i already have a lot of my effort bitrotting away in the issue tracker, and why would this one not also fall through the cracks... and then i decided not to. and that untidy TODO file will remain there to be one of the inputs that newcomers will use to form an impression, which will then inform their decisions about e.g. whether to contribute.

if it were a wiki page, or a file in a separate guix-doc repo, etc, then giving me write access would not be the same decision as giving me commit access to the guix repo.


to sum it up: human cooperation cannot grow beyond a certain size without an organizational structure that can accommodate the newcomers. my impression is that guix has reached such a threshold. and while a new stucture is not formed, potential contributors are constantly frustrated away. and it's very much not obvious to judge how much value is lost that way.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“One of the evils of paper money is that it turns the whole country into stock jobbers. The precariousness of its value and the uncertainty of its fate continually operate, night and day, to produce this destructive effect. Having no real value in itself it depends for support upon accident, caprice, and party; and as it is the interest of some to depreciate and of others to raise its value, there is a continual invention going on that destroys the morals of the country.”
	— Thomas Paine (1737–1809), 'Complete Writings of Thomas Paine' (1786)

Re: Discussion on Guix funding // future

[Greg Hogan]

On Fri, Oct 25, 2024 at 7:25 PM Attila Lendvai <attila@lendvai.name> wrote:

[...]

> this is also a chicken-egg issue: until some authority is delegated, the center will remain a bottleneck.

[...]

> ... then i considered the effort it would take to send a patch, and the fact that i already have a lot of my effort bitrotting away in the issue tracker, and why would this one not also fall through the cracks ...

In Apache projects new committers are nominated, voted on, and invited
by the Project Management Committee rather than waiting on individuals
to step forward as in Guix. Given the current committer capacity,
perhaps Guix would be better served by having both processes.

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

[Christine Lemmer-Webber]

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


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

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

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


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

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

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

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

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


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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

 - Christine

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

[Ekaitz Zarraga]

Hi Christine,

I think you very well said here.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


What do you think?

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

[Ludovic Courtès]

Hi!

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

Ekaitz Zarraga <ekaitz@elenq.tech> skribis:

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

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

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

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

It is one way to do it, yes.

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

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

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

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

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

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

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

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

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

Only if they participate in code review.

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

We should.  I think maintainers started doing it?

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

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

Ludo’.

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

[Ekaitz Zarraga]

So,

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

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

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

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

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

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

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

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

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

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

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

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

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

I like that.

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

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

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

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

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

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

Maybe we should do it more.

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

Yes.

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

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

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

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

> 
> Ludo’.

In the end Ludovic, if I may:

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

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

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

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

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

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

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

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

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

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

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

[Suhail Singh]

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

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

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

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

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

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

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

-- 
Suhail

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

[Ludovic Courtès]

Hi,

Suhail Singh <suhailsingh247@gmail.com> skribis:

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

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

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

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

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

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

Ludo’.

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

[Suhail Singh]

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

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

Gets into what?

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

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

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

> how do we transition?

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

> what API compatibility guarantees do we make?

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

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

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

-- 
Suhail

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

[indieterminacy]

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

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

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

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

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

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


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

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

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


JM

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

[Ludovic Courtès]

Hello Christine!

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

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

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

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


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


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

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

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

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

Ludo’.

Re: Discussion on Guix funding // future

[Ludovic Courtès]

Hello,

Ekaitz Zarraga <ekaitz@elenq.tech> skribis:

> Second, grants work kind of well for specific tasks, but what happens
> with the structural work? Is anybody actually getting paid for it?

Should the project have the ability to pay people, I think it should
first and foremost reward thankless tasks—from system administration to
boring but crucial packaging work.

> Finally, grants push individuals to try to do things, but don't
> encourage collective action (also the amounts are not high enough for
> collective action). That's not necessarily bad, but those individual
> projects also drain energy from those who are structural to
> Guix. Patches have to be reviewed, and commits need to be merged.

I once proposed having a space where those applying for NLnet grants for
a Guix-related project could discuss and coordinate, and to arrange so
that “the project” knows who’s applying for what.  That would still be
individual grants, but it would be a step towards collective action, as
you write.

Now, the problem is that we cannot force applicants to follow that path;
they might have good reasons to not discuss openly about their plans or
event to avoid the extra burden of coordinating with others.

> I think free software projects use to be precarious and we are too
> used to that. However, I think we should try to break with that image,
> and try to push for funding collectively, so we can cover structural
> costs: people and machines.

On one hand, I like the good vibes that come from collective funding:
see Spritely or the Reproducible Builds project, for instance.  OTOH, I
sympathize with those concerned with the negative effects this could
have on the many excluded from said funding; a further concern is the
administrative burden with actually employing people.

Besides, note that it is becoming easier to work on Guix as part of
one’s paid job as Guix becomes more useful (quite a few people at the
Guix Days, myself included, were on a “business trip”!).  That’s another
option to keep in mind, even though it’s again focusing on individuals.

What we do need and can have is a strong non-profit to cover costs like
machines, events, internships.  That’s the goal of Guix Foundation and
it’s been helping a lot in these areas, but it desperately needs love
and energy.

Thanks,
Ludo’.

Re: Discussion on Guix funding // future

[Noé Lopez via Development of GNU Guix and the GNU System distribution.]

Hey everyone,

As a relatively new user and contributor I thought I should share my
point of view.

When I started using Guix, the documentation was the greatest thing
ever, few projects have a manual like this that can help you in so many
situations.  Of course the lack of wifi drivers was an issue, and I
wished it had a mention that solutions exist, even if not endorsing
them.

This, in my opinion, should be improved as it turns Guix into a hostile
project towards users that *need* these non-free drivers to make it
work, as bad as it is.  What I mean by hostile is you will see on the
internet people saying don’t even dare trying to talk about it on the
list.  Or the nonguix project having to mention to not ask for help
about itself.  Trying to silence people in this way is a real shame and
we can’t just act like non-free drivers don’t exist and people don’t
need them.

This leads me to my next point, which is there’s no reference to
external resources from the guix websites/manual.  Things like the
toys.whereis channel webring, system crafters, the lemmy community, the
many channels like rde, guix-science, or even nonguix.  These are
important parts of the ecosystem and should not be left out as they are,
we should acknowledge them and reference them.

Furthermore, on the topic of mail, I totally agree with David
Thompson. Mail is cool, I get it, but another way to contribute like
pull requests on a forgejo/gitlab mirror would be much, much easier.
Mail might seem like the default easy thing for many of you, but for
anyone that’s a new contributor needing to configure send-mail and
making sure that your email was received and that you receive the
replies, not seeing it appear on the issues list for a little while is
quite inconvenient compared to using git, pushing on your fork and
continuing with a web interface from there.

Overall, Guix is a great project but it should take care of opening
itself to keep up with the times.

– Noé

Re: Discussion on Guix funding // future

[Greg Hogan]

On Fri, Oct 25, 2024 at 10:21 AM Noé Lopez via Development of GNU Guix
and the GNU System distribution. <guix-devel@gnu.org> wrote:
>
> Furthermore, on the topic of mail, I totally agree with David
> Thompson. Mail is cool, I get it, but another way to contribute like
> pull requests on a forgejo/gitlab mirror would be much, much easier.
> Mail might seem like the default easy thing for many of you, but for
> anyone that’s a new contributor needing to configure send-mail and
> making sure that your email was received and that you receive the
> replies, not seeing it appear on the issues list for a little while is
> quite inconvenient compared to using git, pushing on your fork and
> continuing with a web interface from there.

Can the suggested, user-friendly alternatives to email integrate into
the build cluster, QA, and teams-branches workflow?

WIth 29,000+ packages the nature of the project has changed from
adding new software to managing updates (what fraction of new packages
are rust or python dependencies?).

What we have works well but Guix needs even more tooling and
automation! We have importers and updaters. There exist innumerable
free software updates, of which Guix only applies a pseudorandom few.
Much of this could be automated using the existing tooling for
updating package versions and building dependents. We can automate
multi-versioning ('pinning') libraries for upgrade failures.

Guix should be capable of things like keeping git up-to-date, but this
isn't scaling. #73309 was submitted two weeks ago. #70656, submitted
by a core contributor six months ago, reduces the git dependents from
921 to 136 and appears overlooked. We need more of the latter
submissions in order to better automate the former (#70031 does this
for cmake). As noted recently, "upgrading Numpy and friends" is
challenging. How can that process be improved?

If our goal is "how can I keep package X up-to-date" rather than "can
I update package X", it isn't clear to me that moving to forgejo or
gitlab takea Guix in that direction.

Greg