Revealing the code and going open source

Did Paul Daniels ever tell us where he hid his fluffy white bunny before it was pulled out of his fetching purple hat? Was he right not to break the old school rules set by his magical founding fathers that forbid his secret from being revealed?

So why would a software vendor take their prized flagship product and allow everyone, including their competitors, to know their secret and see exactly what is going on under the hood?

Software applications are built from ‘source code’ – many lines of instructions that developers write to carry out different functions. Normally, this code is written internally by a closed set of developers with the source being hidden from an end user. When the code is openly and freely available for anyone to view and alter, it is referred to as open source.

Open source is often considered tobring a number of immediate benefits to the end user, including:

• a zero purchase price/annual licensing fee, which in turn provides a lower total cost of ownership for the solution
• higher levels of customisation, allowing users to tailor the solution to their needs
• software bugs being fixed more quickly by either the end-users’ own developers or by the pool of developers across the world who contribute to the project, rather than relying on a vendor’s development process
• increased security and reliability of the product as a result of any vulnerabilities being open and available to be immediately patched.

Putting all of this into a digestible example, imagine that the only meals that we could eat were prepackaged. You can only microwave the small plastic tubs for four minutes and eat with a fork. No condiments are on the table. The producers of the meal take six months on average to make any suggested changes or fix any missing ingredients.

Now imagine having the recipe for the same meal with the freedom to change and add to the ingredients, adjust the cooking time or how you plate the dish. Imagine having salt and pepper to hand and being able to eat the meal with the addition of a knife or a spoon. Imagine Jamie Oliver’s latest TV escapade adding inspiration to the dish. Perhaps he sprinkles over a ‘pukka pinch’ of Moroccan cumin ‘from a height’ or allows a lick of smoke from a wood fired oven. Which situation would you prefer – the closed source fixed four-minute micro-meal or the tasty open source recipe?

Yet, there is still a mist of doubt that follows the term ‘open source’ around. Many still view an open source product as inferior, unsupported, and a liability when compared to closed source proprietary software.

In my view, this attitude tars all cases with the same brush. While open source solutions might not be appropriate for every organisation or industry and there may be substandard open source packages out there, the same can be said for substandard closed source packages.

“Gerald Weinberg, author of ‘The Psychology of Computer Programming’, once famously said: ‘If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.’ He was right. Up to now, the reliability of most software has been atrociously bad. The foundation of the business case for open source is high reliability. Open source software is peer-reviewed software; it is more reliable than closed, proprietary software. Mature open-source code is as bulletproof as software ever gets.”

Open Source Foundation

But the obvious question remains – how do these courageous software vendors make a profit when they start giving away their software for free? Dependent on the type of license being applied to the package, the vendor can flourish by supplying a number of supplementary services in parallel.

For example:

• offering support contracts and documentation for the software – just because it is open source does not mean it is not complex or intricate
• selling value-added enhancements – for example premium website themes for an open source website content management system
• selling expertise as a consultant – who is better suited to build add-ons, custom based extensions or bespoke installations than the originator?

In this era where tight belts are fashionable, it is with a happy heart that I see the NHS considering open source solutions and the advantages they can provide to trusts.

“[Open source] gives the same assurance as a proprietary vendor with the added benefits of transparency and the ability to get quicker changes through and see the code and share innovation between them.”

Richard Jefferson, head of business systems, NHS England
eHealth Insider, March 2014

Starting with a high quality closed source software package and enhancing this by moving to open source potentially brightens the outlook for the package and lets end users move into top gear using open source as their engine. I personally would prefer to know where Paul Daniels’ fluffy bunny was hiding and potentially offer some advice on how to improve his ‘big reveal’.