Crowdmatching implementations, charging up-front?

I really like the draw down approach outlined at the end, especially when a project is starting out. It would allow for some initial operating / startup capital (often necessary at project formation) and then allow others to join when the project is less speculative.

I’d advise researching committed capital , deployed capital , capital calls. Very neat work being done , glad to see practical implementation details being discussed !

We haven’t thought of Crowdmatching in general as working for large capital influx for project startups. One-time stuff does work reasonably well through Kickstarter-style fund-drives.

Our original idea was to hold money in escrow, but it wouldn’t be designated for specific projects, it would just be the patrons’ wallet for us to draw from to run the microdonations to all the projects. But that has too much liabilities legally.

To avoid holding money in escrow, my point from before is that we could implement an authorized-lump-sum approach like this: It would be just an internal agreement of “you give us permission to make future charges up to this amount”. That way, we wouldn’t hold the money (or the liabilities for it) in advance. But that also means it’s not available for use as capital by anyone. The only difference between that and monthly-budget is that it’s less of a long-term commitment but also a different framing of the point where patrons consider how they want to continue. Instead of “I’m at my limit, should I raise it?”, it becomes “I need to authorize more funds, should I do that, and how much?”

That said, a full draw-down approach where capital comes in advance isn’t impossible. Patrons would have to specify funds for specific projects ($10 here, $30 there) in order for us to process immediately and not hold anything. And the crowdmatching calculations would then effectively be a pledge to other patrons about how soon patrons donate again. So, if enough others come along and join the crowd, everyone makes their next lump-sum donation sooner.

I haven’t really thought about that, but it’s not crazy. But it’s a different framing and it feels more focused on urgency and less on long-term cooperation. I don’t realistically see us moving to that. It’s much more of a shift than what I was describing.

I meant more like a couple hundred dollars to cover startup costs . Often projects have a large spike of a cost graph timeline at beginning , does months of development , then may need ongoing crowd matching. That’s more what I was thinking. The original funder could then re join contributions at the mutual level.

1 Appreciation

At least initially, we’re planning on targeting projects that already exist without crowdmatching — they’re slogging on without sufficient funding. In those circumstances, initial startup funds aren’t as important; I think that’s what @wolftune was trying to get at.

edit: Certainly later on we’d like to support new projects as well, but it’s well out of scope for our initial expansion to multiple projects.

Agree with your assessment here. Not looking for a shift in model at all. Just covering the special up front startup case of someone long term aligned who wants to build a sustainable project, never taking on any investor capital , just crowd matched capital. It solves an annoying cold start problem.

Of course. I see that use case , fully support it and concur.

I’m raising the use case of projects that want to start out and stay crowdmatched based.

1 Appreciation

A post was split to a new topic: What is the scope for inital expansion to support other projects?

Using the snowdrift model to fund startup costs is using the wrong tool for the wrong job.
There are other websites that provide that service, including ones that have supported the startup costs of this website.

Also, asking patrons to cover startup costs alleviates some of the initial contribution project starters need to invest, which makes them less invested in their projects.

One of the reasons why I’m a patron of snowdrift.coop is that the team has already sunk so much time, money, and effort into it.

If @Wolftune and co had just suggested the idea and asked for money I probably wouldn’t have supported them.

2 Appreciations

Interesting.

You state this as a fact/absolute. Would you mind defending your absolute position / dismissal of the matter more in depth? I was merely suggesting it as something to explore, and a way for crowd matching to be adopted from the get go for a project. I think this is a good thing. I’m curious to see a detailed argument why it’s the “wrong tool for the wrong job”.

Here’s specific questions I’d like to see detailed answers to:

Why shouldn’t patrons be invested in a project from the absolute get-go on a crowdmatched/drawdown basis?
How else can a project start and stay crowdmatched?
Why should a project have to switch it’s model in flight?
How does a project switch it’s model in flight? Many complications with adding future stakeholders down the line, vs being setup for it in the first place.
Why do you think that project starters would be less invested? I’d argue they would be more invested, as they have to recruit donors/funders/customers/patrons and more of them, so that would require defending the project to the many, as opposed to needing to only pitch a single investor, or commit their own capital on an idea that doesn’t have traction.

We have a tentative someday plan already to support this sort of thing! It doesn’t need to involve a different way of handling money. All we need is to have donations be paused until they hit some adequate starting threshold.

As @smichel17 mentioned above, this isn’t our initial focus for project recruitment (we want established projects that just need to grow or become more sustainable, ones with established audiences already). But in the future we could have more speculative startup projects. For those, we’d offer to have them say that they really can’t do anything with small donations until the total reaches X. We let them collect pledges, but they won’t become active and start actually donating until the threshold is reached.

That still works fully with the basic crowdmatching, sustaining model.

side-note: that same idea of inactive pledges could be used for projects that were active but take a hiatus but hope to return to active status in the future. They could pause their donations but the pledges could stay in place and just become active again when the project is back to active development.

Ah! I like it. Very nice. So committed capital , the first capital call happens at threshold. Makes total sense .

Maybe we can combine and materialize different ways of donating, using badges?
Maybe in the shape of shovels (as it’s snowdrift).
Here’s a suggestion:

  • if you make an initial donation towards startup costs, you get a pioneer’s shovel (shovel with star)
  • if you are making “full shovel donations”, ie keeping up with the mutual amount, you have a live shovel (shovel with lightning bolt)
  • if you were matching the mutual amount but reached your objective, then you have a historic shovel (shovel with clock. I think objective is better than limit - this should be considered an achievement for the patron, not a limiting factor)

At all times you have charts like stock price graphs showing the progression of the amount, your contributions, and the number of patrons.

When the project reaches your set objective , you get a message

  1. Congratulating you on reaching your objective
  2. Offering a number of options:
  • keep on giving your objective sum to the same project (the default option).
  • set yourself a new objective
  • keep the same contribution, picking a second lower-level project - either a sub-project, or a completely different one. Then you have 2 badges: 1 historic, 1 live. As the live one gets bigger, if you keep to the same sum, the historic one gets smaller.
  • make changes, just deciding who you want to give the money to (good if you don’t care for badges)
2 Appreciations

Yeah, the idea of badges to honor current and and past patrons was one of the earliest design ideas, but has not yet materialized. It makes sense.

There’s some misunderstanding here still. We don’t propose that anyone set objectives per project. We suggest patrons stay in touch and generally keep track of whether their continued support is worthwhile and they are happy with the project’s progress.

The budget at this point is system-wide. It exists for the sole reason of giving you assurance that you won’t spend more money than you are up for, for the sake of your own finances. It is not meant for setting anything about goals or limits for the projects. We’re only giving people assurance that the system will check with them at a certain point so that they won’t suddenly be charged more money than they feel comfortable putting into the system

We’re not encouraging people to say, “I don’t think the project deserves more than X”. We might ever add budget categories so that people could put a limit on a specific project or a specific set of projects in a category (e.g. “I only want to put as much as $8/mo toward music projects”) but we’re not set on that necessarily.

The other suggestions about what to do when limits are hit… not bad ideas. But we can worry about the details when we are successful at hitting limits. In order for limits to become relevant, we will have to first get thousands of patrons and will already be a successful platform!

I would like to explain that I primarily view all discussions from the perspective of someone who is/will be a patron of projects and advocate from that perspective.

In regards to time frame, I take the perspective of approximately 1 year looking forward, with anything beyond that as a purely abstract discussion.

It’s not my position to defend. It’s snowdrift.coop’s position. I was simply para-phrasing snowdrift.coop’s own position of threshold crowd funding campaigns, as most of the issues raised would also apply to a crowd-matching system using large dollar amounts, even if through a draw-down mechanism.

Why shouldn’t patrons be invested in a project from the absolute get-go on a crowdmatched/drawdown basis?

Ultra-high risk is the reason why. I’m aiming to maximize the profits of my investment in a project and minimize the risk. The advantages of snowdrift.coop’s distributed funding model is distributed risk. The most I could ever end up wasting is the current max of $10 a month. Even if every project I support fails, I’m not out of $100+ with nothing to show for it.

How else can a project start and stay crowdmatched?

In regards to starting, there is an entire page of alternatives here. In regards to becoming crowd-matched, all they would have to do is gain enough snowdrift.coop patrons once in a stable enough implementation of their idea in order to scale and sustain their project.

Why should a project have to switch it’s model in flight?

Because project needs, capabilities, staffing levels, and market conditions can all change when a project or company scales up to become a bigger and bigger market participant. This is not unique to online software projects, governments, businesses, and even non-profits also have to deal with this issue.

How does a project switch it’s model in flight? Many complications with adding future stakeholders down the line, vs being setup for it in the first place.

There are various different ways that a project can switch its funding model in flight, and/or have complementary funding models. Businesses, non-profits, and even government do it all the time. You are correct that there are complications with adding stakeholders, however just because something is setup doesn’t mean that it won’t require some work in order to sustain it.

Why do you think that project starters would be less invested? I’d argue they would be more invested, as they have to recruit donors/funders/customers/patrons and more of them, so that would require defending the project to the many, as opposed to needing to only pitch a single investor, or commit their own capital on an idea that doesn’t have traction.

Attracting donors/funders/customers/patrons doesn’t cause project starters to be more personally invested in the project, in makes them more personally invested in dealing with donors/funders/customers/patrons. Maintaining relationships/outreach/communication with a large number of people is time and labor intensive. There’s only so much time in the day, and every moment spent recruiting is a moment not spent directly investing into the project itself.

Finally, the main concept behind snowdrift.coop is a well balanced blend of risk management, and community encouragement in order to support already established projects to scale upwards into larger organizations that can compete with mainstream products and corporations.

I reduce risk by pledging to give up to $10, but only if enough other people also pledge to give money. I also reduce risk by keeping the amount I donate low. If I have a life event that effects my financial situation, I’m more likely to cancel my pledge the bigger it is.

Projects reduce risk by encouraging large numbers of re-occurring small donations instead of a small number of large donations. The higher each individual donation is, the bigger the project’s risk if any one of those individual donations stops or falls through.

If not enough people support a project, my money isn’t wasted. If enough people support a project, I know that the money I have pledged has supported more than just the project itself, it has also supported encouraging other people to support the project themselves.

2 Appreciations

Hi @wolftune,

Thanks for answering.

For the Objective thing I was thinking more in terms of me as a patron reaching my own objective of “betting” on a project and seeing it reach the level I said it would. Or just a chance to celebrate the progress made. I hadn’t thought of it as setting a limit on what “the project deserves”, although I see now that might be read from the mechanism.

I guess what is exciting about this project is that it is entering into uncharted territory, so nobody really knows what will work and what won’t! I do think getting the wording right to explain this to people will be all the more important that being a new idea, people don’t have ready-made references to fall back on.

For the badge icons I can offer some suggestions if you think that is timely (for example, in the form of svg images).

I get your point, on the other hand I think understanding what happens when the limit is met is important to grasp the concept and spirit of the formula. My first reaction when watching the video was “hey, do I get bowled out when I can’t follow the rise of the set price anymore”.

1 Appreciation

Yes, lots of potential for that sort of thing. Overall, I expect goals to be defined by the project teams and they can decide to celebrate milestones and communicate that and their thanks to patrons.

Indeed, we will iterate as we go, but we do want to think about things in advance to have some clarity and be confident that the direction we’re going is good. But we can and will adapt along the way. The best part is that joining early is low-risk, so there’s no reason for patrons not to jump in and enjoy the ride.

[I’m going to reply to other points in new topics]

First, off, nice clear illustrations! This sort of thing helps communicate in ways that words can fail.

It seems you may be confused still. To be clear: yes, you do get bowled out when you reach your limit. We do not support patrons having some per-project limit where they continue donating without matching.

We don’t want overly negative reactions to the bowled-out issue. Mostly, we don’t want people to think that we’re making donation an exclusive privilege. Instead, we want people to understand that this is part of social negotiation. We want people to not be bowled out — but the way to stay in is to increase your limit. And we start the crowdmatching so low, that hitting the limit is a far off possibility even for a modest limit level.

Note that the budget limit is system-wide, not per-project. The limit assures people that they will never donate more than they can afford. Per-project limits wouldn’t apply to that concern. If you can afford more donations at all, then it doesn’t matter for affordability which project gets the extra. What matters is that you can afford all your active pledges.

The ideas about reduced-frequency or sub-projects are potential (but not yet decided on) mechanisms to allow patrons to continue crowdmatching without raising their limits (primarily aimed at people with lower wealth who truly cannot afford to donate more). Either way, all donations we support are still crowdmatching. We’re not currently considering any scenario where patrons donate through us but are not doing crowdmatching.

Read over this section of the mechanism wiki page: Snowdrift Wiki - The Snowdrift.coop Funding Mechanism: Crowdmatching

What you called “honorary shoveller” appears in the illustration to be someone donating money but no longer crowdmatching. They would actually still be shoveling but not doing any extra to encourage others. We don’t support ever having such an option within our system.

If someone drops a pledge entirely, we could still have some recognition that they are a former patron.

In the potential future of some sub-project option, we could possibly illustrate somehow that the patron moved from the main project to the smaller sub-project. Or in the case of offering a less-frequent donation, your graph above would continue to show the rising donation bars, but there would be a point where the patron shifts to donating every other month. Perhaps they would then have a different badge/honor for that state.

Hope that’s clear. I’m not sure if I wasn’t clear enough above or if you understood the ideas but it just didn’t quite come across in your illustration.

3 Appreciations

Sorry for the late reply, but one form of a Capital call is something that I’ve advocated for in the past. Stripe’s API allows us to pre-authorize a payment 7 days in advance. It’s not exactly a capital call, but it creates a buffer time where if someone’s card gets declined, it gives us time to notify them and encourage them to update their card information and/or add more balance to their card. Note that, even if they cancel their card after the pre-authorization, the charge will still go through. This is the exact same process that hotels use when you check in.

See the follow topics for more previous discussion on the issue:
Closed git issue #16
Open git issue #84

Food for thought.