this post was submitted on 23 Feb 2024
113 points (93.1% liked)

Linux

48333 readers
645 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

We all love FOSS. Lately, many of us have expressed their disarray at hearing stories of maintainers quitting due to a variety of factors. One of these is financial.

While donating to your favorite app developer is something many of you already do, the process can be tedious. We're running all sorts of software on our machines, and keeping an exhaustive list to divide donations to projects is somehow more effort than tinkering with arch btw™.

Furthermore, this tends to ignore library projects. Library maintainers have been all over FOSS-centered media rightly pointing out that their work is largely unnoticed and, you guessed it, undervalued.

What can we do about it? Under a recent Lemmy post, some have expressed support for the following idea:

Create a union of open source maintainers to collect donations and fairly redistribute them to members.

How would this work?

Client-side:

  1. You take some time to list the software you use and want to donate to
  2. You donate whatever amount you want for the whole

Server-side:

  1. Devs register their projects to the union while listing their dependencies
  2. A repartition table is defined by the relevant stakeholders. Models discussed below.
  3. When a user donates, the money is split according to the repartition table

How do we split the money? It could be:

  • Money is split by project. A portion of donations go to maintainers of libraries used by the project.
  • Money is split according to need. Some developers don't need donations because they are on company payroll. Some projects are already well-funded. Some devs are struggling while maintaining widely used libraries (looking at you core-js). Devs log their working time and get paid per hour in proportion of all donations.
  • Any other scheme, as long as it is democratically decided by registered maintainers.

Think of it like a worldwide FOSS worker co-op. You "buy" software from the co-op and it decided what to do with the money.

We "only" need to get maintainers to know about the initiative, get on board and find a way to split the money fairly. I'm sure it will be easy to agree on a split, since any split of existing money will be more satisfactory than splitting non-existent money.

What are your thoughts on this? Would you as a maintainer register? Would you donate as a user? Would you join a collective effort to build this project? Let's discuss this proposition together and find a way to solve that problem so that FOSS can keep thriving!

you are viewing a single comment's thread
view the rest of the comments
[–] makeasnek@lemmy.ml 2 points 9 months ago* (last edited 9 months ago) (1 children)

I think you can still have users decide which projects get funding and have the system/organization/smart contract/etc automatically distribute funds to the libraries those projects depend on. 80% to the project, 20% to the libraries, etc.

If we let devs decide which projects get funding, they're just going to always pick their own project. Since that doesn't align with what users want, users won't want to donate. If you want users to donate, you need to let them have some say in what their projects their donations go to.

[–] GroundPlane@iusearchlinux.fyi 3 points 9 months ago

Ideally you would let picky users override every setting and provide fair enough defaults. That includes library donation cascading etc. At the end of the day it seems the core part of the project should be providing fair enough defaults