Adventures in mutual credit

Users have been asking for more and better statistical aggregation of transactions, but have been unable to articulate what that would look like, so I decided to concentrate on exposing everything to views, so that use can be made of exposed filters, the new GROUP BY utility, and the theme layer.

I set out to ensure that the following analysis was available to user 1, preferably in views.

Sea change radio introduces new ideas to switched on urbanites. Gets interesting at 12 minutes!

Agorist radio is much more technical and premised on a better understanding of money, markets and software. This interview is fully 70 mins and we managed to cover a lot of ground.

One of the barriers to local money adoption is the limited number of things you can buy with it. A typical community of 100 middle class people, generally only provide each nonessential services and a few second hand goods. A community that small hardly constitutes a local economy.

Various things need to be done to address this problem.

There is a clear need for a certain kind of community web platform which I have never seen articulated. The communities that need it either don't know, or are thinking locally, or aren't investing in web technologies, and the commercial sphere isn't addressing this need at all.

In previous versions of mutual_credit, I went to great lengths to provide a 3rd party transaction form, a first party form which assumes one of the traders is the logged in user, and multiple transaction forms, in which multiple payers or payees could be specified. They should be completely malleable to user experience experts (who would surely pay a LOT of attention to a payment form). However it seemed that each new use case broadened the scope.

In strict mutual credit systems, unlike most others, users balances must not deviate too far from zero. It is common for LETS groups to impose positive and negative restrictions on users' balances. In other accounting systems, a minimum balance of zero is common.

Some users may have different balance limits to others, for example trusted or collateralised users may have access to more credit. Someone saving up may be granted a higher balance limit.

And if balances limits are to be individual, then there are no end of suggestions as to how to calculate them.

See here.

This is the first post documenting my work on the mutual credit module version 3 for Drupal 7. There will be several valuable new features and my aim is to stoke demand and clarify in advance what it can do. I'm talking only about features already implemented...

For the next few months I'm going to be using this blog to think aloud about Drupal 7 and the mutual credit work I'm doing within it. This will be part rumination, part peer review, and part PR. I will only discuss stuff I have moreorless done.

This post is a response to a number of high level discussions about using a single Drupal instance to serve many communities, each using their own currency. Running many Drupal instances can be done with reasonable efficiency, though they take time to set up, and there is a trade off between their independence and the amount of time and expertise taken to train, administer and maintain them. CES is already running in one instance of custom built software and its success is testimony that few of these kinds of communities value independence over convenience.