FOSS donations which reach the roots(github.com)
github.com
FOSS donations which reach the roots
https://github.com/openfare/openfare
49 comments
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).
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.
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.
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?
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?
It's a tough problem.
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.
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.
> 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.
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.
it is much harder though.
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.
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.
Should you continue to be paid for software as long as it provides value, even if you no longer work on it? That is a question that will spark ideological debates for centuries.
There is so much variety in how people contribute and what they hope to get out of it in a perfect world!
My goal is to put the mechanisms in place. And give people another means of self expression.
My goal is to put the mechanisms in place. And give people another means of self expression.
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.
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.
This seems to be solving the wrong problem.
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.
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.
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.
Thanks for moving the needle.
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.
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.
I want to be optimistic about this, but I don't think the result would be that every company would sign up for this. Rather, every company would implement their own 10-liner library for adding ANSI color codes to terminal output. The whole system of smallish dependencies you add in on an as-needed basis only works when the cost of adding them (INCLUDING the transaction costs, the cost of dev hours spend on convincing the procurement dept, etc etc etc) is cheaper than the cost in dev hours of just writing it yourself.
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.
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.
> the cost of adding them (INCLUDING the transaction costs, the cost of dev hours spend on convincing the procurement dept, etc etc etc) is cheaper than the cost in dev hours
I think this gets to the heart of the matter. The goal with OpenFare (for non-FOSS) is to minimize this overhead cost. I believe that it can be minimized to a point where it is negligible. For FOSS it is already negligible. The method for minimizing that cost is to make a predictable pattern familiar and ubiquitous.
> had better respond quickly to security vulnerabilities and feature requests
That depends on the deal. If you buy software for $.01 what do you expect beyond your expectations had you paid nothing? Software support can't be assumed just because money is trading hands.
I think this gets to the heart of the matter. The goal with OpenFare (for non-FOSS) is to minimize this overhead cost. I believe that it can be minimized to a point where it is negligible. For FOSS it is already negligible. The method for minimizing that cost is to make a predictable pattern familiar and ubiquitous.
> had better respond quickly to security vulnerabilities and feature requests
That depends on the deal. If you buy software for $.01 what do you expect beyond your expectations had you paid nothing? Software support can't be assumed just because money is trading hands.
Yeah, the $BIG-CO companies I work for have many many developers and projects. Once they realize that they pay a small yearly fee (compared to seat licences for Intellij etc) and that saves tons of time, they would pay it for sure.
The "no warranty, express or implied" is an important part of the licence.
The "no warranty, express or implied" is an important part of the licence.
Umm, I could be wrong, and you might be referring to what I have in mind. But your dream sounds an awful lot like the OpenFare Commercial License (non-FOSS) idea:
https://github.com/openfare/openfare#micropriced-commercial-...
https://github.com/openfare/openfare#micropriced-commercial-...
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?
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.
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.
> It codifies the social side of
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.
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.
In practice I think it's likely that most law firms and jurisdictions who configure and accept business ownership structures enforce their terms in a nearly-as-restrictive manner. No doubt there are exceptions; a file format can be adjusted over time to handle those equally.
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.
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.
I have nothing against it being written down, or even written in a structured format. I just think putting this in the source code repository is inadequate.
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.
> 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.
[email protected] and [email protected] are surely in use.
"example.com", "example.net", and "example.org" are reserved domain names for a reason.
Will update, thanks.
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.
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 agree with your view.
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 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).
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.
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.
There is a difference in donation to a legally registered non-profit and an individual. I was reading some us legal code for public companies and it covers stuff like this. Each of the examples here is for a legally registered non-profit.
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.
See: https://github.com/openfare/openfare#micropriced-commercial-...
However, software for a fee is not FOSS.
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.
> 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.
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.
Yes, I agree. There are two different audiences: public software developers and public companies. And they both need different interfaces. I love it.
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.
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.
The private corporations build all the wrong code.
I would love to see this supported by projects such as librepay:
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
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
I haven't heard about librepay before, thanks for letting me know. I'll take a look!
They are not as big as patron but host many FOSS projects and devs. Seeing how hard FOSS devs work and how little they earn, maybe HN reader can show them some love?
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.
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.
I like the idea of Snowdrift for FOSS funding:
https://snowdrift.coop/ https://github.com/fossjobs/fossjobs/wiki/resources
https://snowdrift.coop/ https://github.com/fossjobs/fossjobs/wiki/resources
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.
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.
I need to think about it a bit more. And I'd like to hear more opinions on ideas like this.
Micropayments just repeat the same old mistake of applying individualistic solutions to problems that can only be addressed collectively.
We need a trade organization like the RIAA that collects and distributes royalties from profitable business for developers.
We need a trade organization like the RIAA that collects and distributes royalties from profitable business for developers.
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.
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 would turn open source into trick and bait fraud.
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.
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.
The whole debate is about open source with licenses that do in fact allow corporations to legally use it for free. And open source advocates of the past spent a lot of effort ensuring them it is so.
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.
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.
the two seem orthogonal issues.
a foss collective could act as the enforcer of the openfare license, sure.
a foss collective could act as the enforcer of the openfare license, sure.
I see the issue as 'how do we get resources to OSS contributors'. Micropayments will never be more than a pittance as long as it has to compete with "free"
For a user of the software, free might have downsides that micropayment-funded-at-scale might not have.
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.
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.
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.