A user on the Twin Cities PHP User Group asked this question recently, with the context being the configuration of a complex site with many users and data relationships between those users and other content. 

In these communities Drupal sometimes gets a bad reputation.  People don’t fully understsand what they’re dealing with when they download Drupal.  They un-tar it, install it, and end up with a “now what” moment.  

As a community, how do we respond to this?   Here’s one example.

The Answer

The primary reason I've maintained an interest in working on Drupal is to accomplish the CRM system you are describing here.  The only way you can get a comprehensive view of how users are participating in your network is to use a system that is extensible enough to aggregate and produce information on a variety of data points of different shapes and sizes.  As others suggest, it can't be done without some out-of-the-box thinking and a little code, but I'd argue that it's a very good investment.

Essentially, Drupal is a RAD system disguised as a content management system.  That is, it's made up of "content types".  Out of the box, you get "page" and "story", which are not especially inspirational.  It's expected that you add other content types such as blog posts, events, polls, and so-on.  This is also interesting, but not groundbreaking.

When you stop thinking of content types as content, and start thinking of them as entities, things get interesting.

Describing the tools

Before you get anywhere with this, you need to install an important module, CCK.  This allows you to add arbitrary fields to your content types.  You can add text fields, numbers, and checkboxes.  You can also add Node Reference fields, which create relationships between different entities.  Now you can create "courses" that link to "departments", or "organizations" that link to "managers", or just about anything else you can think of.

Another key module, Views, is a query builder of sorts.  You can mash up any of these fields, and/or fields from your other entity types, filter on a variety of field-based and global criteria, and output the results however you'd like ( lists, tables, CSV, RSS, json, query results for integrated mass mailings, etc.)

With all of this, most Drupal applications are created without any coding at all.  You can build up content types and list them out, import them and export them, share the data with other applications, or possibly be an RDF data store.

Most Drupal coders spend their time writing fields and formatters to jack into this system.  There are field modules for date handling ( with ical import/export ), image handling, image post-processing, local and remotely-hosted media, geocoded addresses, sky's the limit.

For example, some of the work I've done recently includes adding OpenGIS datatypes from MySQL or PostGIS into this framework, and/or searching for data based on publicly available shape files.  (I'll cover this at this Wednesdays DUG meeting - http://groups.drupal.org/twin-cites for more ) You could do that yourself for a one-off app, but why?  This is true of any number of field types.

Fields can use different output formatters depending on the context of how they're used.  For example, an address field could be a zip code, a formatted address, or a map.  It's all a little like MVC, but on a much more slice-and-diceable level.

A reason Drupal frustrates people is because its focus is more on processing data and information than on micromanaging the rendering of a single web page.  Folks with a background in HTML, Dreamweaver, etc. expect to be able to place and order information "just so" on their web pages.  They don't want to think about their pages as data, and they certainly don't want to think about routing a flow of community content throughout their site.  This causes many webmasters to run screaming to Joomla.  By contrast, people who think in terms of databases, or people who are accustomed to working with a flow of content ( such as newspapers ), or people who simply view it as a newfangled word processor have a much easier time.

I hate Drupal!

This is a sentiment I hear quite often from people who went about it the wrong way, or from organizations that got stuck with a set-and-forget installation and no training.  It's an impression that can be avoided with some foresight, some planning for sustainability, and some understanding of best practices.

For example, the biggest mistake people generally make is failing to understand the deconstructionist model I've described, so they start downloading dozens of single-use modules that don't work well together.  They also fail to understand that "less is more", and so they switch on every possible module and every possible permission.  The result is daunting for users.

People "hate" just about any tool that makes powerful claims but whose usage is elusive.  In Drupal's case this is often a problem with education or pre-planning, of getting started without a knowledgeable guide.

Starting off on the right foot

I would never start a Drupal project without using a pre-made distribution, such as something that Bryght, Acquia, or even Advantage Labs provides (our latest build is at http://svn.advantagelabs.com/managed/drupal/releases/drupal-6/campion ).  Not only is this a time saver, it's a way to outsource module vetting to someone whose survival depends on the sustainability of the modules they're including.  Many (but not all) of the usability arguments against Drupal are addressed by these distributions.

A lot of people also "hate" proprietary solutions or their developer's roll-your-own tool, but since you can't always call those out by name, you don't hear about them as consistently.  The difference is that there's a much smaller pool of resources, training, or support vendors who can help people out a proprietary dead end.

My $1.50