Why is there never any money in FOSS (where it's needed)?

Continuing the discussion of the Technology Invesment Funds:
While the convenience that such funds provide is beneficial to acquire more donations, but the funds cannot pass on 100% of the donations to the projects and neither should they.

Operating such a fund requires at least the following costs:

  1. Researching and validating project dependencies. Projects do not necessarily disclose all of their dependencies, especially if they compete with their dependencies for funding, thus the dependencies have to be regularly and independently verified.
  2. Funding inter-project infrastructure: support hotlines, conferences, support groups - in short: Guild work.
  3. Usual operational costs of a digital business: servers, domains, administration

If these “funds” should operate as investment funds, this would be deducted as a percentage fee from any investment (i.e. 5% of all investments are used for fund operation).

Alternatively investors could be compelled to pay a more regular fee instead of the percentage fee, though this is a detailed discussion for which this is not the correct place.

The questions we should elaborate more here are: Who should initiate a TIF/TIP?

Should it be developers, a reputable foundation? How should the start capital for TIP/TIF be raised?

See: socialcoding

Why is there never any money in FOSS (where it's needed)?

I’m not considering this point an obstacle because we should assume that any project that is critical and in a desperate state is willing to be funded. Even when the maintainer does not want to receive compensation for their time, having the ability to hire a trusted contributor or maintainer to take over when the volunteer is exhausted, burned-out or wants to give up their hobby. The willingness to receive funds for your own work does not mean you don’t need money for other purposes. As the XZ affair has shown, it is increasingly difficult to impossible for a maintainer to find a trusted maintainer to take over from them and if the previous maintainer has to

Read More
Why is there never any money in FOSS (where it's needed)?

According to the 2020 FOSS Contributor Survey conducted by the Linux Foundation, 48.7% of respondents are paid for work on free and open-source software[1].

And yet there a critical free and open-source software projects that are chronically underfunded and that have no realistic ability to monetize.

Difficulty of financially supporting “FOSS”

Finding projects to support

It is surprisingly difficult to financially support “FOSS”. You can of course support some projects that you know you use or that you know you like. But this will always just be a small fraction of the projects you actually use.

A company or an individual has only one option when trying to support FOSS: they have to research what projects they actually use. They can’t fund all the projects they use, because even just using a single FOSS project (e.g. Mastodon, the Linux kernel) entails depending on hundreds, if not thousands of independent projects. Only the wealthiest donors can afford to split their donation into a thousand pieces and still end up with amounts that

Read More
Weekly Guild Report for Sprint #2

2023-09-18: Sprint Midpoint

What have we accomplished?


  • @CSDUMMI Added fetching of ActivityPub Actors PR #5.
  • @mjh has created a PR #4 with fixes for database creation and the media carousel.
  • @mjh has made upstream improvements to LibRate security.

What’s Next?

  • PR #4 & #5 needs review and merging as soon as possible.

See: socialcoding

Read More
A sustainable Guild: A discussion of Finance, Mental Health, Democracy and Institutionalization

With the conclusion of the first Guild Alpha sprint and beginning of the second, a new way of developing free software is starting to take shape.

We are trying to innovate on the basic structure of free software development defined by often uncoordinated work of individuals with a collective and democratic approach.

Every sprint a group of people comes together to vote on a project to work. Goals are set, development takes place for eight to ten weeks and then the sprint ends and results are either proposed to an upstream project or handed over to a maintainer to continue development in a smaller team.

All work is voluntary. More detail about the structure and progress can be found in the links above and on the website.

We are still iterating on the format of the Guild itself.

The following is my personal opinion on the future of the Guild and not a position of the Guild or the Editors of the Guild. I hope for a constructive discussion on the

Read More
Weekly Guild Report for Sprint #2

2023-09-13: Announcement

Today the sprint officially starts. The announcement has been published on our brand new website and we, the editors, are looking forward to new members, new proposals and a new project.

Changes from last sprint:

More editors

Thanks to our new addition, @dannymate, there are now three editors. The editors can thus take on more organizational tasks this sprint than last.

Promise System

Every week we will now ask members to tell the editors, what tasks they want to try to complete in the week and check in with them at the end of the week to see how they have been progressing.

Weekly reports on Wednesday

The weekly reports will be published on Wednesday for this sprint. A week for guild purposes is now from Wednesday to Tuesday. This is so we don’t have a deadline every Monday and we can all enjoy our weekends a little more.

Always open

As there are now three editors,

Read More
Weekly Guild Reports

September 13. 2023 - Start of the second sprint

Today we have announced the Second Guild Alpha Sprint.

The last two weeks were spent in the inter-sprint. We have setup a website, a kbin magazine and rewritten the forms for starting a guild.

This sprint has been concluded with the proposal of the PR with our changes to bookwyrm. Our concluding thoughts on this sprint can be read here.

The second sprint is now looking for members and open for project proposals. Read about everything on our website.

We will continue posting our weekly report of the sceond sprint here

See: socialcoding

Read More
Weekly Guild Reports

August 14. 2023 -

What have we accomplished?

  • @dannymate fixed some issues casued by the merger for Celery tasks #27 and re-added Hugh’s fix for #25.
  • hugh fixed numerous bugs with #28 and is currently being tested for merge.

What’s next?

  • We’ll have a check-up meeting this week to conclude this sprint and discuss the organization of the next.
  • @dannymate and hugh work on making #28 stable and tested
  • Research the Django File Storage and FileField API and answer the questions:
    1. How can files be created using FileFields?
    2. Where can the FileField be stored?
    3. How can old archives be removed to clean-up disk space?
    4. How to generate a tar archive file using tarfile and a zip archive file using zipfile.
  • Implement self-contained archive as a tar or zip file

See: socialcoding

Read More
Weekly Guild Reports

August 7. 2023 - Mergers and Tasks

What have we done?

  • @CSDUMMI added links to exported files in #26
  • All export and import logic has been moved to celery tasks and merged by @dannymate and @CSDUMMI.

What’s next?

  • The current state of the export-import branch needs to be tested on the staging server.
  • Documentation for the export-import branch (in the form of docstrings) should be added and reviewed
  • All media files fetched from the origin server during imports should be added to a tar archive
  • A pull request needs to be created to bookwyrm with our changes in export-import. We should reach out to bookwyrm maintainers and create a draft of the PR text.

See: socialcoding

Read More
Weekly Guild Reports

July 31. 2023 - Celery Tasks

What have we done?

  • @dannymate created the final two PRs for moving the Import/Export process to Celery #24 #26.
  • hugh fixed an export bug #25

What’s next?

  • Add link to created archive file after export job has completed to export page
  • Add messages about successful import job on import page
  • Complete the migration of import/export to celery tasks
  • Start work on self-contained tar archive

See: socialcoding

Read More
Weekly Guild Reports

July 10. 2023 - Incremental advancements

What did we accomplish?

  • @dannymate makes progress on the Export PoC and made SubTasks generic #17
  • Deployment of Hugh’s #15 to facilitate further code reviews. There were group discussions around the export download mechanism, tarfile data inclusion and unit testing.

Our goals

  • This week, we should merge #15. There are a few conditions that need to meet for that:
    1. All code reviews need to resolved
    2. Several manual tests must have been completed, including:
      • A test that a no-op archive (exporting & importing into the same account) does not result in any change to the account (and does not throw an error)
      • A test that a full archive (export from an account with books, readthroughs, saved lists, follows, blocks, comments and reviews) to an empty account, recreates all of the archive (without error)
  • #17 should be rebased on #15 and deployed to test instances.
  • We should start developing unit tests for the behavior implemented

    Read More
Weekly Guild Reports

July 3. 2023 - Successful progress on tasks, extending archives and TAR archives

What did we accomplish?

What’s next?

Currently we are progressing quite well. We should aim to complete #15 and #17.

We’ll have to decide on how to create the archive. Currently there appear to be three options:

  1. Create it in-memory (currently the case)
  2. Store it on disk
  3. Stream the archive (creating it on-demand and archiving most used parts.

See #16 for more.

While we can experiment with different ways of generating the archive

Read More
Weekly Guild Reports

June 12. 2023 - Code Review

This week we began reviewing the bookwyrm source code. The results of this review is being collected on our wiki in the form of an FAQ. Thanks Valery Briz, @tomat0 and @Ryuno-Ki for working on this.

@dannymate has created two ansible playbooks to setup an environment and a bookwyrm instance. These should make it easier to create test instances.

We also created and discussed several issues to organize our work.

What should be the goal of our work?

This has by now crystallized roughly three possible options for us:

  1. We can base our work on @hugh’s. This means we’ll use plain JSON in the archive, add the media in the form of a tar or zip to the archive, and create an activity
  2. We can follow Mastodon’s approach and use ActivityPub objects (actor, inbox, outbox, likes, followers, following) in the archive, together with media attachements. This

    Read More
Weekly Guild Reports

June 5. 2023 - Bookwyrm Proposal Accepted

Last week we gathered three proposals and held a vote between them.

The Bookwyrm Migration proposal has won the vote by a 4/5 majority on the first preference.

The form’s results have been published here.

Because this project will be contributing to the Bookwyrm project, we’ll be using the Anti-Capitalist License although the AGPL 3.0 License has won the second question.

What’s next?

We have forked Bookwyrm to our Codeberg organisation. If you send your Codeberg username on the Matrix, we’ll add you this organisation.

These are the current questions we need to answer to work on the Bookwyrm project:

  • Identify the structure of the codebase (where is the frontend, backend, database schema, etc.)? Collect the information about this in the wiki.
  • What data needs to be included in an account archive? See this issue
  • Reach out to the Bookwyrm project. Their Matrix room is Read More
Mastodon in Under a Minute

I like the idea.

I’d think that an interactive web interface is the only way to get onboarding <1min. Especially if the Fediverse is experiencing sustained growth now.

To avoid the concept of “instance” as much as possible, we could:

  1. Develop a web app that considers a users interests (e.g. a list of hashtags/topics to select from) to suggest an instance
  2. include account creation in the actual web app (e.g. as an iframe)
  3. include invite- only instances through a special arrangement allowing direct sign-ups for users of the web app.

With something like this, the idea of an instances could be optional to using the fediverse.

See: socialcoding

Read More
Organisation of the SC Guild


The weekly report

  1. Every monday the editor will publish a short, descriptive report on the activities of the guild during the preceeding week.

  2. The editor is CSDUMMI and tomat0 if he is unavailable.

  3. Anything that every member of the guild should know, must be sent to the editor to be included in the weekly report.

  4. The report will be published in a topic on discuss.coding.social

The forum

  1. discuss.coding.social is the location for long-form discussion of the guild. There is a category called sc-guild for this purpose.


  1. The Matrix chat is for optional-but-quick communication.

  2. Matrix will not be used as a basis of the weekly reports.

Video Conferences

  1. Video conferences should not aim to be with all guild members.

  2. Consider time zones when scheduling video conferences.

  3. Keep video conferences spontaneous.

Issues and Pull Requests

  1. These serve for technical discussion relating to the respective repository.
  2. For discussions about the group, it’s structure and group decisions, please use the forum.
  3. Feel free and encouraged to assign yourself to issues,

    Read More
About the editors category

(Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters.)

Use the following paragraphs for a longer description, or to establish category guidelines or rules:

  • Why should people use this category? What is it for?

  • How exactly is this different than the other categories we already have?

  • What should topics in this category generally contain?

  • Do we need this category? Can we merge with another category, or subcategory?

See: socialcoding

Read More
Announcing the Social Coding Guild

The Social Coding Guild is a guild for software development.

We work collectively on the projects, we choose democratically as a group.

Through this we hope to realize more ambitious projects and be more sustainable than any of us could be individually.

See: socialcoding

Read More
Trading on the Fediverse

I’m just looking through the code of Takahe and must say that I like the code very much. I think I will use that as the basis for this project. Either as a soft-fork or by merging the changes into Takahe itself (less likely).

See: socialcoding

Read More
Trading on the Fediverse

Thanks for you comment, especially the references to existing projects is very helpful. Could you give me a link to the Takahe and Mitra projects?

Integrating Payment Providers

On the topic of integrating payment providers, I’m concerned that the integrating any set of payment providers will reduce the accessibility of the entire software.

Integrating a crypto payment system is controversial in-and-of itself and I’m also doubting whether the effort required here would be worth the development time needed to implement it.

And other payment processors, such as Stripe, PayPal, Klarna, Direkt all have the problems of accessibility and privacy. Most of these systems are only available on certain markets or for certain currencies or for people with a bank account, credit card etc. And while it is completely legitimate for a single offer to restrict buyers to use a specific payment provider, doing so at a software level is very restrictive if not patronizing. If I only implement a subset of all existing payment providers (e.g. Stripe and not AliPay), I’m telling people from those

Read More
Trading on the Fediverse

The following is an excerpt from a funding request I have submitted to the NLnet foundation under their Open Call, which relates to an idea that was inspired by the discussions taking place here. And which I would like to debate, improve and refine in this forum.


My goal is to create a federated online shop. For this purpose I will implement an ActivityPub-compatible Python Server or fork an existing server and extend it.

Users will be able to offer products for sale at a set price. Others (either from the same or another server) can then accept these offers to indicate they wish to buy it.

Delivery is the responsibility of the seller. The seller creates an invoice object containing all relevant information (delivery date, payment details, name, tax, etc.) and sends it to the buyer via an ActivityPub Create activity.

Users will be able to interact with the Server through a Web interface, implemented with the ActivityPub C2S protocol.

As part of this funding I will set up and operate a first instance for a

Read More
Idea: Micro-crowdfunding for feature requests

The business logic.

The business logic of this website is rather simple:

  1. Somebody creates a feature request
  2. Maintainer approves and declares an approved contributor.
  3. Approved contributor sets a bounty.
  4. Sponsors pledge support ($)
  5. If the bounty is reached before X time since step 3, the bounty is collected and access granted to the approved contributor.
  6. Otherwise the feature request is out-dated and removed.

The approved contributor is a programmer of sufficient skill and resources, who is trusted by the maintainer to complete the feature request according to the project’s standards. This can be the maintainer themselves.
Every other actor should be self-explanatory.

The most complex part of this project would be the integration with:

  1. (International) Payment systems (SEPA, Stripe, PayPal, etc.)
  2. Software forges (to connect a maintainer with their projects)

An out-there idea

Disclaimer: I’m not an economist or modern monetary theorist. I only watched this video about the subject and thought it was neat. This is my first attempt at applying the concept as I understood it.

One disadvantage of the feature request approach is that it only rewards and

Read More
Idea: Micro-crowdfunding for feature requests

I like the idea and would like to make it possible.

On the implementation side: I don’t think it will be necessary to integrate this tool into an issue tracker or software forge.

A website could be created where a maintainer could list the feature requests and required commissions ajnd link to them from the relevant issues.

This approach is independent of the software forge and could be integrated using their APIs. And it could very quickly be prototyped.

See: socialcoding

Read More
Unionize Free Software. Found Software Guilds

I am committed to guilds.

I want to set up the first guild quickly. It only needs two steps:

  1. a member list
  2. a means to make democratic decisions

A first goal of the first guild should be the organization of labour by giving education, support and addressing the problems of the members.

I’d organize this first guild using a Codeberg Repo under the SocialCoding or Coders org. The repository contains these files:

  • Members
  • Decisions
  • Constitution

The members text file contains a list of all members.
Decisions is a folder of decisions as text files.
And constitution is a text file containing the fundamental rules of the guild.


Issues in this repo serve as the ground for discussions on the guild and guild activity.

Pull Requests

Pull Requests are proposed decisions, membership changes or vhanges to the constitution.

Pull request must be voted on prior to being accepted, if they affect decisions or the constitution. If a member is removed, this must also be voted on.

New members do not need to be voted in.

I’m unsure on how voting should take place. It could happen by

Read More
Unionize Free Software. Found Software Guilds

This thread has become too large and detailed for anyone to act on it.

Social Coding’s aim is a sustainable, mutually beneficial community for and of software developers, practicioners and dependents.

To ensure this aim this forum is insufficient. It requires action and the structure to enable this action.

I propose that this structure should be the FOSS guilds. Guild’s should have a set list of members, though only for making voting practical.

The guild members’ democratic decisions must be the basis for all actions taken by and on behalf of the guild.

Guild’s allow for the organization of labour (developing standards, that are actually followed, teaching principles and technology to improve members), the organization against exploitation (oppossing the abuse of projects, ethically and legally, promoting free software to capital and enterprise, not just as a ressource but as a community and developing projects and invention beyond the limits and necessities of profit that too often limit the ideas implemented in software development.) and thez benefit society by providing an alternative entry and forum for software development to capital controlled

Read More
Social Coding: Nonviolent democratic principles

Democracy as mentioned in the description of Social Coding is not simply a description of the communication within Social Coding projects and movement.

It is my conviction, that sustainable development communities require the principles of democracy:

  1. Right of speech and proposal for all decisions.
  2. Equality of votes on decisions.
  3. Accountable and short lived leadership.

See: socialcoding

Read More
Idea: 100 days of Code Improvement

A little unoriginal idea for a Social Coding Event: 100days of social code improvement.

Two steps:

  1. Pick a small to medium size project in need of upgrading their code quality.
  2. read one of that project’s files/modules per day and see if you can make an improvement. Try to make a PR/MR/patch within the day.
  3. repeat step two for 100 days or until the project runs out of files to read
  4. (share your participation on the Fedi?)

Organizations TODO

  • create a list of potential projects (projects should have an active maintainer, willing to merge these kinds of patches)
  • create a hashtag
  • create an entry on the website with all suggested projects

Important: These projects are suggested, not required.

Potential projects (nothing final)

See: socialcoding

Read More
FreeCoop: A platform for democratic labour organization

FreeCoop aims to be a tool for organizing democratic organizations, with a focus on commercial, labour organizations.

FreeCoop is built on three pillars:

  1. Decision Making
  2. Groups
  3. Accounting

Decision Making (Decision API)

Internet Voting (I-Voting) is a difficult software to implement.

FreeCoop relies on Decision API for implementing secret, certified and extensible I-Voting.

Decision API is another Social Coding project developed by me, so let me introduce it here in detail.

Decision API is not supposed to be invoked directly and instead decisions and accounts should be created by some service, such as FreeCoop.

Account Managment

An account contains a UUID id and a an optional name string.

When an account has been created, it’s id is returned to the creator (usually the services using Decision API).

This services then issues the id to the person, they want to use the account, who can then exchange the id for an authorization token.

After an authorization token has been issued for an account, it cannot be changed or reissued. And the authorization token remains valid for the lifetime of

Read More
Unionize Free Software. Found Software Guilds

There has been some very active discussion about this post on the Fediverse in response to my toot requesting feedback.

I want to summarize the arguments that were raised in response to this post and respond to them.

Free Software shouldn’t be developed to be exploitable by the big tech capitalists.

@alcinnz@floss.social made this argument, that they advised against making free software that suits the big tech capitalists.

Examples for this kind of software might be:

  • Deep Learning Libraries, that can only be operated on super computers and cloud services - which profit big tech capitalists, who own these services.
  • JavaScript Frameworks. These most benefit the websites with the most complex and advanced browser logic. And these are mostly profiting the big tech capitalists. While most websites only need a CMS or static website generator with a little bit of styling.

While these discussions are legitimate and should be had, this is a discussion on creating sustainable free software. And we shouldn’t make make more assumptions about free software than are

Read More
Unionize Free Software. Found Software Guilds

In the article “The changing economics of open source” Ken Mugrage present the Free Software Sustainability problem from the perspective of companies depending on free software developed by hobbyists.

The article defines three different types of free or open source software:

  1. Free Software developed by companies or individuals trying to make a living by this activity.
  2. Open Source projects used for publicity of Big Tech.
  3. Free Software developed by hobbyists as a recreational voluntary activity.

And provides examples for each of these types of projects, namely ElasticSearch, React and Log4j respectively.

It ends with a recommendation for companies to:

  1. Investigate what project’s they depend on
  2. Review how likely these projects are to change licensing.
  3. Investigate the possibility of maintaining a fork of a FOSS project if the project developers change licensing.

While these recommendations are rational from the perspective of a business depending on free software - which today is almost every business, even if they just use Wordpress for their website - I disagree with the underlying assumption that free software can be exploited for maximum gain and that companies should

Read More
Idea: Dependency Funding Tool

I have drafted a proposal for what I call “The Dependency Funding Tool” (TDFT).

It’s purpose is to provide funding to all free software projects, regardless of their proximity or visible to the people utilizing them.


  • The tool relies on a federated graph of project (as nodes) connected by dependencies (directed and weighted edges)
  • To calculate how reliant one project is on another all paths between the two projects in the dependency graph are taken, their edge weights multiplied and then summed up.
  • The tool analyzes the usage of a person and creates a list of projects they are directly or indirectly reliant on by calculating for each program they interact with directly all the projects they depend on and sorting them by their dependency.
  • The tool can be configured to send automatic recurring fees or direct people to a project’s CONTRIBUTE files.

See: socialcoding

Read More
Idea: Practice "Usage-based Commons Support"

Something of note about the FOSS Contributer Fund by Indeed is that the projects supported by anyone company running their own fund is entirely determined by themselves - which is inevitably going to lead to bias and oversight, maybe because some projects are not considered important or are ignored by the operators of the fund.

To solve this problem I’d implement a single shared dependency graph for all projects in the Dependency Funding Tool.

For example:
Suppose I work with the OrbitDB library, which depends on both IPFS and p-map. But I only know of the first and not the latter dependency - IPFS is considered part of the “OrbitDB Stack” and p-map only an auxiliary library.

If I worked at a company running the FOSS Contributor Fund, I’d probably propose and vote for OrbitDB and IPFS - but I’d not know about the dependency on p-map unless I looked at one of the many package.json files in OrbitDB’s source code. Thus removing an important source of support for

Read More