Skip to main content

Why Drupal?

I just got back from Drupalcon last week. It was my first time attending and it was great to see many faces, old and new, some of whom I've only met online. It really energized my enthusiasm about the project. For me, Drupal has been a job, then side project, then serendipitous side jobs, to full time career. The one constant has been the many friendly and helpful Drupallers I've met along the way.

Coming off that thought, I thought I'd post my various thoughts and words I've spoken in the past when the topic of "Why Drupal?" comes up. There are plenty of CMS's out there. I've worked with a handful, but I find myself consistently sticking with Drupal. There are many reasons why (or why not) to use Drupal. Here's a couple reasons I often state to clients on when discussing Drupal as an option for managing content.


The big keynote, or Driesnote, where the eponymous creator of the Drupal project, Dries Buytaert gives his vision for the future of Drupal (powered by voices of all Drupallers who care fill out a survey), had a great slide comprising of all the adjectives people used to describe Drupal. It was word cloud representing some of the most popular descriptions. One of the biggest, Flexible, is the primary reason (as do many Drupallers, apparently) I use Drupal. 

The web is big chaotic network, there's a stack of standards on standards that allow for a network of networks to display a gradient of interactive documents that range between mostly static linked text to robust web applications. In this network, there are many actors trying to carve out their own space to be the one true standard.

This is all to say that web development is full of many dangerous paths to get lost on. The best you can hope for in such environment is to carve your own domain where you tightly control everything (think large organizations like Facebook or Google) or you try accommodate the chaos and be as flexible as possible. That's what Drupal tries to accommodate. 

From its core, Drupal tries to make minimal assumptions about what you want and allows for interchangeability of parts where your use-scenario might apply; I often make the comparison between Android vs. iOS in that Android allows core parts (e.g. your phone dialer or SMS app) that Apple would rather control for a consistent user experience. This makes for a powerful, but dangerous, navigator that you really need to understand its purpose before you follow it.

The first thing is to understand your goal, endpoint, or destination. Are you wanting a brochure site, an ecommerce site, a web application, a blog, etc.? If there's a hard destination with not too much concern of specifics, just a need to fill a static bullet list of requirements, with no asterisks attached, Drupal might not be the best for your needs. There might be a better solution that does exactly what you do; a web application or framework that covers all the requirements with little-to-no-input from you.

If your goal is multi-faceted and needs to evolve and respond to a changing demands (either from outside or within your organization), this is where Drupal excels. Along the way, many parts of Drupal are sectioned off in separate projects (custom functionality, or modules, custom design, or themes, custom use scenarios, or distributions) ran by like-minded people trying to solve common scenarios. All these projects can take Drupal from a basic, mostly-static, content site to a site with a mix of static and dynamically-detailed evergreen content, with some web application functionality.

People, Process, & Community

I've worked in many organizations where a tool or process (e.g. web application or software development methodology) has been oversold as the solution to some large problem. I'll self-deprecatingly note the irony in that I'm doing this currently about Drupal. Ultimately, I've found that it's people that self-solve specific problems, and the best a tool or process can do is be a framework, or guide, for people to solve a problem. To me, it's the projects that lead me to my next reason about why I use Drupal.

Within those projects, you'll find people and processes, that make up the Drupal community. Within the niche Drupal community, you'll find many open and collaborative people, who have started many different projects. These projects provide great beacon to those who are looking to the solve the same (or near same) problem. Within these project groups, you'll find many open and attentive people looking to learn from one another to solve a subproblem (custom functionality, design, or scenario) within a larger goal (e.g. I want my website to solve these big goals!). The Drupal project and its subprojects have created a process to learn from one another and create an environment of collaboration. 

To that end, it's important to understand that when you're signing up for a Drupal project, you're not just getting the commissioned work from a freelancer web developer or digital agency. You're receiving the collective work, from a whole community of people committed to the project. This is important for the robustness of your own web project. You're not locked into one vendor, one person, or one company that is your sole purveyor. You can receive input from others within the Drupal community who have been down the same path.

Throughout the lifecycle of your website, problems with arise and be solved, people will come and go, the demands of your market, enterprise, or project will change. Throughout this, it will be people that will be a the center of this. If you look at your website as just means to an end that's what you'll get, "a product that does _____." If you're looking to foster not just a site, but a place to communicate with people in a dynamic, ongoing dialog, I can't help but recommend Drupal. Developing community is at Drupal's core process of code development. 

Loading Image