all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Steve George <steve@futurile.net>
To: Ekaitz Zarraga <ekaitz@elenq.tech>
Cc: "guix-devel\\@gnu.org" <guix-devel@gnu.org>,
	 Simon Tournier <zimon.toutoune@gmail.com>,
	Tanguy Le Carrour <tanguy@bioneland.org>
Subject: Re: Discussion on Guix funding // future
Date: Fri, 25 Oct 2024 09:12:24 +0100	[thread overview]
Message-ID: <2wxdckzlcrj244urhij3j7to2hcvxiwqnb43npgfncfekipqqi@jebt4vhbwwl2> (raw)
In-Reply-To: <6daee7b4-a5d6-4f80-bbfa-995e65e17ae0@elenq.tech>

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/


  reply	other threads:[~2024-10-25  8:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-24 22:08 Discussion on Guix funding // future Ekaitz Zarraga
2024-10-25  8:12 ` Steve George [this message]
2024-10-25  9:11   ` Ricardo Wurmus
2024-10-25  9:16     ` Ekaitz Zarraga
2024-10-25  9:37       ` Ricardo Wurmus
2024-10-25 11:05         ` indieterminacy
2024-10-25 11:22           ` Steve George
2024-10-25 11:51             ` indieterminacy
2024-10-25 12:05         ` Efraim Flashner
2024-10-26 17:16         ` Tomas Volf
2024-10-25 11:06     ` Steve George
2024-10-25 12:13       ` Ricardo Wurmus
2024-10-25 12:18     ` Efraim Flashner
2024-10-25 15:49       ` Steve George
2024-10-25 12:58 ` Thompson, David
2024-10-25 14:31   ` Christopher Howard
2024-10-26  6:57     ` Steve George
2024-10-28 16:47       ` Christopher Howard
2024-10-25 19:13   ` Ekaitz Zarraga
2024-10-25 23:25     ` Attila Lendvai
2024-10-26 12:49       ` Greg Hogan
2024-10-26 13:48   ` Guix (and Guile's) promise, and how to (hopefully) get there Christine Lemmer-Webber
2024-10-26 14:49     ` Ekaitz Zarraga
2024-10-26 20:22       ` Ludovic Courtès
2024-10-27  0:38         ` Ekaitz Zarraga
2024-10-29 23:04           ` Ludovic Courtès
2024-10-28 10:09         ` Andreas Enge
2024-10-28 10:20         ` Andreas Enge
2024-10-26 16:40     ` Suhail Singh
2024-10-26 22:07       ` Ludovic Courtès
2024-10-27  1:33         ` Suhail Singh
2024-10-26 22:28       ` indieterminacy
2024-10-26 21:12     ` Ludovic Courtès
2024-10-28  9:21   ` Discussion on Guix funding // future Andreas Enge
2024-10-26 15:04 ` Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2024-10-25 14:21 Noé Lopez via Development of GNU Guix and the GNU System distribution.
2024-10-25 21:26 ` Greg Hogan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2wxdckzlcrj244urhij3j7to2hcvxiwqnb43npgfncfekipqqi@jebt4vhbwwl2 \
    --to=steve@futurile.net \
    --cc=ekaitz@elenq.tech \
    --cc=guix-devel@gnu.org \
    --cc=tanguy@bioneland.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.