We (Carsten and Carina) have been sent out to tell the Drupal community about our latest project which has potentially huge implications not only for Cocomore, but for Drupal as well.

The topic of Drupal’s backward compatibility issues has come up in various ways over the years and has been an issue of debate in most cases. When we responded to Dries’s “State of Drupal 2011” survey, only about 8.2% of the community members who responded indicated that improving backward compatibility was one of Drupal’s “biggest challenges”. But this is actually a pretty large number of respondents, considering that there were 19 other options for the question, and we could only select three, and also considering that the majority of those who took the survey might not represent the majority of Drupal stakeholders who would most benefit from improved backward compatibility: people who might not work with Drupal full-time, and might not personally maintain any code, and who want to upgrade their sites to the next major versions, but cannot do so easily because of missing modules and the fact that, regardless of whether a module might be very close to compliant with the next major-version API, modules are only for one major Drupal version.

If this lack of API backward compatibility were common with Windows or Mac applications, or Firefox plugins, or just about any other software written for a platform, far fewer people would make these upgrades or they would wait a very long time to do so (and might end up changing operating systems or browsers to avoid the headache). The opposite is actually true in the case of Mac apps; Apple has historically supported legacy code and legacy processor types with compatibility bridges which, although not particularly great for performance, at least allowed needed software to run. Firefox and Safari, my two most-used browsers, regularly release major updates which don't break every plugin (at least with Firefox, some add-ons are identified as incompatible and disabled until a compatible version is released). And PHP deprecates functions, but usually doesn’t make it impossible to use code that worked in the previous major PHP release. But Drupal introduces major changes that result in developers having to learn a whole new API just to get their modules or themes ready to run again. This made sense in the past for a variety of reasons, at least back when Drupal was still in diapers, but there might be sufficient reason, now, to revisit the issue and explore whether this approach still makes sense in the foreseeable future.

Lest it sound like I think this approach was always a bad idea, I should say that I do understand the logic behind breaking compatibility, at least historically. Too much attention to backward compatibility and it limits innovation, more bugs creep in, and the code starts to bloat. There are even former Drupal developers who claim they now work on slimmer platforms in order to avoid what they consider too much bloat in Drupal, already. It’s doubtful that Drupal would be as popular as it is today if the core team had focused on maintaining backward compatibility in the API just to keep from breaking legacy code. But what worked in the early days of Drupal may not work so well when there are thousands of modules which are not considered high enough priority to port to the next major Drupal release and most larger Drupal sites seem to have at least one of those that they consider a necessity.

Bar chart from Dries’s summary of the State of Drupal 2011 survey results:
For the purposes of this post, I’ve marked up the image to discuss a few points. Yes, there are “only” 269 respondents who chose backward compatibility as one of Drupal’s biggest challenges. But it is also arguable that this challenge is directly related to many of the other challenges which ranked higher.