In Problems with crowdmatching + proposing an alternative, @sandra.snan proposed a new protocol, now called preshold (from precise-threshold).
That thread had a lot of discussion comparing preshold to crowdmatching, and thinking about the optimal audience for each. In this thread, I’d like to focus on finding the best possible variant of preshold.
Note: I moved a few replies here from the original thread, so they may feel slightly out of context.
I think it will be clearest about the distinctions I’ve made and the ways the two systems serve different project cases with real examples. If you can, give me an example of a real project you have in mind that you imagine working well with your model.
Overall, great replies. Thanks for reading me charitably and carefully, I appreciated that very much.
curves taper off
That’s fine; that’s not the main point I was trying to make with them.
As far as I understand it, crowdmatching has several mechanisms that work against maximizing the quantity of patrons.
like what?
This is something I’ve tried to explain in my posts. Since crowdmatching is a very unappealing pitch to me, and precise-threshold is, I generalized those sentiments to the public.
But I have no real researched data on that except asking a friend who did agree with me but we usually tend to think alike so that doesn’t say much.
I’m repeating myself, but some of those mechanisms are:
• uncertainty of amount of donation (mitigated by “monthly cap” system)
• uncertainty that my donations are truly needed (because the chaotic matching)
• discomfort with perceived mismatch of “matching” concept, general “I don’t get it…?” sensation
• fear of the system being gamed
In short, the two fears are “Am I donating to a project that’s doomed anyway” and “Am I donating to a project that’d be successful anyway”. These two fears are eloquently summed up by the game theorists that originally described the Snowdrift Dilemma. The precise-threshold protocol is intended to address those two fears.
[People have been asking] “I give more when more donors join, that seems backwards, I thought I’d be able to give less when others join”
Yes! That’s exactly why I came up with precise-threshold!
In prec-shold the minimum and the maximum is the same level.
Can you come up with any real-world example where this is a good fit?
It’s not just that it’s a good or bad fit, it’s part of what makes the protocol work.
Any project where monthly salaries, “living wages”, are on the line are appropriate fits for this. A FLO project that wants to hire a programmer full time for a couple of months to clear up the issue tracker backlog, an artist who wants to quit her day job…
Would they appreciate a higher maximum to make a little extra on good months, or a lower minimum to have an “atleast I’ll make rent, I’ll have to skip one month of phone bills” situation going? Yes, but prec-shold was designed to ease the mind of potential patrons.
Precise-threshold is about the concept of enough. You can’t get by with less than enough, and you don’t need more than enough.
To clarify three things:
The third and biggest clarification needed here:
I want to clarify that the precise threshold isn’t set in perpetuity. It can change. “OK, my dear patrons, we’ve laid off the editor so you’re going to see rougher cuts but the threshold has been lowered so hopefully it can be met more often and we’ll release more episodes” or “I’ve taken on the help of a colorist so the threshold is now higher to pay for her, but the episodes will look clearer and more beautiful, hope you like it”.
Increasing the burden of my fellow patrons is demotivating to me
This is a core insight. It’s personal, social, emotional… not part of game-theory math.
The math aspect of that is that their financial burden is increasing when I join a crowmatching campaign.
Please self-reflect that your preference for crowdmatching also has a significant personal, social and emotional component, as we discussed with the “bike-a-thon” example.
The name “precise-threshold” comes from bidding games. In Bridge if you take more tricks than you bid for, you get bonus points. (There are mechanics in Bridge’s scoring and bidding system that encourage you to bid exactly as many tricks as you’re going to take, please disregard those for this particular analogy.) In games like Oh Hell and Ninety-Nine, you need to take precisely as many tricks as you bid. If you take too many, you bust. These games are called “precise”, “precision trick taking”, “precise-bidding”, “precise trick taking” and variations. (I used to work as an editor for The Journal of Games and Puzzle Design so that’s why I went to world of game design vocabulary for this.)
It’s dangerous and unreliable
We’ve both been dismissive of Patreon in the past but in many ways I see precise-threshold as “improved Patreon” or “fixed Patreon”. It’s less appealing for projects in favor of being significantly more appealing to presumtive patrons.
However, this critique is applicable to Patreon as well. Planning your own finances while living on Patreon money is difficult. This aspect of quitting your day job in favor of living on Patreon money is very frightening, I agree, and I’m not sure what the current best practice is. I’d like to know because I hope to be supported that way too, if and when I become more skilled as an artist.
This is a good counter-argument to the “progress should be hidden” aspect of precise-threshold, but that’s there to prevent “self-pledge sniping”. Not sure which is worse, Scylla or Charybdis, but since precise-threshold is designed primarily to appeal to patrons rather than appeal to projects, that uncertainty might be worth it.
Being in a situtation where the pledges are made in advance and you have a day job where you can work flexible weeks – say you’re able to take on an extra month here and there unless you get a month paid by your patrons – would be ideal but that’s not easy to set up.
less stable than crowdmatching
If you want to support yourself with crowdmatching, you still have bills to pay. Rent, food etc. That’s an implicit “threshold” for you as creator.
If you get above that line w/ crowdmatching, you drop your day-job, and then if it decreases suddenly (and quadratically because the nature of crowdmatching), it all fails as well.
This is another example where you are very good at identifying dilemmas and problems, but then crowdmatching doesn’t solve those problems either.
How does it work if people realize they want to increase the threshold? That’s risky too.
You can tell when there’s a lot of overpay and you can make a post explaining why you’re increasing the threshold. Inflation, higher rent costs, employing someone else… It’s risky, yes, if your patrons don’t buy the case you’re making. Again, the protocol is designed to favor patrons because they’re the ones I want to appeal to.
Doesn’t the success after a month provide enough foundation to undermine the secrecy of the negotiations (i.e. the value of not showing progress toward threshold)?
The secrecy is there to prevent last-minute self-pledge sniping. If there is success without self-pledge, i.e. threshold is met, the negotiations were successful without need for further secrecy.
But let’s say you self-pledged $200 and after a couple of months of success with that, you can start adjusting that to $50 if you find you get a lot of overpay (but be careful, you’ll also lower the overpay refunds for all your patrons causing some of them to drop) or you can adjust your self-pledge upwards to $250 if you’re dangerously close to not making it, at the expense to you and at the benefits of your patrons, receiving more overpay.
That’s the protocol working as intended.
A last-minute self-pledge snipe is “We’re $200 short, I’ll self-pledge that right away and boom we made threshold and no overpay”. That breaks protocol.
“We’ve tended to be about $190 short, so I’ll keep self-pledging $200”, that’s fine. That’s self-pledging working as intended. You might still under- or overfund.
Remember, self-pledging isn’t actually good – projects will net more money by lowering their threshold instead of self-pledging – it’s a costly, optional “insurance” to get a wider window. There are many cases where that insurance is worth it, sure, and that’s why it’s there. And if you can fine-tune that window over time, that’s beneficial. If you can last-minute self-pledge exactly what you needed, without “placing a bet” as it were, that would be breaking the protocol, but month-by-month data isn’t enough to do that, with emphasis on “last-minute”.
Thanks again for reading♥
Sandra
PS Today I also proposed precise-threshold to LiberaPay on their github issue tracking site.
I have no idea how to set up or manage a payment/escrow site. I’m a quarrelsome, loner-type artist, I know my limits and I can’t do something like that.
I’m just interested in coming up with protocols and this was the favorite one of the ones I had.
That’s why I want established sites / infrastructures / communities to adopt the idea.
I propose the abbreviation “preshold” for the full name “precise-threshold” instead of what I’ve been using above, “prec-shold”.
The quality of being a nonce word that preshold has is nice, less imbued with previous meanings and connotations. It can aquire its own meanings and it’s just close enough to — and just different enough from — pre-existing words like “precise” and “threshold”.
Statements like
All thresholds are precise-enough.
will be less likely♥
I have 2 ideas that I think could improve preshold:
Add multiple levels, like Kickstarter (and other threshold platform)'s “stretch goals”
Mechanically, they’d work the same as the initial threshold, but instead of refunding patrons 100% of their money if the goal is not reached, they’d only be refunded down to the previous threshold. It’s intended to solve the case where a team wants to make an expansion without risking their current income.
I do acknowledge this would have the downsides of added complexity and reduced clarity about what it means to pledge to a project (am I helping them reach this goal, or this goal plus future goals?). This could be mitigated by pledging separately to base and stretch goals, or simply by projects choosing for themselves whether to stick to one goal per project or multiple.
Show an indication when the funding level is near to the threshold (above or below).
“Near” is a random amount between 5 and 15 percent of the threshold value, which changes periodically. I chose 5 and 15 arbitrarily, since I don’t have the information to choose them correctly. In reality, both numbers must be small enough so that patrons know that it’s actually uncertain whether the project will be funded or not. Meanwhile, larger number and the distance between numbers must create enough uncertainty to discourage self-donation sniping.
This is intended to mitigate the downsides of progress-hiding while preserving its benefits.
Multiple levels
I like it. I once predicted that the stretch goals of kickstarted was like the hologram variant covers of the 90:s comic boom, i.e. heralds of a bubble-bursting doom, but, I think I’ve been proven wrong by know. You make a good case for them.
Indicate when near threshold
The point of having the progress hidden is, as you note, to prevent self-donation sniping. I’m not sure a near-indicator adequately inhibits that. To me, it just looks weird.
Also, sort of a cool thing about preshold is that it wants to create the peace of mind in patrons to pledge without fear. Near, far, wherever you are, you can pledge and it’ll optimize. Some rando unknown project that looks cool? Pledge and if it fails you’re refunded. Some project that goes super viral? Pledge and if it’s a smash hit you get a lot of your money back.
And since preshold is designed to work with:
for the subscriptions, it’s only a good thing if the typical rate of success, i.e. based on the most couple of months, is made explicit. Like “you can typically expect to be refunded about 30%” or “this hasn’t funded successfully in 10 months” or w/e.
I dunno
I’m not the boss of preshold; I have released the idea by posting about it here. So whoever actually implements it can add things to it that I believe are bad ideas and maybe turn them good.
The multiple levels idea, my first impression of it is that it’s a great addition, with the strong disclaimer that I haven’t fully thought through the game theory implications of it.
ps
big thank you for working on ideas for preshold♥
Re-reading the original thread, I see that I saw “You can even keep the ‘snowdrift’ name”.
And re-reading the feedback on that thread and on this thread, I see that a common feedback is that preshold [or whatever ya wanna call it!] is not FLO-aligned. Which is… uh… crowdfunding originally stemmed from the FLO community with Kelsey’s and Schneier’s paper. I sure as heck fire had FLO in mind when I first proposed it.
The specific argument that “even a single nickle helps most FLO projects so a threshold is not appropriate” is A. counter to the specific snowdrift metaphor that’s the basis of this platform, and B. something I’ve addressed even in my initial post by proposing that the refunding is optional on a patron-by-patron basis.
I know asking for a pivot to a new protocol would be a big ask but I’m just not on board with this particular criticism. I’m happy to hear problems with preshold and I’ve also pointed out problems with it myself (snipe self-funding).
I want to reiterate that I don’t think crowdmatching is somehow perfect, there’s reasonable concerns to work through and discuss. I also think Preshold has a lot of merit and is in the short list of proposals I truly see as potentially viable and indeed aligned enough with the Snowdrift.coop mission. I’m not ruling it out. I really appreciate the discussion.
At this time, I’m not convinced enough to support actually dropping crowdmatching in favor of Preshold, but I don’t want any of my concerns to be read as though I’m anti-Preshold or as though I’m looking for justifications to reject it and defend crowdmatching. I’m just openly discussing it.
By contrast, there are other proposals I see as less intriguing or viable that I do just reject.