CiviCRM Community Forums (archive)

I'd like to start with a disclaimer. I really can't stand posts like this... when some dude simply spouts off about everything he hates about an open source software package. But it isn't a hate post. It is a grievance post. I don't hate CiviCRM, but it is a headache.

Before everyone starts telling me how incorrect my impressions are, I'd like to clarify why I am posting this elaboration on my grievances with CiviCRM.

This was prompted by a single Twitter post on my part... simply a random "argh!" moment: "CiviCRM is an administrative headache"

Lobo noticed the post, asking me to elaborate. Since the 160 characters of Twitter are not enough, he asked me to write a forum post, so here it is.

---

I've been running Drupal/CiviCRM for three years now. I first started with CiviSpace. It was my first venture into open source software. I was a volunteer on a tight budget, trying to get a tech foundation built for a nonprofit startup. Since then, I've learned a lot about Drupal and CiviCRM & they are meeting our needs pretty well.

So these grievances are not from someone new to CiviCRM, but are my general impressions of CiviCRM, built up over the last three years.

My quick summary of grievances are as follows:
(Drupal integration is flaky) + (releases always have errors) + (tech reqs are steep) = best for XL orgs

# Drupal integration is flaky
Lets say I want to have a calendar for my org... further, I'd like for volunteers to be able to sign up or for donors to buy tickets. There is no really elegant way to do this easily. That's not to say that it cannot be done... I know it can (I am working on getting it setup), but it is a headache.

I am forced to choose between CiviEvent and a combination of Drupal modules to manage the events. If I go with CiviEvent, I am stuck in CiviCRM and cannot use the wonders of CCK/Views to do cool things like mapping my events or custom presentations of attendees or photos and tagging of events. Plus, since CiviCRM's theming standards (colors, icons, etc) are inconsistent with Drupal, I have to run a totally separate theme to accommodate CiviCRM, which makes donation pages and the "CiviCRM profile" pages totally inconsistent with the rest of my site's theme, branding, and user interface.

Further, it makes no sense to me to force users into have *both* a CiviCRM profile as well as a Drupal profile. Sure, I can collect a user's address on registration, but there is no good way for Drupal to use this info because its stuck in CiviCRM.

Or, lets say I want to do a newsletter. CiviMail, right? Except that, again, it stays inside of CiviCRM. Oh, if only I could expose my newsletters as nodes! CCK, where are you? Instead, there is a highly technical interface for sending a newsletter via CiviMail, then my ED has to copy and paste into a Drupal node. Argh. If only I could use CiviMail as an output option for the Messaging Module! Then, I could get all of the wonderful high-tech tracking features of CiviMail, but let users manage their subscriptions without (again) dealing with the CiviCRM profile page.

These are just key examples of the overall headache of CiviCRM for me. The little bit of integration with Drupal that exists is flaky. Like the ridiculously archaic Gallery2 Module for Drupal, CiviCRM seems to just sit *inside* the shell of Drupal, but not really interacting with it or using it. Instead, functionality gets built in parallel to similar functions being developing within the Drupal framework. I get why this is the case, though: Joomla and the sponsored standalone version don't need Drupal integration.

#Releases always have errors
Well, yes, of course releases always have errors. But they are still a headache, right?

Where this becomes difficult for me is that I have a really hard time navigating the issue cue for CiviCRM. I wish I had a good way of looking up for myself whether a problem that I am having has been addressed in the latest build.

There doesn't seem to be a good way for me to check if I am "up-to-date." I think I am... the version numbers match with the download page... but then after posting in the forums here, I am kindly asked to download the latest release.

#Tech reqs are steep
This is the kicker, I think. I've spent the last three years of my life consistently needing to learn more tech just to try to get CiviCRM to do what I want it to. CiviMail? You better be running your own server. No Dreamhost free-for-nonprofits hosting for you. You want to try to use CiviCRM's dedupe functions? Again, only if you are running your own server. Everything else will work, but will be exceedingly slow.

Plus, to try to massage CiviCRM into playing nicely with Drupal, you will need to have someone fairly tech-savvy to find the hoops or write custom code.

For example, CiviCRM has an honoree function, where a donor can specify an individual which a donation is "in honor of," so I set it up only to find that it doesn't collect address info? WTF? This seemed to me to be an obvious piece of info to collect for such a field. Nevermind, though... lets go to the forum.

http://forum.civicrm.org/index.php/topic,5914.msg25964.html#msg25964

Lobo's reply represents the best and worst of CiviCRM, IMO.

User: Can I do X?
CiviCRM community: Yes, but only if you hack it.
User: Eeg! Code!?!
CiviCRM community: Don't worry, we'll walk you through it. Just login to IRC.
User: Huh? What's IRC?

The community is awesome and it is incredible that Lobo would extend an invite to walk me through the headache of tweaking CiviCRM to get it to do what I need it to do.

But it is still a headache & IRC represents a tech hurdle in itself.

# best for XL orgs

In summary, to *really* make good use of CiviCRM, you gotta have time and money, because it is not going to do what you need/want it to do out of the box. You need developers on staff in your nonprofit to hack the code so you can collect address info for honorees, and to develop custom Drupal modules to interact with CiviCRM. And you better have the budget for a killer sysadmin who can run her own linux server (none of this non-profit friendly budget hosting business), so that your staff can actually run reports, dedupe contacts, use CiviMail, and wait less that 20 seconds for a contact page to load.

---

I would like to close my spiel with what I consider to be the very best aspect of CiviCRM... the forums & the people running the show. I've never had any problems getting good, solid feedback on this forum from both other CiviCRM users as well as the core developers. Lobo's response to my inquiry about collecting honoree addresses is a good representation of the quality of the support, even if IRC is a further technical hurdle for a lowly admin like myself.

And I understand *why* these headaches are there. No need to explain to me (CiviCRM can't decide what its relationship with Drupal & Joomla is and/or ought to be... all software has bugs... powerful tools need powerful infrastructure)

As warned, this was a spiel, and I've no intention of going anywhere. CiviCRM is adequately doing what we need it to do. In all, I think CiviCRM is worth the headache, but it is still a headache.

Hi NeuroMusic

As everyone here can attest, I certainly need all the CiviCRM / CiviMail help I can get and would welcome the chance to share ideas.  I'll send PM - you can track me down at:
http://healthcareforallcolorado.org/?p=32

Also, might be time to suggest an internet radio program again with CiviCRM as the topic:
www.BlogTalkRadio.com

Eileen - just noticed your post here. I added a link to Demo, but was concerned that some folks wouldn't understand the "sandbox" concept without context. Also not sure about linking to IRC client (altho could put up link to in-browser mibbet client - was that your thought? ).

http://embed.mibbit.com/?server=irc.freenode.net&channel=%23civicrm&forcePrompt=true

Done (IRC now part of header for forum, wiki and issue tracker).

It's an iframe - so takes a while to load in browser cache. Try loading the iFrame URL directly and then come back to forum:

http://civicrm.org/sites/civicrm.org/developers/index.html