Introduction

EHR has become a trend in reaching cost efficiency and better healthcare systems among industrialized countries [1]. However, most countries adopted proprietary EHRs - as opposed to Open Source (OS) EHRs - and are dissatisfied with costs and interoperability associated with these systems [2]. This situation makes OSS become an attractive alternative for health care organizations.

The Japanese Medical Association (JMA) estimated an unaffordable cost, US $180 billion for EHR implementation in the whole health system over a 10-year period. To diminish this cost, implementing OS software (OSS) is recommended [3]. However, OSS high failure rate raises concerns about its sustainability [4]. Thus, strengthening OSS projects sustainability is paramount for both contributors and organizations using these systems, including health care organizations.

Remembering that the OSS governance affects its sustainability [5], this study reports on the governance and sustainability of OpenDolphin, an OS EHR developed in Japan: GitHub:https://github.com/dolphin-dev/OpenDolphin; screen shot (Fig. 1).

Fig. 1
figure 1

OpenDolphin Interface

Full size image

This research addresses two questions: (1) how the OpenDolphin EHR governance evolves over time; (2) how the governance enables or constrains OpenDolphin EHR sustainability.

Conceptual background

We use an initial framework (see Fig. 2) that integrates concepts from OSS literature. These concepts were selected based on their “insightfulness” to the empirical materials we collected. Their relevance was challenged on the ground of our growing understanding of OpenDolphin’s story. The relevance of these concepts was challenged over the process of collecting and analyzing field data, in accordance with our interpretive position [6, 7]. The three key concepts we retained are: underlying dimensions of OSS project governance [8], OSS sustainability definition [9], and a stage model of OSS project governance [10]. According to the framework, there are three types of OSS governance, through which an OSS project can evolve over time; each of which can be described in depth from four dimensions. Finally, the sustainability of the project is the result of activities related to the governance of the project under the influence of both the general and the specific contexts of the OSS project.

Fig. 2
figure 2

Initial Research Framework

Full size image

General context of healthcare in Japan

Like all OECD countries, Japan has a universal health insurance regime. Compared to other OECD countries, in 2016 [11], Japan dedicates 10.9% of its GDP on healthcare and spends $4519 US per capita; slightly above the OECD average of 9.0% and $4003.

Over the past decades, the Japanese healthcare system has been cost efficient with significant progress in life expectancy, infant mortality, and eradication of communicable diseases [12]. Moreover, promoting HIT (Health Information Technology) is one of the pivotal measures in the growth strategy of the current Government, known as “Abenomics” [13, 14] .

Specific context of medical Technology in Japan

To deal with countrywide EHR diffusion, the JMA chose OSS as their “infostructure” in 2000, and released the ORCA (Online Receipt Computer Advanced - a claim system created by JMA - It is interfaced with OpenDoplphin and had over 15,000 users) [3].

Because of the high cost associated with EHR, the adoption rate in Japan is still low. In 2014, the adoption rate was about 32.2% for hospitals in general and 35% for clinics [15]. However, a slight increase has been observed in subsequent years. In 2017, the adoption rate was 46.7% for hospitals and 41.6% for clinics [16]. Of note is the fact that this rate is higher when considering only newly opened clinics [17]. Nonetheless, the adoption rate is higher in other OECD countries such as the US (87% in 2015) [18, 19] and Canada (between 87% and 62%, depending on the provinces in 2014) [18, 19]. In all the statistics adoption is treated as a dichotomous variable measuring EHR adoption or not whatever the functional scope.

Methods

Following Walsham recommendations [20], we used the research framework to guide data collection and analysis. Data analysis was started as soon as the data collection began. In accordance with our interpretive stance, our attempt was to understand the governance of OpenDolphin EHR from the perspective of the actors involved in the project through the meanings that they assigned to it, and we tried to interpret these meanings in context [21, 22].

After the Japan government approved the electronic storage of medical records in April 1999, the Dolphin project was crafted to sustain its objective of about 60% of EHR diffusion in Japan within 5 years [23]. Today, the main OpenDolphin development contributor is OSCorp (a fictitious pseudonym) - a for-profit organization. In 2019, it was used by over 560 clinics and hospitals in Japan. OpenDolphin projects have several forks. A fork is a copy of a repository that is independent from the original OSS project. This study focused on the two most widely used versions, the OpenDolphin and OpenDolphi Pro created by OSCorp.

In order to reach an appropriate level of internal validity, we relied on six sources of evidence: semi-structured interviews, written documents related to the OpenDolphin project, a short questionnaire, a focus group, researchers’ field notes, and the attendance of the 2017 ORCA annual conference in Tokyo by all three researchers. In total, seven individual semi-structured interviews were conducted including two with medical doctors who use OpenDolphin and contribute to software programming. A focus group was conducted with three informants at OSCorp’s premises. We used the same interview guide for individual interview and for the focus group. The themes of the interview guide were based on our initial conceptual framework, and included questions to identify actors that were involved in the projects and their roles, enablers, constraints, key events, and the evolution and dimensions of governance, from the inception of the project to July 2017.

As indicated by Table 1, most respondents (5 out of 7) played more than one role in the OpenDolphin project. In the same manner, the large majority (5 out of 7) has over 10 years of professional experience in one of the following three domains: OpenDolphin project, Open source software and Health Informatics.

Table 1 Informants Characteristics
Full size table

As stated earlier, the concepts included in the framework were challenged over this process of data collection and analysis. More specifically, data analysis was conducted in an iterative manner following the fundamental principle of the hermeneutic cycle, the principle of contextualization, and the principle of abstraction and generalization [21]. More concretely, transcribed detailed informants’ statements were first read and read again several times to familiarize the researchers with the data. During this process, actual interpretations were challenged through discussions between the researchers. We followed several iterations, critically reflected during discussions on the social and historical background of the project by applying the principle of contextualization [21]. We then managed to reach a deep-seated understanding of the social and historical context of the OpenDolphin project while identifying the following elements: sequence in time, focal actors, frame of reference (desirable project outcomes), and other contextual indicators [24]. Hence, it was possible to make sense of detailed informants’ statements reorganized through critical moments and activities of the OpenDolphin project spanning over a 16-year period between 2001 and 2017.

Finally, we applied the principle of abstraction and generalization [21]. Using theoretical concepts (dimensions and evolution stages of governance) as vehicles to derive abstraction and generalization, we were able to relate detailed informants’ statements to theoretical concepts through an iterative process of hermeneutic cycle by moving back and forth between informants’ statements and theoretical concepts and also moving back and forth within theoretical concepts as well as within informants’ statements. Of note is the fact that the need to add the concepts of “business model”, “motor” and “entrepreneurial responsibilities” emerged only at this stage. All the data analysis was done manually.

Results

In order to satisfy our willingness to stick to the data, three concepts are added to the final research framework (Fig. 3): business model, motor of change, and entrepreneurial responsibilities. All new concepts appear in bold in the figure. First, because there is not yet a consensus on OSS business models we adopted two categorizations suggested by Watson, Boudreau, York, Greiner and Wynn [25] and Perr, Appleyard, and Sullivan [26]. Watson et al. [25] is one of the most cited categorization in the literature. They distinguish four different business models of OSS production or distribution: (1) open community model relies on volunteers with limited commercial interests in software development and support. Examples of such OSS project include Scikit-image, a collection of algorithms for image processing which is a peer-reviewed code, written in Python by an active community of volunteers [27], and The OWASP Zed Attack Proxy (ZAP), one of the world’s most famous free security tools, that is actively maintained by a crowd of international volunteers [28]; (2) corporate distribution model takes advantage of quality products developed by open community models, “improving distribution methods for these products, and providing complementary services in order to make these OSS products more accessible to a broader market.” [25p. 42]. Examples of such models include RedHat and SpikeSource; (3) sponsored OSS model supported by corporations or foundations or both, like Apache Web Server with Apache Foundation and Eclipse with IBM; (4) second-generation model, also known as professional open source, is a hybrid between corporate distribution and sponsored OSS. Actually second generation firms “typically own or tightly control the software code and can exploit their intimate knowledge of the code to provide higher-quality service than could potentially competing service providers” [25, p. 43]. Examples of such OSS projects include MySQL and JBoss.

Fig. 3
figure 3

Evolution of the Governance of OpenDolphin EHR

Full size image

Perr et al. [26] identify seven business models, but only the first four are presented here: (1) professional services/consulting model where revenue is generated from professional services, training, consulting or customization of the open source software. Examples of companies who adopted this model include JBoss, Compiere, MySQI ; (2) support model for which revenue is generated from sale of customer support contracts. Examples of companies who adopted this model include JBoss and Compiere; (3) subscription model were revenue derived from annual service agreements bundling OSS, customer support and certified software updates delivered via the internet. Examples of companies with this model include Red Hat, SpikeSource and JBoss; (4) dual license model where the vendor licenses software under different licenses (free ‘public’ or ‘community’ license vs. paid ‘commercial’ license) based on customer intent to redistribute. Examples of companies with this model include MySQL and Berkeley DB (BDB) which is a software library created to offer a high-performance embedded database for key/value data. It seems important to note that the corporate distribution and the sponsored OSS models suggested by Watson, Boudreau, York, Greiner and Wynn [25] are similar to the professional services/consulting and the support models suggested by Perr et al. [26] respectively whereas the dual license model is similar to the second generation model. According to Perr et al. [26] a great number of firms are following either blended business models or multiple models at the same time.

Second, we selected Van de Ven and Pool [29] concept of motor of change because it is the most used concept for explaining the dynamics of change. They identified four conceptual motors of change that operate at different levels, and can be used to explain the move of an organization from one state to another: life cycle, teleological, dialectic and evolutionist.

The remainder of this section is structured along different stages of the evolution of the governance model of an OSS project and the four dimensions describing the concept of governance of an OSS project.

Although the model proposed by de Laat [10] was insightful, our data revealed that the OpenDolphin governance model went through two out of the three phases.

Phases 1 and 2: Spontaneous and internal governance

The OpenDolphin project began in 2001, following a tender from the Japan Ministry of Economy, Trade and Industry (METI) and targeting regional medical associations.

The tender was awarded to the “Dolphin project” led by three universities (Miyazaki, Kumamoto, Kyoto) and one regional medical association (Tokyo Medical Association) which received 60 million yen funding —about $570,000 US. This consortium won mainly because it adopted Medical Markup Language (MML) to facilitate the data exchange between EHRs whatever their locations. MML was created in Japan from research funded by the Japanese Ministry of Health, Labour and Welfare [30].

Vision and goals.

Primitively, the OpenDolphin project’s goal was to electronically emulate the user experience of the paper medical record at a low cost. Instead of simply achieving a high level of functional coverage, it aimed to emphasize simplicity and usability for a better user experience, and was envisioned to be compatible with different operating systems. A statement from Akyo (a fictitious pseudonym given to the main contributor of this initial project) illustrates the vision: we wanted to have “clinical user-oriented EHR with UX [user experience] resembling that of a notebook”.

Ownership of the assets.

The ownership of the assets was sealed by the grant awarded by the METI, which requires the research outputs and the software to comply with a Bayh-Dole Act-like regulation adopted by Japan in 1999 [31]. The Bayh-Dole Act is a US legislation enacted in 1980 and cosponsored by Senators Birch Bayh and Robert Dole. It allows universities, nonprofit research institutions, and small businesses to own patents, and market any inventions resulting from federally funded research within their organizations [32]. Hence, the GNU General Public License (GPL) version 2 was the de facto choice.

Software development processes.

In 2000, the project started with a six-month requirements specification phase followed by a one-year software development phase with two full-time developers, Akyo and a junior software engineer. Six months later, the junior software engineer left and Akyo handled the software development alone. In 2001, the software was delivered to the research team and then was released to the public. The guiding principle of this OpenDolphin development was “DIY (Do It Yourself)”, based on Akyo’s beliefs, “there are various doctors with different needs, so the project needs to work as a platform on which DIY solutions to the needs not answered by the project as-is can be created”.

Community management, leadership, and finance.

During the first phase, Akyo was the only contributor. Despite its newness and the absence of a community of users and developers, 23 clinics adopted it. Although the pricing for its services was entirely Akyo’s discretion, the revenue was not enough to sustain Akyo as a professional software developer. Hence, he started something else unrelated to IT to supplement his income. Meanwhile, four medical doctor users started to contribute at a very high level of expertise including the development of new functionalities for OpenDolphin EHR.

Use of information and tools.

The following tools were used: Repository: GitHub (dolphin-dev/OpenDolphin); Development tools: NetBeans, SourceTree, SublimeText, TeraTerms, BitBucket (only for certain parts of the software).

Without a team to manage users’ questions, Akyo was the only one providing answers and the communication tools used were Twitter and email.

Technologies and translation language.

The selection of technologies was guided by interoperability, freedom, and low cost. Hence, the following technologies were selected: database (PostgreSQL), development language (Java), application server platform Wildfly (JBOSS), and client application (Apache MAVEN for XML). At this moment, OpenDolphin was available only in Japanese.

During this stage, the OpenDolphin project accomplished some achievements that confirmed its position as a promising OS EHR: (1) successful connection with ORCA system in 2001; (2) release of a MacOS version in 2006; (3) launch of an ASP service in 2007; (4) establishment of compatibility with the iPhone and the iPodTouch in 2009.

Phase 3: External governance

In 2009, OSCorp, one of its support providers, suggested cooperating with Akyo for “scaling up the OpenDolphin services”. Thus, Akyo joined OSCorp and the OpenDolphin project departed from the community-managed governance model. OSCorp brought in new initiatives to develop and sustain the OpenDolphin project.

Vision and goals.

OSCorp is planning to create a EHR with a combined hospital management system (HMS). According to Akyo, historically, HMS has been the foundation upon which the EHR system is installed. OSCorp approached it in the opposite way, having EHR as the foundation, and implementing HMS functionality on top of it.

Ownership of the assets.

The license was moved from GNU General Public License (GPL) version 2 to GPL version 3. To develop its business, OSCorp created a new commercial version of OpenDolphin named OpenDolphinPro that is also distributed under GNU GPL license and packaged with services provided by OSCorp.

Software development processes.

Since OSCorp participated directly, the software development team increased to eight, four (4) internal developers within OSCorp and four (4) medical doctor users contributing actively at a very high level of expertise.

To improve the OpenDolphin project sustainability, JBoss AS (Application Server) 6 is replaced with JBoss AS 7, known as WildFly, a completely rewritten server which is faster and easier to configure. To reduce the risk related to this technological transition, OSCorp has partnered with RedHat Corporation in Japan in order to use their deployment methods and development environments as references. Additionally, the development process has become more efficient, as OSCorp manager stated: “We are employing an agile development method where the project manager goes through the details of every request, and uses them to assign required members to do the development. Because of this, we do a much faster implementation than development based on the waterfall model”. Agile development method is “a set of software development methods in which requirements and solutions evolve through collaboration between self-organizing and cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to changes” ([33], p. 2).

Moreover, there is a dedicated customer support division to collect users’ requests. Those requests and resolutions are passed to the development division to implement new functionalities in OpenDolphinPro as minor updates. Thereafter, these functionalities are integrated into the regular OpenDolphin version.

The OSCorp team stated that “having the software always up to date is ideal. However given that OpenDolphin differs from web applications [in the sense that clinics have source code updated at different levels], there is a need to consider the special circumstances that each clinic has”. To properly manage this situation, the customer support division decides if a clinic needs to update its software based on assessing each clinic’s environment and structure.

Community management, leadership, and finance.

The community at this stage has increased to 27 resellers nationwide. From 2009 to 2016, one sales executive was selling at a rate of 30–40 clinics per year through directly visiting the targeted clinics and sometimes 50 clinics a year. Unfortunately, since this sales executive left, OSCorp has been struggling to attract new clients. The management decides to change how they deal with their main market segment formed by medical clinics, and emphasize the OpenDolphin cloud and digital marketing to attract more users. The sales target of the cloud version is about 100 per year.

At this stage, OSCorp is just above the break-even point and the management is taking various initiatives to increase profitability. The break-even point is reached when a company’s total costs equal its total revenue.

To increase its community size, OSCorp has realized the need of partnerships with various actors. One of the initiatives is to connect with the Medical Open Source Software (MOSS) meeting that is organized twice a year in Japan and brings together medical informatics experts, advocates, and supporters.

Use of information, communication, and tools.

The tools used at this stage are the same as the previous stage. Repository: GitHub; Development tools: NetBeans, SourceTree, SublimeText, TeraTerms. Whereas the OpenDolphin version is managed on GitHub, the OpenDolphinPro is managed on OSCorp infrastructures .

All outward communications with medical clinics are managed using the company e-mail or a remote desktop software. Within the OS-Service Corp, communications are managed using the company e-mail, Redmine, and Slack. Redmine is a free and open source web-based software for project management and issues tracking, whereas Slack is a proprietary set of team collaboration tools and a cloud-based service.

Technologies and language development.

OpenDolphin was written with Java but the client is being rewritten in JavaScript. This is because JavaScript is primarily a client-side scripting language designed to run in the internet browser without having to be compiled as is the case with Java. Additionally, artificial intelligence (AI) technology is planned to be added in OpenDolphin. Concerning language translation, OS-Service Corp is planning to develop an English version of the software so as to move into the international market and extend its market reach.

The OpenDolphin project made some achievements that confirmed its position as a promising EHR: (1) the release of a comprehensive documentation named OpenDolphin Perfect Guide in 2016; (2) the release of three iOS apps (DolphinPro, VisitTouch, Super EHRTouch); (3) the launch of authentication based on SSO (Single Sign On); (4) the establishment of compatibility with iPads in 2010; (5) obtaining the status of certified partner solution for IBM Japan in 2011; (6 ) the completion of connection between Orca and OpenDolphin cloud solution in 2013; (7 ) the celebration of the 10th anniversary OpenDolphin cloud ZERO (pay-as-you-go system) in 2014.

Among the most important achievements is the fact that, even if OpenDolphin EHR was at first targeting medical clinics, it has successfully expanded its market share to small hospitals (e.g. a rehabilitation-oriented hospital in Gifu Prefecture; a hospital doing dialysis; a home-nursing care clinic with 30 medical doctors).

Discussion

OSS is a growing phenomenon with a promising potential in the medical informatics field. Nonetheless, scholars have expressed extensive concerns about its sustainability [4, 34]. First, our data reveals that the stage model provided by de Laat [10] as well as the dimensions suggested by Markus [8] are relevant and helpful in understanding the evolution of the governance of OSS project.

Going back to the literature on OSS project governance we found Jensen, Scacchi [35] suggesting that OSS project governance issues can be analyzed at three levels: micro (individual participants; issues related to individual actions and resources, artifacts and resources as objects of interaction), meso (project team; issues related to collaboration, leadership, control, conflict resolution), and macro (inter-project ecosystem; issues related to coordination, leadership, control, conflict resolution). Interestingly, our data revealed that none of these themes emerged as a real issue for the governance of OpenDelphin project during the stage of “spontaneous governance”. The only issue that the project leader worried about was economic in nature. For their part, Poba-Nzaou and Uwizeyemungu [34] suggest four factors that are the most worrisome to OSS contributors because of their potential impacts on OSS project sustainability: software quality, attraction and retention of contributors and users, inside and outside communication, entrepreneurial responsibilities. Our data analysis revealed that “attraction and retention of contributors and users” as well as “entrepreneurial responsibilities” were major issues during the spontaneous governance stage of the OpenDolphin project.

Now, contrary to our initial framework, the “spontaneous governance” stage can be difficult to disentangle from the “internal governance” stage. This result is somewhat surprising because Poba-Nzaou et al. [36], who empirically investigated the evolution of the governance of an open source EHR in Canada over a 14-year period, found that the two stages were clearly separable. This contrast raises an obvious question: why the difference? Although it is not possible to associate this difference with any given factor with certainty, we can nevertheless make some conclusive arguments. According to De Noni et al. [37], the transition from spontaneous to internal governance stage is triggered by the growth in the size of the community. Since the community hadn’t really grown, this argument does not apply to OpenDolphin project. In addition, we contend that another explanation lies in the presence or absence of an instance of a motor of change, as defined by Van de Ven and Pool [29]. More specifically, in the case of OS EHR reported by Poba-Nzaou et al. [36], there was at least one instance of a motor of change that caused the EHR project to move from the stage of spontaneous to internal governance. In other words, an instance of the dialectic motor of change. In fact, the move was the result of “confrontation between opposing forces” arising from divergences within the EHR project ([29, p. 514]. However, our data analysis reveals that there was no instance of a motor of change that would have moved the OpenDolphin project from the first to the second stage.

Second, before Akyo received OSCorp’s offer, he had already noticed the ineffectiveness of its governance model, although the main concern during that time was the inefficiency of the business model. Actually, our data analysis reveals two main findings in that respect. When relating Akyo’s concerns to the dimension of “vision and goals” included in our initial framework, we find out that these concerns are broader in terms of their scope. They are better conveyed by the concept of “entrepreneurial responsibilities”, that is worries related to fundraising and leadership as well as legal issues, suggested by Poba-Nzaou and Uwizeyemungu [34]. For OpenDolphin project, the deal with OS-Service Corp had an impact that went beyond the business model and de facto induced new governance arrangements. At first glance, we concur with De Noni et al. [37] in asserting that the transition from spontaneous to external governance has been triggered by the growth of the number of external participants (from 0 to 1). However, the use of Van de Ven and Poole [29] framework suggests an alternative explanation. Following the last authors, we contend that the transition from spontaneous to external governance was triggered by an evolutionary motor of change. In fact, this move can be understood as the result of probabilistic sequence of variation, selection, and retention events in the broad population of EHR projects; the logic is natural selection among competitors and the metaphor that describes the move is “competitive survival”.

The analysis also reveals a high degree of dependency between the business model and the governance model. It also reveals that, during the first phase, OpenDolphin was a technological success but not an economic success. Of note is the fact that, during the first phase of governance, the community of software developers has never really grown beyond Akyo. One possible explanation may be the fact that few initiatives have been undertaken to attract contributors. The arrival of OS-Service Corp brought the needed resources to sustain the technological success and convert it to an economic success. Our data reveals that the involvement of OS-Service Corp has altered the “business model” of the OpenDolphin project, moving it from “open community” to “corporate distribution” as explained below.

At the beginning of the third phase, OpenDolphin has experienced a rapid growth by attracting a large number of clinics each year (30–40 per year through clinic visits). However, since the departure of the sales executive who was in charge of sales, OpenDolphin growth has been stagnant, despite sales activities being managed by OS-Service management. Even if this stagnation can be partially attributed to the departure of the sale executive, OS-Service management feels the need to make some changes in the way they deal with their main market segment formed by medical clinics. In fact, OpenDolphin’s situation is surprising for at least five reasons: (1) the OpenDolphin EHR is appreciated by its users, medical doctors (2) the market has a great growth potential due to the low EHR adoption rate by Japan medical clinics (about 40%) (3) the EHR adoption rate by newly opened clinics is higher (4) the JMA has chosen open source as their “infostructure” in 2000 and released ORCA, which has created a fertile ground for OS to expand in primary care organizations (5) since OpenDolphin project was led by regional medical associations, it has a certain level of proximity to the Japan medical field.

Knowing that the cost is one of the main barriers to EHR adoption by small hospitals and clinics, a local market characteristic may explain why OpenDolphin, a low-cost product that meets the needs of medical clinics, is struggling to attract new users. In Japan, a consultant on behalf of a medical doctor usually handles the process of opening a new clinic. Since consultants’ fees are calculated by the percentage of the project’s total cost, consultants might not recommend the low cost OpenDolphin. This structural situation echoes one of the most important barriers to the adoption of open source mission critical application, such as an EHR, underscored in previous research [Ex. 38]: “Disadvantageous tender/procurement processes vis-à-vis mission critical OSS”.

As stated earlier, during the third phase, due to the sales executive’s departure, the market growth has been stagnant. To sell faster, OSCorp decides to promote the OpenDolphin cloud version and favour a digital sales strategy. The initiatives undertaken may substantially alter the governance and the business model, hence, the question is whether there are other governance models and business models for OpenDolphin. When contrasting OpenDolphin characteristics with the eight open source business models defined below, OpenDolphin goes through two of them (the community model and corporate distribution model) [25]. However, the categorization suggested by Perr et al. [26] allows to recognize one of the models as a community model. However, the corporate distribution model doesn't match any of the models defined by Perr, Appleyard, and Sullivan [26].

In addition, the second generation as well as the dual license models do not apply to OpenDolphin because of the characteristics of the GPL license. Hence, within our theoretical background, the only remaining option is the sponsored model. If OpenDolphin becomes a corporate-sponsored or non-profit foundation sponsored project, OSCorp maybe a corporate sponsor or associated with a foundation. Both options will allow OSCorp to share new functionality development and marketing costs. In particular, the foundation option may attract more contributors and partners and foster the development of an ecosystem as in the case of Linux Foundation. Again, the use of the categorization of issues suggested by Jensen, Scacchi [35] is not really illuminating to the understanding of OpenDolphin governance and sustainability. However, the categories of four worries suggested by Poba-Nzaou and Uwizeyemungu [34] is once again illuminating. In fact, after a period of sustained growth, OpenDolphin was once again faced with the same major issues: “attraction and retention of contributors and users” and “entrepreneurial responsibilities”.

Overall, the governance of the OpenDolphin project has evolved so as to strengthen its sustainability. However, it’s not easy for OSCorp to handle all the challenges in this third stage of the evolution of its governance arrangement. Going back to our research question, the study confirms that the arrangement or orchestration of the governance of the OSS project actually constrains or enables its sustainability overtime. A deeper analysis of this case reveals that this constraining or enabling effect is actually mediated by the business model. This finding is consistent with Chesbrough and Rosenbloom [39], who contend that the business model in innovation projects such as open source projects, acts as a mediator between technical and economic domains. In other words, the mismatch between the technological (OpenDolphin EHR project is successful from a technological point of view) and the economic (OpenDolphin EHR project is a semi-success from an economic point of view) dimensions of the OpenDolphin EHR project can be understood via the scrutiny of its business model. Our analysis reveals that environmental factors that are beyond the control of the main stakeholders may also be at play – for instance, the method of calculating consultant fees in new clinic installation process. This finding implies that a complete understanding of the constraining and enabling effects of the governance arrangement on the sustainability of the project, as well as the mediating role of the business model, requires a strong contextualization [40].

Returning one last time to the actual project under consideration, our study reveals that some elements are already set to be highlighted and combined in order to create an OpenDolphin ecosystem, including OSS experts, advocates, and supporters among both HIT decision makers and HIT policymakers, which will greatly enhance its sustainability: the connection with the Medical Open Source Software (MOSS) meeting, the partnerships with IBM Japan and with RedHat.

Conclusions

Organizations are fascinated by OSS, and want to jump on the bandwagon [10]. Although OSS represents a viable alternative to proprietary software, its sustainability is of great concern, because of the high failure rate. Our premise is that OS project sustainability relies on its governance. Through a single case study, the results indicate that governance arrangements do enable or constrain the OpenDolphin sustainability, and the business model also provides a broader understanding of OSS project sustainability through its mediating role.

This study is not exempt from limitations. First, some of our interview questions were related to past events. Even though we tried to control potential participants’ selective retrospective bias [41] with triangulation of data [42], our findings may have been affected. Second, given the qualitative method we adopted, our study involves naturalistic generalization, not statistical generalization [43]. Although more empirical work is needed to overcome the limitation of this single case study, our rich insights allow OpenDolphin stakeholders and primary care stakeholders at large, to assess the degree of resemblance between the present case study and those to which our findings may apply [44].