Every museum’s choice of Content Management platform will have a significant impact on the implementation of their digital and content strategies. Since it’s not easy to change platforms, this decision should be carefully considered by your museum’s leadership team before making that core investment.
But because typical Content Management debates quickly get deep in the weeds of technical jargon, museum leadership teams sometimes tune out this discussion and just leave it up to their IT department, or go with whatever platform their development partner recommends. But there are some significant long-term consequences built into this fundamental choice that museum leadership should weigh before committing to such a core system.
I’d like to address this important decision from a leadership perspective, rather than merely a technical one. I want to help your museum’s leadership team get beyond all the technical acronyms and feature wars.
I have a seasoned history with Content Management Systems. My first web development firm, which I founded in 1995, built its own CMS in 2000, three years before that newfangled WordPress blogging platform arrived on the scene. Our early proprietary CMS was far more functional and much easier to use than any of the alternative platforms available back then–if I do say so myself. But alas, open source systems like WordPress and Drupal eventually ate proprietary systems like ours for lunch. Nevertheless, we managed to compete effectively with our platform for well over a decade (and I think my old firm still uses that system from time to time). So while I may still be somewhat of a museum outsider, I’m very much a CMS insider. So allow me to offer you an insider’s perspective on this important decision.
To WordPress or to Drupal?
Today, for most museums, the choice is between WordPress or Drupal. Joomla! and Expression Engine have a smaller representation among museums, and then there’s a smattering of other platforms that occasionally show up on the radar. But almost half of all the CMS usage on the entire Internet is carved up between WordPress and Drupal (WordPress at 37% and Drupal at 8% as of this writing). In the museum space, Drupal does seem to enjoy a somewhat higher percentage, but even so, WordPress use still outpaces Drupal at least two-to-one among museums.
Beyond the Bullet Point Feature Wars
At the end of the day, as far as evaluating the technical capabilities of WordPress and Drupal, both platforms are excellent systems used in complex ways and at high volumes (the New York Times is built on WordPress and Warner Brothers uses Drupal). Each can scale, each is secure, each is customizable, and each can integrate with other systems. So what is the difference then? And what factors might incline a museum to choose one over the other?
Cost. While there is parity between the technical features and capabilities of both platforms, pound-for-pound, WordPress development is less expensive than Drupal development (at least 20%-40% less). The increased cost of Drupal is the result of the economic law of supply and demand. Since there is less demand for Drupal, there are fewer developers that specialize in Drupal. This not only increases their cost, but it also means there are fewer developer options, if and when you may need to find a new developer.
So, if WordPress is just as functional as Drupal, and Drupal generally costs more, why would anyone choose Drupal?
The answer to that question has to do with each system’s development philosophy. And it’s their development philosophy that tends to incline technical, software engineering folks to lean toward Drupal, and the creative teams toward WordPress. There are pluses and minuses in each development philosophy, and this evaluation will focus on the long-term benefits and liabilities of each system more than their current comparable feature sets.
Comparing Development Platform Philosophies
In a nutshell, WordPress follows a more aggressive updating philosophy, and allows a much more open plugin environment than Drupal. Pretty much anyone can make and offer a WordPress plugin. Drupal, on the other hand, has a much more cautious, deliberate, and slow development process. In order to submit a new module (Drupal’s term for a plugin), it has to run the gauntlet of scrutiny from the Drupal developer community before it gets greenlighted for use.
For this reason, IT and engineering staff tend to favor Drupal–as they appreciate the more predictable development approach compared to the faster-paced WordPress process. (If I had to be on call, or carry a beeper to respond to technical emergencies, I’d vote to play it safe too!)
These differences in development philosophy lead to the generalization that Drupal is more secure, more stable, more controlled than WordPress, making WordPress less secure, less stable, and less controlled by comparison. And, to be fair, that is a valid claim, by comparison. But such qualities as security, stability, and control are always relative. With more money, more network resources, more system administrators, any site can be turned into Fort Knox. But at what cost? The real question is to what degree is Drupal more secure? And again, at what cost? And while WordPress is less controlled, that doesn’t mean that it is uncontrolled, or insecure, or unstable. In fact, when WordPress is professionally handled, it is no less secure or stable than Drupal.
While it’s true that the Drupal core development philosophy is more conservative, there are downsides and significant liabilities to this emphasis on control (in addition to its higher costs). I’ll come back to some of these other liabilities after considering WordPress’s development philosophy.
The Upside to WordPress Update Philosophy
WordPress’s philosophy of pushing out frequent and incremental updates means that new versions differ from previous ones by small degrees. This allows WordPress to maintain continuous backward compatibility with its previous versions.
It can maintain backwards compatibility even when it rolls out major feature upgrades. For example, in early 2017 WordPress released what’s referred to as a “REST API” to their core. That basically means that WordPress can now integrate with any other system (like your Collections Management System, or DAMS, or CRM) that support this industry standard protocol. So if you’ve ever been told that you can’t integrate with WordPress like you can with Drupal, that’s no longer true. And if you’ve been told that WordPress can’t be customized like a Drupal site, you should know that WordPress released an upgraded that allows for custom post types and custom fields quite some time ago.
Another benefit of the more open WordPress environment is that it enjoys a larger, and rapidly growing, ecosystem of plugins. Among this massive ecosystem are some poorly developed options that must be avoided. But there is also an ever expanding list of robust, professionally built, and well supported plugins.
Speed vs. Stability?
The real reasons why WordPress sometimes suffers from a negative generalization of its security or stability when compared to the tightly engineered Drupal platform, is not because it’s fundamentally less secure–but rather because it’s so popular. It only stands to reason that the platform with the greatest user base will have the most instances of failure–because there are so many more of them! Additionally, since WordPress has such a low bar for entry for design and development, there are a lot of horribly built sites, built by incompetent developers, using broken plugins. But that is not a platform problem. That’s a developer problem.
But if you compare apples to apples, and evaluate the security and stability of professionally developed sites on WordPress to professionally developed sites on Drupal, those unfavorable generalizations disappear. Both platforms are equally powerful, scalable, integratable, stable, and secure–when handled professionally.
An Engineering Philosophy Strategic Error?
But I think there is a much bigger issue lurking behind the scenes of this debate, which may prove far more consequential than the typical feature comparisons or debates over relative stability of the platforms. My experience, having directed the research and development of that older proprietary CMS, gives me a perspective on the future trajectories of these two dominant platforms. The Drupal platform is driven by engineers and I believe that the Drupal engineering development community made a strategic error in how they moved from the currently dominant use of their version 7 product with the newer release of version 8.
While I was managing our CMS product, my software developers would regularly pitch me the idea of rebuilding our CMS from the ground up using all the latest tools, systems, and techniques that were not available when we first architected the system. “Besides,” they would say, “the source code has become patchy, and a fresh start would make it so much better.”
Sounds plausible, but such an idea is usually a big mistake. Fortunately, some of my clients at the time were venture capital firms who had invested in large scale software projects, including some of the early enterprise level CMS platforms. My venture capital contacts gave me some good advice, to not give into engineering pressure to engage in a total rebuild. They told me that when managing their investments in these kinds of companies, they frequently had to resist this common engineering impulse. Their experience that the best products tended to be older, patched, adapted, and modified systems. Apparently real-world tested and proven systems were more valuable and dependable than the outcomes of optimistic plans for squeaky clean and newly built systems. They often saw companies throw away their older platforms, in favor of brand new ones, and that such decisions often led to failure.
How does this relate to the evaluation of WordPress over Drupal? You see, whereas WordPress just keeps updating, patching, and building into their system, Drupal made the leap to a new core software architecture from version 7 to 8. So, if you invested in a Drupal 7 site and now want to update to 8, the work required to switch to 8 is more of a rebuild than a simple update. (Drupal’s own website uses the description “re-build” as they provide a long checklist for the upgrade process). Their engineering-driven community couldn’t resist the urge to start from scratch. Now version 8 is indeed a nice new platform–but that leap forward was made at the expense of backwards compatibility for version 7 users. As a result there has been slow traction for 8. And it also means that the Drupal community now needs to support essentially two distinct platforms–splitting their overall resources between maintaining version 7 at the cost of forward progress for 8.
One of the key problems my venture capital friends warned me about, with regard to rebuilding our product’s core, was that we would not be able to control the adoption rate of a new system. And if it proved slow, our research and development efforts would be split, and overall forward progress slowed.
And if you look at Drupal’s adoption rates, specifically from 7 to 8, they are having some significant problems. As a result their overall adoption rate has slowed. WordPress, on the other hand, updates their one core system frequently, with backwards compatibility, and so the WordPress community tends to follow the upgrade path pretty smoothly. Thus WordPress traction is growing, even as Drupal rates have stalled.
My analysis, from a business management perspective, is that this trend line will intensify and, as a result, the current cost differential will likely increase–on top of the added cost to rebuild in order to upgrade. I think Drupal progress will continue to slow.
In the Final Analysis
As an advisor to museums about their overall digital content strategies, I want our clients to have the strongest, most flexible, most affordable, and most sustainable platform for their digital content strategies. I’m very comfortable making a strong recommendation of WordPress over Drupal. I commend WordPress as the most cost efficient, flexible, prolific, capable, and growing platform for your museum’s future digital initiatives.