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.
Précis:
We are going to build a central web publishing and application platform. It will replace your existing website, meeting all your requirements more cheaply and efficiently than what you have, whatever that might be.
We are going to build the platform now, as we sort of understand what we think you do. When we migrate you to the new platform, you may have to change what you do to fit what we have built.
You will have full control over your part of the platform, within the limits we set. You may find you have to set up a guerrilla satellite website to cover the bits we have missed – perhaps running on WordPress or Drupal.
I think Chris sort of nails it there, and yet I’m not sure there’s a better option.
True, people may have to re-engineer some processes and content as part of migration, but I guess @govuk see that as a feature, not a bug, and they’re probably right. I still think a single platform for all departmental publishing is a bigger gamble that government really needed to take, but the alternatives (give it to a big SI to sort out vs keep on procuring and managing 30-40 big flawed CMS across central gov) don’t really do it either. Though I’ve obviously got vested interests, I don’t see a problem with microsites in WP or whatever mopping up the edge cases that would otherwise complicate a good solution.
I’m genuinely agnostic about the role of specific tools like WP or Drupal in this, since I don’t know what kind of work is going on to model government publishing in more creative ways. But I can see that there’s an opportunity to do more than manage pages of content in the traditional way, and that really hot developers can probably build something more easily and flexibly using Rails-type components than adapting a higher-level framework.
There’s quite a lot of implicit ‘ifs’ in there: it can work if the developers are great, and if they stick around for a long time, and if the architecture can be extended and integrated with by less stellar developers like me, and if the data modelling and requirements gathering going on really pins down what users and departments need.
I’m still optimistic for now.
Leaving aside my cynicism born of bitter experience for a moment, I can’t argue with what Steph says, nor with the caveats. A positive sign would be if the team starts by building some functionality that’s not already working well and popular. The high-hanging fruit, so to speak