Trivial version of (Unix philosophy)

Continuing the discussion from On solving the world's problems:

The snowdrift rule is: Every snowdrift-style patron donates 0.001$ per other snowdrift-style patron.

Each month, the donated money is transferred and the patron’s “Crowdmatch progress” pages are updated – this is equivalent to sending an invoice, except that the donation itself is automated. (Let’s ignore the automation bit for a moment and try to imagine the most trivial system that would implement the crowdmatching mechanism.)

Notice that the amount donated by the patron is the exact same amount for each patron of the project. As a result, the identical invoice is sent to all patrons. This can easily be done via a mailing list where all patrons are subscribed – no harm is done if additional curious people are subscribed. (In reality, the invoice is not exactly identical, because donations are only transferred if they are above some threshold, so carry-over computations need to be displayed per patron.)

In this simplified world, the only piece of software needed is a counter to keep track of how many people pledged. There’s a huge problem though: How do you verify that the number of patrons is correct? You want to use a reasonably correct number for generating the monthly invoice. (Since we’ve ignored the automatic donation bit for the moment, we cannot do fancy tricks like 1. reserve money from each credit card, 2. count how many of them succeeded, 3. transfer donations using this precise number.)

The most precise data we have is once the donations actually come in, i.e. at each crowdmatch event, we know how many patrons there were for the last crowdmatch event. Nothing stops us from simply using this number in the invoice – this will imply a 1 month lag in the number, but who cares.

If we now stop ignoring the automation of donations, here’s what would be left to implement:

  • Count how many people donated a certain exact amount in a certain time window, multiply with 0.001$ and send the result as a human-and-machine-readable invoice
  • Automatically pay incoming invoices that come from (i.e. invoices that are PGP signed by a certain key)

Both would be absolutely trivial if the outside software ecosystem would follow the unix philosophy. But it doesn’t. (Edit: This still ignores the carry-over stuff, but see my second post)


In fact, the second point can be eliminated in the following way: Instead of counting how many people donated the exact amount, also count people who donated more. Next round, also count donations from previous rounds that still have enough left if you substract the donation amount that was counted earlier.

For example, if someone wants to become a patron for, he could donate 10$. However, the 10$ wouldn’t be available for actual use by Only once there’s a crowdmatch event, a small amount of those 10$ would be “transferred” from the “not-available” money to the “available for actual use” money.

(This is equivalent to storing money for people and paying crowdmatches from there, only that the money isn’t stored at, but at the project that is being donated to. The project simply commits to not using it until it is properly crowdmatched.)

As a security mechanism (to make sure no money is lost because it is never crowdmatched), you might want to completely “transfer” all donations that were made more than, say, 10 years ago. If a project wants to really embrace the snowdrift mechanism, they can even delay all incoming donations for 10 years and count all donators as patrons.

This would still be trivial if a project’s financial data is publicly available in a machine-readable format. Maybe this is even the case for some real-world projects…? (The important detail is that it must not be anonymized, only pseudonymized at most: You need to be able to correlate donations which come from the same person. I don’t even know if the financial system provides projects with this amount of data, or if it’s already anonymized except for the reason for payment)

1 Like

This is interesting. I also try to do my computing in a unix-y (modular) way, and I like the idea of anyone being able to donate any amount, but the project only receives the money when that amount is crowdmatched against. That said, I’m not entirely convinced that this approach would work in the real world.[1]

As far as I can tell, unix-style programming is enabled by a really strong, simple, common abstraction: the file. This makes it possible to compose tools that weren’t written specifically to interact with each other.

On the web, URIs are kind of the equivalent, but the spec is much messier (more complicated and less well-defined). I think that’s a natural consequence of their origins and uses — a long discussion that I will skip over and summarize as, there are many more people on the web with different goals and interests, and building any sort of consensus at that scale is very difficult.[2]

From a theoretical perspective, these seem identical, though they’re very different in practice. A different way to frame the idea, if I understand it correctly, is that they’re paying into a “crowdmatching fund”, which then dispenses money to projects over time depending on the number of people who’ve paid into it.

I was originally going to make an analogy between such a “crowdmatching fund” and a unix file, but after leaving this draft and coming back several hours later, I don’t think it fits very well any more :stuck_out_tongue:

  1. I'm not convinced it's impossible, either. And even if it were, it would still be interesting to discuss. ↩︎

  2. It's like a harder version of what tries to solve. We're focused on coordinating people who all share the same goal, to fund FLO works. Creating standards for the web also includes negotiation between groups of people with different priorities. ↩︎

1 Like

I would be very interested to hear objections/concerns. Maybe because then people actually do donate money even if the project doesn’t “succeed”? I might be starting to see the point here…

Instead of delaying donations, projects could refund donations – maybe after 1 year or so. But I can see how this would a) create lots of additional complexity (interfacing with the outside software world, again) and b) still have a slightly different psychological effect on people than what does currently.

Note that the wallet-approach (make $X available, add more when it runs out) is superior and more trivial than the charge-in-arrears / carry-over approach. The only reason we aren’t doing it that way is because we don’t anticipate any reliable way to get a financial system to allow that sort of escrow holding while still meeting all legal liability regulation concerns. In other words, we can’t be holding un-donated funds without prohibitive legal hassles. There are already liabilities for supporting fundraising at all, but if we don’t touch the money, our liability is much less. Hence the more difficult carry-over workaround. I wish we could just do it the simpler way though.

Does this include the case where the money is not really at, but at the project? The only thing would do is facilitate a certain style of bookkeeping where non-crowdmatched money is calculated seperately, and no debt is allowed.

There’s 3 problems with this. Maybe fix-able.

  1. In the previous/current design for the wallet approach, you have a site-wide wallet, not per-project. This is desirable because of how it directs money.
    • You put $x in the system, decide which projects you want to support
    • Money goes to those projects which receive the most other support.

With per-project wallets, you might pledge $x to proj_x, but then it doesn’t get support and the funds are stuck unmatched for eternity. It might be possible to work around that, but this gets us back into fishy legal territory — if there are easily-engineered situations where someone can put money in and then withdraw it (eg, huge donation to unpopular project, refunded in a year), we become subject to banking regulations.[1]

  1. Asking projects to hold money in reserve puts additional accounting burden on them. In order to reliably follow the rules, they’d probably they’d have to open a new bank account specifically for funds in reserve, and then transfer to their main account as directed by us.

  2. It puts a lot of trust in projects. This isn’t inherently bad. After all, projects need to be vetted by us first, and there’s an honor code… I’m not terribly worried that projects would skirt the rules and use “reserved” money.

    However, it is tricky, and risky, from a messaging perspective. Consider from the patron’s perspective: the whole reason to use instead of a unilateral direct donation is the mutual assurance provided by crowdmatching. If the only assurance we provide that funds actually will be matched before they’re made available to the projects is, “trust the projects”, that’s a harder sell. And if there ever is a “scandal” where a project dips into reserved funds, it erodes a lot of trust in the platform.

Will get to this later, I’ve got deadlines at $dayjob and have already spent enough time on what was supposed to be a short reply :stuck_out_tongue:

  1. As I understand it. I am not a lawyer. ↩︎

1 Like