ABSTRACT: Although they present a number of advantages, Open Source Software (OSS) are more the exception than the rule in eHealth sector. Why? We highlight the incentives and barriers that arise for developers who want to contribute to OSS related to eHealth solutions. Finally, we present a set of alternatives to lower barriers and stimulate motivation of collaboration in the development of OSS solutions for the eHealth sector.
Implication of going OS? Incentives and Barriers
Many politicians and academics advocate for Open Source (OS) in the area of eHealth [6]. They argue that software development in the field of eHealth must at once: use standards in order to be inter-operable and then be able to integrate existing solutions and exchange data with them; be modular to adapt them to different contexts and be scalable in terms of functionality; be affordable to help promote the development of weak economies; present an innovative potential, be accessible and create clear benefits; be elegant with a great quality of code; be maintainable by third-party in order to avoid lock-in.
The best solution available to meet these requirements are without doubts OS solutions. The availability and access to code avoids lock-in, license are free of cost (in theory), they are very modular and most of the time they are using standards as they are the best documented [12].
One of the main benefits of adopting an OS development mode in a software project is the opportunity to attract volunteers developers, users and testers. This additional task force leads to faster, more efficient development and keeps the software more attuned to the needs of people who directly contribute to it. Implementation of the famous quote of Eric S. Raymond based on Linus’ Law : ”Given enough eyeballs, all bugs are shallow”. However, volunteer contributors do not participate in a project that require advanced skills for whatever reason. A set of incentives are motivating and justifying the work of contributors in OSS. Lakhani and Wolf [8] found that motivations of OSS developers were not based on irrational or altruistic justifications, but on a set of various extrinsic and intrinsic motivations [8]. The extrinsic motivations for contributing to OSS include personal experience gains for career advancements. It is also sometimes related to the norms and shared value of a community based on higher common principles [4] included in canonical documents like GPL license, Jargon file, New Hacker Dictionary, Cathedral/Bazaar metaphor. Intrinsic motivations are also fundamental and the most common reason among developers who participate to OS projects. It concerns the intellectual stimulation of the programming activity that bring them enjoyment of the activity itself regardless of the outcome [11]. They are doing the job for fun or challenge rather than for external rewards or sanctions. This enjoyment is also linked to the need of creative discovery sometimes required in advanced development activities, as well as based on whether they improve their programming skills. A final motivation (both intrinsic and extrinsic) highlighted by developers is their personal interest in a particular product. They often started to develop as frustrated users who, through their skills, wanted to change a product for their personal use [7]. In this sense, doing OS help them to find, attract and collaborate with developers who meet the same needs (with an expectation of reciprocity), as well as, enhancing their own reputation.
What are the barriers that prevent the OS world to be more interested in the eHealth sector? Brian Behlendorf wrote : ”The open-source approach is not a magic bullet for every type of software development project” [3]. Anderson reported that quality software in health sector is a real obstacle to implementation: ”One survey found that 86% of the physicians surveyed stated that vendor’s inability to deliver acceptable products as a significant barriers to implementation of IT in their practices” [1]. Software quality in eHealth is problematic for four main reasons.
Firstly, the eHealth sector is a very specific niche market. It is very focused and aimed at satisfying very specific demands. For Douglas Carnal, this is an argument in favor of promoting OS: ”In niche markets such as specialized health care applications software houses regularly fail and leave their customers in the lurch: and not everyone will have third-party escrow written into the contract. The Open Source model is obviously attractive for this reason” [5]. Nevertheless, very precise and specific demands are not necessarily the more interesting and challenging for developers. In fact, the software development in the health sector are perceived by developers as boring and not very stimulating; because it mostly consists in trivial coding activities. Secondly, health care software systems also require a very large and heavy monitoring as they ”… operate large, complex and 24’h nonstop operations, face heavy and changing regulatory burdens, and have heavy implementation and support requirements” [9] – thus, this makes the maintenance operations very stressful [6]. Thirdly, because data managed by eHealth solutions are important, sensitive and request protection, developers and citizens critics are more or less similar to those addressed to the voting machines in our democracies. Any developer mistake in the area of health care has consequences which could be dramatic. And fourthly, political responses to security and quality problems was the establishment of strict standards and certifications which validate and authorize the deployment of the given solution. From a developers point of view, this certification process reduces the expression of freedom and creativity – which in turn impedes the incentives to OS development.
These four arguments remove much of the fun associated with intrinsically motivated software development. Nobody wants to work in conditions of intense stress for its own sake. Proper external rewards are required for this type of work to compensate missing intrinsic motivation.
Discussion
We have shown that, even if it has a lot of advantages, a number of sizable barriers exist when considering the development of OS solutions in the field of eHealth. This is a tricky and difficult situation because one of the main advantages of going open is the possibility to outsource some tasks like bugs reporting, documentation and translations writing, add-ons coding, etc. Among other benefits, there is the transparency of processes (because of the availability of code). The transparency leads to greater legitimacy of solutions – which is crucial, if not fundamental, if we speak about public initiatives.
Even if the benefits of OS development are not all met in the field of eHealth, it seems nevertheless interesting to consider it but taking into account barriers and try to overcome them by offering innovative solutions.
As stated in the subtitle of this paper, ”how to lower the barriers”, the first and more obvious problem is the wall between professional sectors. This barrier leads to a situation where we must either lower barriers or raise intrinsic motivation and awareness of software developers willing to implement eHealth solution. Among the possible solutions to achieve this goal, a number of them seem more relevant.
Implement a Participatory Design (PD) methodology [10]: the main idea behind the concept of PD is to actively involve all stakeholders in the design process to ensure that the product designed meets their needs and is usable for everyone. This often requires the creation of a hybrid zone between domain professionals and developers, where the creativity and ideas can be expressed and shared in the most efficient way possible.
Develop community of practices (CoP): another solution is to develop a hybrid CoP [13] composed by physicians and developers – through which professionals will get to know their own practices and develop communication that will foster incentives to collaboration. Make each domain more accessible and understandable for each profession is a big challenge. It is also conceivable that the birth of a community of practices could lead to the sponsoring of the community to the development of OS solutions for eHealth.
Decrease the difficulty of the programming activity: an alternative to the integration of actual developers, is the presence of physician developers – which consequently could be interested in developing software for their own use. However, very few doctors have advanced skills in software development. Hence, making programming easier by creating frameworks that can automate and facilitate the development of applications for the eHealth sector can be an extremely reliable solution.
References
[1] J.G. Anderson. Social, ethical and legal barriers to e-health. International journal of medical informatics, 76(5):480–483, 2007.
[2] R. Anderson. Security in open versus closed systems–the dance of Boltzmann, Coase and Moore. Proceedings of the Open Source Software: Economics, Law, and Policy Confocuce, June, pages 20–21, 2002.
[3] B. Behlendorf and S. Bradner. Open Sources: Voices from the Open Source revolution. Open Source: Voices from the Open Source Revolution, O’Reilly, 1st Edition January, pages 1–56592, 1999.
[4] L. Boltanski and L. Thévenot. De la justification: les Économies de la grandeur. Gallimard Paris, 1991.
[5] D. Carnall. Open Source software in healthcare. Informatics review, 2000.
[6] J. Henriksen, J.G. Bellika, C. Gurrin, and G. Hartvigsen. Open Source software, the future of medical imaging? 2006.
[7] G. Hertel, S. Niedner, and S. Herrmann. Motivation of software developers in Open Source projects: an Internet-based survey of contributors to the Linux kernel. Research policy, 32(7):1159–1177, 2003.
[8] K. Lakhani and R.G. Wolf. Why hackers do what they do: Understanding motivation and effort in free/Open Source software projects.
[9] C.J. McDonald, G. Schadow, M. Barnes, P. Dexter, J.M. Overhage, B. Mamlin, and J.M. McCoy. Open Source software in medical informatics–why, how and what. International journal of medical informatics, 69(2-3):175–184, 2003.
[10] M.J. Muller. Participatory design: the third space in HCI. Human-Computer Interaction: Development Process, page 165, 2009.
[11] E.S. Raymond. The cathedral and the bazaar: musings on Linux and Open Sources by an accidental revolutionary. O’Reilly & Associates, Inc. Sebastopol, CA, USA, 2001.
[12] M. Shaikh and T. Cornford. Managerial strategies for open-sourcing innovation. 2009.
[13] E. Wenger. Communities of practice and social learning systems. Organization, 7(2):225, 2000.
