Context
Background info: Why we're moving to a goal-based mechanism framing
We want to present the simplest useful explanation of the mechanism, so that people will understand it and feel comfortable participating in Crowdmatching.
When we only say something like, “you pledge to 0.1¢ for each other patron who pledges along with you”, about half of people freak out about “What if a ton of people join and now I’m on the hook for $$$? Is this some kind of scam?”[1]
Mentioning the limit produces a bunch more questions about details that we don’t want to spend valuable first-impression time talking about. "What happens when you reach it? Who do you decide to drop from the crowd? etc
A year and a half ago, @msiep proposed a new framing for the same mechanism: pledging towards a goal
-
You pledge up to a certain amount per month towards a funding goal for the project
- Ex: I pledge $6/month towards a goal of 6k patrons giving $36k/month total
-
Before the goal is reached, your actual donation is only some portion of your pledge.
- Ex: When 3k patrons have pledged a total of $18k/month (halfway to the goal), I will donate $3 that month. The other patrons will also donate half of their pledge, so the project will receive $9k total that month.
This framing is a little more complicated, but is simpler than the current approach plus all clarifications, and produces better intuition. It’s also easier to explain if someone doesn’t understand right away— most people are familiar with one-off fundraising campaigns where a “generous sponsor” has agreed to match the first $X thousand in donations; if they don’t meet the goal, that person only gives a percent of their pledge; this is the same dynamic, but with the crowd matching each other instead of one sponsor.
The discussions are long and with frequent side-tracks and communication failures. If you really want to read them, they start here, but consider reading the rest of this post first.
We reached consensus that the goal-based framing is better, but not about some immediate next decisions. In particular: once we make the system more flexible than “everyone pledges the same amount”, should the goals/matching be based on number of dollars or patrons? We can move forward without a decision, but it makes certain things more difficult (e.g. describing the updated mechanism in language that applies equally well to either type of matching).
I think a key reason for this “stalemate” is lack of alignment. In a more recent conversation between myself and @mray, we stepped back and asked, what criteria should we use to evaluate which mechanism is better? He checked our mission/vision wiki page… It reads nicely, but was not specific enough to help decide. Actually, almost nothing on that page could be used to justify why we are building a crowdmatching platform, rather than, say, a Liberapay clone.
I ran into the problem from a different angle working on the Plan for Moving Off Haskell[2] One open question when considering the database design: how much does it need to scale? Specifically, I am considering using json-in-postgres.
- Maybe the mission of Snowdrift.coop is to build a robust and sustainable but minimally-staffed proof-of-concept that we can point to in our advocacy efforts, to convince people that a system like ours is possible. In that case, we will probably never do a major DB redesign, but also we will eventually outscale postgres+json performance, so it would be best to avoid it, and save our future minimal staff a migration headache.
- Maybe we aspire to fund projects at scale and move enough money to change the world. In that case, it’s probably more valuable to use json now for more flexibility. After all, we will certainly need to redesign the database at some point anyway, and should have the resources to do it.
Comparison
I think OpenCollective’s Mission and Values page is a good reference.
We are on a mission to enable communities to be sustainable and fundraise in full transparency without having to create a legal entity to do so.
Our comparable statement is:
Snowdrift.coop facilitates community support for projects that develop public goods
They are quite similar, but the biggest differences in my eye are:
- Ours has a more specific (better) scope of which projects we are trying to support: “public goods”
- Theirs is more specific about which activities they want to enable: “fundraise in full transparency”
- Theirs mentions a specific problem they are trying to solve: “having to create a legal entity”
(I also happen to know that our mission is significantly more ambitious than “facilitate community support” suggests.)
Plans
So far, we discussed this a little bit in last Friday’s meeting. It was an (intentionally) open-ended discussion just to get the conversation started, so there’s a fair amount of general sentiment discussed there, not necessarily specific enough to go into the mission statement. But there are some good parts.
I think the next steps are to review the notes and pull out the good points that we’d like to make sure are captured in our mission statement. A follow-up discussion (maybe next week, since @Salt will be absent this Friday) would also be good.