CiviCRM Community Forums (archive)

As an open-source enthusiast I'd love to be able to recommend CiviCRM to replace our existing Raiser's Edge installation. But I have several concerns, principally the issue of customisations and future-compatibility. If we adopted CiviCRM, we be budgeting thousands of dollars for various customisation - some of which wouldn't be of much use to anyone else, but some perhaps of use to the community. But what happens to all the customisation in the future.

Take the newish Gift Aid module, for example - a must for UK charities. Currently it only works in Drupal 6, so can't be used with CiviCRM 4.0. Neither does it work with Joomla. No doubt it will eventually be upgraded, but when? And if that's the case for a project blessed by the core committers, what would be the future of our own customisations? Will we have to pay hundreds or thousands of dollars every time a new dot release of CiviCRM or Drupal comes out?

And what if we supported the WordPress project (which is our preferred platform)? Would that place our customisations even more in danger? I had expected that the Joomla/Drupal modules would act as a bridge between Civi and Joomla/Drupal, but it seems as though they're more tightly integrated than that. Could we end up having not only to create a WordPress base, but also to maintain it into the future? Or would it get maintained by the core team once it's done?

Anyway - like I said, the prospect of using our budget to improve Civi for ourselves and others, rather than to pay licence fees for a proprietary product, really appeals. But if we're going to do it, I need to know it won't be money that's wasted next time there's a new release.

As an open-source enthusiast I'd love to be able to recommend CiviCRM to replace our existing Raiser's Edge installation.

I'd like to hear what you see a strong/weak points on each side.

But I have several concerns, principally the issue of customisations and future-compatibility. If we adopted CiviCRM, we be budgeting thousands of dollars for various customisation - some of which wouldn't be of much use to anyone else, but some perhaps of use to the community. But what happens to all the customisation in the future.

My experience (I tried everything from hacking, custom module, overriding template, contributing to the core...) is that quite a few stuff "specific to me" are requested as  well from others (we are not that unique after all) and that discussing the needs in the community helps finding the cheapest and more robust way. More often than not, by expending a tiny  bit the scope, it can be generic enough to be included in the core, and that's obviously the best way of future proofing your customisations (not to mention improving civicrm).

Discuss early, discuss often

Being able to change everything because it's open source is both a strength and a risk as you might end up changing anything. The "do not trespass" line is much clearer with closed source programs.

We have a much improved api, hooks, custom templates and enough experience to be able to help you customising the safe/future-compatible way, but obviously, something custom might need to be upgraded, hopefully it's going to be simple and we try to give enough early warnings about incompatible changes.

Take the newish Gift Aid module, for example - a must for UK charities. Currently it only works in Drupal 6, so can't be used with CiviCRM 4.0. Neither does it work with Joomla. No doubt it will eventually be upgraded, but when? And if that's the case for a project blessed by the core committers, what would be the future of our own customisations? Will we have to pay hundreds or thousands of dollars every time a new dot release of CiviCRM or Drupal comes out?

They aren't new major versions of drupal or joomla that often, and previously, the upgrade of custom code were rather pain free. By starting now you can be fairly confident that your custom modules upgrade should be simple/cheap, or not needed most of the time.

As for giftaid, probably when someone would need it and the users/sponsor are all (I think) using D6. As for the when, depends when someone will sponsor/code the needed. If that someone is you, it will be as fast as you need/can

And what if we supported the WordPress project (which is our preferred platform)? Would that place our customisations even more in danger? I had expected that the Joomla/Drupal modules would act as a bridge between Civi and Joomla/Drupal, but it seems as though they're more tightly integrated than that. Could we end up having not only to create a WordPress base, but also to maintain it into the future? Or would it get maintained by the core team once it's done?

They are a lot of different ways of customising civicrm, and you could do a lot of modifications that are not specific to one CMS.

We started using modules (that are CMS specific) mostly as a tool to package changes (ie. mostly using civicrm hooks, not drupal specific stuff). It should be fairly simple to migrate from one CMS to another, but wasn't a need of my customers, so by default that's drupal specific only. Same goes for joomla specific modules.

I don't know enough about wordpress, but it's fair to say that most of the heavy customisations and dev are on drupal, with a bigger experience (and pool of resources if you want to outsource some of the dev). One of the reason was that Joomla didn't handle advanced permissionsing, not sure WordPress does either. How much the CMS matters for your project (ie. is this only a wrapper around a new civi specific site or about integrating with a site that has years of content and customisation?). I'd suggest to keep it open if you can.

If you are in London on August 22, I would strongly suggest you to attend civicon, will be a good place to learn and exchange info with integrators and other users.

I'd like to hear what you see a strong/weak points on each side.

The big problem with Raiser's Edge is that if it doesn't do what you want it to, it's VERY expensive to customise. To do any meaningful customisations you either have to buy the API (a five-figure sum), or pay Blackbaud to do the customisations for you. Although you can rename or disable certain fields, you can't even edit the built-in forms without the API. There are other annoying restrictions (e.g. you can't query using SQL, only with their wizards). Don't get me wrong, I love Raiser's Edge in many ways, but for medium-sized organisations who need flexibility, it's just too expensive.

I don't know enough about wordpress, but it's fair to say that most of the heavy customisations and dev are on drupal, with a bigger experience (and pool of resources if you want to outsource some of the dev). One of the reason was that Joomla didn't handle advanced permissionsing, not sure WordPress does either.

WordPress has an excellent permissions system in the backend, though it's largely hidden. By default there are only see six levels of permission (roles). But plugins can create an unlimited number of own capabilities and roles for their own use:
//Set up roles and capabilities
$civi_admin = add_role ('civi_admin');
$civi_admin->add_cap( 'edit_civi_events' );
//Example use
if (current_user_can('edit_civi_events'))

With regards to the costliness or otherwise of extending CiviCRM to meet your requirements I think your strategy and budget process have a big impact.

We have a customer where we knew a year before they wanted to implement online memberships that they would need a specific improvement. However, they were unable / unwilling to commit any funds to sorting it out until the 11th hour at which point the only option was custom code (fortunately someone in the community had shared a prototype). Now we have another customer with the same requirement but as they have a short-decision chain and a few months notice our goal is to get them to co-sponsor the feature into core. It will wind up costing them less than it did the first customer and it will be available to others & by virtue of that improved and tested by others.

So, my thinking is that the way to make your money work for you in an Open Source project is to commit time / money to some of those things we often don't get around to - like promoting and sharing the work you have done in the hope that others will improve it, test it & make it more robust.

Another way to make your money work for you is by having an idea of what features you might want down the track & actively trying to promote those features and encourage / help others that are working on them. We are having pretty good success with the Make-it-Happen campaign in this area and I am encouraging our customers to set aside a budget for MIH that they can use to back the initiatives that would help them.

With regards to whether there is an extension framework - really there are several. However, I am like many, in the drupal camp - there are just so many drupal modules that provide really useful extensions for CiviCRM - views being the big 'can't do without'. However, CiviReports, Smarty templating, the API & the hooks system provide great api possibilities.

The drupal 6/ drupal 7 issue does make this a particularly difficult time - However, Drupal only does major version changes every 3 years. I took a quick look at the gift aid module & it seems likely it will require only a few lines changed to work on D7 (the version in the info file will definitely need to change). I expect no-one has tested it beyond that