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's OPENFARE.lock file specifies a 60-40 split but I don'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?
Machine-readable payment preferences are a step forward, I guess, but it seems like a very small step if that's all it does.
Fifty people donate $20 each, to be divided between 100 recipients, that's 150 transactions (50x$20, 100x$10). As long an the donations are earmarked for more than 3 recipients per donor, that works out as fewer transfers.
Apple Music in theory could have paid artists more, but I haven't heard any news on that front since ages ago, when Weird Al puzzled out loud about how he was making about 1/10th of what he used to make.
And I thought Brave's original model was something along this line and they seem to have abandoned it, which is probably worth digging into.
I think you have to consider as well that if and when someone actually figures out how to make this distribution model work, Visa will notice and introduce their own system. They can split the difference on overhead and increase their margins while also increasing donation efficiency. But perhaps only once someone else has proven the idea (free R&D).
My intent is to create a community around the idea and to get early feedback. It's true that there are many problems outstanding. I'm yet to share a payment portal for instance that will effectively outsource the infrastructure necessary to distribute funds.
I wonder how we could actually "reach" 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.
Personally, I treat any contributions I make to FOSS more as a hobby. There are some PRs I'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.
For instance colors.js basically adds ANSI escape codes to strings which is someting you can do in 1LOC. How much compensation should the person who made colors.js get?
Some projects are bigger and actually require a decent amount of effort, but still are something most programmers could put together in less than a month. For instance core-js, a JavaScript standard library. Should the creator of core-js deserve more compensation? When do you draw the line on how much payment you get for being a dependency?
But I think mechanisms for rating software packages already exist (GitHub stars for instance). And we have reasonable metrics for whether a software package is under active development/maintenance. If we combine those two factors in deciding which dependencies to fund we might be in a reasonable place.
Any metric can be gamed of course.
This is certainly a problem that I would like to address. It's important to reward/fund contributors as much as maintainers.
Donation schemes defined in code are as modifiable as any other code in the software. I would like to build a bot which will open a pull request on behalf of contributors and propose a share of donations.
i contribute weekly to one project, but i am not a maintainer. i could reason that my contributions to this project are worth money. being paid every month would be reasonable.
in another project, i only contribute when i run into a bug or need something added. this happens maybe 3-4 times a year. i could reason that these bug fixes and feature additions are worth money, but i would be out of line to say that a monthly amount of money is reasonable. do one time donations or 1-2x a year donations make sense?
i also have various projects where i've contributed 1-10 lines of code once and never come back. i don't deserve to be paid for those, in my opinion.
My goal is to put the mechanisms in place. And give people another means of self expression.
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.
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're at risk because it's GPL it could detect that payment can be made to obtain the code under some other terms.
The basics of the proposal aren't bad... it proposes that there is a machine readable definition of how payments should be shared and made... however there's still a lot that needs to be done to make that useful, the upside is that some of that becomes more obvious.
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't much money contributed.
The macro goal of OpenFare is to put in place a mechanism that developers can use to receive funds for developing public software. If there is a demand for donations, it needs to be brought to the surface. I don't think we're adequately over that hurdle.
Many content creators (youtubers, gamers, ...) get paid a lot. I think that there is room for public software engineers to ask for their share.
Millions of companies use open source without contributing anything. I have a theory/daydream that:
a) a new foundation could be created with a new licence, whose only purpose is to accept payments and distribute them, with max x% overhead
b) that licence would stipulate that by paying a nominal yearly fee (e.g. 10 hours average developer cost in your country) you would get all-you-can-eat commercial use of such licensed software
would lead to software adopting that licence, companies paying that fee as a no-brainer, and in time would mean that those millions of companies would at least give some money, without warranty etc, that would be distributed somewhat fairly.
Which would no doubt be massively imperfect, but better than now.
In addition to this, if a company pays for software the devs they buy it from had better respond quickly to security vulnerabilities and feature requests. The standard FOSS "this software is provided as-is, without even some guarantee of fitness for purpose" is not really something that would fly in a commercial contract.
https://github.com/openfare/openfare#micropriced-commercial-...
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?
It codifies the social side of enterprise ownership.
Not just for the participants in the enterprise itself, but for potential investors, users of the service, collaborators and business partners as well.
I've spent a bit of time wondering how to effectively measure and assign share value to FOSS project contributors, and have always looked to technical solutions. Things like metrics and weightings and machine learning models built in aggregate based on customer success, company growth, and revenue metrics across a wide range of projects, with the resulting models then used to evaluate individual market entrants.
It has never felt like that is a workable approach: every enterprise is different, and some would be unfairly overvalued as a result, and some would be unfairly devalued. It also might not generalize well to non-profit and community-interest companies.
And so the technical approach might all be too complicated: perhaps a better solution, as offered here, is simply to commit the ownership structure into a repository and then allow that to be edited like any other code.
There's the problem. The reason the thing you're replacing is so complicated is because it tries to codify some aspect of human behaviour. If your solution for handling (e.g. money) is radically different to the existing (financial) system (which this is), it will probably blow up in a big way.
The file format should -- and to some extent, is already -- separated from the mechanism(s) of payment.
Version-controlled software development is social and provides history, evidence, and allows code to evolve over time; I like that this approach leverages those properties.
> If you, a contributor, want to change your funding preferences, you have to file a PR with the project?
Yes, or, a bot could track your funding preferences from some repo and submit a PR for you. (Cryptographic verification permitting.)
> If you update your preferences, other branches of the same project can still have different preferences?
Yes but those other branches will be outdated and git will make that clear. Only the commit from which the software package is derived matters. Donation schemes are derived from software packages.
## Forking a project
Contributors could get a share of donations by proposing a change to a project's lock file via a pull request. Or they could fork and make a change. But their fork would have to stand on it's own as a software package.
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 'leaders'? Is it being saved up for infrastructure, dedicated staff, travel to conferences?
It seems we need a ton of different funding models, or a model that takes a ton of different variables into account.
I imagine the distribution curve of funding. If it shifts one way, more developers become full time open source maintainers. Those who previously received nothing might start receiving coffee money.
If we can normalize a low friction mechanism for receiving funds for developers then the curve might be shiftable.
I would suggest people try to get funded through methods that functionally work through the big corps/public companies instead of donations (unless they are looking for a corp to donate to a legally registered non-profit).
If I as a C suite decide to donate to the NRA, I may discover an angry mob outside my office who inform me that the majority of the company is anti-NRA, or planned parenthood, or Susan G Koman or or or.
If I earmark a half a million for matching, then my employees 'vote' on where that money goes, and it's not my 'fault' that employee A hates employee B's decisions. "We" didn't decide anything. Our employees did.
You could however do the same thing without the matching part and just allocate $200 per employee that they can allocate how they want. If I think jquery deserves $5 and five coworkers all think that should be $10, then a check for $55 goes to jquery.org. Or perhaps the cutoff is $100 (because some administrator has to write all these checks), and either they get nothing or I find more people who like jquery.
I think where we can help this sort of process is by pointing out how much money we are saving by using these tools, and try to convince our employers to allocate a couple % of that to donations, regardless of whether they get a tax break due to the group being a 501c3.
We just switched a number of services off of Oracle. I know some of them went to postgres but probably not all. I bet postgres, mysql, redis, elasticsearch haven't seen one thin dime of that money.
Commercial payment plans defined in code can be managed programmatically. Which means that small payment obligations can be managed at scale. Consequently, trivial software dependencies could raise meaningful capital from micropayments.
See: https://github.com/openfare/openfare#micropriced-commercial-...
However, software for a fee is not FOSS.
Now this is moving into differences between Free and open source software.
You can have open source software which has some form of support and specialized feature development for a fee. Many many many do this through companies today. They do it as a company rather than an individual due to the way you need to work to get paid by public companies.
One issue I keep seeing is setups that don't work for the constraints public companies have on them. People want their money but aren't willing to work within their constraints.
Corporations make all kinds of “ordinary and necessary” business expenditures. (See IRS publication 535.)
Note that “necessary” in that phrase is more like “helpful” than “absolutely required and unavoidable” in definition.
If the dev wants the money and the company wants to pay it, I’m sure they can make it happen.
1. It better captures the project dynamics. Sometimes the author and maintainers don't do much work or don't need the money at the moment.
2. It makes it easier to ask for money.
3. It may also solve the unclaimed donations problem. See for example https://liberapay.com/explore/pledges
Since my current job would have been much harder without FOSS, during the pandemic I made it a habit of drinking coffee at home and sending my fav developer of the month equivalent of one overpriced cappuccino.
https://snowdrift.coop/ https://github.com/fossjobs/fossjobs/wiki/resources
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.
I need to think about it a bit more. And I'd like to hear more opinions on ideas like this.
We need a trade organization like the RIAA that collects and distributes royalties from profitable business for developers.
What about ... slapping license you are actually ok with. It is 100% fine to sell software for money, closed source, open source, free software and completely restricted.
That's not possible. It would all have to be clearly stated in the license.
> What about ... slapping license you are actually ok with.
You would have to slap on a licence saying the trade org represents you, etc.
There are licenses that don't allow such thing. And afaik, corporations avoid those libraries or pay for alternative license. The people however don't complain about these.
a foss collective could act as the enforcer of the openfare license, sure.
If all users chip in $1/month, perhaps it adds up to something significant.
I think the challenge is to minimize the overhead costs of that process.
