The Australians are risking everything on Drupal… seriously?
When John Sheridan, Australian Government CTO, announced earlier this month his intention to standardize all government websites on Drupal, I can’t have been the only one having a slack-jaw moment. Here are five reasons why I simply can’t see it deliver what they want it to.
OK, I’m the CEO of Kentico, and Australia is a major market, so I have a bias for sure, but please, put the
‘well, he would say that wouldn’t he’ filter to one side for a moment. I just want to evoke some common-sense principles, our collective experience and a few publicly available facts.
First, let’s look at what’s at stake, and then why logically Drupal is simply a terrible idea for the Australians. The objective is of course worthy; to get control over Government spending on its digital communications, by standardizing and centralizing everything (let’s skip the fact that history tells us this rarely works).
According to Sheridan the first site to go live under this initiative will launch in September 2014 to be followed over the next 4 years by between 182 and 437 sites.
That’s a pretty challenging goal and a major investment... and as we all know, scale is a multiplier of risk and compromise.
So where are the risks and compromises in the choice of Drupal?
Reason #1: Why are they investing in redundancy?
If Drupal 8 isn’t ready, they’re going to have to go for Drupal 7
If the Australian government aims to start now, which version are they going for? Drupal 7 is soon to be replaced by Drupal 8, but how soon? No-one knows.
According to the official Drupal site, the next version
release date hasn’t been set yet with Drupal founder and Acquia’s CTO Dries Buytaert saying
“It’s ready when it’s ready.” Given the commitments to the start date and the above number of sites, logically, the Australians will have to go with Drupal 7.
Now, what we’ve all been told is that Drupal 8 will be a significant rewrite with a new API and no backward compatibility of code as explained in
Drupal policy.
So any investment into websites or extensions built on Drupal 7 will have a very limited shelf-life and will need rewriting if they want to leverage the future capabilities of Drupal and its 3rd-party add-ons.
Ouch!
Reason #2: All that proven Drupal 7 code is heading towards the waste-bin
A major architectural change is a double-edged sword
The upcoming Drupal 8 release represents a significant rewrite of the software and a major change in the architecture with a move to the Symfony framework. In other words, the Drupal community throws away all of that existing tested and proven code and replaces it with new, shiny, not proven code.
As we all know, all too well, no amount of testing can replace the crucible of real-world use. Inevitably, customers struggle with issues of stability, security, and performance as well as user experience in the early months.
Need a salutary reminder? We don’t even have to look that far back. Remember Umbraco 5? After more than a year of waiting for a new version, Umbraco released version 5 in January 2012. From the get-go, the product suffered from the
high complexity of the new API and major performance issues. Five months later, Umbraco discontinued version 5 and returned back to version 4,
leaving version 5 customers high and dry.
And it doesn’t stop there. Other down sides of any major change is that implementation best practices change when the architecture does. That’s a lot of experienced Drupal 7 developers having to re-learn key concepts and needing to experiment and learn from experience to divine the best practice.
Again, we’ve all suffered the direct and indirect costs of learning via trial and error. A lot of implementations that take longer cost more and deliver less.
Reason #3: It’s not just the community that gets forked
If forks in the community are inevitable, where does that leave standardization?
The Drupal community are an independent minded bunch – the developers who like Drupal 7 architecture and its simple APIs are refusing to change and to preserve what they like are creating their own fork of Drupal 7 called
Backdrop CMS. So when Drupal 8 launches where will we be?
So we can expect that the development efforts of the community will dilute into multiple directions and it may lead to a potential mess in add-ons where some will work with Drupal 7, some with Backdrop CMS and others with Drupal 8.
So whilst I applaud the strategy of standardization, will they truly be able to get its full benefits by going the Drupal way? It doesn’t take a genius to know the answer.
Reason #4: 7’s modules won’t work. 8’s modules can’t be started
No backward compatibility between versions 7 & 8 leaves you where?
If Drupal was a complete solution, not simply a platform, this might not be such a problem. But it isn’t. So it is (if you get what I mean).
Drupal customers rely heavily on a range of add-on modules and custom code to get the job done. But because of the lack of backward code compatibility between version 7 and 8, the module developers will have to rewrite their add-ons for version 8. But there’s a problem. They’re currently
discouraged to even start to do so until the API is finalized.
So, while the Australian government presents code reuse across sites as one of the main benefits of the standardization, this change means that any custom code they write on version 7 will have to be rewritten for version 8.
Am I the only one thinking that means a whole load of additional complexity, confusion and duplication of work? Nope, didn’t think so.
Reason #5: What’s ‘Free’ about $100 million dollars?
Isn’t the argument missing a little something… like the Business Case
“Free” is a lovely word, a powerful word, a democratic word. No wonder politicians and administrators love it.
No wonder no-one trusts it.
Sheridan points out that the current government websites run on a whole range of different platforms. So, that means they will have to redesign and rewrite all of those websites, migrate the content, and re-train users.
So, yes, the Drupal license is ‘free’, but we’re talking about costs that may easily total over 100 million dollars to make the transition to Drupal in the upcoming years.
That’s a big number and some serious leverage for the Australian government to make a great deal with commercial vendors able to deliver a more advanced solution with more functionality out-of-the-box, all of which would mean much lower implementation costs and more value-added opportunities.
A commercial solution would provide them not only with a technology platform to build on, but also with the instant functionality that the open-source Drupal lacks – especially in customer experience management.
Marketers today ask, “How can I deliver the right content to the right people at the right time and make the communication more effective?” So too are the more forward-looking elements of the public-sector. Ultimately, everyone will have to do it.
Has Mr. Sheridan and his team worked back from the inevitable, and desirable future, or simply from the perspective of moving away (incrementally) from the unsatisfactory situation they find themselves in today?
Have they considered the bigger questions like the savings/opportunity cost involved in the time spent by Australians every year looking for practical information from the government? What for instance would be the impact of providing them with personalized information relevant for their context and making their lives easier?
Has anyone done the maths? Truly analysed the direct and indirect costs, allocated a number to the risks involved? Put in contingencies against all the unknowns I’ve outlined above?
Or has the dogma of ‘FREE = Good’ overridden everything, including the fact that things are rarely free in any aspect of life?
Final Thoughts
Let’s put Drupal to one side. I can’t be the only one who is nervous about the proposed highly centralized approach. I mean, all those websites to be hosted and managed at one place?
Our own experience with multinational clients managing hundreds of website has embedded a conviction that a certain level of decentralization reduces risk, improves efficiency and raises quality, all as a result of increasing the autonomy of those responsible for the websites.
I completely understand the logic and need to get control of expenditure of government websites and save taxpayers’ money. But is this the way?
So as I stated at the start of this piece, even if you think
‘Well, he would say that wouldn’t he...’ do you think that Drupal is the right choice for the Australian Government?
P.S.: If you want to see why we believe Kentico is a better choice, please
join us for the Kentico Connection conference in Sydney on June 4-5, 2014.