Insights

Two predominant platforms we see debated frequently in the public sector are Drupal and WordPress, along with justifications for their use by the requesting public agencies and the contracting firms responding to the proposals. This is an area of concern for us, as we have identified a pattern of selection that entails consumer pop-culture rather than a holistic, fact-based justification for selecting one platform over the other, and we’d like to change that. Our agency does not feel that it’s sound to make such heavy decisions on web infrastructure without evaluating both the short and long-term community impact in terms of resources, security, content, usability, and sustainability. Additionally, organizational and community needs must be translated to aligned requirements with the chosen platform, which we have rarely seen in the proposals we’ve participated in and reviewed thus far.

Our hope that this article is useful for government buyers, and teams supported by those buyers, to demystify these two choices so that public agencies can better serve their communities. While this is not an overly detailed and comprehensive overview, we may expand on these topics in a future white paper or e-book.

Drupal and WordPress are similar in nature but different in scope

Both platforms are used for content management, but each platform has its own culture, maintenance schedule, complexities, and intended use that shouldn’t be taken lightly. Drupal, for example, is a matured and trusted platform that’s predominantly used to manage content for larger government and commercial sites, including e-commerce applications (such as Tesla). The framework for this platform is not oriented for beginners and is bare-bones, requiring most features to be coded in PHP by a skilled team. Drupal is very secure in this sense, as its stability and security are rarely compromised due to this “code only” culture. It’s not as open to exploitation and platform modifications via third-party plugins and canned, unvetted themes.

This is in opposition to WordPress, a mainstream and popular CMS, where both skilled and unskilled teams have derived methods of creating sites that cover a wider gamut of uses. In this instance, while WordPress can be just as flexible and secure as Drupal, it can be the most misused and ill-programmed framework in the hands of amateurs feigning to be experienced professionals. WordPress has been hijacked by theme and plugin developers over the years, turning it into a Wix or Squarespace clone with bloated drag-and-drop interfaces that threaten the stability and security of the platform. In the hands of experienced WordPress developers, this framework is used as a hybrid software delivery platform with an avoidance of canned themes and plugins, keeping it nimble, flexible, and secure. WordPress has been successfully used with low to mid-level government projects (such as Tacoma Public Utilities), e-commerce applications, and commercial projects.

Resources, management, and community implications

Both platform choices have costs associated with them for planning, design, development, implementation, hosting, and maintenance. Communities that are seeking a new website redesign should perform careful and comprehensive due diligence to outline the pros, cons, and resources needed to support a platform preference. It’s very common to see Drupal as the selected framework, but not all of the Drupal build preferences make sense. For example, agencies and internal IT teams request Drupal simply because “everyone else is using it” is a fallacy, as not all agencies use it (only about 25% of public agencies). Oftentimes, these recommendations are based on pop culture and layman’s knowledge of the CMS while being unaware of the economic impact that decision will make on their community. Drupal, as a professional-only platform, requires a heavy investment for a branded, fully-featured construction (e.g., from $45k – $100k+) with maintenance costs easily exceeding $30k every year. It’s like purchasing a house when you know that your economic future may negate the paying of the mortgage a year or more down the road. It’s a reckless recommendation and wastes taxpayer money unless the community sustains it.

WordPress is also programmed via PHP, but benefits from having many pre-built functions that are ready to customize, making it quite a flexible contender for agencies on a budget. Unfortunately, this is one of the most exploited CMS platforms, leaving a bad impression with clients, including government buyers, due to negligence on the part of contractors. The ability to use themes and plugins, not only to add features and functionality but to drastically modify the platform itself, is cause for concern. Contractors selected to construct with WordPress must build using minimal plugins (only if necessary) from mainstream, known-safe origins while coding the site in native PHP without “visual builders”. Any feature that the public agency needs to be fulfilled can be done so in WordPress using inline, procedural, and object-oriented PHP, just the same as Drupal. Costs are less due to the pre-built functions and the ability to write custom ones that will modify WordPress’ default behaviors. Construction costs for public sites are far less, generally ranging from $16k – $30k on average for a custom solution (depending on complexity) with maintenance costs being far less per year due to the hybrid nature of the platform and how it’s coded.

Drupal and WordPress cultures play a big role in deliverables

Drupal programmers are more often classified as working within a software development role, while WordPress programmers are considered “web developers” instead of programmers due to the cultural notoriety of the platform. However, to help dispel that myth, our firm (like many others) has full-stack PHP developers to work with WordPress. Those same individuals also work with Laravel, Angular, and can program custom JavaScript applications. They are programmers, not developers, as they don’t simply install WordPress, setup themes, and configure preferences or plugins, they actually produce custom code based on project requirements without the need of third-party add-ons.

Unfortunately, this doesn’t always apply to many firms that just specialize in WordPress, and government buyers need to be aware of this to screen accordingly. Examples of WordPress sites should be coded and the firm should be able to explain how the site is built, and why it was built that way, what benefits their project structure has for the site, and how that impacts users and long-term sustainability. Firms that only offer page builders, such as Beaver Builder, Divi, Visual Composer, Elementor, and similar should be vetted, disqualified, and avoided as these construction methods are unsafe and unsuitable for public applications.

Alternatively, Drupal has a small and unique community, also maintaining open-source code with community repositories containing modules, themes, core updates, and distributions. Drupal developers follow a more structured approach to website planning and construction within a software development pattern. Drupal is used by many large firms as a platform of choice for government projects while keeping it custom, flexible, and very secure. Drupal can be combined with front-end frameworks to make it responsive for mobile devices, desktop users, and everything in between. When planned right, designed with user experience in mind, and containing well-thought-out control systems, it can be a powerful and long-term investment for larger agencies and communities, despite maintenance costs. However, many large “code farm” agencies realize this and shape their entire software business model around the Drupal platform for government agencies, mass-producing templated sites.

These companies are easy to spot, as their portfolio samples look very similar (as they are with mass-producers of WordPress sites). The “customization” comes with modifying re-usable modules, code blocks, and theme template parts for the client’s specific needs, but they are oftentimes the same across many sites. Many established firms re-use code, and that’s fine, but it’s generally not an exact duplicate as with this illustrated business model. These template firms also use Drupal as a competitive differentiator, as it requires a team to fully develop, thus weeding out smaller companies without such a structure and those who don’t know how to comprehensively program PHP. While this is great for the contractor, it locks the client into an untenable position of being completely reliant on the software firm as a provider due to the nature of the CMS, making it difficult to leave or even switch platforms due to the technical requirements needed of the incoming contractor. The public agency must go through the software firm for most changes, further increasing maintenance costs while creating an informational bottleneck for the community.

Conflicting project requirements based on pop culture

It’s been our experience after reviewing expired RFPs and newer opportunities, that many public agencies struggle with writing proposal requests. While we’ve responded to some proposals, we’ve walked away from many due to oddities, conflicting requests, and the lack of enthusiasm on the part of the public agency to actually engage in the project. For example, agencies state the need for “exact features” found on another site that they wish to have duplicated, or “award-winning features” that are described as such but have no valid basis for that characterization, along with requests for functionality that are incongruent with the platform choice they’ve made. These types of items can choke a firm’s ability to help the public agency by increasing confusion, stifling feedback loops, limiting creativity, and making requests haphazard or unintelligible. This can cause firms to walk away, and many do. What’s worse, some agencies make these common mistakes and then refuse to have a public meeting with the interested contractors to answer questions and make clarifications, funneling such requests through purchasing officers who don’t readily have those answers.

Project requirements should be sound in nature, based on data, usability, and patterns of behavior with users and their interaction with the community. Requirements should also be building blocks to solutions that address community or organizational challenges, such as increasing community feedback, engagement, or the ease of public transactions. Public websites should be a tool, not a compendium of old and outdated information, or a new delivery mechanism to present that same information in an ineffective way. They should not be littered with widgets, mega menus, redundant links, and programming gimmicks that have no real-world efficacy rates but are requested merely because a proposer or panel felt it “should be included” with the next website remodel.

Agencies should stop providing requirements based on whims and start providing guidelines based on community needs, goals, and challenges. This will then allow professional software firms to recommend needed requirements, instead. Currently, this flow is quite backward and ineffectual, ramping up costs for the agency (well over $100k+ in many cases) while creating stress and confusion for contractors attempting to decipher what it is that a public agency really needs over what the agency may desire.

In conclusion

Seek out contracting firms that are capable of executing custom software development, not just canned web development tasks, for both WordPress and Drupal. This will ensure that the contracting candidates have an intimate understanding of both platforms, the programming languages needed (the ‘stack’), software design patterns, project management in Agile environments, testing and quality assurance, and sustainability practices (e.g., maintenance and code repositories). It will provide public agencies with a better product and teams that can honestly recommend needed features to solve problems, not merely supporting collections of unrelated features that will increase costs to arbitrarily satisfy RFP requirements.

Until the process of requirement-building and RFP construction is changed, public money will be widely wasted on expensive feature sets, layouts, and widgets that don’t serve their respective communities. Instead, agencies should be providing contractors with an opportunity to justify feature sets as a method of screening, because they will either understand user flow, interfaces, design standards, and conversion psychology, or they won’t. It’s really quite that simple, as the current bidding structure places the public agency as the expert, not the contracting firm. That’s like taking your car to a mechanic and telling them what needs to be done on it when you’ve never completed those repairs before, and then discounting their professional findings and opinions when they differ from your own.

We as humans have been culturally trained over the past decade to seek out a set of predefined user experiences and expectations that are “commonalities” when visiting websites (i.e., how things look, feel, and respond on a variety of devices). Those experiences and expectations don’t merely go away when public sites are involved, and the government sector could greatly benefit from the lessons learned within the commercial and e-commerce development arenas.