Adventures in mutual credit

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.

There are two approaches to the problem of allowing exchange between mutual credit circles.

(This builds on my previous post, Choosing CC software 2009)

Today I released version 2.0 of my mutual credit module for Drupal. In the mania of recent weeks it has become clear to me that national currency backed currencies and mutual credit each imply different values, accounting standards, security, and features, and require different kinds of software to do it. My offering is clearly intended to meet the needs of the latter.

Last month's meeting at Tiocan, near Geneva was pivotal for Community Forge, as it was the first time we had really engaged with a broad spectrum of users, potential users, and other actors in the movement. We made tangible progress on many fronts, but the headline issue, how we should coalesce into a Community of Practice wasn't properly addressed. Nor was it addressed at all in Lyon.