After reading the readme and skimming a couple source files it's not clear to me what this actually does other than define how you would like to be paid.
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.
In theory aggregation and distribution allow for lower transaction overheads but in practice the middleman seems to keep a lot of the money.
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).
Thank you for taking a look at what I've shared so far.
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.
Machine readable definitions are nice, but I think the real problem is not that people/companies can'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?
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.
Another issue is that many popular FOSS libraries are pretty simple, and the only reason they're popular is because the creator was the first person to come up with a (decent) implementation.
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?
> 2. the maintainers are surely not the only ones contributing; how to pay all the rest?
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.
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.
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.
I don't believe enough public software developers ask for or expect to receive donations.
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.
I don't understand why you would want this to be in the code. That is just not compatible with how source code versioning works.
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?
I'm not sure it's the perfect solution, for reasons that relate mostly to the (necessary, useful) ability to modify and adjust rewards on a long-term and after-the-fact timescale, but I'll offer one reason why this could be a good idea:
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.
Changes to the lock file (`OPENFARE.lock`) need to be reviewed. The lock file needs to survive a project fork. Changes to the lock file need to be tracked on a contributor level. The lock file needs to be signed by those who care about the project.
> 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.
The examples shouldn't use real email addresses.
john@gmail.com and steve@gmail.com are surely in use.
"example.com", "example.net", and "example.org" are reserved domain names for a reason.
I was thinking about FOSS funding earlier, and it'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.
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.
One of the issues with this is the dynamic of donations. People keep talking about how public corps don't give out donations to developers for projects they use. I'm beginning to think it's not something they can do and I've been poking at tax and legal code on it. There's likely a reason they don't do it.
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).
A lot of big companies do donation matching, and as near as I can glean this is a political thing.
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.
OpenFare does open the door to an alternative non-FOSS strategy for funding for small software libraries.
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.
What makes you think that corporations can’t pay developers of open source code? You may not be able to characterize it as a “donation” but I don’t think you have to in order to get the money to flow.
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.
Nice initiative. Any exploration into funding publicly used software is a good thing.
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 really like that idea. I think it's really compelling. The latest features/bug fix can be made available at a price before a certain time limit. And then of course you eventually end up with the advantages of FOSS.
I need to think about it a bit more. And I'd like to hear more opinions on ideas like this.
That would turn open source into trick and bait fraud.
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.
CrazyStat|4 years ago
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.
hinkley|4 years ago
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).
rndhouse|4 years ago
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.
WJW|4 years ago
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.
armchairhacker|4 years ago
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?
rndhouse|4 years ago
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.
buro9|4 years ago
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.
mcherm|4 years ago
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.
rndhouse|4 years ago
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.
remram|4 years ago
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?
jka|4 years ago
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.
rndhouse|4 years ago
> 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.
vdddv|4 years ago
rndhouse|4 years ago
0xbadcafebee|4 years ago
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.
rndhouse|4 years ago
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.
mfer|4 years ago
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).
hinkley|4 years ago
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.
rndhouse|4 years ago
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.
sokoloff|4 years ago
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.
DarylZero|4 years ago
zibzab|4 years ago
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
rndhouse|4 years ago
pabs3|4 years ago
https://snowdrift.coop/ https://github.com/fossjobs/fossjobs/wiki/resources
jgilias|4 years ago
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.
rndhouse|4 years ago
I need to think about it a bit more. And I'd like to hear more opinions on ideas like this.
alangibson|4 years ago
We need a trade organization like the RIAA that collects and distributes royalties from profitable business for developers.
watwut|4 years ago
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.
tpoacher|4 years ago
a foss collective could act as the enforcer of the openfare license, sure.