A new funding model for open source software • Hacker News Board

Re: A new funding model for open source software

#101

Post by black_puppydog » Thu, Jul 30, 2020, 8:48 AM UTC

inputmice wrote: post #76

Two issues here: Models like these existed. Flattr and Liberapay. The latter had to switch away from the pooling model because turns out when you do the pooling you essentially become a bank and that’s difficult to do legally. Those models only work if users actually visit your website or your Github. I’m developing an app targeted at end users and I bet 90% of them have never been on Github or even know what that is…

I totally take your second point. But for the niche of apps that is developed for tech folks (think sth like ripgrep) this seems pretty viable.

For user-facing apps, it should always be the platform(s) distributing it that should have a pool mechanism. So google for android apps, Apple for iOS. Yeah, I know, that'll be a cold day in hell...

PC software is a tough one there since there's no one app store. Which is the PC platform's strength, but yeah, that makes a pool difficult. As you said, Liberapay tried something like this. Would be cool if something like this could become big enough to justify the legal legwork necessary for this.

Re: A new funding model for open source software

#102

Post by maccard » Thu, Jul 30, 2020, 8:53 AM UTC

black_puppydog wrote: post #100

colinmcd wrote: post #71

Earlier quoted context omitted.

Author here - 100% agree on all fronts! I was dancing around this conclusion but it really does need to be GitHub. And I agree people would be fine paying their own fees if it came to that. Also, in that case, if someone is donating a non-trivial amount, they're incentivized to fund their wallet with a cheaper payment method like an ACH transfer.

I just want to point out that in Europe we have 0-fee SEPA transfers that also work for regular payments. I'm not sure why nobody makes use of that more really. There are simple-as-paypal solutions for it, and given the amount that CC processing costs I'd have expected it to be picked up more. Maybe someone here has practical experience to share on why it's not that easy?

What happens if the transaction is fraudulent?

Re: A new funding model for open source software

#103

Post by [deleted] » Thu, Jul 30, 2020, 8:54 AM UTC

[deleted]

Re: A new funding model for open source software

#104

Post by black_puppydog » Thu, Jul 30, 2020, 9:03 AM UTC

maccard wrote: post #102

black_puppydog wrote: post #100

Earlier quoted context omitted.

I just want to point out that in Europe we have 0-fee SEPA transfers that also work for regular payments. I'm not sure why nobody makes use of that more really. There are simple-as-paypal solutions for it, and given the amount that CC processing costs I'd have expected it to be picked up more. Maybe someone here has practical experience to share on why it's not that easy?

What happens if the transaction is fraudulent?

This might actually be the right question to ask, thanks for poking. :)

From a customer's perspective, fraudulent transactions are handled in the best way possible. Here's Stripes docs on it [1]:

> Customers can dispute a payment through their bank on a “no questions asked” basis up to eight weeks after their account is debited. Any disputes within this period are automatically honored.

> After eight weeks and up to 13 months, a customer can only dispute a payment with their bank if the debit is considered unauthorized. If this occurs, we automatically provide the bank with the mandate that the customer approved. This does not guarantee cancellation of the dispute; the bank can still decide that the debit was unauthorized and the customer is entitled to a refund.

> Unlike credit card disputes, SEPA Direct Debit disputes are final and there is no process for appeal. If a customer successfully disputes a payment, you must contact them if you want to resolve the situation.

So for a small company I can see how this process would be stressful. Although I'm not sure what the rate of fraud by the customers would be. After all, the customer still signed a contract. But that would likely need litigation then.

So, I haven't been on the vendor side of that. Not sure how much more stressful it is than CC, and if it's worth a few % of your revenue...

[1]: https://stripe.com/docs/payments/sepa-debit#disputed-payment...

Re: A new funding model for open source software

#105

Post by sqrt17 » Thu, Jul 30, 2020, 9:11 AM UTC

andrewstuart wrote: post #88

The problem here is marketing..... "sponsor pools" "sponsorships" and "donations" are all words that imply optional, not required requests for money as a favor. i.e. begging. The way to monetise open source is for payments to be required in some way. i.e. provide a core feature set that is valuable on its own and monetise by providing additional valuable features under a commercial license.

You're missing the point here. The point is not to find ways to sell/rent out software (these already exist) but to monetize open source projects in a non-forced, non-compulsory way.

So, instead of selling your songs on a CD for a fixed price, that approach would be more like busking or having your music streamed on music services (Spotify, Apple Music, YouTube Music, etc.). It's unlike begging in that you do provide valuable goods with the expectation that the community is paying, and that providing better value (more catchy songs) will get you more revenue.

Non-required payments already work ok in a number of shapes for music and video creators, and we've seen some success in terms of feature bounties and direct sponsorship in software.

Given that enough people are willing to support the software they use, there are two things missing in the equation

- an entity collecting, pooling, and distributing money in a transparent (enough) fashion - the prime candidate would be GitHub because it already has sponsorships and the necessary bits of information

- an attribution model; and this is a bit harder for software than for music or videos where you can simply use watchtime as an attribution metric. Software has a more complex dependency graph, and arguably open source software is the silver bullet that allows us to stand on the shoulders of a herd of giants instead of implementing our bloom filters, routers etc. ourselves. This is a hard problem, and arguably one in danger of not being solved "correctly" in that an entity collecting money could do something intransparent and unfair and people might still sign up because it's the only game in town and they want the warm fuzzy feels and the convenience of not having to write 0.50$ checks to a gazillion small-project maintainers.

Re: A new funding model for open source software

#106

Post by imtringued » Thu, Jul 30, 2020, 9:15 AM UTC

ZinniaZirconium wrote: post #22

OK my project is open source. I have zero stars, zero downloads, and zero users. How much do I get paid? Zero? But I wrote open source code that solves a real problem. It's open source. I should deserve to get paid. Because open source software. I don't think your funding model works.

I don't think the article made the argument that you should be paid unconditionally. It only suggested that it should become easier to donate to multiple projects with a single click.

I'm not convinced that a funding model doesn't work because it pays nothing to a project nobody (not even its own creator) has heard of.

Re: A new funding model for open source software

#107

Post by NicoJuicy » Thu, Jul 30, 2020, 9:24 AM UTC

ekianjo wrote: post #99

peteforde wrote: post #63

I think that this essay is fundamentally brilliant, but doesn't come out and yell the self-evident truth: the ONLY way this ever takes off is if Github does it. And man, do I ever hope that they do. There's no other entity in the ecosystem that even approaches the role Github plays, with all due respect to Gitlab and the rest of the also-rans. It'd be wonderful if they did the same thing, but in the end, they are goi…

> the ONLY way this ever takes off is if Github does it. Yes, let's encourage another walled-garden controlled by a dominant player which would be benefiting from FOSS donations (keeping % of it) while doing nothing to make GitHub a FOSS platform at the same time.

Please inform yourselve. GitHub does not take a single penny!

They even cover payment fees.

https://github.com/sponsors#:~:text=GitHub%20does%20not%20ch....

Re: A new funding model for open source software

#108

Post by bnkamalesh » Thu, Jul 30, 2020, 9:27 AM UTC

dimitrios1 wrote: post #70

I like the idea but instead of pools going arbitrarily every which way or to the discretion of the donator, it should be automatically applied across that open source project's dependencies as well. If I am open source software A, and I make ample use of open source software B within my project, your pool donation should automatically apply some to B, relative to it's usage in the project.

Distribution indeed seems to be tricky. Out of the myriad of utilities you use, e.g. React & a string sorting library. Should they both receive the same remuneration? That feels wrong.

Re: A new funding model for open source software

#109

Post by [deleted] » Thu, Jul 30, 2020, 9:29 AM UTC

imtringued wrote: post #89

I expected Youtube Red to work like this. Each person has its own pool. Channels should have been weighed by watch time with a minimum weight so that small channels get something as well. If I watch one channel then that channel should get the whole $10 (minus youtube cut). Instead we got a stupid global pool based on global popularity that primarily benefits PewDiePie even if I don't watch him. The compensation was…

[deleted]

Re: A new funding model for open source software

#110

Post by NameDoesntExist » Thu, Jul 30, 2020, 9:34 AM UTC

JimDabell wrote: post #83

colinmcd wrote: post #73

Earlier quoted context omitted.

Agreed this would be nice, though this layer of complexity introduces a bigger attack surface for bad actors. They could try to get their modules listed as dependencies of popular projects to piggyback on their downloads. On the flip side there are some low-level tools (say, the `stylis` CSS autoprefixer) that are almost never used in their "raw form" but are the backbone of several massively popular projects. It's a…

Is this really a concern though? In this situation, adding a dependency to your project means making a decision to divert some of your funding to them as well. It gives an incentive to avoid adding unnecessary dependencies.

Workaround: fork all your dependencies with minimal if any changes and add them back to your main project.

This allows you to cut-off the trickle-down funds in bad faith.