Idea: Practice "Usage-based Commons Support"

Movement Ideas
#1

Dependency funding

@CSDUMMI mentioned in our discussions repo the idea of “dependency funding”. Summarizing (read issue for whole thread):

A problem I see with modern day free software development is the lack of dependency funding.

The majority of funding, support and donations are received by user facing projects - that rely on hundreds if not thousands of libraries, programs and systems developed by others. But these developers of dependencies often only receive a fraction of the funding that User Facing Software receives. An example of this can be seen in the recent log4j Vulnerabilitiy in a program that was used by millions but only received funding from a handful of people.

I call this problem the “dependency funding” problem of free and open source. […]

And proposes a solution:

Dependency Funding Tool

[…] Create a tool that runs on a person’s machine, finds the software installed/run on that machine and proposes a list of projects that the person could support and to what degree - a list that is composed both of the software used by the person directly and indirectly (as a dependency).

This tool could also be used to automatically make donations of a regular amount based on what software a person used within a given time periode.

This is a great idea and certainly a project for consideration under the Ecosystem umbrella of Social Coding.

FOSS Contributor Fund

Recently via this SustainOSS topic (SustainOSS is a community with corporate background, more OSS than FOSS) I found the following project created by Indeed company:

https://github.com/indeedeng/FOSS-Contributor-Fund

It is a framework with which corporations can set up their own funding program in support of the FOSS they use. It is along the same lines as dependency funding, but broader as it deals with implicit dependencies beyond what a code project specifies in its codebase. It reflects policies of Indeed, but can be adapted.

Interestingly they also provide a tool to select the ‘best’ projects to fund, based on metrics:

https://github.com/indeedeng/starfish

Though the initiative can be applauded, you can tell the corporate culture from language use where they refer to eligible projects as “Winners”. Eligible means they were upvoted the most after being selected by Starfish metrics. Competition, not collaboration.

Another thing that struck me is that you can only be eligible if you are on Github :exploding_head:

There’s a nice idea here to improve on for Social Coding.

Usage-based funding

I think we can start to derive a practice from these ideas. And that is: Strive to fund the free software you use!

“Strive” mostly relates to free software projects financially supporting other free software projects. This is not always feasible. Note: For corporations we can adapt this so there’s no “strive” but more of a SHOULD or a MUST.

The practice aligns with the "Evolve the Commons" core practice. But that means that it might go beyond funding for FOSS and into funding any work that exists in the Commons that is to the benefit of another project (or to a corporation). Think of a tutorial e-book, technology courseware, research paper, etc.

If we broaden from FOSS to Commons there’s better alignment with FLO principles (defined by Snowdrift).

Usage-based support

Because funding is not always feasible (like if you are unfunded yourself, or lack funds) and there are plenty more ways to support a free software project, this Social Coding Practice can be further generalized into a recipe to determine how you can best support the projects you use.

You might contribute to the code, help with advocacy, PR, marketing, UX-design, documentation, product management, security audits, performance testing. Etcetera.

Part of the practice should be to do all of this consciously, and track the nature and amount of help that you provide. It is perfectly okay to help in such way to create a win-win situation. For example a security business might provide free security audits to FOSS projects they use. I suggested something like this to @NGIZero and later to Melanie Rieback of Radically Open Security (which is an Non-profit Venture).

So then the name of the resulting practice becomes:

→ Usage-based Commons Support   :rocket:

#2

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

This is why we need a global single dependency graph that can be used to calculate the dependency of a single project on any other project.

Anyone should be able to add tips to this graph (i.e. adding a new project and it’s dependencies) and petition other projects to add them to their dependencies.

The connections between graph nodes should be directional and weighted indicating the severity of the dependence (in the example above, IPFS may receive a higher dependency weight than p-map).

To then calculate a list of projects that a person should contribute to with money, time, effort or otherwise I’d look at the projects they use directly (by scanning their usage statistics or browser history locally) and then looking up those project’s dependencies in the graph and sorting the resulting list based on the weights of the dependency and the distance between a project and the user facing project.
(This is fair, because a project like log4j or Linux, that is used by millions of people and is only part of the dependency graph at a far latter stage, than say, MongoDB, OrbitDB or p-map, receive smaller but more numerous support in this system).

The institutions of a global dependency graph, that is publicly known and where project developers can add, remove and change the weights of their projects, as well as petitioning others to change their own projects connection with them, is thus a more transparent and fairer way to support free software than using a corporate controlled funding program.

Yet it’s not without it’s problems, project developers could try to unfairly manipulate their dependencies or unfairly weight certain connections. But I believe this system can work well on a good faith basis, since all changes are public, such manipulations of the graph would be known and could be counteracted by removing projects from your project’s own dependencies or asking people using the tool not to support certain projects that are calculated.

(Equivalents to the Fediverse’s bans, muting and blocks instituted not by an overarching institution but by small parts of the Fediverse in a semi-democratic manner).

2 Likes
#3

Criticality funding

I just found the following toot (also posted to SustainOSS) of Serkan Holat doing a public funding experiment, and donating to OpenCollective projects based on how critical the projects are. And apparently some framework has been developed in that area by Google and one of the designers of Golang:

Here’s Serkan’s blog post on the topic: Open source public fund experiment - DEV Community 👩‍💻👨‍💻