Open Source can be anything but free

The standard business reaction to the possibility if using an open source solution for a website or web applications is that if it is free, it is therefore going to save us money. In some cases that may be the case, but in many – the majority I would say – the compromises you may have to make by using an open source may cost more than you think.

As mentioned in other blog posts, I have recently been using Drupal as the core to a corporate internal communications intranet. In this case the decision to use an open source application was based on the requirement. Admittedly, with the specified functionality which will be in place on day one, I could have built a bespoke solution for the same price, however, the ongoing development costs to create the additional elements to be rolled out in the coming months, would have made a bespoke solution prohibitively expensive. Despite the core application being free (open source), a significant amount of time has been spent re-engineering, tweaking and downright hacking Drupal to make it behave the way the client wants it – even then a few compromises have had to be made.

The same client has now asked me to develop their external corporate website to run atop a content management system (CMS). In this case, again based on the requirement for the site and despite the need to create minimal integration with the intranet system, Drupal in not the most appropriate solution.

Another client for whom I recently prepared a draft proposal document, specifically expressed a preference to use an open source CMS for the solution, on the basis that:
1. It would not tie them in to future development requiring a particular developer/company (i.e. me)
2. It is free and therefore cheaper
3. It already exists and therefore cheaper.

Fair enough, I thought, now let’s talk about the specifics of the requirement…
In the conversation which followed, they expressed a number of functional elements which they wanted to behave in particular ways. Each time a new element was described, I had to mentally cross out the possibility of using a particular open source CMS for the solution because it simply did not work they way they wanted. By the end of the conversation it was down to a couple of possibilities which, through heavy hacking, might be able to be tailored to their needs.

The straw-breaking point for me came when they described a no-compromise approach to the user interface; the look and feel for the website (see here on my frustrations with interface compromise). Having just recently re-branded the company in both visual and textual content, they wanted to leverage that as much as possible within their web presence. That’s the remaining two possible CMS off the list. The layout compromises – or the vast amount of hacking to work around them – now pointed to a bespoke solution.

Open source solutions are fine for targeted niche CMS, such as WordPress for blogs or Drupal for community based sites, but when you need to create a corporate website with a no-compromise user interface and specific operational behaviour in the back end, open source rarely fits the bill.

The problem with much open source, in the CMS space, is that it generally falls into one of two categories:
1. A focused niche system (such as a blog) or
2. A vastly broad system developed to keep as many potential users as happy as possible with vast arrays of add-ons, plugins and additions, most of which are not stable enough for commercial use and the rest rarely have the behaviour or ease of re-programming to enable precisely what the client wants.

To me, creating a solution is not about persuading a client they can put up with a half-solution because it’s cheap and easy. Rather it is about providing the client with what they have asked for – for the most part, there are, of course, some global limitations of web-based applications, though with techniques such as AJAX these are diminishing. In the real world however, the urge to fulfil the requirement has to be balanced against budget and time-scale. But that’s another story.

The Open Source buy-in
Open source CMS projects are generally run by a team of developers (if they are not, steer clear of them as ongoing development often becomes sporadic and unpredictable). Those developers react to the sometimes endless requests of other developers using that CMS to create their own client solutions. And that is where these systems sometimes fall down: the development process is about developers talking to developers, rarely if ever, are the end users – the clients – talking to the developers. The chain of communication often very clearly results in ongoing development being unfocused and little more than knee-jerk reactions to the multitude of conflicting enhancement requests.

Deciding to utilise an open source solution as the basis for a client’s web application, places a great deal of trust in that CMS’s development team. Small teams come and go, large teams are often unmanageable and both are unpredictable in that you can rarely determine when or even if a particular bug – which may be holding up development of your project entirely – will be fixed. Fix the bug yourself and at some point down the line you will have to invest the additional time of integrating your fix with new code releases from the development team. More cost to someone.

If development of a particular open source project ceases entirely, you may find yourself up a certain waterway without a certain means of propulsion.

It has its place
Open source has it’s place certainly. But the decision to use an open source CMS must be made on the basis of it fulfilling the client’s requirement and not the too often seen misconception that because it’s free, it’s therefore cheaper. It can be cheaper, but sometimes at too great a cost.

---