[HN Gopher] FOSS donations which reach the roots
       ___________________________________________________________________
        
       FOSS donations which reach the roots
        
       Author : rndhouse
       Score  : 69 points
       Date   : 2022-01-12 16:40 UTC (6 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | mcherm wrote:
       | 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.
        
         | rndhouse wrote:
         | 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.
        
           | cromulent wrote:
           | 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.
        
             | rndhouse wrote:
             | 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-...
        
             | WJW wrote:
             | 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.
        
       | 0xbadcafebee wrote:
       | 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.
        
         | rndhouse wrote:
         | 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.
        
       | alangibson wrote:
       | 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.
        
         | tpoacher wrote:
         | the two seem orthogonal issues.
         | 
         | a foss collective could act as the enforcer of the openfare
         | license, sure.
        
           | alangibson wrote:
           | 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"
        
             | rndhouse wrote:
             | 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.
        
         | watwut wrote:
         | 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.
        
           | alangibson wrote:
           | > 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.
        
             | watwut wrote:
             | 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.
        
       | CrazyStat wrote:
       | 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.
        
         | hinkley wrote:
         | 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).
        
         | rndhouse wrote:
         | 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.
        
       | remram wrote:
       | 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?
        
         | jka wrote:
         | 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.
        
           | wizzwizz4 wrote:
           | > _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.
        
             | jka wrote:
             | 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.
        
         | rndhouse wrote:
         | 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 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.
        
       | buro9 wrote:
       | 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.
        
       | WJW wrote:
       | 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.
        
         | armchairhacker wrote:
         | 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?
        
           | rndhouse wrote:
           | 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.
        
         | rndhouse wrote:
         | > 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.
        
           | diogenesjunior wrote:
           | 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.
        
             | rndhouse wrote:
             | 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.
        
             | WJW wrote:
             | 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.
        
       | vdddv wrote:
       | 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.
        
         | rndhouse wrote:
         | Will update, thanks.
        
       | jgilias wrote:
       | 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.
        
       | mfer wrote:
       | 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).
        
         | sokoloff wrote:
         | 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.
        
         | DarylZero wrote:
         | The private corporations build all the wrong code.
        
         | rndhouse wrote:
         | 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.
        
           | mfer wrote:
           | > 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.
        
             | rndhouse wrote:
             | Yes, I agree. There are two different audiences: public
             | software developers and public companies. And they both
             | need different interfaces. I love it.
        
         | hinkley wrote:
         | 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.
        
           | mfer wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2022-01-12 23:01 UTC)