5 ms·
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 poolin
by inputmice 6y ago
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.
- black_puppydog 6y agoI 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.
- OJFord 6y agoBut if you're targetting end users who haven't been to GitHub... aren't you just billing them for access to your app? Seems like a different problem to getting paid for OSS by people who do know how to find and use it for free.
- sbuttgereit 6y agoI think an even larger issue is that, I might know what OSS projects I make use of and will elect to support. But I might not have visibility into the OSS projects that _those_ projects themselves rely upon and really should be getting a cut. So as I see it the proposed solution does remove friction to supporting a large number of projects, but doesn't solve the visibility issue very well as I expect most projects to be in that "used by something I use" category.