What do you think the barriers are to adopting open source?

open forum
1

Within Ripple we are meeting lots of different people and groups and we encounter questions like is it safe, is it secure etc.

To move the open source agenda forward and drive real change within the health and care sector, I wondered if the group could provide any questions they have been asked (and answers) to help educate the masses.

1 Like
2

I wonder if some concerns about open source come from the idea that it may lack brand assurance. Although that probably doesn’t apply e.g. in the case of Apache - a strong brand backed by a large corporation.

It may be that people equate open source with lack of assurance, accountability, service guarantees etc, where these things actually are supplied, or should be, by a competent service organisation irrespective of whether the code is open source or not.

Perhaps some inevitable conflation / confusion between the system and the support?

3

I’m doing my MSc Project evaluating where the Technology Fund money went and how much of it was spent on Open Source projects.

Some of the things that have come out so far are:

Some organisations have a strict do not use Open Source policy.
Open Source isnt supported.
Procuring is Difficult
The transfer of risk is iffy with Open Source (i.e. if it breaks who’s to blame).

I’ll share what I have eventually but the questions i asked were:

  1. Does your organisation have an Open Source Strategy?
  2. Is the software and technology you have used for your project an Open Source Product?
  3. Does the software / technology interface with another system?
    4.1 If so is the interface based on Open Standards / Open APIs?

This went out to all of the Tech Fund trusts via FOI’s (https://www.england.nhs.uk/digitaltechnology/info-revolution/idct-fund/)

John Pyle has done some work on this before (goo.gl/1MurcL).

I have a lot of references to add into my report but I’m getting an idea of how much of the Tech Fund projects aligned to the Personalised HealthCare 2020 and 5yr Forward View.

I’ll add in anything I can but likewise, i’m really interested in seeing where this post goes.

4

Some links:
FOI’s sent out & answers:
https://www.whatdotheyknow.com/user/ben_sewell/requests

Google Sheets Stuff (A Work in Progress):

Enjoy!

5

people and organsations (particularly those working in health care IT) are entitled to be paid for the work they do and are entitled to protect their IP

6

Open Source is useful
but it totally fails to tackle the fundamental dilemma of healthcare IT worldwide
i.e. our massive Plain English Inter-operability impasse.

Traditional IT tools such as Data Modelling,Coding, Data Dictionaries
are of no use in making medical IT systems Inter-operable

That will only because

“Analysable and linkable Electronic Patient Records (EPRs) will only attain their true potential for improving the quality of patient care and reducing the risk of human error, without excessive data re-entry overload, when, in each speciality and sub-speciality - following intense, open, web-based discussions - bit by bit their detailed, logically and chronologically-arranged, flow-patterned questions and the full range of all allowable answer-options (always including, whenever needed, “Unknown -Free Text” and “Other - Free Text”) - are, by stages, taking into account as many interested parties as possible, individual question by individual question, internationally standardised.”

It really does not matter whether a hospital uses open source or proprietary software
or whether it uses Snomed or any other code or whether it uses the code called “Plain English”
Such matters are almost irrelevant compared for example the need that every IT system which included the Question “Title?”
should
always insists that the only allowable answers should be for example: “Mr, Mrs, Miss,Other (Free Text)
Almost every database everywhere used a different fixed set of answers and not one of these is ever genuinely “Inter-operable"

7

They’re also entitled to give it away for free if they want to do so.

Open Source is a choice.

8

KIS - at the national patient level, name , postcode, dob - no one has asked me for my title for ages, and of course NHS number, as deemed law by the house of lords (forgot his name, but i am sure he won't be offended ;-))

9

exactly, i might be happy to give some away for free (e.g. on a cataracts PERSON pathway) but probably not other

(e.g. on a testicular cancer PERSON pathway), if organisations are not able to distinguish between the different types of health data,

then shame on them, forget it, but your point is exactly right, it should be our ... choice

10

Hi all,

Can anyone provide specific examples of where open source options have been overlooked/rejected in favour of non-open source options and where the decision was either because of, or influenced by, a preference of non-open source? I’m interested to find out more in this area and examples would certainly help me.

Thanks in advance,
Damien

1 Like
11

Do you mean open source as in ripple or endeavour product or the open source projects (tomcat, Java, camel, Spring, etc) it uses.

On security, scalability, safety most common solutions use open source projects (inc most commercial offerings).
The big difference is the technical knowledge you need. NHS (trusts and smaller) doesn’t have many app or systems specialists (except HSCIC) and its security teams are hardware focused. Those app people it does have tend to be front line support and rely on commercial for 3rd line app support.

12

It all comes down to the solution and whether it is open source or not should be irrelevant.

Whether a solution is open or closed is far from an indication of the quality of software as there are good and bad examples in both worlds. Open or closed software is also not an indication of the cost of implementing the solution either and in my experience costs have been similar.

I think that the barriers really come down to the lack of an overall, completely open source solution which meets users and purchasers requirements. And importantly as per the last post, a lack of technical teams locally to support the use of open software. You end up paying for the services whatever you do, so, again, whether it is open or not becomes a moot point.

Also worth noting, I have never come across any specific policy of not using open source, and more often than not, there have been policies of prioritising the use of open source over closed.

13

we see quite a bit of confusion around open source - one area not mentioned above is procurement not being quite sure how to buy something that is essentially free.

Other things that we’ve seen reflect the other comments on security, supportability and the like. There is a lot of comfort in traditional licensed software in that it often comes with maintenance and with committed to roadmaps and the like. Clearly opensource can do that too but it needs the community to focus on it.

14

I have had our ICT department chose closed source over open source due to a lack of support for the open source solution. Essentially they like being able to sign a solid support contract with a supplier to ensure they can get things fixed if they go wrong.
Whilst this does not exclude open source (and ICT are happy to use open source) it has steered a lot of ICT systems to non open source solutions.

15

In my opinion (I seem to have too many of these) i believe the following are a couple of reasons people do not engage with open source solutions (Not Languages or Frameworks):

  • Service Management - there is a general concern that solutions that are open source will not have good ITIL/ISO Standard service management with reasonable response times.
  • Change Management - there is concern that change in an open platform is difficult to manage. Feature management and development line merging is a full time job in an open source solution.
  • Compliance, IG and Legal - there is concern that open source solutions will not have gone through the stringent checks that most “Medical Device” systems would be required to go through. Therefore if there is an incident relating to the solution who is legally responsible.
  • Code quality & Performance - there are concerns relating to the general quality of the code and how that affects both performance and the users experience.
  • Longevity & Sustainability - there are concerns that the cadre of developers that came together to develop the original solution may lose interest or may not gain enough interest to fund the key internal management processes required to make the solution viable, thus leaving the consumers of the system without support and maintenance.

Just some of my thoughts.

1 Like
16

Some very interesting patterns emerging within there. Should make for a good report which I’m sure many would want to share wider.

17

Thanks for all the contributions, really helpful.

Kevin - I mean Ripple, openeyes, endeavour etc, so OS solutions and platforms rather than projects/components.

I personally think there is a lack of trust and understanding of what OS is and a fear that things can wither and die, and then where is the client/trust left. So the underlying business and support models seem key within this. The fact that OS is widely used across other industries as part of solutions but not openly or proactively promoted means generally awareness of OS remains low.

I think organisations are often looking for a steer from central government departments to say that going down OS is fine. Whilst the NHSE Open Source programme, C4H are really championing this, I think this also needs a consistent or strong leadership message from all departments to bring OS into the mainstream and normalise it.

I also think that the freedom or flexibility OS can provide can also spook people as they are perhaps not used to having a choice, control or say in the solutions.

18

Interesting open source comments on FOI. I notice a couple of them refer to mirth(Implied when people say open source TIE) which is quite a mature product that is pretty well managed and you can buy service support from them. Which provides a good financial model for running a business.

Other feedback on the FOI is people developing in house “open source code”. Which i think is a great way of bringing together health developers and sharing experience, however most trusts would struggle to provide the support / service agreements required to deliver a managed service relating to their open source product.

Would be great if someone could work on a framework for organisations on “how to scale up a sustainable open source solutions”

19

I find there is a bit of a disconnect in the replies here. The big difference between (most) open source and commercial software production is that open source is a production method, whereas commercial is a production and a delivery method. In other words ‘open source’ as a team organisation (e.g. many of the projects we have on openEHR) is designed to create software, but not sell it. Selling it means being able to engage in contracting activity and taking legal responsibility for supply and maintenance. A lot of OS groups can’t do this.

The big ones like Apache are different, because their core devs come from tech giants and work full time. There’s no need for a contract, because the product is already being built and maintained in a professional way. Linux is an interesting case. The core is so high quality it’s almost a non-contest against closed OSs. But w.r.t. the consumer versions, well it’s clear that they don’t respond that well to users, witness the regular and ongoing UI/UX wars in Linux land (Unity anyone?). In any case, again, the core devs are full time. And - in these large projects, there is professional project management.

It’s a lot harder for a small open source project to do what these giant projects do - even if the dedication and professionalism is there (in our openEHR corner of the world, the majority of open source is built by software professionals) - they usually work part time on it; they don’t get paid extra if they work more than business hours, so response to problem reports is not guaranteed to be within a time frame or prioritised to a given customer, and so on.

In summary: all ‘contracted’ software is ‘commercially’ supplied, regardless of the way the source code was developed, or its license. It’s perfectly reasonable for a trust to want a legally and technically responsible entity to act as supplier - even if it is the IT department, it has to have a dedicated team that takes responsibility. Without this identifiable responsibility, noone knows who to point to when things go wrong. My mental test: just start with patient safety and work your way back - where does the buck stop?

The corollory of this is: if trusts etc want good open source solutions on a contract basis, they have to be prepared to pay properly, and forget the delusion that open source is somehow ‘free’. It is free of runtime licences, but not maintenance-time costs.

3 Likes
20

Hi Stuart - Are you able to be more specific about what the requirement was and/or what the candidate solutions were, please? (please accept my apologies if the question is inappropriate!)