Apologies for my totally lame play on the words of the famous sausage sandwich game*.
A lot has been written about open source software in the last week, so at the risk of boring you all here is some more.
All kinds of reasons abound as to why people would choose to use open source software, or not; even though I dare say that most software users – and even some IT professionals – may not have a full grasp of what open source is.
I read somewhere that open source software is more like free speech than free beer and it kind of makes sense, with the nuances that exist in the various licensing models.
Is it free?
Monty Widenius, who is a keen advocate for the open source movement, having been one of the main authors of MySQL, worries that too many people are seeing it as a way to get free software.
“More people are using it and, in these cases, abusing the whole idea of open source by not paying back either with development or money to help projects,” he has said.
It is clear that Widenius was mostly talking about corporates using open source components to further their own aims and effectively milking the system; in health we would assume that there is a more cooperative approach to things.
However, in EHI recently Dr Rhidian Bramley is quoted as saying: “There’s no reward for people developing open source, but there is for people using open source.”
In a market economy there has to be a way to monetise product and there is a whole world of patents for protecting ideas.
There is little doubt that it has gone too far in software, with ownership of things such as the hyperlink. However, should software authors be expected to give their work and ideas away for free?
Is it open (and is this a good thing)?
Open source has also become synonymous with “open” as in transparent and standards based, and “agile” as in adaptable. It is often promoted as a panacea to avoid the dreaded vendor lock-in.
None of these comparisons are correct or fair: you can get into similar problems with both modes of operation; and just because you avoid vendor lock-in, you should not assume that application lock-in isn’t just as bad.
In a large electronic patient record application, it is unlikely that you are going to want many people from different organisations modifying code. There are various models for creating a trust or custodian of the software, but in the end someone, some ‘organisation’, has to own this.
The developers of the Open Eyes electronic patient record at Moorfields Hospital in London have recognised the risk of it potentially “forking it into several radically different versions.” As a recent conference was told, this runs the risk of “lowering its clinical value and making it difficult to provide support.”
It’s not magic
Open source is a licence model and nothing more. People working in it tend to work in similar technologies, such as Python and use open source databases such as MySQL.
Someone coming along and “opening” their old proprietary code, written in a closed source environment, so that others can potentially use and modify it is arguably nothing more than a publicity stunt.
The reality is that it is unlikely that anyone outside of that software house is ever going to be developing it. Open source that requires niche skills, combined with many years of experience of the code (who knows why they did it that way?), is much better left closed.
You might well be better off building some kind of API wrapper around it and treating it like a black box. The original code authors could have done that for you.
Nor is it funny
The Mirth integration engine is an example that displays the benefits and the pitfalls of open source. Vendors can build-in this product and get a level of functionality, making their products very flexible and adaptable.
It does a great job out of the box, and you can build on it and share with others who have a similar need. However, the core product is tightly controlled by Mirth, and only Mirth can distribute a new official version.
In order to achieve enterprise class features, such as resilience and support, you have to pay; and these costs mount up to become similar to those in any other commercial arrangement.
There are companies such as Red Hat that claim to be able to support your open source deployments. Well, yes, they can; and to be fair they know a lot about things such as Linux.
But if there is an open source EPR product out there, then anyone with the right development and deployment capabilities can assist you in supporting that. I am quite sure that Extormity (www.extormity.com) for example would love to talk to you about deploying your open source EPR project.
The key problems in any kind of co-operative in a complex software environment are going to be version control and risk management. You are either going to have to pay-in to a club that keeps a locked down version of the code, or set up a commercial vehicle to do that. Isn’t that starting to sound a bit like a supplier?
What about the nasty stuff?
Assuming you have agreed all of the intellectual property issues – ie: ‘nobody owns it’ – then the difficult issues are risk and indemnity.
What happens if the software makes a decision that harms someone, either a patient or organisation? Software development is fun, for some people, but these things definitely aren’t.
Auditors, Monitor, and various other people including your trust board aren’t going to be best pleased if your EPR project is not contractually protected against the usual mishaps, and if you don’t have ‘time to fix’ guarantees, business continuity plans and so forth.
All of this is possible with open source, but it’s what comes straight out of the box in a traditional vendor relationship, even where that relationship is troublesome. You can’t beat having “one throat to choke”; as someone in a recent procurement reminded me.
But I’m not anti
By now, some of you might have conclude that I’m against the whole thing. You’d be wrong. Open source has its place.
What I’d like to know is why, when the rest of the world is marching on using open source products such as Linux, Open Office, MySQL, Python, PostgreSQL and many more (www.ohioh.net), we are not creating relationships in which our vendors move into these technologies within a vibrant marketplace.
Why aren’t we doing that, instead of getting into some of the higher risk and largely uncertain areas where we seem to be bound?
*The Sausage Sandwich Game is a Radio 5Live contest, hosted by Danny Baker, in which two callers must predict a guest’s answer to three questions, the last of which is always what kind of sauce they would have on a sausage sandwich; “red sauce, brown sauce, or no sauce at all.” Guests like John Humphreys make things difficult, by coming up with unhelpful ideas – in his case “Dijon mustard.”
Adrian Byrne
Adrian – Ade – Byrne is director of IM&T at University Hospital Southampton NHS Foundation Trust which, he says, has been working on its IT environment for 15 years.
On his LinkedIn profile, he says its aim is to “build an electronic patient record with full decision support, sharing data across disparate, so-called best of breed systems.” The trust is also developing a patient record and services, built on Microsoft HealthVault.