The Growing Complexity of Drupal Core

A few days ago Jeff Eaton made some interesting comments on twitter regarding "noob patches" in core. In a nutshell he contends there's substantially less room in core for novice patches than there was 3 or 4 years ago. The cause: increasing architectural complexity in the Drupal codebase.

Based on my experience (I've been working with Drupal since 4.6) his point seems impossible to argue with. Drupal core has definitely grown more complex over the last two major releases but don't take my word for it, check out these code examples:

Drupal 6

    $result_db = db_query('SELECT * FROM {actions} WHERE '. $where_clause, $where_values);
    while ($action = db_fetch_object($result_db)) {
      $actions[$action->aid] = $action->parameters ? unserialize($action->parameters) : array();
      $actions[$action->aid]['callback'] = $action->callback;
      $actions[$action->aid]['type'] = $action->type;
    }

Drupal 7

  // When we have action instances we must go to the database to retrieve
  // instance data.
  if (!empty($conditions)) {
    $query = db_select('actions');
    $query->addField('actions', 'aid');
    $query->addField('actions', 'type');
    $query->addField('actions', 'callback');
    $query->addField('actions', 'parameters');
    $query->condition('aid', $conditions, 'IN');
    $result = $query->execute();
    foreach ($result as $action) {
      $actions[$action->aid] = $action->parameters ? unserialize($action->parameters) : array();
      $actions[$action->aid]['callback'] = $action->callback;
      $actions[$action->aid]['type'] = $action->type;
    }
  }

Both of these code snippets are from actions_do(). Prior to Drupal 7 if you needed data into or out of the database you'd use db_query() and that was that. With Drupal 7's object oriented database abstraction layer, you have many more options, but at a cost of obviously increased complexity. Note: db_query() still works as expected in Drupal 7, at least at time of writing.

Admittedly some increase in complexity between versions is probably unavoidable, perhaps even desirable. But when the complexity of the codebase is approaching a point where the developers at Acquia and Lullabot are the only ones capable of making even simple patches to the codebase I can't help but wonder what this is going to mean for the rest of the developer community.

At what point does the trade off between features and an accessible codebase stop making sense? Where are we going with all of this added complexity? What's the real goal here?

Return on investment

The most common complaints about Drupal I've encountered (from developers and non-developers alike) all involve complexity. It's a PITA to set up common website features. For example it takes at least three modules (forums, advanced forums and some kind of WYSYWIG) to convince Drupal forums to stop sucking. Even then you're stuck with moderation issues.

Another common complaint is the ever changing nature of available community contributed modules. Some modules are available in Drupal 5 but are stuck in dev limbo in 6. Some exist for 6 but where never backported. There are hundreds (if not thousands) of orphaned or semi-orphaned modules in contrib, many of which replicate the functionality of other modules.

Taking this into account, the question (in my mind) is why is so much effort being pumped into making Drupal Core hairy while the contrib codebase is (desperately) in need of some serious attention?

The community at large has made it quite clear that increased adoption of Drupal is the overarching goal. If that's true then wouldn't it make more sense to directly address the most common complaints about the CMS before adding a bunch of new features to core? Perhaps launch a cleanup initiative in contrib like cleaning out the orphaned modules and building out some robust modules that provide plug and play for common features (forums, groups, events calendar WITH rsvp, galleries, etc)?