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.
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:
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:
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
There’s a nice idea here to improve on for Social Coding.
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.
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