Drupal Is a Developer's Toy

Children Playing with Toys Photo

When I was younger, I was fond of experimenting with different kinds of operating systems and applications. The internet connection was, politely speaking, not so good. So my parents regularly bought me a Russian magazine, called Hacker, which contained a DVD disk with a number of shareware and freeware utilities for everyday use. Oh, I remember how eagerly I waited every new release of the magazine and then spent days carefully learning the content.

I reinstalled my operating system almost every week, because I often broke it by installing some incompatible or buggy tools. I tried new design themes for my OS, music players, file managers, etc. I collected the most useful and convenient ones and shared with friends. I should say, my friends were fans of the software that I shared. I guess I developed a taste for good software at that time, of course, as a user.

Later, at university, I studied how software is built, experimented with many programming languages, learned theory and practice of programming. My hobbies also changed. Instead of finding a better music player I would prefer creating it myself. So, I became a developer.

My first job was partially related to Drupal. Drupal taught me how to develop modular, universal solutions applicable to a range of use cases. I believed there was the only one right way of developing Drupal extensions until I started to communicate with non-tech savvy users and tried on a user’s skin myself.

Today, I decided to integrate our Job Board powered by Drupal 7 with the Sparkpost email service. As usual, I went to Drupal.org to find an existing solution and I found it right away.

When I was installing the Sparkpost module, I noticed that it depends on two third-party libraries and two modules. It also requires Composer and Drush console tools. I have no doubts the module has a great architecture and its authors are very professional developers. The thought that bother me though is that a user never ever manage to install the module herself without assistance.

I have to say that the Sparkpost module is just one of the hundreds, maybe thousands, projects in the Drupal world, which an ordinary user without technical skills cannot even install. I repent I probably developed a couple of such projects in my past too.

In fact, Drupal community often focuses on better code architecture, rather than on building tools that work for ordinary people. Thus, Drupal 8 has been reinvented in favor of better architecture and that process has taken years. Developers seem to be happy with their new toy, but what’s the value of it for end-users?

An approach of building developer-friendly projects somehow worked for years but I think times change. Today users expect to be able to install a module for their CMS in one click, similar to how it is done on mobile App Stores. And if users install a blog, they expect to see clean and simple interface and receive seamless experience, similar to what Medium provides.

I recently read that Backdrop developers made multiple usability improvements and it received a built-in project installation tool (like Project Browser). Looking at Backdrop CMS, I caught myself thinking that it could be Drupal 8 released three years ago. Anyway, time will tell where Backdrop goes but Drupal definitely follows a different path.

Dear Drupal Developers, please do not forget about your target audience. Primarily, It is ordinary users and not developers. They do not care about OOP, code standards, decoupled architecture and architecture in general. Users just want an application, module, site or whatever name you give it to be easy to install and usable out of the box.