Dear Josh, Rob et al.
Writing an RFI was exactly the right thing to do, since it shows everyone where you are, and that you are seeking consultation and collaboration, and are open to suggestions.
As far as possible I will stick to your prescribed response format, but my most important messages don't fit it. However, I don't think you'll find anything here irrelevant.
Me and Community Forge
In 2005 declined to work with Michael Linton on multiple currencies and instead coded a single currencyphp/mySQL LETS application. Unable to persuade my home LETS to use it I then worked extensively in 2006 with LETSlink UK to understand the requirements and design an architecture to support them. There is a very strong correlation with your own requirements, by the way. The application was never used, and I was needed in a small NGO, for 18 months which landed me in Geneva with expertise in Content management. In 2008 I judged that Drupal showed great promise because of its strong community ethic, flexible architecture and appropriate governance. I am now an expert in Drupal and I still believe it is the most appropriate platform for our needs. I urge anyone who disagrees to re-implement my architecture in another platform, and we can compare.
By the end of 2010 my generic accounting/payment system is in use by 20 - 30 communities, (pending adoption of another 100 Timebanks, and with interest from other blocs). Through an organisation I co-founded, Community Forge, knowledge and control of the software is devolving towards the users. This means I can spend less time supporting end users and more time supporting the centre.
I mostly rely on gifts or exchanges for my food, extensive travel, hardware, clothes and technical support. This is a privilege, but sufficient and hence inefficient! My point is that I've brought the project this far, but institutional involvement would make a world of difference.
I have a very good idea how to get most of your features implemented using Drupal as a basis and how to structure the currency ecosystem you need because I have been working towards exactly this, pretty much on my own, for the larger part of five years. Although I have very little experience working in large software projects, I really understand the larger issues, like governance, processes, design, architecture and participation, which are essential to your project, and that's why my work in Drupal is a serious contender despite only having 2 man years behind it.
Community Forge arose from a partnership between the Chairman of SEL du Lac, the LETS in Geneva, and I. Our premise is that people should do it for themselves and that we can't wait for governments to building the new economy. We understand how hard it is to get money in this fields, and are concentrating instead on meeting the needs of communities and looking to meet our needs with inkind gifts. This is starting to generate a lot of goodwill and is seeding a strong spirit of collaboration and participation.
Community Forge does not seek to start any currencies, or persuade people to change their behaviour, rather it seeks to support existing initiatives with the difficult but important business of software. Our early adopters have mostly been French speaking because that's where Tim's network happened to be. We believe that the French Belgium will soon make a collective decision to come to our platform, and we are keen to build up their own Drupal expertise, to hand over the keys, and concentrate on being the centre, rather than directly supporting the edges. Next month I will train some Belgian volunteers in intermediate Drupal, and in February at our General Assembly we will work out a new agreement about how they can operate as a national group and what our role should be. We hope to make similar arrangements with the French in due course, and are also talking to representatives in New Zealand.
Questioning the questions
1. It seems to me that you are looking for a piece of software which will do more than Cyclos. That's not how it's going to work. You're not going to identify something, have it customised and delivered, and then set it up yourselves as many times as you need to. Instead you are going to raise money, and put it into an existing software effort in order to drive development towards your requirements.
You are going to engage deeply in a process that will gradually deliver more and better solutions to the problems you care about.
The end product is not the software, but a community of users who use and benefit from the software and who support and shape its development.
2. It sounds like you want to commission the one piece of software which
will run the whole next economy. You want each instance to be infinitely scalable, but you also want it to be compatible with other instances. In terms of architecture, this is a very tall order, especially if you want it delivered all in one go. This kind of thing is best considered before any code is ever written.
Generally software development is driven like this:
You create it to solve a specific problem.
You extend it to solve related problems.
You refactor it to solve a family of problems.
Each stage is funded because it solves more problems. If you just straight to stage 3 you have a lot of work to do without really understanding the requirements and without having a an actual deployment at the end. Its a perfectly acceptable and indeed efficient approach, if anyone is prepared to take all the risks up-front.
I think you need to be clearer on whether you are solving a general problem and then offering customisations to various projects, or whether you are solving a specific problem and looking to generalise as quickly as possible.
Don't try to solve a specific problem and a general problem at the same time
3. I understand from my travels that want to run Brixton Pound with a digital back end and plastic cards and a point of sale devices, and you assuredly want to run Bristol Pound on a compatible but separate system. And then you want the rest of the CC movement to benefit from your sharing. However the RFI doesn't say any of this.
There's no harm in telling us about:
- the TT governance structures
- what TT, NEF and Qoin each hope to achieve
- where the money is supposed to come from, and how much, and for how long
- who will be looking after the software
- who else you think will use it
- the participative process by which you determined all these features were necessary
- related timelines
4. You have composed a long list of requirements, some of the hardest ones are mentioned most briefly! e.g. "instalments should be able to fully work together, share tasks, connections etc"
Instead you are looking for a bundle of functionality which you know doesn't exist to address problems which don't yet exist.
Separate your requirements:
- ones that you actually need delivered in phase 1
- ones you expect to need down the road,
- ones you could live without
Other occupants of the CC space
I believe I currently have the best overall understanding of the software in the space. My knowledge is weakest around Cyclos and GETS because they do not have a culture of sharing. My report for IJCCR wasn't the place to provide evaluative assessments, but I think this is the place to offer some opinions, and I am publishing early so they can be augmented by the projects themselves. I would also direct you towards my blog posting on how to choose CC software; though it is aimed at smaller projects than yours, the same rules apply about assessing the whole project. It's like an arranged marriage: you're not just looking for the best quality babies, but to make a relationship with a whole family.
I believe you should be aiming to throw your all your weight behind one (or possibly a combination of) these projects. Be assured that you are not asking for anything which has not been considered and which other projects do not have on their todo lists. At the end of the day everyone in this space wants to provide a generic solution to all the money problems. All the projects mentioned in this section understand
- It should be next generation, modular software rather than 1990s monolithic application. This means that there is some kind of ongoing software framework, with a community of developers extending it in all directions, so you would expect it to support web APIs.
- the need for decentralised governance (this implies open source software)
- the need to support a wide range of experimental currency designs than
- the need for a scalable, modular architecture
- the need to support national currencies alongside 'complementary' currencies
Each of the projects is concentrating on different aspects of the whole problem as their resources and immediate drivers dictate. My comments below relate not to specific features but to these six strategic requirements, to which the string of 1s and 0s refers. The first requirement is in bold because I believe it is essential. '-' means I don't know
Cyclos (00101) is an extremely powerful piece of software which some would consider the obvious choice. Of all the players, it takes pole position by already meeting most of your functional requirements. The intention of the project has always been to support STROhalm projects and it is the perfect application for that; However despite being open source, the project has given little attention to providing general solutions or supporting a community of outside developers. The software is now showing its age and the architecture seems somewhat entrenched compared to more modern software. To compensate for it's lack of pluggability, Cyclos has built in many features such as content management and a marketplace, but while these features do extend the usefulness of what is otherwise accounting software, they do not come close to providing the flexibilty that engineers have come to expect. Finally, while the Tauschring network is running many instances of Cyclos side by side, I've yet to hear of cyclos instances working together in any way.
CES (01000) is flavour of the year since it has enable many many LETS-like groups to start trading online easily, and Tim is greatly to be commended for his software achievements. CES is valuable because it has got all the users on one software platform thinking of themselves as one big community. However after ten years continuous development this software is at the end of its useful life, and needs to be completely re-engineered. I hope the achievements of CES will be honoured by someone providing those 250 communities with a way forward which preserves most of their data and ideally allows them to continue trading with other. Tim himself continues to work on intertrading over the internet, and plans to turn his attention to a global marketplace.
GETS (00001) runs myriad B2B barter networks in an industry which has failed to engage 97% of businesses even in a depression. Which is to say the B2B model which GETS is designed to support is failing to thrive. The ethic is not so much open, but seeking to enlarge the silos. The so-called universal (barter) currency does not have an open API. Users report that software development is not responsive to their needs. Nor is the code available for inspection or modification. A partnership with GETS would necessitate a change in its business model, if not starting from scratch.
Drupal (11111) (note - this is why I've been doing Drupal for 3 years) is rapidly becoming a standard for web application development. It has hundreds of thousands of developers and thousands of modules which extend it in every possible direction. Originally designed to be a general solution for LETS, the mutual credit module can be set up by an enthusiast to run a baby-sitting circle or it can run all the timebanks in parallel. Though the accounting ability falls far short of Cyclos, development continues apace, and the indications are that there are many potential applications out there.
One very interesting possibility which I have discussed briefly with Qoin is build drupal integration for Cyclos, and to use Cyclos just as an accounting tool. Another would be to extract or re-engineer the Cyclos accounting architecture and build a web API so that other applications can use it as a sort of accounting back-end. This would potentially have very wide impact.
OS Currency (11-1-) is well architected and shows great promise, despite being mainly a 'hobby' so far. the platform it uses is rather obscure. If it was decided to start from scratch, this project would have something to offer as it is very modern.
Xchange Stewards (11111) is a new project which aims to reshape the B2B industry by providing a set of APIs which allow the marketplace, payment systems and accounting functionalities to be performed by completely unrelated software instances. This should end the software lock-in which the barter industry seems to depends on, and should open up barter currencies to much wider marketplaces. Although at an early stage of development, this approach is very strategic and deserves to succeed. Currently they have modified the Spree marketplace, and are integrating it with Drupal as an accounting back end. I hope any solution would involve this project.
Metacurrency / Ceptr (11111) intends to meet all these strategic requirements from the start by re-engineering some parts of the internet most of us take for granted. Of all the projects mentioned this one is taking the highest view, but is also the least mature. The particular emphasis of this project is on designing different kinds of permission-enabled groups with different kinds of filters and rules for exchange. Then to release it as a software framework suitable for a whole new breed of application. The really important thing about this project is that reputation metrics are offered alongside monetary currencies, which offers a lot of room for experimentation in a direction a lot of people think is the way forward.
Common Good Bank (11001) recently advertised for engineers to build their software for nearly $1,000,000. I don't how secure the funding is, but there are no indications that they intend to build a software ecosystem. The approach seems to be much more akin to venture capital to start a new kind of banking business. Their priorities are very accounting centric, and I do not know of any attempts to engage other actors.
Comox Valley (11110) is securing funding for a large scale project designed by Michael Linton. The innovative design emphasises a multiplicity of currencies running with very little external governance; there is a strong emphasis on groups shared with Metacurrency. This project seeks to own as little code as possible but its requirements correlate strongly with the other projects here.
Transition Drupal (11000) name is set aside to Angel Angelantoni in San Francisco. I talked to him in October. The plan is to build a Transition Town Drupal installation, including a local currency. It hasn't progressed very far, but he should be kept in the loop for now.
How I would build the FD
Every feature requested in the RFI is reasonable and possible, but they will not all happen at the same time or even work in the same software installation. Instead, modules and features will be developed and deployed in order of priority. Some installations will have more features than others. Some installations will share configurations and other resources. I am not concerned here with individual features, but with the development processes.
Firstly I would not release an RFP, because I don't believe this work should be done as a contract. I would instead seek to make many grants. The only actual contract might go to a firm who would design an attractive, usable TT web site with the payment system, and only if those skills couldn't be found within the movement. For maximum impact my approach would be to foster many initiatives and seed sustainable community processes which could own the software when the grant money dries up. I would not seek to implement all these features for Transition Towns, but provide the road, the map, the bicycles and a good push.
In my opinion there is one thing really important element which the movement is not yet working on and which you should support. I have already mentioned the silos which even the so-called 'universal currency' cannot escape. Any two currencies can make an agreement like an exchange rate, but they won't really be able to trade unless each software supports a common protocol. That protocol doesn't exist. In fact there isn't even a candidate yet. Your RFI says, and I strongly agree, that we should for now concentrate on building one system, and that different instances of that software should be able to transact, but we should get right to work defining the way that they should transact, so that different softwares can be part of the ecosystem from the start, if they want to. Building on the relationships I have with various projects, I am promoting an idea called Mutual Recognition Agreements. Several projects are very close to appending their names. Without the support of the key projects, I will not push this.
You should decide who you want to work with for the next three years, and who will do what, and what the end state should look like. Then choose a real world project and aim to meet its minimum requirements. This should be called phase 1. When you deliver phase 1, you will have built the first parts of the whole system and they will available for all the others if it is properly built and published according to the project plan. Then choose another beneficiary project and take them to the next level and so on. All the time we need to be encouraging grass roots participation because top-down funding is politically motivated and whimsical, while grass roots participation is what makes a project sustainable and relevant.
Rough schedule
If I were implementing the above strategy, this is what I would do in the first 3 months (kickoff)
- Approach Metacurrency and Xchange Stewards and pay them to develop a protocol for mutual recognition agreements.
- Convene a Community of Practice led by Stephen de M and John Rogers, so that all innovators and implementers could be on the same page. I would make special invitations to organsiations like Spice, STRO, Wir, Banco Palmas, BACE, Fourth Corner, CES Community Tools, Timebanks everywhere, and strive for participation from every continent.
- Invite Bristol to be the beneficiary of phase 1 and prioritise their requirements
- Develop a formal design document describing the 'end state' we were aiming for
- Engage the London hackerspace to develop cheap, open source Point of Sale technology .
- Set the agenda and provide material support for the next version of the drupal module. Assemble a small team of engineers who would upgrade the mutual credit module to Drupal 7 meeting Bristol's launch requirements
Then for the rest of 2011 I would (phase 1)
- get Bristol launched as soon as they were ready
- Work with Community Forge to start and foster a grassroots software support community which manages software per town
- Start a learning process in the CoP which looks at issues of implementing currency designs and increasing adoption
- Introduce a system of bounties to encourage feature development for Transition Towns
- Implement Mutual Recognition Agreements between Transition Towns
- Work with John Rogers to come up with a "NEF currency governance rating"
- Support CES to become MRA compliant and make agreements with Xchange Stewards' groups.
- Promote the MRA and the rating together in public to get the B2B industry and Cyclos on board.
- Give money to CES to develop a migration path to Drupal
- Define phase 2
Then in 2012
- Find a way to get a for profit MRA compliant B2B network started in every town, by developing a template, franchise, or other enabling technique
- Encourage academic assessments of the new economy
- Make available a Transition-Town installer package
- promote attempts to localise the internet and other communication infrastructure without which no transaction can ever be private
- Work with energy companies on backed currency designs
- Consider other requirements that couldn't be met by drupal
- start talking to serious financial people about the debt-free economy
Conclusion
The software that needs building would have numerous commercial and social applications, and should be able, with right business plan, to fund itself in the long run. I believe that to be worthy of the kind of up front funding we need, we have to build a coalition. I hope there is a paid role for me in this project (I have been 'saving myself' for it!) because I believe it has the potential to be important, although the Drupal module itself isn't ready for me to walk away.
The vampire squid (this is now acceptable centre-left parlance, I think) is fastest vanquished by our radical giving. By the giving of gifts, we protect each other. The urgency is palpable; we must identify and enable the doers. Whatever strategy you adopt, I shall be seeking to engage with the project and to support it in word and deed.