Re: Discussion on Guix funding // future

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

Forge and build automation

[Ludovic Courtès]

Hello!

(“As an online Guix discussion grows longer, the probability of ending
up talking about the email workflow approaches 1.”)

Greg Hogan <code@greghogan.com> skribis:

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

At work, we have integrated Cuirass (guix.bordeaux.inria.fr) with GitLab
(gitlab.inria.fr) for the purposes of testing merge requests for our
channels.  It’s wonderful, really.

As someone who’s often repelled by web interfaces, I have also
experimented with forge.el, an Emacs interface to Git{Hub,Lab}, Forgejo,
and more; it is “promising”.

But…

> 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?).

… that’s the crux of the problem.  What works for our little channels
mentioned above is insufficient for the main ‘guix’ channel.

qa.guix is a very adequate tool.  Should we decide to experiment with
something like Forgejo, we would need to make sure its webhooks can be
understood by qa.guix.

Surely not insurmountable, and worth considering.  We “just” need more
hands to try that out.


Besides, I agree with you Greg that we need more automation, in
particular for package updates.  Nixpkgs has an auto-update bot; we
could just as well have a bot that roughly runs ‘guix refresh’ and
submits patches/merge requests.  I’m sure somebody will end up
scratching this particular itch, it’s such an obvious thing to do.

Thanks,
Ludo’.

PS: It’s a long thread and I do mean to comment on other issues, but
    it’s going to take me a while.  :-)

Re: Forge and build automation

[Suhail Singh]

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

>> 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?).
>
> … that’s the crux of the problem.  What works for our little channels
> mentioned above is insufficient for the main ‘guix’ channel.

Why does the main 'guix' channel have to contain the "entire world"?

> Besides, I agree with you Greg that we need more automation, in
> particular for package updates.  Nixpkgs has an auto-update bot; we
> could just as well have a bot that roughly runs ‘guix refresh’ and
> submits patches/merge requests.  I’m sure somebody will end up
> scratching this particular itch, it’s such an obvious thing to do.

Where would such a bot run?  Do we have an example of a bot that runs in
a similar context?

-- 
Suhail

Re: Forge and build automation

[Ludovic Courtès]

Suhail Singh <suhailsingh247@gmail.com> skribis:

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

[...]

>> Besides, I agree with you Greg that we need more automation, in
>> particular for package updates.  Nixpkgs has an auto-update bot; we
>> could just as well have a bot that roughly runs ‘guix refresh’ and
>> submits patches/merge requests.  I’m sure somebody will end up
>> scratching this particular itch, it’s such an obvious thing to do.
>
> Where would such a bot run?  Do we have an example of a bot that runs in
> a similar context?

Yes, there’s a bot periodically updating the guix-cran and guix-bioc
channels:

  https://hpc.guix.info/channel/guix-cran
  https://hpc.guix.info/channel/guix-bioc

Currently it’s a script running periodically on berlin.guix:

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/services.scm#n1335

Ludo’.

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

[Christopher Howard]

Steve George <steve@futurile.net> writes:

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

Okay, thanks. I'm open minded to that, so long as I don't in the end get forced into using a Web interface. I could talk for a good while regarding what I hate about the modern Web and Web browsers. I of course don't have cred like the real Emacs developers around here. But I find that working with debbugs, usings gnus alongside debbugs-guix.el and debbugs-gnu.el, is satisfactory and convenient. Applying a patch was very easy the last time I did it from a gnus ephemeral buffer.

E-mail seems, despite its flaws, to end up being a better option than everything that tries to replace it. But I'm open to other APIs if there ends up being a nice *.el interface available.

-- 
Christopher Howard

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.

Re: Discussion on Guix funding // future

[Andreas Enge]

Hello,

Am Fri, Oct 25, 2024 at 08:58:58AM -0400 schrieb Thompson, David:
> Is the Guix Foundation (https://foundation.guix.info/) the official
> non-profit for Guix?

I would say so, insofar as a volunteer project can have an "official"
non-profit (there is no office to decide officiality). The idea when
creating it was to have a European counterpart to handle money transfers
within Europe more easily, leaving the US part to the FSF (as mentioned
by Andy, tax deductability is a nice incentive and depends on local
jurisdiction; for instance in France, only donations to European
non-profits can be deduced).

In practice, our money still is with the FSF, following a donation
campaign some years ago. There is a committee of three people that can
decide how this money is spent. Usually Guix Foundation advances expenses
(hosting, Guix Days organisation), then sends the receipts to the FSF
and gets reimbursed.

We could run our own donation campaign, but have not needed it yet
(the limiting factor of what we can do right now seems to be rather
humanpower than money).

Setting up credit card payments has been discussed at our yearly
assembly and will probably come soon™. We thought about the (nominal)
yearly membership fee, but this could easily be extended to donations.

Andreas

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’.