Correcting Drupal FUD

Chris Wilson at Slate Magazine recently wrote an article criticizing WhiteHouse.gov for its move from a proprietary content management system (CMS) to the open-source Drupal CMS.  Unfortunately, Mr. Wilson has his facts wrong.  Let’s go through his arguments one at a time.

Should you, say, go completely rogue and try to add some Javascript in the body of a page ... the platform will have none of it.

The default input filter in Drupal is set to disallow JavaScript the “14-year-old technology” that Mr. Wilson feels is safe because it’s old – at least by Internet standards.  Perhaps he doesn’t realize that 80% of all security issues (as documented by Symantec) were cross-site scripting (XSS) attacks.  What allowed XSS onto your site?  JavaScript submitted by malicious users.

The “little mouseover footnote” that Mr. Wilson claims necessitates “rooting around in the API” requires nothing of the sort.  The Drupal modules BeautyTips, Popup filter or Tool Tips (and others) all do mouseover tooltips with varying levels of complexity.  Or, if Mr. Wilson trusted the folks submitting content to his site, say, his paid staff, he could simply grant them permission to use “Full HTML” on any page they wanted.

Drupal is impenetrable. Even the software's defenders admit that it is hostile to newcomers

Perhaps the best rebuttal to this argument is made by Conor McNamara, the author of the site Mr. Wilson links to.  “Yes, Drupal has a steep learning curve, but that has little to do with the front-end usability of whitehouse.gov.”

Drupal can be difficult to configure and has some administrative and nomenclature quirks that make it harder for newcomers to install than, say, signing up for a free account at Blogger or WordPress.  You also get a lot more.  Anyone running a site as large and popular as WhiteHouse.gov will have a top-notch IT staff.  They should be up to the challenge.

Drupal hates change. Want to modernize Drupal by upgrading to a newer version? Ask these guys how that worked out for them.

Yup.  I’ll agree with this one: deployment is one of Drupal’s weakest links.  While upgrading is fairly painless, setting up development, staging and production servers in such a way that you can test that upgrade before launching publically is painful at best.  Fortunately there’s a lot of very smart folks working on this and, if the WhiteHouse.gov IT staff were to come up with a brilliant solution, they could release it to into the wild letting all Drupal users benefit from their work. 

That’s how open source works.

Drupal is disorganized. Instead of displaying your pages in folders that you can browse, like you do on your personal computer, Drupal provides a nightmarish content list.

Again, Mr. Wilson shows he doesn’t understand the system he’s reviewing.  Sure, you can search for content, but that’s not the only way to find the page you’re looking for.  The Content Management Filter which, ironically, Mr. Wilson links to, is an excellent example of user submitted modules that extend the core functionality that comes with Drupal.

And unlike most content management systems, Drupal doesn't have a convenient way to prevent two people from accidentally editing the same page at the same time.

Methinks Mr. Wilson was getting tired at this point because the discussion he linked to has nothing to do with concurrent editing.  He is correct, out-of-the-box Drupal does not prevent concurrent editing – the second submitter is given an error, but they have the opportunity to copy their changes and re-edit the page.  But again, Mr. Wilson doesn’t do the research to discover such modules as Checkout – it’s the first result in a simple Google search.

Mr. Wilson goes on to call Drupal “righteous,” as if that’s a bad thing.  When you’re excited about something, you want everyone to know exactly why it’s great.  When I worked at Microsoft, our marketers were called evangelists.  Seems they still are, and there’s nothing wrong with it.  Life is too short not to be excited about what you work on.

He also uses the Recovery.gov rewrite as a “cautionary tale” of what could happen to a major Drupal site which later gets rewritten at the cost of $18 million over six years.  But there’s so little information about this tale that it’s hard to be cautious about it.  Inital reviews of Recovery.gov (version 1) complained that it was hard to drill down below the high-level numbers.  My guess (and I’m dipping into tin-foil hat speculation here) is that, at the lowest level, most of the Recovery Act money tracking takes place in Excel.  The government is already standardized on the Office suite of products and it’s easier to get Excel information onto the Web using SharePoint.

Regardless of the reason Recovery.gov moved off of Drupal, Mr. Wilson does not present any good arguments for WhiteHouse.gov to be concerned about their use of the product and most of his attacks are uninformed if not outright bogus.  In addition, he does not present any good alternatives to Drupal – there are lots out there and the public would be better served by an educated comparison.

Seems like a drive-by FUD attack to me.  Too bad he has a big megaphone to broadcast with.