Hosted CiviCRM at Koumbit.org

Publicado
2011-11-14 12:42
Written by
sfyn - member of the CiviCRM community - view blog guidelines
We've been offering CiviCRM consulting and hosting on a per-client basis for some time now, and as we have grown, we have started to feel the need for greater automation and consistency in our hosting offerings and contracts. Koumbit is currently in the midst of developing a comprehensive hosted CiviCRM offering, with the support of a few courageous clients. On the technical side our solution is intimately linked to the Drupal frontend and the Aegir hosting system. The aegir hosting system is primarily designed to host multi-site drupals. Once configured on a server, aegir handles many aspects of site deployment, from database creation to virtual host configuration. It also allows for the easy cloning of existing sites and the migration of sites from one Drupal codebase to another. At Koumbit we use Aegir to partially automate minor and security updates of Drupal and CiviCRM. Koumbit has participated in the development of Aegir since before it was called Aegir, and at the time of this writing we host several dozen client sites on our own Aegir servers, as well as supporting a handful of aegir vservers for developers and resellers. It was natural for us to extend the system to provide better support for CiviCRM, and the results of our efforts have been published to drupal.org as provision_civicrm. On the business side we are balancing several competing, but complementary, concerns. Hardware costs, maintenance and support time all have to be factored into the cost. At the same time, we want our offering to be competitive with comparable hosted CRM offerings, and want to meet high standards of reliability, uptime, and customer support. Finally, on a long-term perspective, we are still exploring the potential of this service as a turn-key hosted solution.

Our User Base

The majority of Koumbit's customers come from Québec's non-profit sector. This community has a number of concerns that directly affect our work and choices when it comes to CiviCRM.

Language

The most obvious challenge in our work with this clientelle is language. The majority of our clients and workers speak French as a first language. However, in Canada and Québec, most membership organisations must provide services and materials in both official languages. Multilingual websites are the norm, and the transition from one language to the other must be smooth, complete, and easy. I don't think it is controversial to assert that English is the most prevelant language in use for documentation and discussion in the FLOSS community. This demands a daily extra effort on the part of our mostly French-speaking developers to participate, patch, and report issues, as well as find solutions for their problems. It also means that we must often write our own documentation and create our own trainings rather than point our clients to existing resources. This challenge is of course an enormous opportunity for us as well, and in recent years Koumbit has expanded it's training offering, with an introductory CiviCRM training in French in the pipeline for January 2012.

Technology

CRMs are a relative newcomer on the Québec landscape. Many organisations, sprung up from the grassroots, have used the most readily available solutions to keep track of their membership and contacts. Over the years we have seen Access databases, Outlook address books, Excel spreadsheets, and a host of scratch solutions. Our own preference for Mailman as a mailing list manager has also recently come on the table, as a client has asked to us to allow them to manage their Mailman discussion lists via the same CiviCRM interfaces they use to send mass mailings. Koumbit's own CiviCRM is a case in point. Our CiviCRM contains imports from a Mailman list, our client list in LedgerSMB, and hosting accounts from our old shared hosting system, AlternC. Managing and synching these disparate data sources is a significant technical and logistical challenge.

Budgets and Financing

Québec non-profits face a particularly convoluted funding landscape. Private donors are few and far between, and conservative in their approach to funding projects, if not in their outright politics. Federal, provincial and municipal funding programs exist, but require applications in different languages. Every time there is a change in government, programs are cut and new programs are opened. Project funding is the norm, with funds offered on a limited period of time and for clear deliverables, often with the requirement that the funded organisation source a portion of the project costs elsewhere. In this environment small donations and membership drives of the kind that CiviCRM can facilitate are particularly crucial to long-term organisational health, and are presently becoming more central to most organisation's funding strategies. If we can provide an affordable and dependable solution for this kind of fund-raising, Koumbit and its clients will reap the benefits.

Case Studies

At Koumbit we know that client's needs and means can differ wildly. We typically experiment with new offerings by negotiating custom hosting and maintenance contracts with existing clients. Here is a brief description of one of our existing hosted CiviCRM contracts, which we are using to develop a final set of prices and services for our offering.

Réseau québécois des groupes écologistes

The RQGE asked us about CiviCRM after meeting with a company offering a proprietary solution and checking out some other open source options. We offered them a $900 a year contract for hosted CiviCRM. The contract included their existing hosting, updates to their Drupal site and their new CiviCRM installation, and one hour of support a month. Rather than have us migrate their contact database, RQGE chose to have an intern sift the database and enter data into the CiviCRM by hand, in order to allow them to iron out the inconsistencies that had built up over the years. This work is currently ongoing. This contract has pushed us to identify a panoply of issues affecting CiviCRM in the Aegir/Drupal environment, from well-known administration menu issues to problems with CiviCRM's templates and temporary files directory.

You?

This is a beta service. As such we are open to adding new clients to our roster who are both serious about investing in a hosted CRM solution and willing to help us improve our offering. Please get in touch if you are interested.

Technical Notes

The meat, potatoes, tofu and organic kale of Koumbit is and has always been website development. As a primarily Drupal shop we have developed considerable expertise with hosting php, MySQL and a host of related services. Desjardins, the province's federation of credit unions, recognises us as an e-commerce service provider, and this also brings considerable business to our door. Three key issues have thus come up for us time and again as we and our clients have adopted CiviCRM: hosting and maintenance, translation and language, and payment processing.

Aegir integration (provision_civicrm)

The Aegir hosting system is divided into two parts. Hostmaster is the frontend - a drupal site to manage drupals. In the backend we have Provision and Drush. We maintain Debian packages for Aegir in order to simplify our deployments, and instructions for installing from those packages are available on the the Aegir community site. provision_civicrm was first written during the CiviCRM codesprint following the San Francisco CiviCon in 2010. Since then we have refined and expanded it, as the module has passed through several hands. It is not a one-size fits all solution. provision_civicrm is intended for small and medium sized systems (think thousands of contacts, and not hundreds of thousands) and supports only the Drupal frontend of CiviCRM. provision_civicrm makes a number of assumptions, in its current form, that are helpful to understand:
  • A site created on a drupal codebase with civicrm in it is a civicrm site.
  • The CiviCRM database and the Drupal database are one and the same.
Because of the Aegir concept of the Drupal codebase as a "platform", this works for us as a way to manage all of our CiviCRM sites on the same platform. "Ordinary" Drupal sites live on one or more seperate platforms. CiviCRM updates and upgrades are handled by the Aegir migration and cloning features. We use LDAP, file acls, and provisionacl to manage client and developer access to different sites. One of our current challenges is to ensure that provisionacl and provision_civicrm talk to each other.

Payment gateways (Desjardins and Moneris)

We have tried a number of approaches to managing payments with CiviCRM and our client's preferred payment gateways. One memorable hack relied on the Ubercart Drupal e-commerce module to process and receive payments and update CiviCRM accordingly. Presently we are working on integration of both Desjardins and Moneris with CiviCRM's built-in payment system.

Translation and multi-lingual issues

Koumbit has contributed many hours to CiviCRM's translation and multilingual management, including a partial translation (sadly, no longer online) of the CiviCRM book, and a multitude of patches to CiviCRM and to the Drupal suite of internationalization modules.

Comments

Great post!

Just a small nitpick: provision_civicrm no longer assumes that it is located in sites/all/modules, thanks to some recent patches.

Also note that if you wish to try the module, make sure you checkout the latest version from the git 6.x-1.x branch. We committed a few patches following the Albany code sprint, but haven't done a formal release yet.