Torenware Networks

Right now, most of my work revolves about getting Drupal to work well with CiviCRM, the contact relations management package that's bundled with the CivicSpace distribution of Drupal. Some of the work is about ready to demonstrate to the wider developer community, and I'm getting ready to do just that.

As a part of doing this, I want to start a discussion about how people are using CiviCRM, and what features that general users and developers believe they need to get CiviCRM to do what they need. So first, some general ideas of what people are doing, and why they're doing it.

Why Contact Relations Management

Drupal, the content management system that's running this site and many others, is as well known as it is mostly due to one and only reason: people involved in the Howard Dean For President campaign chose it as one of their main tools, and during the campaign a lot of people became familiar with that. I'm not sure if the Wesley Clark For President campaign did so as well, although I suspect that more than a few Clarkies were Drupalers as well. But between the two campaigns, a nucleus of computer professionals became very good at PHP in general, and in using Drupal in particular. A number of the best people founded companies that built their business on Drupal as a platform, and in doing so, created a small but very dynamic "economy" based upon Drupal.

While the key "application" for these political campaigns may have been blogging and other community building applications, pretty much everything that a political campaign can do on-line has been tried by someone or the other in the community, including the core things that political campaigns do: contact voters, manage volunteers in a campaign, and support basic activities like get-out-the-vote (GOTV) and political canvasing (i.e., send people door-to-door to talk to voters, find out what local people think, and help persuade them where it makes sense). Drupal has not been central to this. The most popular application for this currently is Advokit, which was stitched together during the 2004 campaign. Advokit is not bad for what it does, but was never intended as a long run solution to these sorts of things: it was created quickly to solve the needs of the 2004 campaign, and was not engineered to be easy to improve or maintain. So out of the frustrations of working with Advokit, many people have been looking for an alternative.

CiviCRM isn't an alternative by itself, but a number of us think that it can form the basis of an alternative. CiviCRM is a system developed by Donald Lobo and Dave Greenberg in PHP, and is designed to give a non-profit or community group the tools to manage their membership and the various groups and constituencies that the group works with or deals with. It's a specialized data store that's designed to deal with information about people and organizations ("Contacts" in CiviCRM's parlance), and to organize the contacts into groups and by various criterion ("Groups" and "Tags" in CiviCRM). It also has tools to record the relationships between contacts ("Relationships") and the history of what's been done with/to a contact ("Activity History"). Lastly, it also includes applications that work with the data for mailing ("CiviMail") and for taking contributions on-line ("CiviContribute").

While CiviCRM does not have the UI that Advokit has, it has a much more flexible and extensible data model: you can create custom fields easily, for example. It also has various mechanism for controlling the "view" of a contact ("Profiles"), which make it possible to restrict which fields a user sees, and how those fields are presented for data entry.

And it has a final advantage about which I'll write about at much more length: you can use frameworks like Drupal or Mambo together with CiviCRM to build applications. This is my major area of work right now, and CiviNode, a project sponsored by the Collective Heritage Institute of New Mexico, the people who are better known as the Bioneers.