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.
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.
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.
A new web site Our Goods, a barter network for the creative community "is a recipient of The Field's Economic Revitalization for Performing Artists (ERPA) Phase 3 Implementation award. The Field's ERPA program receives funding from The Rockefeller Foundation's Cultural Innovation Fund."
$20,000!
It hasn't even got an accounting system!
Why is there money for artists but not for engineers???
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.
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...
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.