libreplanet-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreplanet-discuss] Solving the prisoner's dilemma in crowdfunding


From: Aaron Wolf
Subject: Re: [libreplanet-discuss] Solving the prisoner's dilemma in crowdfunding
Date: Fri, 19 Feb 2016 09:36:03 -0800

On 02/19/2016 06:42 AM, Fabio Pesari wrote:
> Alice wants to build X, and Bob wants to fund Alice's effort. X is to be
> released under a free license.
> 
> There's a problem, though: Bob doesn't want to pay in advance, because
> he's afraid Alice will not deliver X as promised. In a typical
> crowdfunding scenario, there are hundreds of Bobs, so this issue is even
> worsened.
> 
> Likewise, Alice doesn't want to be paid at work finished, because she's
> afraid Bob won't pay her. She's also afraid that her time or budget
> estimate might be wrong, which might ruin her reputation forever even if
> she works earnestly.
> 
> Both scenarios happened in the past, so their paranoia might be
> justified, but the lack of crowdfunding efforts right now is IMO the #1
> reason free software development is often slow and/or has to compromise
> (often by adopting permissive licenses, which inevitably helps
> proprietary programs).
> 
> How to keep blind trust out of the equation?
> 
> My proposal: a nonprofit organization evaluates Alice's project. If they
> determine her time estimate is right and her prior experience is
> sufficient to develop X, they raise funds for it and keep them as an escrow.
> 
> After the time limit expires, the organization's committee
> thoroughly evaluates X against the initial goals Alice set out to
> accomplish (works well for software and hardware designs but doesn't
> work for art, obviously).
> 
> If the committee acknowledges that X fits the original specifications,
> Alice is given all of Bob's money, which she rightfully earned.
> 
> If, however, it doesn't, Alice will still be forced to release
> all the work she's done under a free license, and the original funders
> (the Bobs) will be allowed to withdraw their donated sum if they aren't
> satisfied with what they see.
> 
> In short, in order to give out refunds:
> 
> 1) The organization judges Alice's product as unfit to the original
>    specifications
> 2) Each funder must voluntarily ask for a refund (so, if a funder is
>    satisfied with Alice's unfinished work, they can still pay her)
> 
> I think this is fair to both Bob and Alice. It's slightly weighted in
> Bob's favor, sure, but as we said there are always more funders than
> developers in crowdfunding and as a free software supporter, I believe
> users come before developers, so the whole community should benefit from
> Alice's work in any case.
> 
> What do you think? Would this be feasible for an organization like the
> FSF or the SFConservancy?
> 

Just come help us with the existing effort!

I and a few dozen other people have already been working hard for a long
time (and making great progress lately) on creating an entire holistic
platform to address all these issues. Please come join us.

The site is: https://snowdrift.coop

The dilemma we're solving is the "Snowdrift Dilemma" which is actually
more accurate fit to the problems than the Prisoner's Dilemma because
*most* free projects are not cases of totally speculative things in
threat of total failure, they are struggling projects under-fundeded.

We describe all the economics and game theory things on pages like:

https://snowdrift.coop/p/snowdrift/w/en/snowdrift
and
https://snowdrift.coop/p/snowdrift/w/en/economics

and other pages describe our mechanism etc.

In short, all sorts of one-time huge grants are problematic, and all
sorts of pre-set assertions about the costs and exact form of
deliverables are all somewhat toxic ways to fund free projects. Nobody
is great at predicting all these things and conflicts over disagreements
about whether work fits the original specifications end up destroying
communities. It's like the long tried and often failed approaches to
"bug bounties" and such. We have pages describing all these issues such as:

https://snowdrift.coop/p/snowdrift/w/en/threshold-systems
https://snowdrift.coop/p/snowdrift/w/en/status-quo-floss

The answer we propose is to focus on projects that already have history,
which is almost all free projects. There's no priority area for free
software that has zero efforts so far. What we do is just use an
*ongoing* funding instead of huge lump sum. You can trust the project is
real because they *already exist*. You can keep them accountable because
you can decide whether you like or dislike the progress you see
month-to-month. There must be no threat that the project will do work
and then have the money taken away. The threat is that their support
will discontinue if the work they do is unsatisfactory to the funders.

Our model addresses the snowdrift dilemma *while* being ongoing by just
saying that Bob will donate a small amount each month per the number of
other patrons who donate with him, starting at $1 per 1,000 patrons. The
reason free projects struggle and fail is from lack of resources and
lack of numbers of supporters. The issue is people's sense that their
input makes not enough difference, not that they have no trust in the
project to do the work.

Anyway, we have lots more writings, lots more stuff about what we're
trying to do, we're in touch with the SFC and FSF folks and are a formal
affiliate of the OSI. I can tell you more about all the details, but you
(and anyone else interested) should come join us and help us finish the
work we need to get the system launched and operating.

Cheers,
Aaron



reply via email to

[Prev in Thread] Current Thread [Next in Thread]