Open Source Content Management Systems like Drupal and WordPress have been gaining a lot of ground in recent years, with governments around the world adopting them. Drupal in particular has attracted a lot of fanfare as numerous high profile US government bodies -- most notably the House of Representatives and the White House -- have adopted it as their primary content management system. In the UK it's more often WordPress that gets the limelight as it's used for numerous central government sites, both in its traditional guise powering blogs, but also powering more complex sites like Number10.gov.uk and consultation projects like the Public Reading Stage prototype. And yet we've not chosen any off-the-shelf system to power the Single Domain's corporate platform (our Government Machine).



The phrase "not a CMS" has become a bit of a joke around the GovUK office (to the point where more than a few people were humming Once In A Lifetime), but it's a key part of our approach. The Single Domain will include several components that enable publishing on the web but they're part of a much broader ecosystem of tools wired together using APIs and designed to be constantly iterated to focus on user need. As we began to unpack what that means it became clear that we were going to need custom software.

We've got a very strong focus on opening up APIs. While both Drupal and WordPress can be used to offer APIs (recent revisions to Drupal and some of its key modules have helped significantly, as can be seen in the World Bank API project from DevelopmentSeed) adding the range of APIs we're aspiring to would require significant development work, and to make them perform as we'd like we'd need to work around the overheads introduced by WordPress and Drupal. By using development frameworks rather than content management systems we can more quickly optimise the code to serve those APIs.

In order to ensure that the Single Domain can be constantly improved we're going to be building in a large amount of instrumentation that will allow us to analyse how user needs are being served. At the top level some of that can come from traditional web analytics, and at the low end it'll come from server monitoring, but it's important that we have the flexibility to add instrumentation at every layer of the stack. Again, that's certainly possible with both Drupal and WordPress, but to do it effectively we'd be writing a considerable amount of custom code.

Perhaps most compelling for me is our focus on admin systems. There's a huge opportunity in the Single Domain project to identify the right workflow for any given part of the site and to make sure that admin systems are designed to support that. For a publishing tool, that means ensuring editors can quickly navigate the content based on their expectations of the workflow, but also embedding prompts and presenting back data that will draw them to content in need of attention (whether because of agreed schedules, changes in regulations, or quality metrics). Here too we could customise any open source content management system to do the job, but it's highly likely we'd either have to make significant changes to core code or develop a parallel admin system at which point much of the advantage of starting with the base system would be lost.

Having read all that it might be easy to accuse me of "not invented here" syndrome, but I don't think that's accurate. We're using open source up and down our stack, from the server operating system and key components, to development frameworks like Ruby on Rails, and a whole host of components. We're just choosing to start by assembling components rather than customising a package, and we'll be contributing code back to the wider community (whether in the form of new components or patches to existing ones) as we go along. You can see some of that effort by exploring our github profile.

And we're not ruling out using some of the open source content management systems where there's a clear place for them and we can let them play to their strengths. Where we have a need for blogging, or a specialist micro-site that fits a classic content management approach, we know where to find some excellent tools.

James Stewart is Tech Lead at GDS. You can follow @jystewart on Twitter, and read his personal blog.