Community forge must move on from Drupal!

Readers less interested in the story of Community Forge may wish to skip the text in grey.

In 2008 grassroots social organisations were (and still are) behind the curve both in uptake and in appreciating the importance of open source. Most local community currency groups were unaware of the software options available and still using paper although migration to online packages was underway.

• Community Exchange Systems was the largest yet spread only by word-of-mouth, unknown in much of Europe.
• Most of Scotland was using a sophisticated MS Access package
• Fourth Corner Exchange was a cluster using instances of the same software
• LETSlink UK had recently started distributing using a fork of Fourth Corner
• OS Currency had just started in US, using a Ruby on Rails platform
• Time & Talents was running on one Timebank in Portland
• I had written a package, MatsLETS in 2004 but it had never been deployed

In addition the two main timebanking networks in USA and UK were each pouring money into large but inappropriate national web applications to server their respective networks.

Powerful PHP Frameworks like Drupal, Wordpress and Joomla were starting to replace applications coded from scratch, but local groups made software decisions based on the people they actually knew, many of them relying on ageing developers who were not adapting to that new paradigm of collaborative development and modular open source code.

Having just worked with a small NGO in Geneva I had some understanding of the issues that small organisations faced to build and own their own web sites, or rather I should say web applications. While a web site, even a content management system could be fairly straightforward, every organisation, had different business processes and wanted different, which is to say custom-coded functionality. The LETS though, had very standard requirements across the board and I saw that by creating software an order of magnitude cheaper and better I could empower hundreds of community groups and bringing them towards a standardised open source framework which would make future cooperation inevitable!

While the Typo3 guys were snowboarding together, the Plone guys were lost in another paradigm, the community of Drupal developers was very smart, cooperative and the best and most committed people were making good technical decisions. They were building businesses, contributing code as part of the business model, while many were working for the love of it. The range of modules available meant that I could focus only on the accounting (the bit that turned me on!) build a simple directory for offers and wants, and then it was a trivial matter to package the rest of the site. By adhering religiously to Drupal's own standards and conventions, my code would be readable, maintainable and extendable by future developers (paid or voluntary) who would surely come to the project as uptake increased. Build it and they will come, right?

What I really loved was that, once these components were written, Drupal's approach was to provide a vast configuration interface, which meant that the super-user could build a site from modular components without writing code. It was perfect for LETS who often more and less technically inclined people and who wanted a lot of control over their sites.

Drupal is a huge library of useful functions which means you can accomplish a lot by writing a little code. But that little code takes a long time to learn, and if there is a bug, there's a huge codebase to search through. Without the most powerful editing tools (it helps to have a tame sysadmin) or really advanced knowledge of php, I might spend 12 hours tracking down a single bug maybe once a month. It took me 6 months to learn Drupal 6, build my first Drupal site for SEL du Lac, and to deploy the LETS in Geneva. Not bad. Tim Anderson, the chair, and I then founded Community Forge - I wrote the software and Tim worked with other LETS, particularly a cluster in Belgium, to bring them onboard in a way we would all own and manage it. I recruited a friend to learn server management, and together we started to learn how much harder it was to manage many deployments and set up and run and defend, and optimise, and authenticate, and backup a web server.

After about 18 months we were up to about 15 sites and had found a professional volunteer to keep the server ticking over. Much wiser now, I wrote v2 of the mutual_credit module with multiple currencies and upgraded all sites with only a few mishaps. My plan seemed to be working when Timebanks USA deployed about 300 timebanks using my module!

Within days of 2011 when Drupal 7 was released I started work voraciously on the upgrade. It was a big jump, lots to learn. Almost every line of code needed rewriting. I joyously empowered local administrators with new configuration options like a plugin architecture to determine balance limits, spent weeks building an inline transaction form designer, and much more. It was really hard writing the upgrade routines the data for my module, settings for the Hamlets distribution, and all the settings for all the modules we used, many of which hadn't provided upgrade routines, and in the right order! But I was further encouraged when Timebanks UK gave me a verbal assurance they would work with Community Forge to deploy Drupal 7.

By Spring 2012, I had upgraded a handful of sites to Drupal 7 but not very consistently and users were discovering bugs and I was hotfixing an array of live sites, some of them customised, one by one, and just making things worse. But I just couldn't cope. A bug in a mass mail routine led to 3 sites sending not 100 mails, but 10,000 mails and our SMTP provider baulked and cut us off. Phil from New Zealand swooped in like an angel and set us up own own mail sending service. But then one night in Spring 2012 doing more hotfixes on the server I accidentally deleted the wrong directory and all our sites disappeared.

I never wanted to be in charge of live sites; I want to architect and build and fix beautiful things in PHP, but keeping them running 24/7 is tedious work which somebody else should be paid to do! Phil restored the sites in a few minutes but still, it was time to call for deeper engagement from our partner-users. It worked. There were enough donations to pay Phil a retainer, and Marie in Belgium stepped up to test the Drupal 7 version, translate into French, and build a support infrastructure.

Over the next 2 years the team grew to about 3 people who were really meticulous and we worked well together, loved what we were accomplishing and grew to about 80 stable functional sites. Donations increased to EUR3-4K per year, the team took over governance of Community Forge and developed training materials encouraging groups to take control of their sites. Also it was a concern that my work helping the middle classes re-imagine money was still far removed from helping the poor. It had become clear though that however great the software was, LETS themselves still weren't really growing, replicating, innovating or having any economic impact; not very many of them wanted to lend energy to building a global movement or to software. That's why in 2013 I leapt into the Global Ecovillage Network IT team, one of whom had learnt Drupal and single handedly built a colossal ecovillage database and social networking and project-management regionalised multilingual portal, which the network couldn't afford to maintain and was a daunting prospect for any rare drupal volunteer that might come along (i.e. me). Over three years I hope helped with the damage limitation and I kept the thing running until they found funding to migrate the most important bits into Wordpress, (about a year's work).

But that wasn't the only only Drupal disaster going on. Timebanks USA, lacking experience, money, advice and support had had a terrible time migrating and running and fixing their array of sites. hOurworld, an aging, closed source project but with a committed team giving usable Software as a service (SAAS) sites had mopped up hundreds of disaffected Time Banks depriving TBUSA of income and causing some friction between the orgs. I was ready and free and exactly experienced to give myself fully to helping TBUSA move to drupal 7, but the expert they engaged did not talk to me and they took his offer to build them a new system from scratch. At the same moment, Timebanks UK after a 3 year bout of institutional paralysis, lost the money, had hired a managing director who knew none nothing of those promises and accepted an offer of partnership from hOurworld. My plans were in tatters, especially because the timbanking movement had money, while the LETS eschewed money!

I was ready to change direction, but in 2013, that all changed when Karel Boele an Australian activist talented in project management, landed a contract with the state of New South Wales to provide timebanking for five years by upgrading CES into Drupal. CES was monolithic about three times the size of Community Forge, written in microsoft ASP from about 2001, maintained by a respected lifelong activist. I had read his intentions to make it open source and distributed but estimated it would take me 2 years to replicate and migrate to Drupal 7; I hadn't wanted to commit myself to that while single-handedly maintaining Community Forge, and while also wanting to innovate in Business Barter systems and ecovillages and transition towns! But Karel already had a very experienced Drupal developer, who said he could deliver the site in only 4 months! Yay I could help by just doing the mutual credit module but without being responsible! He urged us to go with Drupal 8, which was then in early alpha, and he would help me learn it. So instead of taking a sabbatical year, I girded my loins and started the next version of the mutual credit module.

I was so happy to have a coding partner! We started before Christmas but in the first week of January he had a massive motorbike accident. Over the following weeks it became apparent that he wouldn't return to the project. The back up plan was to hack drupal 7 Hamlets to deliver a multi-timebank solution with maps, a new theme and new stats. The components I already had enabled me to deliver that site, migrated and working pretty well, in five weeks. Thank Drupal!

I spent the next 18 months upgrading the mutual credit module to Drupal 8 two months of which was coping with API changes as Drupal 8 moved through many alphas and betas. But I loved it, great architecture, powerful tools, proper configuration, my faith in the platform was rewarded and strengthened. Hamlets, really a simple distribution was pleasingly quick to recreate!

By the time Drupal 8 launched at the end of 2015, I was an expert. To build CES I was waiting on some critical components which weren't in core. The rules module empowers site managers to trigger actions under certain conditions when events happen, so without writing code, they can do things like:

When a transaction happens:
 If it is in the needlework category
 If it is the first week of the month, 
 If the payer lives in Anyville :
  Charge the payee 5% into the Christmas box
  Send Santa an SMS

There had been a funding drive for rules, regarded as a critical module, the year before, but I tried a beta and it broke. Similarly the organic groups module, a foundation stone of the CES build and many many sites was way behind the curve. I joined the team on github and found several people tinkering at it, and really striving for perfection, but no visible progress being made. Perhaps they were all too busy in lucrative day jobs? Perhaps in the 7 years since I started all these guys had accrued families and mortgages? I started hearing that the love had gone from drupal. Acquia had been pushing it towards big clients, big money, the newer adopters were not communitarian and wanted only to sell sites using free software, not to contribute back. The tragedy of the commons had been exposed as a myth, yet as Drupal grew, somehow I was feeling more scarcity than abundance. A full year after Drupal 8 was released, these modules are still not usable, and worse, the core upgrade routines from Drupal 7 to Drupal 8 still are not ready. Should I volunteer weeks to inch along these huge projects so reap a little benefit for my users and a lot of benefit for the corporoate takers? The tragedy of the commons. Or should I spend time hacking my way forwards until the tools come, or should I wait while drupal 8 loses its lustre and Drupal 9 approaches?

Another elephant crept in the room during 8 years with my nose in my laptop. The technical pressure and my wish to work on wider money issues has afforded me very little leisure to survey the larger trends communing with other developers. I knew that things were moving to mobile phones and the client side was doing more work, but I didn't realise how web frameworks were being pushed out by this whole new approach. Web platforms which perform all the functions of the institutions which own them are being replaced by a new architecture oriented around users' tiny screens and the short tasks they want to do. Apps are more responsive by doing more of the work on the device, not by bootstrapping a massive application on the server and reloading a page every time they want a bit of data.

Drupal is designed to do everything, handle a request, retrieve data, skin it and deliver data. I'm still trying to preach to hOurworld about the separation of concernes into modules in a lovely framework, and wondering if some of those module might be more universally useful as web services with REST API interfaces. Meanwhile the framework itself is being obviated by a separation of greater concerns. The user's device now manages all user interaction by pulling specific pieces of data into an app instead of requesting web pages; authentication and identity can be done by 3rd parties; and data storage is done using web services like Couch DB.

Drupal is finding more uses in mega institutions, not in NGOs. 8 years of full-time engagement enable me to cope with its complexity, but none of the volunteers or institutions I want to partner with have the knowledge or resources to own enterprise-grade software. In 8 years, not one volunteer has contributed code to the accounting module or to Hamlets. While we are wed to Drupal, Community Forge relies absolutely on my special skills. To replace me with a team in India might cost thirty times more money than we currently receive in donations, and we would still be isolating ourselves technically.

Time to pivot. We have come far by building software ourselves without concern for fundraising. But we risk not only creating an impossible dependence, but also becoming irrelevant as we rely on too narrow skill sets. Drupal has helped a lot, and is still IMHO a great web platform for grass roots communities who have those skills; It would be an option for us if our movement were better aligned; but now the tide has turned; in order to stay technically relevant, engage volunteers, give a better user experience to module phone users, something else is needed!