By Jon Honeyball
HardCopy Issue: 42 | Published: 01/11/2008 | Last Revision: 06/07/2010
I’m often asked what I think about open source versus closed source applications. This is, of course, the equivalent of putting your head into the mouth of the alligator and hoping it isn’t hungry right now. That’s because there is no one right answer, and to be honest, that’s a real shame. Talk to a proponent of closed source applications about the benefits of closed source, especially a vendor making a good living from selling such things, and you will often get a blast of abuse directed at the open source brigade. Ask an open source enthusiast about the matter, and there will be a heated rant about the evils of closed source. If it wasn’t serious, it would almost be funny. But real grown men take positions that others, looking in from afar, would consider to be frankly laughable if it wasn’t rather sad.
Open source advocates can get quite heated over the debate
At the end of the day, I don’t have much of a view in favour of the openness or closedness of the source code of applications and operating systems. All I care about is good solutions versus bad ones. I am not going to run my business on a disastrous product simply because it is open source. Nor am I going to stump up money for a product which turns out to be equally bad.
And it is here that the argument about open versus closed runs off the rails somewhat, because whilst there is a goodly amount of truth in the claims and counter claims of both parties, neither ever seem to getting around to answering the core question – is it a better solution for my business?
And that is before we evenstart to spin in the reality about free versus pay-for, for which there are many examples of both closed and open source solutions. So you can have a pay-for open source solution, or a free closed-source – has this made the open source model weaker by deigning to take money? Or is the closed source solution enhanced by the lack of the traditional bill?
Closed source vendors like to quote Sir Henry Royce when he said that “the quality is remembered long after the price is forgotten.” And they have a point – particuarly as the cost of the licences for something like Windows Server and Exchange Server are but a fraction of the true total cost of ownership of the product, when everything is taken into account. But many financial directors tend to take a somewhat more down-to-earth approach and are heard to scream “HOW MUCH?” when told the cost of providing Office 2007 on Vista to all their workforce. Especially when they decide, quite unilaterally, that if they are happy with Windows XP and Office 2003 then everyone else should be too.
So what about the claim that open source code is intrinsically better quality because anyone can read it, and thus spot issues? The closed source vendors claim that they have more than enough people working on their programs to be able to spot issues. I can see truth in both sides of this argument. If I have the source code then I can see what Error 12933 means – and how many times have we gone to the Microsoft website, typed in the error code that we’ve just read in a system log file, and there is no mention of it in the Microsoft Knowledgebase? Too many times, but if I had the code, I could at least see what was throwing that particular error. It might not actually tell me very much, but it would certainly be less frustrating than coming up against an ‘undocumented’ or ‘internal-only’ error number.
On the upside, it is clear that vendors like Microsoft spend an incredible amount of money on testing – load testing, upgrade hardware and so forth. A year or so ago I visited the database test facility at Microsoft: it runs to thousands of computers from the smallest of boxes to multiprocessor monsters that were taller than me. Does some open source database engine have an equivalent? I doubt it.
Nailing the issue
Hindsight is a quite wonderful thing. When the historical analysis of the collapse of the banking system is done, it will be interesting to see what role has been played by the common PC. Back in the 1970s, when the mainframe was God and PCs were still on the drawing board, the computer trundled along in a workman-like fashion, but there was still a great deal of the business being done on paper. Now, when your business is, in essence, to take someone else’s money and move it from huge Pile A to huge Pile B and take a small margin for the work, there is a clear temptation to go faster and faster. After all, the more you transact, the more you earn per day. Crank up the computer, and go for a real-time trading solution, and the money flies at a speed which simply defies belief - and the ability of anyone to reflect on the consequences.
Now wrap in the capabilities of spreadsheets, the big daddy of course being Microsoft Excel. And whilst I cannot, in all conscience, blame Excel for the shortcomings of the people who build financial models, one wonders how many of these spreadsheets used to ‘model’ (and I use the word in its broadest sense) the markets have basically been the electronic equivalent of a ‘back of a fag packet’ doodle, rather than anything which has any rigour or statistical validity. As with the famed ‘PowerPoint Effect’, those digits inevitably take on a whole new level of shine and credibility when presented in a well formatted and professionally styled Excel spreadsheet. It doesn’t matter that the underlying assumptions are a crock, and there might been some judicial nudging of the numbers to produce a better, more profitable bottom line.
I just have a fear that as the corpses of the old trading model are raked through, there might well be some examples of statistical modelling that would embarrass a five year old. You can’t blame the tool but maybe it has been too easy to do some of these things without needing to have a real workable understanding of how statistics and risk actually works. Could this be the end of the one-click Wizard? I hope so, and not before time.
Let’s nail this ‘read the source code’ issue, can we? Just how many of us are actually capable of doing that properly? And doing so in a reasonable timescale, especially in a large application, is going to take a lot of man-hours. Who pays for that? And even if we do find the wart in the source code, are we set up to make the change and then do all the necessary regression testing? Or are we just going to hit the Build button in our chosen development environment, and then throw the resultant new piece of compiled code out to our live production servers?
At the end of the day, I can see advantages to both approaches. Yes, it is good to be able to read the code, but what I actually need is a solution to my problem. Licensing is but a small piece of the total cost of ownership, and there are plenty of pay-for open source applications out there.
Where the battle might be fought with a vengeance is in the Office suite. It doesn’t matter how you slice and dice it, the new OpenOffice.org 9 is a formidable piece of code. And it is free. In fact, I’m typing into it right now. Am I hissing and spitting because it isn’t the ‘Genuine Microsoft Item’? No, not at all. If I didn’t need SharePoint Server integration, it would be hard to argue against this in favour of Microsoft Office, especially for a small or medium sized enterprise. It is on this ground that the battle might well be fought – it will take a long time before companies are comfortable giving up the Windows OS platform.
As I said at the beginning, the only thing that matters is the quality of the code. Any product I consider is judged on the whole spectrum of capabilities – price is but one of the items, as is the openness or otherwise of the source code. Actually meeting the business functional requirement is a much bigger worry for me, and you will excuse me if I let others wallow in their pointless open versus closed jihads.