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.

This tool — which is the little sister of Mesydel — helps researchers to deal with and analyse corpus of text. It can be categorise as a CAQDAS tools.

Computer Assisted/Aided Qualitative Data Analysis Software (CAQDAS) is the use of computer software to aid qualitative research such as transcription analysis, coding and text interpretation, recursive abstraction, content analysis, discourse analysis, etc.

CAQDAS is used in psychology, marketing research, ethnography, and other social sciences.

Link to Mosaïqs. (some screenshots will be released soon)

If you want to install XAMPP (a great webserver) on your AppleTV and you don’t have enough space on your /dev/disk0s3, you can alternatively install it in your /Users/frontrow/Applications folder with the command :

tar -xvzpf xampp-macosx-0.7.4.tar.gz -C /Users/frontrow/

instead of :

tar -xvzpf xampp-macosx-0.7.4.tar.gz -C /

Finally you will need to create a symlink in /Applications/ with this command line :

sudo ln -s /Users/frontrow/Applications/xampp /Applications/xampp

It works great and helps you to save space on /dev/disk0s3.

It was, initially, the concept of tool, which posed problems. From the point of view of a computer scientist, a tool, is a software. From the pedagogue point of view, it is less simpler. It could be a software (within the meaning of technology), if we speak about software dedicated to e-learning for example, but it is also a pedagogical instrument. Thus the term, in the sense of pedagogical tool, can be used for naming the syllabus of a course, such as those of bibliographical references, or about the simple concepts.

As one can imagine, this quickly led to a situation wherein each person starts thinking that his comprehension of the concept is the same as what others have come to understand, or worse, that they are convinced that its meaning is somehow already imbedded in its translation.

After being confronted with these issues, we have concluded that sharing a common reference frame will be one of the subjacent objectives of the research project. In the particular case of the concept of tool, the solution adopted after numerous discussions on the subject, was to keep only the tool term for more generic concepts, and later on replace it with words that can clearly signify their functionalities / properties / services depending on whether there is a need for deeper discussion. The first obstacle was crossed, and until today, it has helped us in producing project reports, which proved to be beneficial in building relationships between partners.

Later on, however, it was the concept of scenario that eventually posed problems on mutual comprehension in a way that was more evident and challenging.

Concept of scenario

A scenario, in the common language indicates, “an unfolding of planned or envisaged events”. The term covers several meanings. We can speak about scenario in the sense of forecast, of projection or prospective evaluation, as well as in cinematography, theater, and romance – and why not in teaching. The arguments for creating scenarios are also varied : while meteorologists
refer to charts taken by satellites in order to make empirical projections, certain data developer make UML in order to create scenarios for the use of their tools (sic). However, this does not tell us which way these various methods of doing do can be compatible, opposed, concurrent, or parallel. Thus we have a need to be more concrete.

If we consider a simple technical device, like this slide for child (picture), and that we decide to work above in order to work out a scenario. Several options are possible according to the point of view from which we are placing ourselves:

• An engineer/developer would explain that this device makes it possible for a human being with two fully functional legs to climb the steps (built from material that is able to support a maximum weight of 60 kilograms) in order to reach sufficient height and get inertia necessary for the body to go down on the smooth board.
• A specialist in sciences and technologies studies will look closely at the action of the involved agents (may they be human or not-human) in order to study their limits as well as the artefactual constraints. In any case, he will not be allowed to blame the technical device, and even less the ontology of the human actors. His vision, contrary to that of the engineer, will be exclusively descriptive (at best, he will be able to make prospective evaluations).
• As for the pedagogue, he will have an opposite starting point. Whereas the engineer develops a technical device according to a succession of imagined actions; the pedagogue, on the other hand, reflects in term of actions only if these have a purpose other than merely the actions themselves. Thus, a teaching scenario will not take into account the use of the technical device in itself but focuses more at the outcome of it, which in itself already exceeds the activity of use. The psychomotrician will consider the slide as a device that allows the infant to pay close attention to of his movements and his weight so that he becomes more aware of his physical capacities as well as his limitations.

The question that needs to be asked, involves finding out whether the engineer / developer needs the assistance of the pedagogue in order to make the slide functional, and so equally if the pedagogue should also know the technical engineering of the developer in order for him to successfully work out related scenarios of training. The answer to this question is obviously yes, if not, a project like PALETTE would not have come into existence. But it is a matter of knowing where and at which time the intersection between the points of view must occur. We can imagine, at the very least, three contrasted situations:

• Either we consider that it is necessary that the technical devices are developed and completed so that the pedagogue will be allowed to eventually be included in the process, but only near or at the end. One thus asks for to the engineer ideal ways to use their tools and the pedagogue then assumes the responsibility of building teaching scenarios around the preset ideal scenarios by the developers. In this case, the role of the pedagogue possibly consists of giving some recommendations to the developers at the end of the process (on ergonomic or accessibility aspects).
• Or, we consider that creating the design progresses in such a way that there is equal respect for the technical requirements as well as the teaching ones. The work then will be done by co-construction with permanent feedback between the various actors. In this case of figure, we speak about methodology using agile development or in spiral. One will then understand that these are the tendencies, which have the most success (at least at the point of view of project’s director).
• On the last assumption, the engineers will need the recommendations of the pedagogues from the beginning, before the very first step. This presupposes that the pedagogues already have ideal scenarios for the training beforehand and have thought of the very precise ideas on the way in which these must be later on conceived.

Until now, I have not found a solution to these problems. The only conclusion that I can draw is that it appears inconceivable to me that by approaching scenarios from two divergent points of view (that are those of the engineers and those of the pedagogues), we will arrive at a point of conciliation.