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. So how would this be done in Drupal?
So I have identified two main questions to answer:
How autonomous communities can share a Drupal instance?
Obviously they are going to give up some of their autonomy, since they will be making join decisions on hosting, graphic design, and configuration.
When serving a city, a high level of integration can be extremely useful. Yet for convenience (and because we are part of a localization movement), people want to pay membership, organise and belong to different segments of the site. Functions such as content management, subscription management, accounting, member search, and marketplace would all need to be modified to support the segmentation of the site. Some work would have to be done on user interface design, since the whole site would have this local/citywide scope. This approach would be quite consuming, but could produce a great community tool. But the more autonomy groups wanted, the more it would cost.
A quick and dirty approach would be to use organic groups. The intention of this module is to facilitate discussion groups which can be started by anyone and restricted or moderated by the starter. There are many other modules however which extend or reinterpret this functionality. OG assumes that users will likely want to be part of many groups and to jump in and out of them, so its not the ideal starting point. This approach is best suited to Michael Linton's work in British Columbia, but probably wouldn't work for all the LETS in one city.
If everyone was a member of one group only and that was moreorless fixed when they signed up, it might be simpler and sounder just to have a an option in the signup form and work from there, using something like the context module to segment the site. This would be good architecture, but adapting all the features to context would still have to be done from scratch.
How to do intertrading?
I have discussed intertrading elsewhere. It means a virtual transfer of value between 'intertrading' account in distinct mutual credit groups. Between different web servers, this is difficult, but if all the currencies are stored in one place, it is technically trivial.
Typically each mutual credit currency will have its distinct ID, membership and sometimes, rules. There is a small distincition in the user experience between trading within the native group, and using the native currency, and trading outside their group. These external transactions shouldn't be at all cumbersome however, although there may be privacy concerns when, say, browsing lists of users in other groups.
A more integrated approach is to store all the currencies in a base value in the same database table. That means everyone is essentially trading the same currency - usually time denominated in minutes. Then when the transactions are displayed they would be translated into the viewer's, or the transactee's native currency. This way there would be no balance of trade issues. The whole system would function as one economy, as indeed many national timebanks and LETS systems already do, albeit with much more informal accounting.
Finally there is the multi-currency approach, which means no intertrading. Each group has its own currency which isn't automatically exchangable for any other currency. Any member might be able to hold any currency, so they might have several balances at any one time. Any exchanging that went on would be ad-hoc, and not supported by the software or done at a fixed rate. There is nothing in this approach that connects a currency to a locality. In effect all the currencies would be competing in the same space. However if there were big issuers or lenders of each currency in its respective neighbourhood, such as an organic cooperative or business alliance, the currency would have to return back to base eventually, and might have more value/meaning closer to that base.
Drupal is ready to tackle these kinds of problems, but I am not ready to test out all approaches at once. Your comments on the above approaches are appreciated.
Comments2
French
French translation:
"Plusieurs communautés dans un seul Drupal.
Ce post est une réponse à certaines discussions de haut niveau à propos de l'utilisation d'un seule installation Drupal pour servir plusieurs communautés, chacune utilisant sa propre monnaie. Faire tourner de nombreuses installations Drupal peut se faire avec une efficacité raisonnable, bien que cela prenne du temps de les mettre en place et qu'il y a un équilibre à trouver entre leur indépendance et le temps, l'expertise nécessaire pour former, administrer et les entretenir. CES tourne déjà sur une seule installation logicielle sur mesure et son succès témoigne que peu de communautés de ce type préfèrent l'indépendance à la facilité.
Comment pourrait-on faire en Drupal ?
J'ai identifié deux questions principales :
- Comment des communautés indépendantes peuvent-elles partager une installation Drupal ?
Il est évident qu'elles vont perdre une partie de leur indépendance, vu qu'elles devront prendre des décisions ensemble sur l'hébergement, le graphisme et la configuration.
Quand on sert une ville, un haut niveau d'intégration peut être extrêmement utile. Mais pour la facilité (et parce que nous faisons partie d'un mouvement de relocalisation), les gens veulent payer une cotisaton, s'organiser et appartenir à différents segments du site. Des fonctions comme la gestion de contenu, la gestion des inscriptions, la comptabilité, la recherche des membres, et les échanges devront toutes être modifiées pour permettre la segmentation du site. Il faudrait travailler sur la conception de l'interface utilisateur puisque le site entier aurait une envergure locale ou de la taille d'une ville.
Cette approche pourrait demander beaucoup de temps mais pourrait produire un outil important pour une communauté. Mais au plus les groupes demanderont à être autonomes, au plus cela coutera.
Une approche brouillonne serait d'utiliser des "groupes organiques". Le but de ce module est de faciliter les groupes de discussions que tout un chacun peut démarrer et ceux-ci peuvent être restreints ou modérés par celui qui a lancé le groupe de discussion. Il y a beaucoup d'autres modules cependant qui étendent ou réinterprètent cette fonctionnalité. Les groupes organiques présument que les utilisateurs préfèrent faire partie de plusieurs groupes et passer de l'un à l'autre. Donc ce n'est pas le point de départ idéal. Cette approche convient très bien au travail de Michael Linton en Colombie Britannique, mais probablement qu'elle ne fonctionnera pas pour tous les SELs d'une ville.
Si chacun était membre d'un seul groupe et que c'était fixé à l'inscription, il serait plus simple et plus avisé d'avoir une option seulement dans le formulaire d'inscription, de travailler à partir de cette option, et d'utiliser quelque chose comme le "context module" pour segmenter le site. Cette architecture serait bonne mais il faudrait quand même adapter toutes les fonctionnalités au contexte à partir de zéro.
- comment faire des échanges entre communautés ?
J'en ai parlé ailleurs. Cela signifie un transfert virtuel de valeurs entre des comptes "inter-communautés" dans chaque groupe de crédit mutuel. Entre des serveurs web différent, c'est difficile, mais si toutes les monnaies sont stockées à un seul endroit, techniquement, ca devient très simple.
Comme cela se fait habituellement, chaque monnaie aura sa propre identité, ses propres adhérents, et parfois ses propres règles. Echanger dans son groupe d'origine avec sa monnaie d'origine, ou échanger à l'extérieur de son groupe est un peu différent dans l'expérience de l'utilisateur. Mais ces transactions externes ne devraient pas être pesantes. Cependant,il peut y avoir de l'inquiétude en ce qui concerne la vie privée, quand, par exemple, on consulte des listes d'utilisateurs d'autres groupes.
Stocker toutes les monnaies dans une valeur fixe dans la même table de base de données est une approche plus intégrée. Cela veut dire que chacun échange avec la même monnaie, d'habitude une monnaie basée sur le temps et dénommée en minutes. Et ensuite quand les échanges sont affichés, ils sont traduits dans la monnaie originaire de celui qui regarde ou de celui qui a participé à la transaction. De cette manière, on évite les problèmes de balance commerciale. Le système entier fonctionnerait comme une seule économie, comme beaucoup de Banques de Temps nationales et de SELs pratiquent déjà mais avec une comptabilité beaucoup plus officieuse.
Finalement, il y a l'approche "multi-monnaie", ce qui implique aucun échange extérieur. Chaque groupe a sa propre monnaie qui n'est pas automatiquement convertible dans n'importe quelle autre monnaie. N'importe quel membre pourrait détenir n'importe quelle monnaie, donc il pourrait avoir plusieurs soldes à tout moment. Chaque échange qui aurait eu lieu, aurait été fait au coup par coup et sans le soutien du logiciel ni réalisé à un taux fixe. Il n'y a rien dans cette approche qui relie la monnaie à une localité. En réalité, toutes les monnaies seraient en concurrence dans le même espace. Cependant, s'il y avait de gros détenteurs ou débiteurs de chaque monnaie dans leurs environnement respectif, comme une coopération organique ou une alliance commerciale, la monnaie serait obligée de retourner à son point d'attache finalement et aurait plus de valeur/signification plus proche de ce point d'attache.
Drupal est prêt à s'attaquer à ce genre de problèmes, mais je ne suis pas prêt à tester toutes les approches en une fois.
Vos commentaires sur les approches ci-dessus seront appréciés."
Member for
16 years 1 monthThis project is now on the
This project is now on the cards as part of a CES upgrade...