System – Nimno

How the on-the-ground direct sponsorships will work, what infrastructure we need to build for it, and how it is to be funded.

Main Points:

All sponsorships must be peer-to-peer (this means a human sponsors another human).
The system thus has to find new ways for people to do collaborative projects.
The reason for having these different types of project is so that sponsors can be sure and clear about what will be done with their money, and can confirm that it is being done.
Time limits should be set within which the person expects the project to becone self-sustaining. This is crucial, we do not want to facilitate long-term dependency.
No-one has done this before, there is nothing to copy. We’re learning as we go.

Overview (philosophy?)

“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.”
R. Buckminster Fuller

I tried to do this with fiat currencies first, before clickforcharity, and it proved to be too difficult. In fact it was impossible because fiat currencies require a centralized entity to do the transactions. I can not send you money directly using my debit card, it has to go via a business.

The existing charity system is that people send money to an organization. The organization then pays people to distribute the money or the things that money can buy to the recipients. To put it politely, this system has not worked out well for the recipients.

The direct sponsor system instead strips down the whole concept of charity and throws out everything that is non-essential. We then build a system to provide what is actually needed, instead of just copying what already exists.

In essence, charity involves two parties⁠—a donor and a recipient⁠—as well as some item, service or currency to be given. These are the only prerequisites for charity to happen. What we need to design is a system that will satisfy the needs of both of those parties and only those parties.

Needs

…we didn’t build Mac for anybody else. We built it for ourselves. We were the group of people who were going to judge whether it was great or not. We weren’t going to go out and do market research. We just wanted to build the best thing we could build.
Steve Jobs, Playboy interview, February 1985

At the very basic level, we have someone with money and someone who needs that money. The donor needs

To send the money with the absolute minimum of cost of transaction
To verify that the recipient got the money
To verify that the recipient is using the money in the agreed way to achieve an agreed aim. (see the verification page for more)

The recipient needs

to receive money in a way that doesn’t leave him beholden to any middleman.
to have an easy-to-use system to communicate with the donor so as to satisfy the donor that he is doing what was agreed.

These needs together constitute the requirements for the direct sponsor system. The sponsor and recipient will be the only people taken into consideration in the design. Other people, such as teachers, aid workers and so on need not be considered at all because they will be employed by the recipients themselves and not by “Direct Sponsor”. They will have to negotiate with the recipients and to do what the recipients want done.

Naturally, we all seek to explain what we perceive in terms of the phase we have been in rather than in terms of the phase we are moving towards. We are like water molecules trying to understand the process of boiling and evaporation in the absence of any concept of being in a gaseous (vapour) state.
From an article on sott.net

Notes

[May be redundant — salvaged from another page]

We need

A system for users to use to communicate with each other.
To find ways for our users to send and receive funds directly between each other securely and cheaply.
To provide an “accounting” system so that our sponsors can see what happened to their money
A way for our recipients to advertise their projects as well as show how the project will improve their lives and lead to independence.
Security for our sponsors that they are not being scammed. (By this I mean proofs not reassurances).

When setting up a site to sell a charity subscription or a range of goods to raise funds from the profits, the functions of the site and its underlying system are already set. We know what we need to provide for users and there are many ready-made solutions that will give us a normal store and then enable us to adapt it for our charity site. We can focus on the form in great detail because the function is already determined and provided.

If the underlying functions are not fully determined yet then it makes sense to focus on those first, so as not to waste time and energy on perfecting a thing that is likely to be dramatically different to what we are using now.

We don’t know yet how the users will be able to send funds, for example. We have ideas but we have to try them out to see which works best. Likewise we don’t know yet what type of communication channels will turn out to be the best to use and for which purposes. Blogs, videos, forums and groups, different types of real-time group chats, private chats… there are many possibilities and we will need to try them out and see which are most useful.

So the present website is good enough, all we need to to keep it running and only add things that are essention because wordpress and buddypress and bbpress together is a nightmare even without doing experiments. Anything not crucial to the functions can be discarded.

The place we need web design is in the finished product that comes after this one. It’s like every thing we do to make the site prettier is adding to the chances of collapse of the cumbersome monster we are building. It’s worth the risk on a finished product.

And pretty much all of the System section.