Random Thoughts on Backdrop CMS

October 2013

I’ve been reading about Backdrop CMS, the new fork of Drupal. Personally, I think forks are great. I think it’s wrong to think of a fork as an insult to a project or a community. Forks are a feature of open source development.

That said, I don’t share the concerns of the Backdrop project leads.

I, too, am a self-taught developer. I was not a computer science major (English majors FTW!) and I wince when people describe what I do as engineering. I don’t use an abacus or even a ruler; I rely on Google Calculator for embarrassingly-simple math. Nonetheless, I’ve always tried to improve my programming skills and to keep mildly abreast of emerging web development techniques and practices. So, for me, the prospect of fully embracing object-oriented code, plug-ins and MVC design patterns in Drupal 8 is exciting.

The motivations of the Backdrop team seem informed by anecdotally painful transitions from Drupal 6 to Drupal 7. I started working with Drupal with version 6 and regard the transition to Drupal 7 as a happy one. That might be partly to do with the fact that I’d done a lot of e-commerce work with Ubercart and was happy to start working with Drupal Commerce instead. Commerce like no other contrib project that I know of, embraced the new entity and field system to great success. I also regard the database abstraction layer as a huge DX improvement. In a previous life, I had done a bit of a work with ASP.Net and C#, Java and played with Rails, so I welcome the opportunity to get back to more OO code.

From some of the Backdrop proponents, I detect resentment at having to learn a new system with every Drupal release. Jen Lampton suggests that many Drupal developers are looking for an “exit strategy” so they don’t have to learn Drupal 8. This confuses me. For developers looking for less complex systems there have always been WordPress and, arguably, Joomla.

My perspective is a bit different. I would not be having fun if I wasn’t learning new things every day. I’d be looking for an exit strategy if Drupal was not trying to embrace standard design patterns and modern programming techniques. Other frameworks/systems are a threat to Drupal only if Drupal continues to embrace Drupalisms while eschewing the every-day patterns provided by Symfony, CodeIgniter, Rails, Django, etc.

Drupal 8 will continue to support hackability, for better or worse, by the simple fact that it’s based in PHP. So far as I can tell Symfony2 does not eliminate the global scope nor one’s ability to hack core. It might stop people from loading all sorts of business logic into tpl files or template.php: is that the sort of hackability Backdrop wants to continue to support? If I were cynical, I would suspect Backdrop was just a round about way to avoid fully porting Webform to the world of entities, fields and exportables :-).

Right now my biggest question regarding Backdrop is how it will support and create a contrib community? Do the Backdrop proponents plan on forking views (and cTools) as well? Rules?

I’m going to keep my eye on Backdrop though. Until now, there wasn’t another CMS/framework worth comparing to Drupal. And now there will be and I have to believe that will be a good thing.

 

This post authored by former Isoveran Kelly Lucas.