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.

Share this article on   LinkedIn Google+

Petr Palas

I'm the founder and CEO of Kentico. I write about Kentico, WCM, CXM, digital marketing and related technologies.

Comments

Jason commented on

Sorry but I am with Petr on this,

Whilst its true all Software updates, you just simply can not have a system were re-writes are the norm. Whilst we are using Cars as the example, most car versions use tech based off the older models. The engines are NOT totally rebuilt but rather upgraded etc. A vauxhall - Ford comparison with all due respect is mute given the argument introduces two different brands. You can't swap CMS's easily from different vendors (Kentico does import Wordpress Data however)

Kentico updates regularly and moves with the times, yes there are some things that needs changing (like implementing Bootstrap 3 off the bat IMHO) but relatively speaking with Kentico you upgrade and it just works 95% of the time.

Kentico as far as I can see always offer an upgrade path, I started with 5.0 on the same site and i'm about to upgrade to 8. Yes code changes need making but then lets take a look at the API of Kentico.

The Kentico API is very well documented and is mature, if you follow it when adding custom code changes, changes are minor, what you don't have is the 'carte blanche' attitude of well "New version, new code". If I had to go into my CEO's office and explain that "sorry you can't have version 8 of Kentico unless you a prepared to pay for the development of the site again" id probably never leave the room! Whether a product is long supported after it is superseded is of little use as it will be dead if we measure the speed of changes within the web and development. Point is the API may change, it may improve and it may be a necessary evil.... But changing for example:

CMS.CMSHelper.DocumentEngine to CMS.ContentEngine is no big deal compared to having to change the entire code base of any customisations or being forced to change everything. I just can't see how that can be forward thinking in anyway?,but alas I wont because I agree with Petr!

Lastly but certainly not least, Kentico support is "second to none" I would say for two reasons, one because the Kentico team genuinely care, and two because its not open source, and sometimes...just sometimes paying for support yields far better results. Kentico is a two way commitment, its a platform its an architecture and for £2,399 english pounds for the base edition its simply unrivaled in my opinion in both support & flexibility at that level.

I have developed a reasonably complex site in Kentico and have had to buy nothing additional except for jQuery Sliders in order to get a specific look & feel. There is just no way it could've been developed as easily and quickly with anything from the open source market IMHO.

Jiri Slapak commented on

Hello Steve,

Actually, I have to disagree with you. Your argument with cars is rather inaccurate. It’s always bad to make people do the same thing twice… Or leave people behind… Anyway we all should know better - we are creating the digital world where anything is possible. In our world we can make the parts from your old car work in your new car and not only that – we can make them work even better than they used to!

Saying that the upgrade is impossible because that is how Drupal stays up-to-date sounds like an awfully lazy excuse to me as I don’t think that Drupal is up to date at all. I mean Symfony2 has been out there for a long time and they are still only working on a new version based on it.

When I look back I can remember many practices of site development in Drupal 7 that I still cannot believe someone could consider to be “up-to-date” even in 2011 (the year of Drupal 7 release) and yet they are still “the current practice” in 2014 in the Drupal world.

Another argument is that being up-to-date means to release often and release incrementally (the whole agile world knows that). Anything being developed for let's say 5 years without any release will have 5 years old architectural concepts which can be a big problem if they were proven to be wrong. And any module to be developed will be forced to be developed on these potentially wrong and old architectural concepts.

What I want to say is when Drupal 8 gets to the point when it can be used with all the essential modules, the core architecture will already be about 6-7 years old. (This argument might be partially invalid if they dropped all their work somewhere in the middle of Drupal 8 development and started from scratch. I did not check if they did and if they did I own you an apology).

I understand Drupal may be a good solution for many web developers and I didn’t mean to offend anybody. I just want to point out what I believe is a major flaw in Drupal’s release and upgrade path policy.

Jiri Slapak, Kentico developer

Petr Palas commented on

Juampy,

thank you for your comment. I'd like to answer your question "Does any other CMS offer that?”

Kentico provides much more functionality out of the box without the need to use external modules. It's stable, flexible and scalable and offers a clear upgrade path to new versions.

Do we have the same community? Our community may not be as big as Drupal's one, but we have 29 certified partners (and other partners without certification) in Australia who are more than capable to deliver projects for the government and already delivered dozens of sites for various government agencies or local authorities: http://www.kentico.com/Partners/Solution-Partners/Australia

While comparing Kentico vs. Drupal wasn’t my goal, I have to be concerned about the decision to standardize on Drupal (7) at this point for the reasons above.

Regards,

Petr

Juampy commented on

The Australian government will use Drupal 7 because of its stability, flexibility, wide set of features and community.

Does any other CMS offer that? As far as I know, there is not.

Regarding Drupal 8, there is still a long path until it beats Drupal 7 in the aspects stated above. In the meantime, 7 its a great choice.

Steve Purkiss commented on

“there is no backward compatibility with the previous code” is such a lame argument as it's the entire reason Drupal is able to keep up-to-date with the latest in technology and enable you to migrate your content and users from your version to the next.

I can't take any of the parts from my old Vauxhall Corsa and expect them to work in my new Ford Focus, but I work well in my new car, it still works with petrol, and I moved my furry dice over too and they fit in well.

I actually tend to agree with you re Drupal 8, in fact the way forward I would've recommended is spend the first few months helping to get Drupal 8 out of the door, then you'll have lots of experience of the product as well as being able to use it in a production environment. But I'm only looking from the outside in, and I'm much more of a risk-taker than I imagine an entire govt IT dept is / needs to be.

Thanks for the article though, been a fun 24h!

All the best with your code, whatever it is :D

Petr Palas commented on

Tom and Webchick,

It’s good to hear Drupal 7 will continue to be supported for several years, but to me, it sounds like investing into a VHS tape factory when DVD is just around the corner. Sure, there will be many people who will keep their VHS players for a few years, but the number of them will diminish over time – just like the efforts around Drupal 7 when 8 is the “new and shiny thing” and most of the new development efforts will go into 8, while Drupal 7 will continue living in a maintenance mode for a few more years.

It seems that many people in the Drupal community just accept the way it is which is surprising to me. Our customers simply expect there’s a reasonable upgrade path from any Kentico version to the most current one that will allow them to use their previous investments into their projects and benefit from the new functionality and hundreds of enhancements that come with every major Kentico release. And they want to get them without going through a costly rewrite of their code.

It may be some cultural thing, because statements like “there is no backward compatibility with the previous code” or “'it's ready when it's ready” just wouldn’t resonate with our customers. And when it comes to a platform for hundreds of government sites, I have to express my concerns about the plan.

Regards,

Petr

Tom commented on

This quote, "...represents a major risk as you’re going to invest into version 7 that comes to the end of its life..." is without basis. It's widely known that the current and previous version of Drupal are supported. Drupal 7 will be supported until Drupal 9 comes out. The Australian government realizes that open source software is the only way to innovate at the speed of the web. Kentico's only shot at survival is to open source their product.

webchick commented on

Oh, additionally, the para about Backdrop CMS is way overblown. Let's be accurate here: "They" are actually 2 developers who started the project, and about 20-30 people pitching in (see https://github.com/backdrop/backdrop/graphs/contributors?from=2013-05-20&to=2014-05-23&type=c), and zero contrib ecosystem around it. As compared to Drupal, which has over 2,000 core contributors http://ericduran.github.io/drupalcores/, a security team behind it, commercial support, etc. So while it's an interesting experiment to keep an eye on, it's definitely not anything close to threatening to Drupal itself.

webchick commented on

Just to clarify one thing regarding Drupal's version support policy, since this seems to be one of the main arguments here (or at least in the comments).

Building in Drupal 7 today is perfectly fine. Drupal 7 will be community-supported until Drupal 9 (or, depending on how the policy discussion currently in process about Drupal 6's community support ends up, possibly Drupal 9 + 12 months). At the current "when it's ready" track record of core releases, that's until 2018, at minimum. And it's highly probable that commercial Drupal shops will offer even longer paid support timeframe, just as they likely will with Drupal 6 (which has already had a 6-year run of community support, and counting) when Drupal 8's ready.

Petr Palas commented on

Hi John,

thank you for your comments. First, I’d like to say I’m sorry for an inaccuracy in my blog post saying “all government websites”. Still, the Statements of Requirements document says the expectation is to move 182 to 437 websites out of around 1200. That sounds like a massive standardization to me.

The main point of my blog post is that choosing Drupal for such a big and visionary project at this moment represents a major risk as you’re going to invest into version 7 that comes to the end of its life and the next version “will be ready when it’s ready”.

While it’s true that any software will get a new version at some point, there’s a big difference between incremental changes with a well defined upgrade process and a major rewrite of the product introducing completely new architectural concepts. Based on what I read about Drupal 8’s new architecture, I can’t imagine the move from 7 to 8 will be any easy.

As you can see, I’m not using the usual FUD against Drupal or open source. There are many commercial products that aren’t easy to upgrade either (everybody who has a customized installation of SharePoint knows what I mean). While Drupal may be a good fit for some government sites, I just do not see Drupal as the right choice for such ambitious project at this critical period in the Drupal’s life.

Lastly, I appreciate that you give the government agencies the freedom of choice. It allows those who are happy with their existing solution to stick with what works and avoid a risky transition or simply choose a different solution that may be more cost efficient for them or provide more out-of-the-box functionality.

If nothing else, I would recommend that you wait for Drupal 8 – when it’s ready...

Regards,

Petr

Gordon Rae commented on

I guess nobody told you that the Australian government already has its own open source CMS, built in Drupal 7, called aGov. The RFP you're talking about is to commission the successor to that. So your five reasons are already factored into the equation. I'm surprised you seem so badly informed, because if I was CEO of a software company that thought he had the solution to a problem, I'd start by downloading the tender documents and reading the requirements.

Your suggestion that the Drupal community is going to go all weird once Drupal 8 appears makes no sense to the people who've been contributing to an open-source code-base that satisfies every mandatory legal requirement for an Australian government website.

That 'instant functionality that the open-source Drupal lacks' you think commercial vendors could help with is a problem that's been solved by the Drupal community, because Drupal is so much more than Drupal core. And the 'bigger questions' have also been addressed, because the Australians consulted with the US federal government and the UK, both whom are running large government digital infrastructure projects. Has anyone done the maths? Yes.

Government likes working with Drupal because it doesn't have the 'Us and Them' feel of most IT procurement contracts. With Drupal, it's 'Us'.

John Sheridan commented on

Hi Peter

We are not standardising on Drupal. We are building a CMS in the public cloud to rehost two sites already on Drupal (australia.gov.au and finance.gov.au) and then offering that CMS to other Australian Government agencies, particularly those with relatively simple sites.

These are not new sites but currently established ones. Money is already invested in them. We are looking to save money by providing a cheaper service, utilising public cloud, built on templates, with appropriate security and WCAG 2.0 AA accessibility designed in from the outset. Owners of those sites will only move if this offer provides value for money for them. Moving to it is not mandated.

Our business case shows that this will provide value for money for us on our two sites. It isn't predicated on other agencies moving as well although this will increase the value over time.

Drupal is our choice of platform for the reasons explained in the post you quoted. Whenever one makes a choice in software or applications, one is accepting a particular version in the knowledge that a new version will arrive at some time in the future. I can't see how this can be avoided. And, as I noted, we are already running Drupal.

The nature of the software as a service solution we are seeking is that the provider of the solution will be responsible for the upgrade of the platform. This will inevitably involve change but in a manageable manner. We will be limiting the modules used to increase standardisation and simplify version upgrade activities.

We also run a WordPress platform: www.govspace.gov.au and will continue to do so. I don't think all agencies will move to Drupal. However, many site owners do use Drupal. I note that one source shows that, together, WordPress and Drupal are used by 95% of open sourced based websites (http://trends.builtwith.com/cms/open-source). Government policy requires us to use open source if it provides value for money (http://www.finance.gov.au/policy-guides-procurement/open-source-software/). Even if open source is not mandated, Drupal is very popular - http://w3techs.com/technologies/overview/content_management/all or
http://trends.builtwith.com/cms.

We are seeking to engage a commercial vendor for this solution, one that offers Drupal on a software as a service basis. We are also seeking other vendors who will help agencies move to the new CMS. We expect to pay for these services but as I said above, agencies will only be using this service if their analysis shows that it offers better value for money than other alternatives.

I trust this information will assist your readers.

Regards

John