WordPress for Government - A Problem of Perception

TL;DR: Among potential government and enterprise users, WordPress has a perception problem especially when compared to Drupal and other “serious” CMSs.

2 minute read

Over the past several years WordPress’s market share has enjoyed explosive growth across virtually every industry. Today, it powers nearly a quarter of new sites, and is the CMS of choice for more than two thirds of the top-million sites on the web making it the world’s most popular publishing platform by a long shot. Yet one group of seemingly ideal users has been slow to take the former blogging platform seriously: .govs.

Drupal powers twice as many federal .govs as every other CMS combined. That’s more than six Drupal sites for every one WordPress .Gov alone, not to mention the Joomlas, MovableTypes, and SharePoints of the world. The build-it-yourself software powers the White House, the House of Representatives, half a dozen agencies, and countless data-driven microsites like Recovery.gov and the IT Spending Dashboard, and its public sector use is equally if not more impressive abroad.

A Problem of Perception

Typical Enterprise Misconceptions

WordPress is a blogging platform
WordPress doesn’t scale well
Most plugins are written by hobbyists, not professionals
WordPress is less secure
WordPress can’t handle complex data types or user roles
There’s no enterprise support
There aren’t many WordPress developers
No “serious” people use WordPress
The WordPress codebase is immature

WordPress’s disproportionately low government adoption is arguably the result of a handful of factors. For one, custom post types, the feature that formally graduated WordPress from a mere blogging platform into a full-fledged content management system, has only been around since June of last year. Yet, even among new sites,¹ the ratio remains somewhat stagnant, if not shrinking, leaving one to believe that the technology has lapped its own already stellar perception.

When you stack the two side by side (or against any other CMS for that matter), WordPress is objectively the prudent choice. On paper, you’d be hard-pressed to make the case for anything else. But, it’s not a technical problem. It’s a human one. It seems that WordPress’s greatest asset – ease of use that has resulted in widespread adoption by a largely non-technical user base – is threatening to become its greatest liability.

Among those empowered to make purchasing decisions, there seems to be a sense that WordPress is what you use on the weekends to post pictures of your lunch while Drupal is what you use for “serious” business, and with good reason. For better or for worse, Drupal has positioned itself as not just a CMS, but rather the enterprise solution — an inseparable fifth layer of the increasingly ubiquitous enterprise LAMPD stack.

Metric	Drupal	WordPress
API Hooks	267	1,506 (5x)
Active Sites	533,136	65,052,049 (125x)
Plugins / Modules	8,536	16,076 (2x)
Themes	893	1,426 (1.5x)
Community²	1.5 Million	N/A

Beyond Cowboy Coders

Not surprisingly, the two communities are a reflection of their underlying software’s position in the broader market. CodePoet.com, for example, a directory of WordPress consultants curated by Automattic, lists a mere thirteen firms in North America that seek jobs over $250,000(often a small price tag for government or corporate sites), while its Drupal counterpart lists roughly 80 firms that specifically target government, enterprise, and NGO clients daily.

I am not suggesting that freelance developers should bring an end to what makes WordPress and change out of their shorts and sandals this instant or that they become intimately familiar with the nuances of federal procurement law, nor am I suggesting that small shops seek to bite off more than they can realistically chew anytime soon. I am suggestion, however, that there are small, tangible steps that the community can take to make headway into the government and enterprise space and gradually entrench WordPress as a viable alternative to otherwise subpar software harming innocent public servants.

As measured by the Federal Web Managers Council CMS survey. ↩
Drupal community size is self-reported. WordPress community size is not publicly available. ↩

Originally published March 5, 2012 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit