Funding Social Coding Communities #21
Labels
No labels
advocacy
app:ideationhub
bug
challenge
contribution welcome
documentation
domain:community
domain:ideation
domain:project
duplicate
enhancement
help wanted
idea
invalid
organization
principle:community-first
principle:democratic
principle:educate-learn
principle:openness
question
upstream
wontfix
bug
contribution welcome
duplicate
enhancement
help wanted
invalid
question
upstream
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: SocialCoding/community#21
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Let me be clear this is a controversial topic because it has to be! If we are not careful, both CODE GEM principles and values will easily be violated by the wrong funding tools.
But instead of staying silent on the problem of funding, we have to address them as the Social Coding Movement and cannot leave the burden to the Social Coding Communities. They've got better things to do.
Funding
The topic of funding free software communities is both critical for free software and a source cynicism - the project's with the most merit rarely receive the funding they need or deserve, while big tech makes millions of free software [1][2].
In that sense we have to create sustainable funding tools to be used by the communities as they see fit.
There exist many ideas for new funding tools for free and open source software, some of which @circlebuilder has gathered into lists for further review already:
These apply to free software and I expect can be transfered to Social Coding without much hassle - but we still need to consider that free software and social coding are separate.
While in free software it might be possible to think about funding as funding individuals, Social Coding always funds Communities first. It's a matter of Community Governance to spend this money as they see fit.
These sources need review, consideration and discussion to develop tools for Communities to receive funding, fund each other and spend their funding.
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.
As a result of this problem most of the FOSS developers (who try to make a living) are incentivzed against creating simple, modular and reusable programs for other developers and instead should develop spectacularly ambitious, complex and flashy software, that the most people can and want to use directly, because this kind of software creates the largest userbase quickly leading to more support and funding for them.
Dependency Funding Tool
The simple solution to the dependency funding problem would be if any "user facing software" just passed along some of their funding to their dependencies.
But this does not happen. And many software projecets (proprietary and free alike) will not bother to put in this effort to essentially give money away.
Thus I propose another solution: 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.
I think this is an interesting road to pursue. "Funding" in general is a Challenge that we can analyse and document. But it has huge scope, and on the solutions side many considerations and choices that'll differ per project. In the Pattern Library that we document there could be a family of funding-related patterns and "Dependency Funding" being of them to choose from.
As for building a Dependency Funding Tool I feel that that is typically an idea that flows through the IdeationHub and spins of a social coding project, but is not per definition part of Social Coding initiative itself.
I agree. As long as we don't have an IdeationHub though - I had to put it somewhere.