Dear reader, as you can see, the title begs the question: “are not we realistic about it?”. The answer, in my humble opinion, is no and this is a major issue.

I just wanted to express a few things I’ve had for some time in my mind about open source software  in written form so that I can give the URL to this post next time I encounter the same situation.

The perception of open source by people with different positions in healthcare seems to swing from one extreme to the other. Unless we can build a healthy, realistic view of open source software, we won’t probably be able to introduce benefits into healthcare IT, at least not at the level we would like to do so.

There is a large group of people who are proponents of using open source software. In many contexts, I am a member of that group.  However, this group is mostly branded as a group of idealistic hackers and activists who are defending open source for the sake of principles. Even worse, the members of the same group is mostly branded as the stereotypical,  paranoid enemy of the big software vendor who hates corporations and believes that open source software is always better. This is wrong, and it is killing a lot of good that could come from open source.

First of all, I do not think that open source can exist in a free market economy without clearly expressing its commercial aspects. Neglecting to assess and communicate the cost of open source hurts its credibility (a lot). The critical point in any discussion about open source is when you hear something in the lines of “and it has zero licence cost!”. Whatever the context is, at that point, someone should underline the fact that not having any licence cost does not mean not having any cost at all. Yes, you would not pay licence fees, but it is quite likely that you’d need to pay some support fees or buy some consultancy and from a cost perspective, if you manage to keep those expenses lower than the proprietary software scenario, then you’ll have a better deal with open source.

When offering an open source solution, one should always draw the whole picture in perfect clarity. This is how much you can save from the license fees, and this is how much you’d have to pay for support, training and consultancy. Once you do that, you have a proper business proposition with pros and cons which is subject to measurement with the same metric that the value of the proprietary option is measured with: money.

Putting the open source to this perspective actually saves everyone from the risk of bitter disappointment. Otherwise, we end up with users, managers, policy makers, all misinformed, waiting for something wonderful to be delivered by the community effort of hard working developers. This is not a realistic expectation, not at all.  Here is a list of facts that everybody who is hearing about open source should know (the sooner, the better):

• Software has to be developed by developers. Good software takes good developers, and good developers are rare and usually expensive.
• Unless they have other means of making a living or they don’t have any financial concerns, no one can escape the realities of making a living. Some people will put more effort for less, but at the end of the day, successful projects do take long term commitments, and people can afford to commit up until a certain limit.
• 1 hour of work from 24 developers every day does not end up as 1 day of work. Good software always have leaders who dedicate focus and time continuously. Contributions do help, but most, if not all successful projects have a core team. Many key open source projects have key people funded by government, vendors, academia etc.
• Not all open source software is in the form of turnkey solutions. Sometimes you get a good starting point, but it will take effort and investment to create value out of it.
• Not all open source plays nice with established business models. Some open source licenses require the party using the open source software to make their own software also open source.  A software vendor may not be able to use open source software even if they want to.
• Having the source code is not an absolute guarantee for survival. Software gets complicated very quickly. Just because you can access the source code does not mean you have the capacity to change, improve or fix it. In fact, developers need to go through serious pain and apply a lot of discipline to make sure that they can read and fix their own code.
• Maintenance is the single biggest cost item in the software life cycle. A group of five developers can develop a very impressive piece of software, but it does not mean they can support two thousand users in a hospital. Even if the savings from not having to pay fees is great, and even if you shift all of those savings to the team, they may simply not have necessary amount of people to run an operation beyond a certain scale.
• The consumer/contributor ratio is incredibly high in open source.

Does it look negative? It should not, because it is only realistic. It probably does not fit the image you have in mind for open source, and that is exactly what we need to change. My own experience has thought me that it is absolutely vital to be objective about what you’re offering as open source, and explain and offer it based on the same principles that are applied to closed source alternatives. Everything else leads to disappointment.  Having spent 15 years in this domain, I am sure that there is a lot that can be done, but we have to be very realistic about how to do it.

I am going to release a key part of my PhD work as open source software pretty soon, and this time I’m determined to be very clear about what I’m releasing, and when and how it can be useful. Once the open source argument adopts this practice of presenting pros and cons with an equal balance, it will certainly make waves. Facebook, Google, Skype, Microsoft, Oracle, IBM, RedHat and many others are already creating huge value from the approach that was once considered their demise, and there is much that needs to be said about the business models of open source especially in a unique setting such as healthcare, but that would deserve another post.