FOSS donations which reach the roots

After reading the readme and skimming a couple source files it&#x27;s not clear to me what this actually does other than define how you would <i>like</i> to be paid.<p>Does openfare collect, apportion, and distribute funds? Solve recursive allocation (e.g. Project A stipulates that 5% of donations should go to Library B, which in turn splits their donations from Project A and elsewhere into N parts)? Address transaction overhead and friction somehow? If a project&#x27;s OPENFARE.lock file specifies a 60-40 split but I don&#x27;t like Steve so I split my donation 40-60 instead will openfare identify that (e.g. by hooking into wallet apis) and tell John he needs to give some of what he received to Steve?<p>Machine-readable payment preferences are a step forward, I guess, but it seems like a very small step if that&#x27;s all it does.

Machine readable definitions are nice, but I think the real problem is not that people&#x2F;companies can&#x27;t figure how to send money to the developer(s) of some piece of FOSS software. Rather, the problem seems to be that 1. many people and companies would prefer not to pay at all and 2. the maintainers are surely not the only ones contributing; how to pay all the rest?<p>I wonder how we could actually &quot;reach&quot; the roots of FOSS with funding. For example, the whole Faker.js thing copied their data definitions from the similarly named Ruby project, which copied them from the even earlier PHP project. How much funding do those earlier projects deserve? Which percentage do any of the ~257 contributors to Faker.js deserve? Somehow Marak does not strike me as an overly generous person.<p>Personally, I treat any contributions I make to FOSS more as a hobby. There are some PRs I&#x27;ve made in the past that fix a decent chunk of technical debt or introduce fancy new algorithms to speed up parts of the software. Those PRs were submitted without an invoice, even though I do similar work as a freelancer. If I knew the maintainers were getting significant amounts of money for their work, it would definitely not be the same feeling contributing significant chunks of work for free.

A possible advantage of a machine readable definition of who should be paid within a repo is to then integrate it with how to spread payment across multiple repos.<p>Most large companies run a licence check across all dependencies, i.e. things like Veracode SCA License reports already list all third party dependencies and lookup licence information... if such tools were adapted (or a new tool created) that allowed you to use that as a billing mechanism it would make sense that just as you can programmatically lookup licences you could lookup who to pay.<p>Going further... it could encourage dual-licensing by default with the OSS licence being viral unless paid for... so on the report that says you&#x27;re at risk because it&#x27;s GPL it could detect that payment can be made to obtain the code under some other terms.<p>The basics of the proposal aren&#x27;t bad... it proposes that there is a machine readable definition of how payments should be shared and made... however there&#x27;s still a lot that needs to be done to make that useful, the upside is that some of that becomes more obvious.

This seems to be solving the wrong problem.<p>As far as I can tell, the problem is not that we lack good mechanisms for making payments to open source developers and deciding how to allocate such funds. The problem is that cash donations are rare and small. A small handful of developers are supported very richly by being paid full-time tech employee salaries to work on open source; a handful of groups like the Python Software Foundation occasionally get together enough donations to fund a developer or small team part time; and aside from that there just isn&#x27;t much money contributed.

I don&#x27;t understand why you would want this to be in the code. That is just not compatible with how source code versioning works.<p>If you, a contributor, want to change your funding preferences, you have to file a PR with the project? If you update your preferences, other branches of the same project can still have different preferences? If you fork a project, you have to put a meaningless commit in there to change funding to your fork project, a commit that will have to be reverted if you ever merge upstream or you subvert upstream funding?

The examples shouldn&#x27;t use real email addresses. john@gmail.com and steve@gmail.com are surely in use. &quot;example.com&quot;, &quot;example.net&quot;, and &quot;example.org&quot; are reserved domain names for a reason.

I was thinking about FOSS funding earlier, and it&#x27;s actually quite a complex problem. Depending on the application and the users, it may have a different audience with more or less money, more or less users, and different types of users and use cases.<p>And regardless of all that, what is the money going towards in each case? Does the developer (or developers) need a full-time salary, or part time, or just coffee money? Does the money get split between all contributors, or just ones making changes recently, or just the &#x27;leaders&#x27;? Is it being saved up for infrastructure, dedicated staff, travel to conferences?<p>It seems we need a ton of different funding models, or a model that takes a ton of different variables into account.

One of the issues with this is the dynamic of donations. People keep talking about how public corps don&#x27;t give out donations to developers for projects they use. I&#x27;m beginning to think it&#x27;s not something they can do and I&#x27;ve been poking at tax and legal code on it. There&#x27;s likely a reason they don&#x27;t do it.<p>I would suggest people try to get funded through methods that functionally work through the big corps&#x2F;public companies instead of donations (unless they are looking for a corp to donate to a legally registered non-profit).

I would love to see this supported by projects such as librepay:<p>1. It better captures the project dynamics. Sometimes the author and maintainers don&#x27;t do much work or don&#x27;t need the money at the moment.<p>2. It makes it easier to ask for money.<p>3. It may also solve the unclaimed donations problem. See for example <a href="https:&#x2F;&#x2F;liberapay.com&#x2F;explore&#x2F;pledges" rel="nofollow">https:&#x2F;&#x2F;liberapay.com&#x2F;explore&#x2F;pledges</a>

I like the idea of Snowdrift for FOSS funding:<p><a href="https:&#x2F;&#x2F;snowdrift.coop&#x2F;" rel="nofollow">https:&#x2F;&#x2F;snowdrift.coop&#x2F;</a> <a href="https:&#x2F;&#x2F;github.com&#x2F;fossjobs&#x2F;fossjobs&#x2F;wiki&#x2F;resources" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;fossjobs&#x2F;fossjobs&#x2F;wiki&#x2F;resources</a>

Nice initiative. Any exploration into funding publicly used software is a good thing.<p>May I suggest using the Business Source License as the basis for this instead of the Openfare Commercial License? This way older versions of software would revert to FOSS instead of staying non-free forever.

Micropayments just repeat the same old mistake of applying individualistic solutions to problems that can only be addressed collectively.<p>We need a trade organization like the RIAA that collects and distributes royalties from profitable business for developers.