In our last Drupal vs WordPress comparison blog post, we focused on the true cost of ownership for each open source CMS project. We spent some time in the analysis of the following diagram, depicting the incremental cost over time for a typical enterprise website project.

To summarize: our contention is that the significant hidden costs of an enterprise grade web development project are oftentimes found in the post launch customization and continuous development tasks over the total life of the project.

Furthermore, Drupal does typically incur a heavier initial setup cost than that of WordPress, but Drupal then becomes more cost effective and responsive to feature augmentation in the long run.

And to go even further, we maintain that Drupal is well suited to long-term enterprise grade development projects, whereas WordPress is still best deployed in the role of blogging platform.

In this blog post, we will build off of the WordPress cost over-run analysis in our previous post, but switch our focus to the fundamental differences of developing and deploying enterprise grade Drupal websites.

The WordPress Use Case

To be fair, it needs to be pointed out that we are describing the experience of an enterprise grade web development project in our comparisons. Any web development agency worth their bandwidth will do you the services of insisting on a discovery phase before they begin charging you for development hours.

Web development projects must be accurately defined at the outset in order to select the right technology platform. If a new website discovery revealed strategic project goals in line with a professional blog, like…

“Gaining readership and collecting contact information from car enthusiasts.”

...WordPress would be top of the list for recommendations.

I actually love WordPress, for blogging or brochure websites, and I often recommend it to friends and small businesses that ask me how to best launch an initial online web presence on a tight budget.

Authors, personalities, speakers, and marketing gurus like Tim Ferriss have built modern digital media empires with WordPress as a core technology.

Content over the Container

But in the game of content publishing, using the most popular platform is still not a prerequisite for success; Seth Godin is still rocking his typepad blog from 2002… and yes, he still writes a post nearly every day.

"The future of publishing is about having connections to readers and the knowledge of what those readers want."

~Seth Godin

If you want to win as an online publisher, everything comes second to the persistent follow-through of publishing relevant content for your desired audiences.

In the blog use case, the platform does not really need to do all that many interesting tricks in order to be competitive. Not to suggest that innovation is nonexistent in the realm of the blogging platform, e.g. Medium. But in this case, Medium succeeds by removing features and options while cultivating a content community.

Beyond Blogging

In our comparison of Drupal vs WordPress we need to get beyond the basic blog or the brochure site, both of which pale in comparison to the importance of content strategy for their use cases. The blog is quickly becoming a technological commodity and the brochure site is destined for a 2-3 year redesign due to the fickle nature of design and branding fashion.

Drupal lives and thrives in the realm of customization and accommodation of unique use case scenarios. The winning advantage of Drupal in this space is the platform’s capacity for accepting change in a continuous development approach. This means that Drupal does not assume blogging or brochure website ends; but rather, Drupal can adapt to any definition of web design and development goals.

Accepting the Process

“The Only Thing That Is Constant Is Change” ~Heraclitus

Successful Drupal websites usually have different, and I would even say; more sophisticated metrics of success with dynamic strategic goals. If the project discovery phase reveals a strategic goal of…

“allowing our customers to build contextual searches of internal ERP data while being exposed to highly personalized cross-sell opportunities from our 3rd party vendors”

...chances are good that a traditional blog is not going to be the best solution for your business. You will need a tool that is less focused on blogging and more focused on flexibility. Drupal is that tool.

“Use WordPress if you want to build a blog. Use Drupal if you want to build a WordPress.” ~Unknown Drupal Master

We often invoke this clever language inversion to describe the nature of the difference between Drupal and WordPress. We do this, because it is true. If you were setting out to build a website like WordPress.com, what would you use?

Well, the capabilities of Drupal actually make it a great platform to build large scale publishing platforms in multisite and multi-user environments.

WordPress.com can only grow in features and capacity because it was built in a code environment with a more granular level of control than the eventual WordPress platform itself.

With enterprise scale development projects, you can’t know exactly what will be asked of your website next, this much is true. However, you can select a website development framework that is robust enough to answer whatever question you ask of it.

By Developers, For Developers

Drupal shares many development environment features with WordPress. They are both open source projects with a large, dedicated user and development base. There are many people, agencies, and organizations around the world committed to the long-term success of each project.

Drupal is different in that the project has always been driven by more technical, developer-centric sensibilities. The Drupal community and the Drupal association is composed of conscientious developers who are committed to making Drupal the most powerful web development framework available.

The WordPress.org Plugin Directory

WordPress got its start almost exclusively as a blogging platform and slowly matured into a Content Management System. The WordPress community is vast, but that vastness also comes with audience dilution.

Many of the WordPress community members and agencies are primarily designers or marketers, I should know... I am one of them. When I attend a WordCamp event, I meet everyone from the flower shop owner to the fortune 500 marketing agency CEO.

When I attend a Drupal event, I meet one craft beer loving Drupal developer after another... and recruiters looking to hire them at a premium rate.

Plugins Built & Organized for End-Users

A Drupal module project is akin to the WordPress plugin directory, but immediately you will feel the differences. The WordPress plugin directory feels like a mobile app store that pushes flashy screen captures of interfaces, download stats, and basic compatibility information to the top.

WordPress plugins are predominantly targeted at the needs of the end-user. The packaging and presentation of each plugin typically speaks to the immediate needs of the end-user. More often than not, the end-user is a marketer or content manager, not a developer working on the web project. 

With the size and diversity of the WordPress community; the lowest common denominator end-user is typically the website builder, manager or web designer. These users do not have the technical background to be discriminating code auditors.

Installing the plugin, checking boxes, and uploading images are oftentimes the extent of their technical aptitude. In the case of web designers, the end-user is usually capable of adjusting CSS code... but rarely writes CSS files from scratch.

The concerns of a developer to shape and manage a cohesive software project with quality assurance measures can easily be lost in this process.

Easy Installation Drawbacks

The WordPress plugin directory and community is designed to be much closer to the end-user experience. Install a plugin, configure it, and go. If you get stuck or have a problem with the software, there is contact information for follow-up with the developer.

Some developers offer support forums or commercial software style tech support ticketing systems, but there are no guarantees. The initial install is easy, but long-term support concerns are oftentimes ignored.

Installing a WordPress plugin is an experience of instant gratification, much like going to the corner gas station to grab a Redbull and a bag of Funions. WordPress encourages this behavior by incorporating a plugin installer directly in the administration interface of the live website.

WordPress administrators are encouraged to mix and match plugins with instant installs, very much like the app store on your mobile phone. The cost of this ease of use and immediacy is the loss of discernment, intentionality, and proper code reviews. 

The point of this analysis is to present how the ecology of the WordPress plugin directory lends itself to a haphazard compilation of code on a live website, all the while side stepping modern software development best practices.

The Drupal Module Repository

The Drupal module repository contrasts with the WordPress plugin directory in that it is a highly structured, moderated, and quality-focused community effort for other developers, typically not the end-user.

Drupal began as a node-based Content Management System from the get-go and has evolved into a robust web application development framework. Drupal’s core modules and contributed modules are organized in the fashion of a professional code repository by the Drupal development community.

The style and approach of these central collaboration points define a fundamental difference between the two open source software platforms. A Drupal module project is geared towards the real-time collaborative work of the developer community maintaining and supporting the module.

Drupal modules are building blocks of code built by and for developers. Clean code, tight security, and robust support are the hallmarks of a successful Drupal module project.

Version Control Repositories

Building a Drupal website with carefully selected modules is like going to a well established farmers market and hand selecting all of the ingredients for your meal prep.

Every item you select from the market comes with the known additional cost of cooking time before it will be ready to serve. Careful decisions, deliberations, and meal planning are essential for a successful dining experience.

Likewise, a properly managed Drupal deployment would never allow for the release of untested code to the production environment. That is to say, you would not let someone grab a Twinkie and Coke and call it a meal.

For Drupal projects, the functionality of the WordPress plugin installer is moved to a much more rubust handler, typically a Github version control repository. Code that is added to the overall web development project in this scenario occurs in controlled stages of review and testing before being deployed to the live website.

The Drupal module repository creates high quality code projects that are aware of the rest of the Drupal project. These code modules can be combined by developers in predictable, documented, and secure ways. This creates a highly coordinated and trustworthy development process that is at the core of every Drupal web development project.

The types of modules that you find in the Drupal module repository are at a lower level of functionality than that of a typical WordPress plugin. They are tools and building blocks that can be assembled by Drupal developers to solve many different types of problems. They are also curated and reviewed for alignment with best practices and coding standards. Drupal developers are cheerful, but stern about adhering to code standards.

Drupal Distributions

Collections of modules and custom code for particular use case scenarios are packaged and maintained by the Drupal community into Drupal distributions.

These distributions are still composed of granular modules that can be customized to the exact needs of each deployment. For example; aGov, a distribution originally created to power all of Australia's government websites, can now be reconfigured for similar municipal and government projects. It was launched in 2012 and receives regular updates up to 1 week of the writing of this blog post.

As a Drupal project moves forward with core and contrib modules, eventually the project will call for the creation of custom code and modules. The entire Drupal website project is geared towards this as an expectation. The developers and project managers guiding the web development project forward will not be caught off guard by this eventuality.

Controlled Development Roadmaps

Every feature request, workflow need, and custom configuration can be handled systematically and predictably as part of the overall Drupal development project.

A WordPress website project typically lunges in drastically different directions as plugins are added or removed from the WordPress CMS. The low level coordination of the development community is not as present as it is with the Drupal developer community. This makes a WordPress website prone to erratic behavior and can place heavy code review burdens on the developers to figure out how the installed software behaves.

The Future is Continuous Development

Drupal projects can proceed confidently from milestone to milestone as the team coordinates with the global Drupal community to find the very best way forward with a stable and incremental approach. This experience is known as continuous development and it is becoming the new expectation of long-range, enterprise-grade software development projects.

In our next blog post in the Drupal vs WordPress series, we will dig into the practicalities of continuous development and introduce the capabilities of Drupal 8 as a decoupled CMS. Accept the Flux and start your next web development project with Drupal 8.