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!

  • makeasnek
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    10 months ago

    I would be interested in this as a user and as a dev for OSS projects. I currently donate to a few projects via OpenCollective, Github sponsors, etc. A few options:

    • Users vote on how the money is spent, perhaps in proportion to how much they have donated over time. I think this is the simplest model that prevents self-dealing and accurately transmits user interest. You could use a quadratic funding model to better represent user interest instead of just giving the most vote weight to the users with the most money. On the other hand, assigning vote weight based on donations over time incentivizes users to donate more and keep donating (stopping a recurring donation could result in loss of vote weight and help redistribute vote weight as users become less active). You could also do a hybrid model: 50% is assigned according to vote weight based on total donations, 50% is assigned based on quadratic funding.
    • Developers vote on how the money is spent. I don’t know how to allocate vote weight here. Devs should also submit a list of downstream libraries which would receive donations. (or is it upstream?).
    • User and developers both vote on how it is spent. Vote weight could be distributed however, for example, 50% to users 50% to devs.

    This kind of a system would be very possible to implement as a DAO, there are templates out there for making an organization like this. You could use BTC or ETH, both support DAOs. The benefit there is that since no single entity holds the money, no single entity has to file taxes and claim that money as income. It also automates the voting process and solves the issue of users having to trust a single person or organization to hold and distribute the funds. Making a DAO on Bitcoin lightning could reduce tx fees to less than a penny per donation.

    You could also incorporate it as a non-profit depending on your jurisdiction. Many organizations like the Linux foundation have pursued this route, look at what things they have tried and what has worked. Also just a link to leave here for your research, I’m not suggesting you use this, I’m just saying it’s relevant interesting thinking in this area: https://blog.obyte.org/kivach-cascading-donations-for-github-repositories-2b175bdbff77

    Other relevant links/research for you: https://github.com/Resolvr-io and https://nostrocket.org/About

    Also research Gitcoin, they have used quadratic funding to fund a number of OSS web3 projects in a similar manner to what you’re proposing. I have participated in a few of their funding rounds as a donor and a recipient. Their interface is a mess but the concept is cool.

    • GroundPlane@iusearchlinux.fyiOP
      link
      fedilink
      arrow-up
      2
      ·
      10 months ago

      The solutions you linked are interesting but ultimately neglect the most important aspect in my opinion: discussion among stakeholders. They also tend to use bitcoin, which has proven it could not gain enough traction to be mainstream yet.

      Taking the core principle of Kivach and making it viable in state-backed currency, using the platforms devs have already set up for payment would be a great leap forward. We need to get something going and build support from a critical mass.

      Why is Kivach not more widely used? We should tackle these questions and try to improve it.

      • makeasnek
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        10 months ago

        The discussion portion wouldn’t happen over BTC, that’s just for funds management and voting. Discussion could happen on a forum, lemmy community, matrix chat, discord hangout, or other space. I suggest BTC because with smart contracts you can automate the voting process among stakeholders and make it so you don’t need to trust any single party to hold onto the money. It solves this exact problem of coordinating financial transactions with multiple people who can’t trust each other. It also solves the “how do we accept donations internationally easily” problem. Bitcoin has a market cap which places it in the top 25 countries by GDP, higher than Sweden. 850 billion dollars. On average, adoption and market cap grows year on on year. It may not be the USD, but it’s already more widely accepted than most national currencies.

        Re: kivach, it’s not more widely used because many people don’t know about it, it’s using a lesser known cryptocurrency as a base, and people reflexively go “eew crypto” even though it’s perfect for solving these kinds of problems. Anytime you have a distributed decision-making process that needs to be international and you don’t want to trust a single party or parties to manage that system, crypto is good at solving that problem. Most people know it for solving that problem in the realm of currency production and decentralizing finance, but it has much broader implications in terms of anywhere you have distributed decision making. Note that kivach doesn’t have any kind of distributed decision making or voting, it’s basically just a smart contract bot that distributes coins based on github dependencies.

        Bringing the state into this just brings us a bunch of problems and no solutions. For one, every state or block of states has different currency, and for every state whose population you want to participate, you have to some how bridge access to that state’s banking system and incorporate it into the system. And you can’t do it in a decentralized way, so you need some legal entity to be formed to handle all this and the staff to do all this. So that’s a nightmare. State-backed currencies can’t easily or cheaply be transmitted electronically across borders, and often, even within the same country. Or you have to use some third-party service like PayPal or Venmo to do this, which is its own set of complications. More nightmare. Plus, hello fees and making microtransactions prohibitively expensive. And that’s just moving funds from A to B, that’s not even getting into managing the voting system and navigating the laws every single country whose currency you use, each of which are going to have their own interpretation of whether or not your voting system is compliant with their legal system and whether or not they agree that funding a project like the Tor project is allowed. You may say you don’t care what Turkeys laws say, but if you want to maintain a bridge to their banking system, you have to. So that’s what incorporating the state and fiat system brings you. Or, you could write a smart contract once and have the administration of this system run automatically forever and be available to anyone in any country automatically. Running an international organization which receives funds, holds funds, votes on how to distribute those funds, distributes those funds is exactly the kind of thing blockchain excels at.

        • GroundPlane@iusearchlinux.fyiOP
          link
          fedilink
          arrow-up
          2
          ·
          10 months ago

          Got you. It is a shame that this part of crypto is not more widely publicized, as it is its most interesting use in my eyes.

          Still think it can’t be the only solution if we want wider reach. To avoid taxes and legal structures, I want to study whether we can interface with projects’ available donation options and automatically split a user donation into several. Skipping the “finding the donation option for each project” problem which can be tediously human-solved for a proof of concept, the issue would be whether the process could be easy for the user while not getting obliterated by transaction fees.

          There is no need to develop a crypto side since I’m sure a way to interface with Kivach could be found if the other fiat currency problems are solved beforehand.

          Thank you for your input, it means a lot.