search

gratipay / gratipay.com

Here lieth a pioneer in open source sustainability. RIP
https://gratipay.news/the-end-cbfba8f50981
MIT License
1.12k stars 308 forks source link

should be able to give non-anonymously #236

Closed chadwhitacre closed 6 years ago

chadwhitacre commented 12 years ago

Gittip Gratipay does not divulge who exactly gives to whom. The reason we do this is to preserve the "no-strings-attached" nature of the gifts. You know how unfriending someone on Facebook can be a big deal? We wanted to avoid that kind of friction. We also don't want receivers to feel pressured by their larger donors. Like, "if I piss off so and so, I'll lose X dollars." Better not to know in the first place so you're not on eggshells.

Now, when we launched we were very focused on individual-to-individual giving, but since then we've started bringing groups onto Gittip Gratipay.

For giving to individuals, I expect us to always stay "anonymous in the particulars" to avoid the social friction mentioned above.

For giving to groups, I think we can relax the constraint, allowing it to be double opt-in. If you give to a company or organization or project, we should let you advertise that. If a company gives to another company, we should make it possible to see that.

Update 2017-01-20: And now as Gratipay 2.0 we are only for giving to groups, i.e., projects.

Original

Turicas in IRC:

why tips must be anonymous? I think it should be up to who donates to choose between being anonymous or not in a transaction

As a receiver, I don't really want to know who you are. I do of course have people telling me in person or by other means that they tip me. Maybe it would be opt-in on both sides?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

chadwhitacre commented 9 years ago

A concern with this, would be, well what if I discover Chad donates to political party I hate.

Good point, @balupton. I suppose to satisfactorily address this we'd need to add the ability to deny gifts on a case-by-case basis, or even "I don't want to receive money from anyone who also gives to X."

chadwhitacre commented 8 years ago

+2 in #3883

chadwhitacre commented 8 years ago

This also plays into the question of whether Gratipay provides support for hard fees as well as soft fees: https://github.com/gratipay/inside.gratipay.com/issues/432#issuecomment-167126228.

mattbk commented 8 years ago

+1 use case from https://gratipay.freshdesk.com/helpdesk/tickets/4494. User has corporate sponsors who are interested in an invoicing system (which would require breaking anonymity) or ACH.

balupton commented 8 years ago

Good point, @balupton. I suppose to satisfactorily address this we'd need to add the ability to deny gifts on a case-by-case basis, or even "I don't want to receive money from anyone who also gives to X."

I was thinking more about what happened to Brendan Eich with Mozilla. It was discovered he donated personally to a anti-gay-marriage lobby, and it cost him his job as CEO - despite it being a personal thing.

Solution seems more for the individual to be able to hide which donations are public and which are hidden, as well as perhaps the receiver. I believe I've got into a few proposals of such a thing earlier.

balupton commented 8 years ago

For what it's worth, I'm developing an application that will pull in a github organisations sponsors from various services (patreon, paypal, stripe) and then evaluate how much they have donated all up over that month and correlate that to a reward tier. As gratipay donations are anonymous, it doesn't fit with it.

Project is in early days as I have other commitments for the next weeks, but can be found at https://github.com/bevry/sponsored

For comparison, Patreon's API is https://www.patreon.com/platform/documentation/api

chadwhitacre commented 8 years ago

From @balupton on #2621:

So far, only the following part is planned for it:

Champions are then listed in everything that the person/community does for the weeks they are champions — project READMEs, talks, etc. This is largely automated through the service provided APIs that can be quiried with the right tokens, and can use bevry/projectz to keep their readmes up to date. If a champions gittip donation changes or fails, they are no longer a champion, the service will autodetect this and email them in case it was a mistake with instructions on how to fix this.

balupton commented 8 years ago

What's the latest on this? Would love to show donors, who give on gratipay who opt-in to it being non-anonymous, on our website and in our readmes via hitting the gratipay API.

chadwhitacre commented 8 years ago

@balupton I'm hopeful we can get this done later this year.

tswast commented 7 years ago

+1 from me on this too. As a giver I would like to be able to opt in to allowing me to share my email address with who I give to. Making my donations to certain teams public could be nice, too, but not necessary.

As a receiver / team owner, I really want to be able to send a personal thank you to those who give to the team.

balupton commented 7 years ago

@whit537 any status update? I'm pushing up a service right now that allows reward fulfilment for different funding platforms - namely patreon right now, as they provide the necessary API calls - would be good to get gratipay support for it too

All I need for integration with my service is a call to see say the last 10 weeks of public donors, with how much they donated each week, and their email address

chadwhitacre commented 7 years ago

Thanks for thinking of us, @balupton! Unfortunately my hopes have been dashed. :( Hopefully in 2017! :-)

chadwhitacre commented 7 years ago

+1 from @sam-toland in private Slack, re: potentially using Gratipay for membership shares in a platform acquisition coop.

sam-toland commented 7 years ago

I think Gratispay could be used for the above co-op idea, particularly in the short-term.

:) And.... - we could also envisage this with Resonate too (website, github), with members making small contributions via Gratispay.

We could then link this with their Resonate account and we could count this against their Resonate membership contribution (which is €5 a year), and then recognise amounts above this with Resonate patronage points (used to calculate their contributions to the platform via dividend) or issuing them non-voting investor shares.

Q. If we began to use Gratipay today to take funds (under the anonymity rules), if this was changed at a later date - would we be able to retrospectively allow givers to identify themselves and allow us to reward them for past gifts?

balupton commented 7 years ago

For my use case. I can probably ask our sponsors for their gratipay user ID and API key.

/~username/payment-instructions.json provides the duration of a tip - however, it is a bit limited, and the ctime and mtime probably aren't useful - a tip that was active in the past, then cancelled, then created again, probably would not have the same ctime as the original

Would be nice if there was a call like /~username/donation-history.json?team=bevry which provides:

That way, I can cycle through all the tips from the user to the bevry account, calculate how much they've donated all time, and how much they've donated in a certain period (say current month, last month, last 4 weeks, etc)

With that, I can pull that data in, and do some nifty things with the extension service I'm working on

chadwhitacre commented 7 years ago

Alright! Some (good, hopefully? :) news! At https://github.com/gratipay/inside.gratipay.com/issues/987#issuecomment-274151963 we've decided to make this our next development focus. 👍

Wrapping my head around conversation to date and thinking about how to go about this ...

chadwhitacre commented 7 years ago

For @balupton's API case it probably makes sense to tie into the existing history API.

chadwhitacre commented 7 years ago

would we be able to retrospectively allow givers to identify themselves and allow us to reward them for past gifts?

Hmm ... we'd have to specifically build it that way, which would be more complicated.

chadwhitacre commented 7 years ago

Prior art: https://github.com/gratipay/gratipay.com/pull/3112.

chadwhitacre commented 7 years ago

Soooo ... what emerged on #3112 (w/ links back to this thread) is that this gets reeeeeeeeal complicated real quick. Are we looking at a Facebook-style fine-grained sharing implementation? That sounds like a nightmare to me, both from a user experience and privacy angle, and in terms of implementation difficulty and maintenance burden. To avoid that, we need to trim the possibility space ... but that still means comprehending it first.

chadwhitacre commented 7 years ago

Let's take it that:

There's the matter of what is shared:

And there's the matter of who it is shared with:

The reality today is fixed for all payment instructions at:

The ... name w/
recipient.		 amount w/
recipient.		 name w/
public.		 amount w/
public.
receiver is willing to share the ... yes / no yes / no yes / no / maybe yes / no / maybe
giver is willing to share the ... yes / no yes / no yes / no yes / no

Further complicating factors:

chadwhitacre commented 7 years ago

A couple further lines of inquiry:

Bit of a mess. 😳

tswast commented 7 years ago

My preference as a giver would be to allow sharing identity, optionally the amount, with the recipient.

It hadn't occurred to me to share it publicly, but then again I might not have stepped as far into radical openness.

chadwhitacre commented 7 years ago

Can we simplify via profiles?

Actually, I think the way to simplify is by cutting out the variation on the receiver side.

Back at the beginning, Gittip receivers were all individuals, and payments were understood to be no-strings-attached mini-genius grants. Giving was a very personal act, very close to a positive judgement of someone's worth as a person. Retracting a payment was therefore fraught with interpersonal peril, and enforced anonymity was designed to reduce this peril.

Now, of course, we've phased out giving to individuals entirely (and Patreon has generally shown that anonymity was probably never that important vis-a-vis individuals in the first place 😆 ). All projects on Gratipay are understood to be just that: projects, not individuals (even if the project happens to be a "team of one"). I am ready to say that if someone takes their project so personally that knowing the identity of the retractor of a payment is a source of significant anxiety, that's their problem. I think instead that projects should want to know who starts and stops giving, so that they can tune the products and services they provide, whether in the aggregate, or in particular. I'm seeing this as a natural step in Gratipay's evolution from individuals, to individuals + teams, to teams, to projects. 👍

(I can imagine a project that wouldn't want to know, but I'm willing to say that we don't support that, for the sake of simplifying our task here. The full set of combinations is just too complicated to support.)

Here's my proposal:

* I think @chrisdev's case is actually more about collecting addresses for those who are not anonymous, which is out of scope. Surely charities must be able to receive anonymous donations!

chadwhitacre commented 7 years ago

My preference as a giver would be to allow sharing identity, optionally the amount, with the recipient.

Hopefully we can offer both identity and amount options without too much clutter. 👍

It hadn't occurred to me to share it publicly, but then again I might not have stepped as far into radical openness.

Interesting. I actually [don't like the term "radical" 😝 and] wouldn't see this as necessarily that radically open. Don't most other crowdfunding sites such as Kickstarter, Patreon, and Open Collective default to public sharing?

chadwhitacre commented 7 years ago

@balupton @sam-toland What's your feedback from the receiver side?

mattbk commented 7 years ago

EDIT: I've reconsidered. See below.

I think instead that projects should want to know who starts and stops giving, so that they can tune the products and services they provide, whether in the aggregate, or in particular.

I disagree that this should be the default, because this is the antithesis (if that's not too strong a word) of what Gratipay has been about. Whether you were giving to an individual or are now giving to a project, the gift has been a gift without strings because the giver was/is anonymous.

I don't know the technical solution, though, especially if the project has the option to toggle off/on anonymity (e.g., to appear as though they only accept anonymous donations, but in reality knowing exactly who was giving the most, and changing behavior accordingly. I don't know why someone would do this, so it may be an edge case.)

I guess it would really boil down to the hobbyist versus project that is trying to break out and raise some real money. It's awesome if you fiddle around with code in your spare time and some people chip in $5 a week for it, but it (subjectively?) becomes less awesome when you realize the person giving you most of that $5 is the neediest person in your issue queue. That being said, you should ask someone who is in that position--I've made more money working for Gratipay LLC than I have from my own project on Gratipay!

balupton commented 7 years ago

Here's my proposal:

Require that projects be willing to accept all types of payment. Only givers can modify sharing. That removes the need for a) any new settings on the receiver side, b) overrides on the receiver side, and c) opt-in of any kind.* Givers get default sharing settings, plus per-instruction overrides. The default default is give anonymously for existing participants, and share publicly for new participants. No per-payment overrides or retroactive application.

Sounds good to me. Is a simplified version that still accomplishes the actual needs, versus some imaginary desires, of what I proposed at https://github.com/gratipay/gratipay.com/issues/236#issuecomment-24893774

No per-payment overrides or retroactive application.

What does this imply? I am not familiar with what Gratipay considers a payment instruction. I think:

I disagree that this should be the default, because this is the antithesis (if that's not too strong a word) of what Gratipay has been about. Whether you were giving to an individual or are now giving to a project, the gift has been a gift without strings because the giver was/is anonymous.

I agree. Also things like someone losing their job over who they have given money to in their private life is silly

The need for givers to have their donations private is essential. As the examples of people being discriminated against for their political views and whatnot is high, and also high even in the tech world. So the cost of people's donations being public is very high. - this will be accomplished by your proposal Chad

The need for receivers to have their donations private is hard to pin as essential. I can imagine problems for this only in the political arena - e.g. Clinton receiving money from Wall Street, or Trump giving money to Clinton earlier - I can't think of tech examples, even in political journalism, where a simple "oh, they donate to me, ask them why they do it" won't suffice. - and for now I don't think anyone at all has expressed a need for this empowerment, until they do, it just seems a imagined desire

nobodxbodon commented 7 years ago

+1 to @whit537's proposal and the thoughts behind in https://github.com/gratipay/gratipay.com/issues/236#issuecomment-274213874. Additionally, as the emphasis is more on new company givers, the trimming down seems particularly proper to me.

mattbk commented 7 years ago

I disagree that this should be the default (https://github.com/gratipay/gratipay.com/issues/236#issuecomment-274223269)

I've reconsidered. The proposal at https://github.com/gratipay/gratipay.com/issues/236#issuecomment-274213874 sounds good to me. That's what people want now, and if there is groundswell of support for going back to the Gittip version of anonymity, I'd be behind adding that functionality, but for now let's move forward.

chadwhitacre commented 7 years ago

What does this imply? I am not familiar with what Gratipay considers a payment instruction.

Our payment_instructions holds the abstract info about weekly recurring payments. The payments table holds the actual payments in a given week. (For completeness, the exchanges table holds transactions between Gratipay and the outside world, e.g., PayPal.)

a change of privacy for a payment to an entity should affect future payments and past payments to that entity from that giver

Future payments: yes. Past payments, I'm not so sure. I was thinking not. Once that info is out there, can it really be taken back? With the rewards platform you're building, once you scrape that data, it's too late to pull it back. No?

That said, I'm having second thoughts about foisting non-anonymity on existing projects. Can we make it a simple either/or, without all of the complication and opt-ins? Either a project only accepts anonymous payments (as now) or they accept any type.

share my email address with who I give to. Making my donations to certain teams public could be nice, too, but not necessary. […] As a receiver / team owner, I really want to be able to send a personal thank you to those who give to the team.

@tswast For your use case it sounds like you'd be more interested in something like https://github.com/gratipay/gratipay.com/issues/2521, maybe?

chadwhitacre commented 7 years ago

I should also say that I'm reaching some clarity that the driver here from the receiver side is being able to provide specific rewards/products/services to specific givers. This is not on the critical path to providing reputational benefit to companies for supporting open source, which we were able to do with seeming adequacy under Gittipay 1.0 by recognizing company giving in aggregate, and which I think we could get back to under https://github.com/gratipay/inside.gratipay.com/issues/987 via https://github.com/gratipay/gratipay.com/issues/4297 without going through this ticket.

That is, there seem to be three points on a spectrum:

Donation — Rewards — Products

Today Gratipay is only about the donation side. Traditional commerce is on the right, fee for service. Kickstarter/Patreon occupy the somewhat awkward middle ground where part of the value is reputational (you are listed as a backer or supporter), and part is concrete (you receive a reward in the mail).

On that model, I'd almost rather see us implement this as a product listing feature than a rewards feature, to keep the clarity of the existing donation model. So projects would list products/services, and companies would either give anonymously, or make a purchase. The latter case is where we would, of course, divulge to the project the amount of the purchase and identity of the purchaser. This becomes a "store" feature, in other words.

tswast commented 7 years ago

Yes, actually #2521 would be sufficient for my thoughts. A backer update tool could be used to share patreon-like rewards with donors.

chadwhitacre commented 7 years ago

This is not on the critical path to providing reputational benefit to companies for supporting open source

Removing from the Recognize companies project, therefore.

balupton commented 7 years ago

pushed up the first public commit of my earlier mentioned sponsorship service - gratipay task over at https://github.com/bevry/sponsored/issues/3

balupton commented 7 years ago

https://github.com/gratipay/gratipay.com/issues/236#issuecomment-273967520

Would be nice if there was a call like /~username/donation-history.json?team=bevry which provides:

an array of objects, each object is a week's tip information That way, I can cycle through all the tips from the user to the bevry account, calculate how much they've donated all time

any chance at getting this api call added in the meantime? or something similar,

at the most essential level, all I need is someway of knowing the total given amount over all time

I've also updated https://github.com/bevry/sponsored with more info on the goals of the project

chadwhitacre commented 7 years ago

+1 from @ntnsndr at https://social.coop/@ntnsndr/17510.

I can't figure out how to respond (remotely?) on Mastodon or I would. 😞

ntnsndr commented 7 years ago

Yes please! We need this to use Gratipay as the basis for co-ops.

∴ Nathan Schneider nathanschneider.info

On May 1, 2017 3:04:27 PM MDT, Chad Whitacre notifications@github.com wrote:

+1 from @ntnsndr at https://social.coop/@ntnsndr/17510.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/gratipay/gratipay.com/issues/236#issuecomment-298432317

ntnsndr commented 7 years ago

And pseudonymous would be okay!

Let's think.about features that.could even do more to make gratipay the go-to tool for new co-ops.

∴ Nathan Schneider nathanschneider.info

On May 1, 2017 3:04:27 PM MDT, Chad Whitacre notifications@github.com wrote:

+1 from @ntnsndr at https://social.coop/@ntnsndr/17510.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/gratipay/gratipay.com/issues/236#issuecomment-298432317

chadwhitacre commented 6 years ago

Closing in light of our decision to shut down Gratipay.

Thank you all for a great run, and I'm sorry it didn't work out! 😞 💃