by froztbyte on 2/14/17, 12:32 PM with 37 comments
by cimm on 2/14/17, 12:49 PM
by michaelt on 2/14/17, 1:23 PM
After all, if I install a package, which depends on something which depends on something which depends on a library for left-padding strings, it's unlikely the library author sees a cent. And each of those levels doesn't just have developers - they have package maintainers, people doing bug triage, people maintaining test infrastructure - and the tools those people use.
Unfortunately I think this would be very difficult to resolve - as the problem of fairly distributing donations would have a very large political element.
by willnorris on 2/14/17, 4:42 PM
by Joe8Bit on 2/14/17, 2:13 PM
* Knowing who (as an individual or an organization) you can give money to to reliably perform the work. So working out a way of managing this would be huge e.g. I want a feature added to Postgres, who the hell do I speak to? Are they reliable? Is their contribution likely to be accepted upstream?
* The tax/employment logistics can be painful, an intermediary could make that simpler. For large contributions you often have to support multiple people, and this becomes logistical complex VERY easily
* A lot of folks who make their living being supported to work on open source are scornful or outright malevolent towards the things that corps need (e.g. invoicing, statement of work, liability protection)
by lathiat on 2/14/17, 12:42 PM
I also Patreon to Jon Oxer for superhouse.tv (mainly for his YouTube videos) he's quite involved around various open hardware projects and open source in Australia - maybe not quitenyour traditional definition.
by whit537 on 2/14/17, 1:53 PM
by jjm on 2/14/17, 3:43 PM
by delegate on 2/14/17, 4:25 PM
Project maintainers should have the ability to 'forward' part of the received donation to other projects - without which the project wouldn't have been possible.
Which contributors, which dependency and how much to share - these questions are best answered by the project maintainer(s) - they can forward zero or all the funds and make the process automatic, so when a donation is received, the system automatically redistributes it to other accounts, as configured by the maintainer.
I've worked on a design spec for such a system some time ago: https://github.com/boomhub/design
I'd gladly resume work on it if anyone else feels like this is the good way to go. Just start by creating an Issue :).
by Midiv0k on 2/14/17, 1:03 PM
by brilliantcode on 2/14/17, 6:35 PM
by lathiat on 2/14/17, 12:55 PM
by akavel on 2/14/17, 1:34 PM
The questionnaire seems to be missing "desktop (GUI) apps" and probably "mobile apps" in "What you'd pay for?" section.
Also, the "time/effort" was weird for me; I don't feel it matches "funding" which sounds like money to me — or I didn't understand what it's intended to mean.
Some general thoughts:
On a related note, personally I don't like paying until I tried an app. But then OSS apps often ask for payment only just before/after downloading. I think a deferred approach is one of the reasons which helped me pay (donate) for the single OSS app for which I've done so yet: Calibre (https://calibre-ebook.com/). While the main reason was that it really struck me that it's an awesome, polished and easy to use app (especially for non-technical users in my family) while I was downloading it to n-th computer one day, it also shows some non-obtrusive but visible encouragement in its GUI (a big heart icon — feels encouraging, not nagging) reminding to consider donation.
From other somewhat interesting approaches, Aseprite (https://www.aseprite.org/) is actually GPL IIUC, but it provides the binary only with payment — thus more convenient (esp. for non-technical users, who I assume are majority of the targeted users group, i.e. artists) — although you can still just download and compile the sources for free. I'm very curious to what extent it's actually working for the author!
Moreover, I felt quite nice about itch.io's (http://itch.io/) approach, where a publisher can pick a "payment-optional" model. But as written above, I'd prefer to be gently reminded in-game from time to time (@leafo? whaddya think? feature idea for Refinery?). Also, I didn't really find a good enough game for me on itch yet, for which I'd feel like paying, unfortunately.
Finally, I think it'd be easy for me to pay for OSS games (dunno about other apps?) which would be parts of a bundle (ideally on gog.com; maybe Humble Bundle too, but as much as it started the bundles trend in awesome way, I feel it's fallen in quality and open-ness for me at some point in the past). I'm already paying for bundles, so if an OSS game got in there, I probably wouldn't even notice I can have it for free (nor I would complain later if I noticed, I believe). Though if it'd be explicit, I think I'd pay anyway (custom? convenience?).
P.S. Now that I think of it, seems what I describe here is kinda variation of "in-game/in-app purchases". Hm, maybe they could be also linked to some specially tricky features of an app, e.g. using some feature would also display non-obtrusive info "this feature was really tricky/took much love to implement/and is unique on market — a donation as act of gratitude would be an awesome gesture of appreciation!" obviously with an easy link.
Also, I think receiving a code enabling personalized label/annotation "Paid for by $DONATING_USER" could be a really cool bonus touch.
by mack1001 on 2/14/17, 2:11 PM
by whit537 on 2/14/17, 1:49 PM