I seemed to cause a bit of a stir a couple of weeks back, when I challenged the decision to develop a new Government [web publishing] Machine from scratch, rather than basing it on an existing third-party platform. My blog post got quite a few comments; and there were some interesting exchanges on Twitter too. And now, to the Government Digital Service team’s great credit, they’ve written a post on their own blog, responding to the challenge.
James Stewart’s piece opens on a rather sour note, choosing to reference the Americans’ adoption of Drupal first, before acknowledging the UK’s primarily WordPress-based initiatives. The fact is, for once, Britain led the way on this. Perhaps if we’d had a high-profile champion like Tim Berners-Lee or Martha Lane Fox, we might have had greater, wider recognition. Instead, we just got on with it, delivering projects quickly, cheaply and quietly.
The choice of WordPress-based projects to namecheck in that opening paragraph is also a little odd. James is of course correct to observe that it powers ‘numerous central government sites’; some traditional blogs, some more complex. But he doesn’t mention the four central government departments who are already using WordPress to power their core departmental publishing – Defra, Transport, Health and the Wales Office. Nor is there a mention for the Cabinet Office’s use of Drupal. Altogether a slightly odd omission in the context.
James proceeds to list the reasons why they took a bespoke approach, but each time, concedes that yes, they probably could have used WordPress or Drupal.
We’ve got a very strong focus on opening up APIs. While both Drupal and WordPress can be used to offer APIs… 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.
[On metrics:] 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… 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.
Or if I might paraphrase, somewhat provocatively: they’re writing lots of custom code because otherwise, they’d have to write lots of custom code.
So on some level at least, it boils down to a comparison on the basis of cost and complexity. ‘We’re choosing to start by assembling components rather than customising a package,’ James writes in summary – implying a conclusion that their bespoke approach will work out easier / quicker / cheaper / more sustainable. Maybe it will, maybe it won’t. So much of it boils down to the individuals you hire, and their varying levels of experience with various components.
James concludes with a pledge that ‘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.’ And of course, that’s to be welcomed. Reuse of code is good. But this doesn’t really tackle the point I tried to make about maximising reuse of the code: a point subsequently made, rather more forcefully, by Matt Jukes.
I think the work happening in GDS will have a real impact on web teams throughout the public sector but it will take a long time for it to leak through to those of us out in the NDPBs and I think I’ll switch to treating the work they are doing there as something as different to my job as that of a Silicon Valley start-up.
Ultimately then, it’s a question of trust. Trust our judgement; trust our assessment of the relative levels of effort; trust our staff and project management skills; trust that the (back end) benefits will trickle down eventually. And looking at the CVs of those hired to do the work, there’s certainly ample reason to put your trust in them.
Will they succeed where others have failed previously? We’ll find out in due course. And genuinely, sincerely, I wish them well. We may disagree on the approach: but we all want to reach the same destination.
