Headscape used to offer its own content management system (CMS) to would be clients. It was first developed back in the early noughties when CMSs were ridiculously expensive and crap to use.
It made sense to develop a tool for our clients that was cheap and simple to use. So we did. No licence fees accompanied by a logical and pleasant-looking interface made for the perfect package. It was great. Everybody loved it.
But, in its original incarnation there were certain developmental fundamentals that meant we couldn’t easily bolt on the functionalities that a) people were asking for and b) we felt we needed to offer to attract new clients. Things like multi-language options and detailed workflow. So, a few years later, we built it again from scratch. It was a bit more complicated to use but certainly not a nightmare. We tweaked this and refined that, we even created a fair few bespoke features for various clients, and we incorporated new features into new projects as they were built. People continued to love it.
When you do web design you really don’t think that an Icelandic volcano is going scupper your plans. NATS was a client of ours back in 2010 when the volcano blew (they still are for various projects here and there). NATS’ main corporate site ran on our CMS. Oh, NATS stands for National Air Traffic Services.
The site’s audience went from a handful of aviation geeks to everyone in the northern hemisphere every hour of every day for about two weeks. All the big news sites pointed everyone at the site.
The site fell over and it didn’t get back up. We had to replace it with a few static HTML pages and the hosting platform (looked after by another outfit) had to be upgraded significantly.
Pretty much any CMS based site would have failed in that scenario, but the whole episode got us looking at our beloved little CMS in rather a different light. Basically, in certain ways it was flawed and if we wanted to fix those flaws we’d have to start again. Again.
When talking about our CMS I used to make some interesting statements (interesting = dodgy) about how we weren’t locking in our clients to us. Oh no… the CMS was developed using .Net so any other respectable agency with .Net related skills could easily pick it up should we all end up being run over by a bus.
Though this is a true statement – Agency X could “pick up” our software – none of them ever would. Not a chance. Why would anyone spend an age learning the idiosyncrasies of someone else’s platform for a one-off project/client. The cost of that learning curve would probably equal moving the site on to another platform (which would be a considerably better choice). There is, I suppose, a case to argue for adopting a system that has a hugely complex site running on it for a big name client. There is a point where the investment might be worth it but that is, I’m sure, for a tiny minority.
People had been asking us for Drupal for a while. RFPs included something like ‘we want an Open Source CMS and we want it to be Drupal’. When pushed as to why, the authors of such statements tended to respond along the lines of ‘because we’ve heard it’s good’.
So, we checked it out and reached the same conclusion. It was a no-brainer to move over to it. There are things about it that could be better (I hear moaning every now and then!) but we have successfully developed some great sites on Drupal over the past few years. The design and functionality isn’t limited by the platform (quite the opposite with functionality) and the back-end is easy to use. Even for me.
If your software is Open Source but you’re the only person/team that uses it may as well be proprietary.
But – and this is key – all of these new sites could easily be picked up by another agency that works with Drupal (and there are thousands of such agencies around the world). Sure, there would be some Headscape customisation that would need to be understood but that would probably take a few days to learn at most. And in the end these sites would just be other Drupal sites that sit alongside Agency X’s own Drupal sites… not a one-off misfit that probably only one developer would have learned; who could also succumb to the catastrophic death-by-bus scenario and the client is straight back to square one. I digress.
Open or closed?
I’m (finally) getting to the crux of my point. Though it makes sense to want Open Source software that you “own”, it’s not the open-source-ness that really matters. What clients want is business continuity as described in the previous paragraph. If your software is Open Source but you’re the only person/team that uses it then, once again, Agency X isn’t going to want to pick it up. It may as well be proprietary. There is no difference between an agency not wanting to adopt a platform and not being able to adopt it because of ownership of the code. The result, for the client, is the same.
There’s nothing wrong per se with buying proprietary software. I think as long as you’re aware of the potential drawbacks and you’ve weighed them against the benefits – and the benefits win – then go for it. After all, that’s what people did with Headscape’s CMS all those years ago. At the time, its low cost and easy-to-use interface outweighed the risks associated with proprietary software. It didn’t last, but then very little does.