3 ms·

OP here. I'd love to see something like this exist. Let me know if it does already, or if someone is trying, and I'll link it below. EDIT: This model is used b

OP here. I'd love to see something like this exist. Let me know if it does already, or if someone is trying, and I'll link it below. EDIT: This model is used by Flattr [0]. Unfortunately Flattr isn't targeted at open-source software; an OSS-specific approach (ideally implemented by a highly visible, established player) is (probably) necessary for something like this to reach its potential. [0] https://flattr.com/ https://flattr.com/

verdverm 6y ago
Have a look at https://coss.media https://coss.media and Sid of GitLab interview with Joe Jacks
quadrangle 6y ago
What you propose exists. It's https://flattr.com/ https://flattr.com/ It hasn't made enough impact over its long history. That's not necessarily because the model doesn't work. However, it does set up a zero-sum game. Each click to another project takes away from the ones you already support. Thus, it won't really change the overall economic situation much. There are also foundations that sponsor multiple projects. E.g. Apache. There are meta-level projects like Ubuntu. In principle these larger downstream projects should do what's necessary to support their upstream dependencies. That doesn't always happen though. Tidelift does funding that emphasizes awareness of upstream dependencies and supporting them. ## On microdonations and fees This is a payment-processor issue. I believe that Stripe and some others have the capacity to process aggregate charges without all separate. So, if in a platform, you donate $10 to 15 different projects and so do many others, they could charge you the one charge of $10 and give the recipients their single payment from everyone. Each donor would get one processing fee, not one for every project they support. This is key. And it cannot be solved at the platform level because holding funds in escrow is only feasible if you are a limited specific set of incorporated projects (that's what Open Collective helps support, they can do this approach with one donation fee for each Collective you donate to, even though the Collective could include a lot of projects. A specific Collective there could offer your system. In other words: Open Collective could do what you're asking somewhat. You donate to a Collective. They don't just have the money for any of their members, the Collective offers a tool for you to vote on which of the members you want to support. That's another way to see your proposal: An org that accepts donations and you get to vote on which projects they give grants to. ## On downstream vs upstream funding Anyway, the bigger problem in free/libre/open funding is that it relies too much on proprietary end-user products that have paywalls or ad-driven business models. If a product is designed to reach all the way to downstream users, everyone can freeride. So, freerider problem, game-theory dilemmas. You might be interested in the ideas at https://snowdrift.coop https://snowdrift.coop which is aiming to build downstream patronage via crowdmatching. The wiki there also has reviews of the issues: https://wiki.snowdrift.coop/about/existing-mechanisms https://wiki.snowdrift.coop/about/existing-mechanisms https://wiki.snowdrift.coop/about/economics https://wiki.snowdrift.coop/about/economics and this is a thorough review of all the existing funding platforms: https://wiki.snowdrift.coop/market-research/other-crowdfunding https://wiki.snowdrift.coop/market-research/other-crowdfundi... There's a long history of failed efforts, some mentioned at https://wiki.snowdrift.coop/market-research/history/software https://wiki.snowdrift.coop/market-research/history/software Cheers
- jacques_chester 6y ago
  One thing that Flattr and many others like them got wrong, in my view, was collecting too little and levying too little from it. Too many schemes were $5/month or $3/month, then collecting 10% or thereabouts. You cannot build a sustainable business with high risk exposure for less than a fraction of cup of coffee per customer per month. But people kept bloody trying.
zaarn 6y ago
https://liberapay.com/ https://liberapay.com/ Liberapay sort of does it that way, though their payment processor has made it somewhat difficult. Basically you pay them 50$ and then you decide how much you're going to sent to projects and how often. For example, I donate about 0.50ct each month to mastodon (sadly I do not have much expendable income at the moment). But it means I can spread little money into donations over an entire year. I think they still need to make a percentage-mode, where I allocate money from my pool on percentages (ie, 20% of the money to mastodon over a year, every month, results in 0.83$ every month being transferred, or 10$ over the year)
smichel17 6y ago
Hi, I'm one of the Snowdrift.coop cofounders. We actually planned on a wallet approach early on, and still consider it the superior option in many ways Not all), but we're launching with a monthly charge model because holding money is more complicated legally. To avoid higher fees for microtransactions, we're delaying donations until they total high enough to keep fees below 10%, then doing one charge for several months (ie, charging in arrears). You don't need a wallet approach to do one-click, though. Just the ability to do many:many charges, which several payment platforms support (usually under "services for ecommerce platforms", like Stripe connect, if I'm remembering the name correctly). That lets you send one bill to each patron that totals their donations to projects, and one paycheck to each project, that totals all the individual donations from various patrons, avoiding a fee per patron-project-month combination. --- Broadly, we don't agree that friction is the core barrier to donations (although lower friction certainly helps!). Instead, we think the barrier is people's reluctance to be the first to donate. Colloquially: people would pitch in if they knew it would lead to enough funding to be useful (ie, actually pay full time developer salaries), but nobody wants to be the chump wasting their money on 2 minutes of developer time per month (which will really be 0 minutes per month, because you can't hire 0.01% of a developer). That's why crowdmatching donations start small and grow as more people support the same project as you. Coming back to the article, I'd argue that both big and small projects alike have trouble soliciting donations from individuals (for the reason above). The difference is, large infrastructure projects can solicit funding from large companies that depend on them. These companies can donate enough money to single-handedly make a difference, so there's no coordination problem. Consider LibreOffice: they're a large project, and their potential audience is even larger. But, their primary benefactors are end users, and they struggle to make ends meet. Snowdrift.coop won't address the small-project funding issue right away, since in order to actually get launched some time this decade we're restricting our initial scope to large projects with the potential to really change the software landscape if they were well funded -- but we do want to expand our focus later, both to smaller projects and areas outside of software, like journalism, music, and research, which suffer from similar coordination problems.

verdverm 6y ago

Have a look at https://coss.media https://coss.media and Sid of GitLab interview with Joe Jacks

quadrangle 6y ago

What you propose exists. It's https://flattr.com/ https://flattr.com/ It hasn't made enough impact over its long history. That's not necessarily because the model doesn't work. However, it does set up a zero-sum game. Each click to another project takes away from the ones you already support. Thus, it won't really change the overall economic situation much. There are also foundations that sponsor multiple projects. E.g. Apache. There are meta-level projects like Ubuntu. In principle these larger downstream projects should do what's necessary to support their upstream dependencies. That doesn't always happen though. Tidelift does funding that emphasizes awareness of upstream dependencies and supporting them. ## On microdonations and fees This is a payment-processor issue. I believe that Stripe and some others have the capacity to process aggregate charges without all separate. So, if in a platform, you donate $10 to 15 different projects and so do many others, they could charge you the one charge of $10 and give the recipients their single payment from everyone. Each donor would get one processing fee, not one for every project they support. This is key. And it cannot be solved at the platform level because holding funds in escrow is only feasible if you are a limited specific set of incorporated projects (that's what Open Collective helps support, they can do this approach with one donation fee for each Collective you donate to, even though the Collective could include a lot of projects. A specific Collective there could offer your system. In other words: Open Collective could do what you're asking somewhat. You donate to a Collective. They don't just have the money for any of their members, the Collective offers a tool for you to vote on which of the members you want to support. That's another way to see your proposal: An org that accepts donations and you get to vote on which projects they give grants to. ## On downstream vs upstream funding Anyway, the bigger problem in free/libre/open funding is that it relies too much on proprietary end-user products that have paywalls or ad-driven business models. If a product is designed to reach all the way to downstream users, everyone can freeride. So, freerider problem, game-theory dilemmas. You might be interested in the ideas at https://snowdrift.coop https://snowdrift.coop which is aiming to build downstream patronage via crowdmatching. The wiki there also has reviews of the issues: https://wiki.snowdrift.coop/about/existing-mechanisms https://wiki.snowdrift.coop/about/existing-mechanisms https://wiki.snowdrift.coop/about/economics https://wiki.snowdrift.coop/about/economics and this is a thorough review of all the existing funding platforms: https://wiki.snowdrift.coop/market-research/other-crowdfunding https://wiki.snowdrift.coop/market-research/other-crowdfundi... There's a long history of failed efforts, some mentioned at https://wiki.snowdrift.coop/market-research/history/software https://wiki.snowdrift.coop/market-research/history/software Cheers

jacques_chester 6y ago
One thing that Flattr and many others like them got wrong, in my view, was collecting too little and levying too little from it. Too many schemes were $5/month or $3/month, then collecting 10% or thereabouts. You cannot build a sustainable business with high risk exposure for less than a fraction of cup of coffee per customer per month. But people kept bloody trying.

zaarn 6y ago

https://liberapay.com/ https://liberapay.com/ Liberapay sort of does it that way, though their payment processor has made it somewhat difficult. Basically you pay them 50$ and then you decide how much you're going to sent to projects and how often. For example, I donate about 0.50ct each month to mastodon (sadly I do not have much expendable income at the moment). But it means I can spread little money into donations over an entire year. I think they still need to make a percentage-mode, where I allocate money from my pool on percentages (ie, 20% of the money to mastodon over a year, every month, results in 0.83$ every month being transferred, or 10$ over the year)

smichel17 6y ago

Hi, I'm one of the Snowdrift.coop cofounders. We actually planned on a wallet approach early on, and still consider it the superior option in many ways Not all), but we're launching with a monthly charge model because holding money is more complicated legally. To avoid higher fees for microtransactions, we're delaying donations until they total high enough to keep fees below 10%, then doing one charge for several months (ie, charging in arrears). You don't need a wallet approach to do one-click, though. Just the ability to do many:many charges, which several payment platforms support (usually under "services for ecommerce platforms", like Stripe connect, if I'm remembering the name correctly). That lets you send one bill to each patron that totals their donations to projects, and one paycheck to each project, that totals all the individual donations from various patrons, avoiding a fee per patron-project-month combination. --- Broadly, we don't agree that friction is the core barrier to donations (although lower friction certainly helps!). Instead, we think the barrier is people's reluctance to be the first to donate. Colloquially: people would pitch in if they knew it would lead to enough funding to be useful (ie, actually pay full time developer salaries), but nobody wants to be the chump wasting their money on 2 minutes of developer time per month (which will really be 0 minutes per month, because you can't hire 0.01% of a developer). That's why crowdmatching donations start small and grow as more people support the same project as you. Coming back to the article, I'd argue that both big and small projects alike have trouble soliciting donations from individuals (for the reason above). The difference is, large infrastructure projects can solicit funding from large companies that depend on them. These companies can donate enough money to single-handedly make a difference, so there's no coordination problem. Consider LibreOffice: they're a large project, and their potential audience is even larger. But, their primary benefactors are end users, and they struggle to make ends meet. Snowdrift.coop won't address the small-project funding issue right away, since in order to actually get launched some time this decade we're restricting our initial scope to large projects with the potential to really change the software landscape if they were well funded -- but we do want to expand our focus later, both to smaller projects and areas outside of software, like journalism, music, and research, which suffer from similar coordination problems.