1. Introduction

Free and Open Source Software (FOSS) is also referred to as F/OSS, FOSS, or FLOSS to mean Free/Libre/Open Source Software. Throughout this paper, we prefer to use the term FOSS as a synonym for the others.

FOSS is a relative novelty within the context of developing countries in general and within their public health sector in particular. The key concept in FOSS is an unrestricted free access to software code, enabling the possibility to study, re-use, redistribute, rework, adapt or improve the programs without being dependent on commercial vendors. It represents a particular strategy to introduce Information and Communication Technologies (ICTs) in developing countries providing the potential to bridge the digital divide without license restriction ^{[1, 2, 3, 4]}. It has also potential benefit for African countries to advance their outsourcing industry ^[5]. The FOSS license facilitates acquisition of software avoiding “the often lengthy and hectic bureaucratic processes, negotiations and associated corruptions apparent in public sector organizations”[^[6] p.18] of developing countries. Moreover, there are various other mentioned potential technical advantages arising from issues of system security and interoperability. While FOSS is flexible to respond to the continuous change in organizations, proprietary software are rigid for change ^[7] once public sectors take ownership of the software. However, realizing these advantages in practice is fraught with various challenges, including those that arise from institutional conditions and capacity, which often tend to favor proprietary software ^{[8, 9]}.

Given that FOSS applications, especially in the contexts of the public health sector in developing countries are in its infancy and surrounded by uncertainty, there are various institutional factors that are used to either enable or constrain its adoption and use. For example, some opponents of FOSS may raise lack of support for FOSS as a basis to reject it in its entirety. The focus of this paper is on understanding how institutions influence decisions to adopt or not FOSS applications. We believe such a line of inquiry is a contribution to IS research in helping to theoretically unpack the institutional shaping of the processes to introduce FOSS. Practically, this analysis contributes to our understanding of the field level challenges in realizing the potential of FOSS for the benefits of public sector organizations in general and health sectors in particular in developing countries.

More specifically, by doing this study, we seek to contribute to the following two research aims:

•To theoretically understand the constraining and enabling institutions around the adoption of FOSS in public sectors.

•To explore strategies to adopt -FOSS- and seamlessly integrate it with the existing proprietary dominated health care systems through a case analysis involving two developing countries.

The empirical focus of this paper is on the processes surrounding the introduction of the same FOSS based Health Management Information System (known as DHIS2) in India/Kerala and in Ethiopia. While presence of formal institutional mechanisms and support for FOSS in Kerala, India contributed for the acceptance of the DHIS2, the absence of the same, we argue, in Ethiopia contributed to its rejection. This micro level study of the implementation processes is complemented with a broader study in both these countries on the general perceptions and attitudes of key stakeholders towards FOSS and proprietary based systems and by studying the regulative and education systems.

2. Analytical Framework

In order to formulate strategies for applying FOSS based computer systems as an alternative solution for public sectors in general and health organizations in particular, we frame our theoretical perspective around the theory of neo institutionalism. Neo institutionalism emphasizes the analysis of institutional change in addition to stability, with a focus on the role of cognitive-cultural institutions ^[10]. This perspective is relevant to this paper as we seek to analyze how various institutional mechanisms contribute to institutionalizing proprietary based technological solutions in a particular setting, and to investigate mechanisms to deinstitutionalize or loosen them for creating a “middle way” platform. By “middle way” platform, we mean an institutional environment where both proprietary and FOSS based systems are taken into consideration when choosing a technological solution for public sectors.

In IS studies, institutional theory has been used for analyzing and understanding the impact of institutional pressures on the diffusion of IT innovation, the institutionalization process of software applications and the interaction between IT artifact and existing institutions ^[11]. However, IS studies are criticized for giving little emphasis on the interplay between the micro and macro institutions ^[12]. Building on IS studies that used institutional theory for understanding the impact of institutional pressure on IT adoption, we seek to fill this research gap by undertaking a multi-level analysis both at the macro and micro level.

Institutions are rule-rule like frameworks that constrain or enable human actions ^{[10, 13]}. Institutions are mostly used in relation to stability, with quite few studies employing the notion to study changes (for the later cf. ^{[14, 15]}). In this study, we used the institutional pillars ^[10] as an analytical framework to unpack the various institutions that shape the adoption of FOSS in the two settings contributing to literature that intends to understand how to bring about change in highly institutionalized environment like the public sector. The analytical framework is discussed below.

We use the concept of institutional pillars (elements)-regulative, normative and cognitive-cultural ^[10] as an instrument to understand the various institutions that influenced FOSS adoption. Those are briefly discussed below.

Regulative institutions are those institutions that constrain and regularize behavior. They give importance to explicit regulatory processes such as rule setting, monitoring and sanctioning activities. Regulative Institutions are described as formal institutions as they are explicitly stated and there is a written point of reference in case of disagreement ^[13]. The primary mechanism of control is coercion and the expected response to regulative institutions is conformity ^[10] which gives a sense of I have to respond to coercive institutions ^[16]. The indicators for regulative institutions, as described in ^[10] are rules, laws and sanctions, which are used as an instrument for implementing and sustaining a technological solution or other practices.

As the name indicates, the chief concern of normative institutions is upholding values and norms. While values are related to the principles that are constructed to guide a certain behavior, norms specify how things should be to achieve defined goals and objectives. The mechanism for such systems is normative and the indicators are certifications and accreditation. While the underlying basis of legitimacy is moral governance, the basis for compiling to normative pressure is social or professional obligation. The logic for normative institutions is appropriateness ^[10]-as I ought to respond to normative pressures because it is morally right to do so ^[16].

The cultural-cognitive institutions emphasize the cognitive dimension of human existence that constitutes the nature of social reality and the frame through which meaning is constructed. While cognitive-cultural is about the construction of common meanings embedded in social routines, the normative gives relevance to social obligation and binding expectations, specified by standards or industry policies ^[17]. The behavioral reasoning towards change or continuing same institutional practice would be the feeling of I want to ^[16]. Although institutions are the byproducts of individuals’ cognitions, institutional studies have given little attention to the cognitive part of those individuals and how that influence change processes in organizations ^[18]. By exploring the perceptions of individuals towards FOSS, in this paper, we tried to understand how the surrounding institutions shaped their perceptions.

Previously, this analytical framework was used to study the adoption and diffusion of cross-cultural inter-organizational information systems for financial transaction ^[19]. The authors found out that the rate of IT innovation adoption in Europe was high because of the strong presence of the three institutional pillars in Europe than in Taiwan. In the same vein, in this study, we argue the interplay of these three to provide legitimacy for acceptance or rejection of FOSS. Therefore, there is a need to study these institutions within and outside the health sector for bringing about institutional change that is sought to facilitate FOSS adoption. Institutional change constitutes deinstitutionalization and re-institutionalization ^[20]. Deinstitutionalization “takes place when established meanings and action in an organization are discredited, either as a result of competing meanings and actions or because they are seen as failing to contribute to the institutional existence” [^[21] p.37]. Re-institutionalization represents an exit from one institutionalization and entry into another institutional form, organized around different principles or rules ^[20]. Political, functional and social pressures, both within and beyond organizations, are conditions for causing deinstitutionalization ^[22]. In addition, others suggest conflicting institutional logics during the introduction of IT in health public sector to stimulate change in institutions by providing room for understanding the pertinent institutions that hinder or facilitate the introduction ^[15].

Information systems research recommends a cultivation approach for deinstitutionalization. Cultivation is a concept, which is operationalized by implementers through sensitivity to the institutional environment, learning from past experiences ^[23], following a small step incremental change ^{[24, 25]} and understanding change as a process ^[26]. The cultivation approach requires the act of institutional entrepreneurs to identify constraining and enabling institutions so as to bring about change in a highly institutionalized environment. The notion of institutional entrepreneurs refers to “the activities of actors who have interest in particular institutional arrangements and who leverage resources to create new institutions or to transform existing ones” [^[27] p. 657]. Hence, institutional entrepreneurs are “those actors whom the responsibility for new or changed institutions is attributed” [^[28] p. 1]. Next, we will present the research approach.

3. Research Approach

This is a qualitative research with a primarily interpretive stance to help us understand the phenomena under study through the meanings that people ascribe to them ^{[29, 30, 31, 32, 33]}. It has also elements of critical stance. The central idea in critical perspective is that “everything possesses unfulfilled potentiality, and human beings by recognizing these possibilities, can act to change their material and social circumstances. And this potentiality for acting to change is constrained by prevailing economic, political and cultural dominations” [^[31] p.19]. Therefore, critical researchers argue that phenomenon cannot be understood just by asking participants as done within interpretivist traditions but also by being critical to existing status quo, which constrains the action of the human agency to bring about change ^[32]. Therefore, the researchers either initiate change as part of action research or they play role in highlighting the constraining and enabling factors for change initiators.

In IS, such studies “are aimed at producing and understanding the context of information system, and the process whereby the information system influences and is influenced by the context [^[29] p. 4-5]. We started the empirical work with the assumption that there exist social, cultural and political constructions of institutionalized perceptions around why certain technological solutions have evolved to become de facto standards. Replacing or changing them requires the active use of strategies for de-institutionalization of constructed shared assumptions and other institutions. By examining the national policies, strategies and human capacity, our intention was to explore the link between macro level institutions and organizational tendencies to adopt FOSS.

The case is built upon two sub cases from Ethiopia and India. We believed taking two cases provide rich insights into the various institutional constraints both at macro and micro-levels. At the macro-level, the two contexts provide a study of contrasts where India is known as software outsourcing destination, while Ethiopia is little known in this regard globally. Various states in India have been proactive with respect to policy pronouncements of FOSS while little movement in this regard is seen in Ethiopia. Thus, we felt that the different institutions in the two countries would be the source for varying perceptions with respect to FOSS and proprietary software, and thus with different implications for the micro level implementation efforts. At the micro-level, the focus was the attempts to introduce the same DHIS2 software within the framework of the Health Information Systems Project ^[34] in the two countries, ongoing nearly simultaneously. HISP is a global network, which has the main node in the University of Oslo and has been engaged in developing and implementing the DHIS2 mainly for developing countries to digitize the routine health data. The network constitutes organizations and individuals that have expertise in health, software development, and organizational issues. The main objective of the program is to make information generated during health care provision to be used for action and planning through the use of FOSS based IT solution. DHIS is a java based FOSS product, which is database and platform independent and have been used in more than 30^{1}countries including at the level of nongovernmental organizations.

Data were gathered through fieldworks within a focused period between April to August 2007 and throughout 2015. HISP was running in Ethiopia from 2003-2008 and the researchers participated in introducing the DHIS2 to in the health sector before and in response to the tender for national electronic health management information systems. In Kerala, we generated most of the data using interviews. We got in contact with relevant stakeholders through HISP India members who were working in this organization. Our role in HISP Kerela action research was closer to what would call an “outside observant” ^[35]. The first author is an active member of the HISP action research and has been involved in the recent pilot testing of the FOSS based DHIS2 in Ethiopia. This involvement generates observation data, which is used to explore the current software adoption in Ethiopian public health sector. The researcher was specifically involved in customization of the software. In this process, the researcher was able to examine how the stable software governance structure of HISP and the expanded use of DHIS2 in many organizations may have influenced its acceptance for pilot testing.

The second author was involved as an action researcher during the phase in which Ethiopia rejected DHIS2. The second author was also a teaching staff in one of the universities in Ethiopia, which enabled him access data regarding supportive structure for FOSS in the education sector. Documents analyses and email correspondences with relevant informants were also conducted to explore the shift of policy in both settings and its implication to FOSS adoption in health organizations.

Interview data and other secondary sources were used as data collection techniques. Data was primarily collected through semi-structured interviews, and supplemented through the study of a vast variety of secondary materials such as policy documents, tender announcements, university curriculum, company brochures, and other related materials. Interviews were conducted with respondents drawn from various sectors including FOSS advocates, academic institutions, software developers, health organizations, and concerned government ministries and users (see table below for a summary of our respondents). The rationale for the selection of these respondents was their importance in the shaping of stakeholder perceptions and capacity towards FOSS and proprietary systems. For example, meetings with university staff helped to understand the emphasis given to FOSS in the informatics curriculum, which was felt to be an important mechanism for shaping the views of students towards these new technologies. Similarly, discussions with private sector software developers helped us to understand the various business models employed by firms to promote FOSS and how those are compared with proprietary systems. Overall, understanding these broader views, we believed would provide us richer analytical insights into the micro-level dynamics of the DHIS2 introduction in the two settings. The following table depicts the representation of respondents in both countries.

Table 1. Number of Respondents in India and Ethiopia

Download as

PowerPoint Slide

Larger image(png format)

• Tables index

Veiw figure

View current table in a new window

View next table

In terms of operational details, interviews were mostly conducted on site, in the premises of the respondent. Typically, depending on time availability of the respondent, an interview would last from 30 minutes to 1 ½ hours. Both authors of this paper conducted interviews. Typically, the meeting started with us asking about the background of the respondents, their job responsibilities, their general views about FOSS/Proprietary software, and the respective challenges they have seen. The questions were deliberately kept open to enable the respondent talk freely about issues they considered relevant. However, with respect to the micro-level analysis, we were particularly focused around asking questions about the introduction of DHIS2, and what were the underlying reasons. This helped to interpret what kinds of perceptions were being brought into the discursive practices, and their role in legitimizing decisions. In both settings, the researchers asked questions and clarifications and extensive hand written notes were taken. The second author had re-written the notes in MS word; already making his own interpretations of the views of the interviewees, which was later, compared and complemented with the first author’s hand written notes.

Document analysis was done on various sources such as curriculums of universities, software evaluation criteria applied by the health care managers in the two countries with respect to software selections. For example, the curriculum of technology related studies in one of the public universities was examined to understand the emphasis given to FOSS. Observations were also conducted in the computer laboratories and firms to get a sense of the workplace dynamics in different setting such as private firms in Kerala and public health care setting in both the countries.

Data collection and analysis went hand-in-hand through an iterative process as two stages process of data constructions. Van Maanen (as cited in ^[35]) describes the two stage process involves first-order construction by the interviewees about the phenomenon and second-order data construction of the researcher based on the first-order construction and using conceptual approaches (p. 75). The first-order data were constructed from interview results. As briefly mentioned above the data analysis started while collecting data giving us possibilities to ask other respondents on areas we noticed more clarifications. A thick description (ibid.) of the case was constructed for each setting primarily from the interview data and they were supplemented by other sources. These first-order constructs were studied independently and together to find recurrent themes or issues and grasp the whole picture of the phenomenon. Then, the data from the two settings were merged and the researchers interpretively categorized them into macro and micro level issues; which was further categorized into “meaning units” ^[36]. “Meaning units” is described as “part of the data that even if standing out of context, would communicate sufficient information to provide a piece of meaning to the reader” [^[36] p. 153]. The case description was prepared using those meaning units by reducing redundancies and shortening the data into meaningful contracts of the researchers.

The second-order construction of data was performed, when the authors tried to make sense of the first-order data using concepts from institutional theory. Theories are used as sensitizing device so as we as researchers could expose the restrictive conditions of the status quo ^[37]. Meaning units from the previous constructs were categorized under the three institutional pillars and their implications to the adoption of DHIS2 were studied and analyzed. While doing this, we noticed that there was another institutional element, which could hinder and facilitate FOSS adoption. We recognized this fourth element as “technological element” and discussed and presented how these could be related to the adoption or rejection of DHIS2.

4. Case Description

The case study is structured in two main sections. The first section focuses on the macro level of the institutions we recognized to exist around FOSS and proprietary systems in the contexts of Ethiopia and Kerala respectively. The second section focuses on the micro-level, wherein we analyze the process of decision making around the introduction of the same FOSS application (DHIS2) in the respective health care settings in the two countries. In explicating this process, we seek to understand the kinds of institutional mechanisms that were drawn upon in taking and legitimizing decisions to reject the FOSS in one case, and how the same seemed to have been relatively deinstitutionalized in the other case.

In this section, we examine institutions related to policy, capacity and perception in the wider contextual settings of health care organizations in Kerala and Ethiopia.

In Ethiopia, the policy related institutions could be described as a “chicken and egg” situation where the lack of proactivity of the policy making body was attributed to the weak demand from the public sectors, who in turn felt they needed a policy framework in the first place to enable experimentation with these new technologies. The former Ethiopian Information and Communication Technology Development Agency (EICTDA), which was established in 2002, had the national mandate of formulating ICT policy, evaluating and monitoring ICT projects, developing frameworks for guiding the different public sectors including health. With respect to FOSS, a respondent in the agency said “in our current policies and future strategies there is nothing about OSS but this doesn’t mean that it cannot be modified.” In further discussing the issue, we understood that there was an implicit view that adequate demand has not yet come from the user departments for modification, creating this “chicken and egg” situation. Recently, this organization is restructured and named Ministry of Communication and Information Technology (MCIT), established in 2010 and have the same mandate as the former EICTDA. We found comforting slight appropriation of both FOSS and proprietary solutions as one of the strategies for e-government solutions in the national ICT policy document. It is described as “adopt and implement an open policy for use of proprietary, free and/open source software systems in developing e-government solutions” (MCIT, 2009).

Potentially, in Ethiopia, there could be other actors in the future who could influence and break the deadlock of this existing chicken and egg situation. A key actor in this context is the Ethiopian Free and Open Source Software network (EFOSSNet), a non-governmental organization established by a group of interested individuals with the mission of carrying out research and development activities related to FOSS. EFOSSNet had specific initiatives to build awareness about FOSS, which is believed to positively contribute to the introduction of FOSS to the public sector in the country. They were also involved with advocacy efforts with the government. An informant from the organization believed that in the long run there was no other option for developing countries like Ethiopia other than going FOSS route. However, as we saw in the case of the health care setting, the impact of advocacy of this group on policy was rather limited.

Another view at the policy level in Ethiopia was the assumption that development agenda of the country was only possible to be furthered by multinational companies. A senior higher official at the policy-making level argued as follows:

Fast social development was possible only by relating to big multinational companies, and it is not good to go against the storm. Microsoft and other proprietary businesses are currently dominant, and so why should health sector take the risk of going otherwise?

In contrast to Ethiopia, in Kerala, India, there were various formal policy related institutions that had been established to actively promote the adoption of FOSS in the state. While Kerala had a relatively high level usage of proprietary systems, although lower than the nearby states of Karnataka and Andhra Pradesh, the intention of the government to actively promote FOSS was evident. The state had formulated specific policy of supporting, using, and promoting FOSS systems in all public institutions, with ambitions as described by some to make it “God’s own e-state.” The Kerala State IT Mission, a governmental organization established to foster the process of IT adoption in general and FOSS in particular, had various initiatives to support policy implementation such as through training, the creation of manuals and other instruments.

Further, policy implementation support in Kerala for FOSS came through 5 semi-governmental institutions, referred to as Total Service Providers (TSPs), established with the objective of promoting alternative computing under the framework of Free, Libre and Open Source Software (FLOSS). They claimed to help the benefits of ICTs reach larger section of society, as well as to promote employment and development through FLOSS. They developed software for different organizations in the public sector and were also expected to support the implementation processes.

Higher education institutions play a key role in shaping perceptions, attitudes and capacities towards new technologies and approaches. In Ethiopia, the educational condition with respect to FOSS was one of passivity. In one of the oldest and most reputable academic institution, the graduates with software/information systems education were not well exposed to FOSS paradigm. By studying some of the curriculum, and talking to and observing students at work in laboratories, we inferred a general lack of awareness towards FOSS and related technologies, and a distinct affinity towards Microsoft technologies. This also reflected by the fact that there is not significant contribution to open source projects from Ethiopia. We attributed this partly to the education system and the consequent job market, which is not taking equal emphasis for both types of technological solutions and partly to the infrastructural challenge-internet and power supply.

The shortage of FOSS skilled professionals in the market further contributed to the dominance of the proprietary based businesses. In contrast in India, where the software industry was booming on a global scale, there were private and public colleges offering courses also in FOSS based technologies to meet the industry demand. However, the demand for FOSS developers in the public sector was found to be poor. The situation was made worse by the strong private sector, which lured away people with expertise in FOSS technologies (like Java) based on high salaries, which the government sector could not match and making them focus on proprietary solutions. A developer in India said:

This reality affects the expansion of FOSS and if organizations go for it, they will suffer shortage of qualified professional. In my former institution, we had a FOSS program, which was used to train our own staff on it. But since the market was luring, qualified people frequently left that institution, and the attrition rate was high. Only few that were committed remained.

Respondents often cited the low level of awareness towards FOSS in the public sector as a reason for the slow uptake of FOSS applications. The mindset of decision makers were described as: “those at the decision making level, whenever they think of a computer based system, they think of proprietary software companies.” The situation on the ground where there was a monopoly of Microsoft products and skills only related to its use, dictated the use of proprietary systems, making it hard to go for FOSS. The counter argument to the lack of capacity for FOSS made by technical people in both countries was that training is part of a normal system development process, be it FOSS or proprietary. Therefore, if there is no demand for FOSS products, there is no development and that it will not be easy to find expertise in FOSS related technologies. In relation to this, technical people argued that it was not difficult to get used to the FOSS habit, and “it was easy to get used to new systems very fast”, but there should be demand from the public sectors first.

On the other hand decision makers complained about the poor help desk support and reference points of FOSS products to resolve technical problems. Some software company managers in India complained on the absence of technical support that “No one is to be hold accountable for failures and troubles, and also that you will not get everything in a packaged form”. The technical people countered the claim by attesting that one could get such support online for FOSS, at the fastest possible speed, and even much better than in the case of proprietary systems. One Indian FOSS programmer also stressed that depending on the demand of the system, it was possible to get all required help.

In Kerala, an interesting contrast with respect to Ethiopia concerned the presence of many private sector software companies who were building feasible business models around FOSS products and services. However, as contrasted to “pure” FOSS models, these companies gave the source code only to the specific client, be it a government organization or private business, which then did not have the right to distribute or sell the code, depending on the agreement.

Given that firms in Kerala had for the last few years been engaged with the development of FOSS applications, they saw public sector settings, for example in health, to provide a rich potential business domain. They had thus developed sharp cost related arguments about the advantages of FOSS over proprietary systems. For example, the CEO of an open source software development company in Kerala noted:

In such countries applications for health institutions can be developed by amateur programmers for a reasonable cost or smaller software companies can offer them for a bearable cost. However the supporting platform, systems have to be bought from big multinational companies for huge amounts and with escalating cost as distribution increases. Such infrastructure related costs are really discouraging for public health institutions where there are hundreds of regional and district level branches.

A researcher and lecturer at a technology related educational college in Kerala stressed that the TCO (Total Cost of Ownership), when it comes to FOSS, was very small. Another software development company manager recalled that, “some public institutions do spend a great deal of money for proprietary systems and yet they fail; and others abandon computerization due to absence of the required money.” Such respondents believed that FOSS products have cost advantage to public sectors. However, counter arguments with respect to costs were put forth my firms dealing with proprietary software. Another manager of such a firm in Kerala, said:

Many people acknowledges getting source code to be an advantage but the thing is who can understand what is written by others…it is just like trying to finish a fiction written by another author…do you think it is possible to do that?…trying this requires high cost….it is very much cost effective to start from scratch.

Related to cost, maintenance issues were raised as important factors for the adoption of FOSS. Firms dealing with FOSS argued that closed source systems required access to the source code for responding to maintenance needs and changing requirements. So it created a lock-in situation with the vendor who always needed to be there for help, always involving additional costs. This dependency, according to a faculty member, often built tensions into the contract, where the vendor claimed that the contract was over while the client demanded more needs to be incorporated. Such tensions were potentially avoided in FOSS; where the source code was available free. However, few respondents countered that FOSS was never for free, and there were always costs involved related to training, maintenance and upgrades. A member of FOSS association rationalized that costs were always involved, be it proprietary or FOSS but the issue is what is most costly especially for maintenance.

We also heard some moral arguments about the cost effectiveness of FOSS, that public money being spent by public sectors, such as in health should, be used righteously. One respondent in India said:

Government owned health systems get their fund from taxpayers or from donors that are meant to help solve different critical health problems. If the money that could have been used to alleviate serious health problems is invested in the supporting health information systems, given that there is other alternative, it will be unfair to the best and unjust to the worst. The only way to make sure that public money is properly used is using FOSS approach.

Regarding license, almost all respondents from both countries revealed that organizations or individuals in many developing countries do use pirated systems; else it would be nearly impossible to develop applications given the prohibitive licensing costs of proprietary systems. However, we did not find respondents being concerned regarding the use of pirated copies in public sectors. They rather thought it was fair to use pirate copies in the framework of social justice.

Access to source code was seen especially crucial to public sectors like health, where the requirements were seen to be dynamic. However, many respondents, especially in Ethiopia argued that the availability of source code became irrelevant without adequate support and documentations. On the other hand, software developers perceived access to source code as necessary means to build internal capacity, gain self-reliance, avoid lock-in problems (when a single supplier would manipulate them in a way they wanted). They also appreciated the possibility of modifying the source code internally to address changing requirements. Access to source code was also seen by some to be crucial to enable interoperability of systems. An official from Ethiopia indicated:

If all health institutions use OSS, information exchange and interoperability will be simple……especially public health institutions in developing countries who are getting to be part of e-governance systems. They are better off following open standards for better data sharing.

However, access to source code was also mentioned to compromise patient security and privacy in the health sector, which was countered by proponents. The counter argument was that FOSS provides more security technologically, as it allows users to add their own security mechanisms, and not be dependent on what was provided by vendors.

Our specific focus in this section is on describing the decision making process of the same FOSS based DHIS2 in the two empirical settings.

The Ministry of Health is the highest authority nationally, endowed with powers and responsibilities to expand health services and provide care to the broader population, especially to the disadvantaged segments of society. There are 11 regional bureaus that report to MOH. Although the regions have a fair degree of autonomy, the decision of the regions is influenced by MOH including one related to technological choices.

Albeit in its early development stage, DHIS2 was presented to MOH in 2007/2008 for consideration as a national monitoring and evaluation tool. The value proposition was that such a system would help streamline health information systems and also would contribute to develop capacity within the country.

The first interesting aspect of the decision making process was the tendering process in which the criteria for applying were stipulated. It was stated that a preference would be given to MS based platform. Specifically, the tender document said:

FMOH has a preference for Microsoft Visual Basic / dotNet (commercial, with free distribution for standalone installations)

At the end of the evaluation, MOH decision was to reject DHIS2 because of two key reasons. First, DHIS2 did not meet the functional requirements of the MOH, and second the HISP team did not have adequate professional capacity to provide sustainable support. The letter received explicitly stated:

It is essential that the FMOH own the HMIS software. The DHIS software source code is publicly available; however ownership means more than access to source code. Practically speaking, ownership means that the FMOH needs access to software developers with the experience needed to modify the source code. There is no evidence that the skills to modify the source code are readily available in Ethiopia.

In response, the HISP team wrote to the MOH that with respect to functional requirements, it was an incorrect argument since they were never formally provided with the requirements. While acknowledging that their software currently was in the process of development, HISP argued that software development was a process, which necessarily needs to evolve through a process of mutual interaction between development and use. They thus needed to be given this opportunity of mutual interaction so that capacity within the country will be developed through the process. Further, HISP strongly refuted the claim of their lack of technical capacity, arguing that:

Capacity is never a given for any kind of technology or application but needs to be cultivated and nurtured in close collaboration between the user and development communities. Here again we would like to argue that we have both strong exiting capacity and a solid basis for its evolution and growth in the future shape by the needs of the health services.

Based on this letter and a subsequent meeting with officials, another opportunity was given to HISP to present their software. A new and much improved version of DHIS2 was then presented, which again was rejected by the MOH, who in their letter emphasized the technical functionality and the lack of human resource capacity as shortcomings to adopt the software.

Through this letter, HISP was formally informed that the DHIS2 had been rejected, and they should with immediate effect stop all development work. A copy of the letter was also sent to the regional health bureaus that HISP should no longer be active. Subsequently, while interviewing respondents about the relevance of FOSS more generally in Ethiopia, the respondent argued that FOSS was not relevant to Ethiopia because of the lack of existing technical capacity in this regard. The respondent said: “Most of the developers in Ethiopia do not know FOSS technologies and it is difficult for us to go for it”. When we pointed out to the same respondent the argument of FOSS to provide the health department with the ownership of the source code, which enables them to continuously modify the software to meet their changing requirements, the respondent countered:

The responsibility of the MOH is to provide sustainable and effective health care. Why should they be concerned about software?.......usually it is not easily to understand what is written by others…so the question is is it cheaper to start from scratch?...may be it is.

By this, the MOH went on employing another donor funded software company to develop the needed software from scratch than building what was started. However, we found the problem to revolve around the low awareness level of FOSS products and began to assess the various institutions that may be relevant to make FOSS products alternative solutions in the public sector of the country. Those were presented in the previous section. On another note, currently, MOH is pilot testing DHIS2.0 as the existing software is not responding to the needs of the health sector.

Kerala is a state in the southwestern India, with an estimated population of 32 million, which is close to half of the whole Ethiopian population. Relevant to our analysis, the following features of the state were pertinent:

•A history of communist governments whose anti-imperialist stance made them strongly anti-proprietary software and pro free software.

•A new Left government was voted into power in 2005, which explicitly made free software use as a formal government policy.

•The state has a history of strong community based involvement in various sectors including in public health, thus encouraging the need for grass root level workers to take control of their own information processing needs amongst other things.

The HISP initiative had started in India in 2000. Initially, HISP approached the health department of the Kerala state and proposed them a pilot project in one clinic, and permission was accorded to them. Six months on, as promising results were seen, HISP approached the health department again to extend the project to the whole district. Around the same time the very first version of the DHIS2 was released. HISP offered to buy 17 computers and facilitate this extension process, and since the state department saw no financial costs to them and that HISP had shown promise in their initial efforts, the permission was provided, and the first version of DHIS2 was deployed in 19 Block level clinics.

However, as this phase of the HISP effort started, they came to know the existence of a competing health management information system project going on through a large government owned computer firm that had previously been responsible for the development of the first supercomputer in the country. This project was funded through the European Commission, and was proposed to be built using a mainframe based architecture where there would be one application running and online use of the system would be carried out through the district level. This application was built on a proprietary platform involving Oracle as the database and Visual Basic as the development language. The view of the implementers was that a centralized architecture was needed because the field level users were not ready for computerization, and the maintenance overheads were tremendous. The HISP model was completely in contrast for various reasons. Firstly, it was built completely on free software. Secondly, the implementation model focused primarily on the grass root level, where the field users were seen to be the most important users of information, and thus it was their capacity, which needed to be developed. And historically, the field level and bottom up implementation model was one, which very much historically inscribed the HISP philosophy as it had taken root in 1994 post-apartheid South Africa (Braa and Hedberg, 2002; Braa and Sahay, 2012).

As both projects were ongoing, and threatening to conflict with each other, the state authorities needed to take a decision on which project should be continued. Both parties were called for a formal evaluation, which was presided by the key decision maker of the state health department. During the evaluation, the government firm sketched out their model of implementation in which they argued for a centralized model. HISP in their evaluation emphasized its approach based on FOSS which they pointed out was supporting the state government policy of promoting the use of FOSS. They also emphasized that their model is empowering the field workers, and indeed they were very capable of running the system and meeting their information processing needs. As evidence, they showed a set of reports for the current month that had been generated by the field staff in the pilot sites they had been working in. This demonstration was well received by the health department, as again it resonated with the left government agenda of promoting grass root level democracy. Furthermore, HISP elaborated on the global HISP network, the expertise available, and how the software would be continuously upgraded and global best practices incorporated.

Table 2. Comparing Kerala and Ethiopia at Macro and Micro level

Download as

PowerPoint Slide

Larger image(png format)

• Tables index

Veiw figure

View current table in a new window

View previous table

View next table

Based on these presentations, HISP was evaluated over the government company, which was extremely large, well endowed with resources, and were supported through the formal machinery of the EU. In contrast, HISP was a small NGO, supported through university research funds, and with very limited resources. Currently, HISP is not supporting the DHIS2 software in Kerala. The state health department has taken the responsibility of maintaining and running the software by themselves after getting several years of support from HISP. The table (Table 2) presents a comparison of the various issues that influence FOSS adoptions in the two settings.

5. Analysis

In this section, we analyze the empirical data provided in the previous section using the analytical framework presented in section 2. In this analysis, we identified the various institutions from the wider context in which the health care sector is situated in to highlight their enabling and constraining role to the adoption of DHIS2.

The regulative institutions in this context include the ICT policies and the official tender documents that sanctioned or support FOSS based systems in the two settings, which are actively drawn upon to “cultivate a belief in the legitimacy” of one or the other ^[10]. These institutions can be coercive by nature and conforming to them is rewarding, while non-conformity can lead to sanctions and rejection.

In Ethiopia, the former EICTDA the organization responsible for ICT policy formulation for the public sector, created a draft policy, which reflected a bias towards proprietary software, and a consequent marginalization of FOSS. FOSS was not mentioned as an alternative technological solution for the public sector in the policy drafted in 2005. However, in our recent examination of the Ethiopian ICT policy document, we found that bias to be slightly corrected by presenting an enabling environment for both proprietary and FOSS as alternative technological e-government solutions. This gives a positive implication to the change of institutions by defining a fair environment for both technologies. Some individuals felt the regulative institutions to be constraining them from going in FOSS direction.

Another regulative institution that constrained the use of FOSS in Ethiopia was the tender document; which again was influenced by the old ICT policy. This institutional element was reflected and also drawn upon by the MOH evaluation criteria in tender document in which explicitly MS products were stipulated as the preferred choice of the MOH for building the national HMIS. In contrast, in Kerala, the policy environment, influenced by historical and political reasons, clearly favored FOSS. Consequently, at the micro level, while the presence of such regulative institution facilitated the acceptance of DHIS in Kerala, the lack of similar institutions in Ethiopia led to the rejection of the same software in the Ethiopian health care sector. This finding is consistent with the recent findings in ^[19] that attributed the low diffusion of Straight-Through-Processing (STP)- a type of inter organizational system in the financial industry- to the loose regulative mechanisms in Taiwan. The authors further claimed that the presence of such regulative pressure facilitated the uptake of the same technological solution in Europe. In the same vein, IS researchers have found out top-down approaches to be more successful when it comes to digital infrastructure evolution ^[38] that includes adoption and diffusion. Regulative institutions as a topic of the top-level management need to be compatible with the nature and approaches of FOSS if they have to be adopted. The case demonstrated two opposite regulative institutions in Kerala and Ethiopia. While the Ethiopian regulations enable proprietary software, the Kerala regulations enable FOSS.

The normative institutions include those institutions that provide principles and guidance regarding the ideology, use, methods, and technological frameworks for FOSS that create appropriateness for its use in organizations. Organizations that are engaged in setting the normative institutions in practice include the formal education sectors, training facilities, and professional association. While the presence of normative institutions for FOSS facilitates adoption, the absence of such institutional mechanisms hinders its adoption and further diffusion.

In Ethiopia, the bias towards proprietary software was reinforced by the nature of the informatics curriculum in the national university where FOSS technologies did not find a prominent place. Microsoft products were seen to have become “part of the furniture” ^[39], and limited alterative voices existed to challenge this status quo and create any form of political or functional pressure ^[22]. In India, while the Oslo university staff and students through HISP could serve for professionalizing the FOSS concept in the public sector, the same potential could not be created in Ethiopia. In addition, the education system, in Ethiopia, has not provided any strong enabling institutions, which could provide guidance and principles in the use of FOSS.

Further contributing to creating positive environment for FOSS and thereby facilitating the adoption of FOSS in Kerala was the presence of a professional organ called TPSs. These organs were actively developing and promoting working business models around FOSS use in the public sector. Furthermore, in Kerala, the university-based model of HISP was seen positively as it was associated with enabling the circulation of new knowledge and global best practices. In contrast, private companies in Ethiopia created a normative pressure for the use of proprietary based systems. That was further reflected clearly in the evaluation result of the MOH, where the lack of private firms providing FOSS expertise was taken as a basis to reject DHIS2. The only enabling normative pressure for FOSS in Ethiopia comes from EFOSSNet- the FOSS association. However, the pressure was rather weak to contribute for the deinstitutionalization of the institutional environment, which is favoring proprietary software.

Moreover, contributing to the constraining normative institutions for FOSS is the professional distinctions health professionals upheld. For example, informants in Ethiopia pointed out the health sector were expected to focus on health aspects to legitimize their argument that software development was the primary responsibility of software firms and not the health department. These software firms, driven primarily by the principle of profit making, tended to pursue development through MS products, which undeniably had higher commercial value to the firm than FOSS. In addition, health sector managers did not believe that it was important to obtain the source code as it was the job of software companies and not themselves to customize the application in the future. Focusing only on health was the normative mechanism by which the organizational role of the health sector was seen confined. We argue that while such kind of professional role distinctions are important, understanding the significance of technology in health, there is a need that the health care sector should also go beyond the health matters and be actively involved in the choices of technological solutions. In conclusion, the different normative institutions were found to be enabling for both FOSS and proprietary products in Kerala, while in Ethiopia they were enabling only the use of proprietary systems.

The study found out conflicting personal believes regarding the theoretical values of FOSS in both Kerala and Ethiopia. In one hand, stakeholders who are involved in FOSS paradigm view FOSS to positively contribute to the good of the health or other public sectors. The mentioned advantages of FOSS by this group of stakeholders were cost, availability of source code and interoperability. On the other hand, the other group of stakeholders perceived FOSS to come with disadvantages of hidden costs, poor support, and lack of expertise in working with already developed code. The theory of potential advantages of FOSS, arguably had been realized in practice in Kerala, thus helping to reinforce and diffuse the positive perceptions. The absence of the same in Ethiopia meant that contradicting arguments of the advantages of proprietary software over FOSS could not be resolved. Further, in Ethiopia, the normative and regulative elements of institutions were dominants and contributed to the reinforcement and diffusion of mindsets that want to follow propriety software paradigm.

In Kerala, there was also a degree of ambiguity in this regard that while the policy makers favored FOSS, other respondents showed preference towards Microsoft products. However, this could also be seen as an advantage, where the option of using either FOSS or proprietary systems remains open, and one option was not closed at the expense of the other. In Ethiopia, we found a belief system by policy makers that leap forging the digital divide was possible only by relying on well-established proprietary companies like Microsoft, and maybe is best left to multi-national corporations. This was related to fear that there is less accountability to FOSS than proprietary software. However, research shows that FOSS projects/firms follow varied governance mechanisms ^[40] that make them equally accountable as firms with propriety software development model. The influence of this institutional aspect towards micro level adoption of FOSS appeared to be similar in both settings. While those who are proponents of FOSS perceive FOSS to have more advantages over proprietary software, the opponents counter argued.

In addition to the three institutional pillars ^[10], we argue that technology by itself can play a role for its own adoption through the notions of network effects and increasing returns (Hanseth, 2000) that are drawn upon an economic perspective of technology adoptions.

We recognize the DHIS2 under the FOSS model has now reached the stage of becoming a global de facto standard for health management information systems in developing countries. More than 30 countries have adopted the software within the 15 years development and implementation time. The value of the software has increased through network effects, which in turn has increased the functionality and importance of the software making it attractive to more users and challenging the constraining institutional elements for its adoption. From being a tool for an aggregated health data, it has now expanded to being a tool for patient-based data. The continuous testing of the software by the involved countries has also contributed to prompt fixing of bugs. The more the software is adopted, the more it becomes improved increasing the return value of the software to new adopters ^[41] (Arthur, 1989). This aspect shows the importance of micro level adoption of FOSS to simulate and pressure change in the wider institutional setting, which has been constraining to FOSS. This is especially relevant to late adopters like the current case of Ethiopia and its interest in piloting DHIS2. However, early adopters like Kerala do not see this kind of enabling pressure. In Kerala, the afro-mentioned three institutional elements were more relevant than the technological pressure. To be consistent and complementing the typology of institutions (as discussed in section 2), we view the indicator for technological institutions with respect to adoption to be the presence of large installed base (number of user adopted the software). The basis for positive response towards such technological pressure would be the increasing return. While the technological pressure is enabling in Ethiopia as late adopter, it was constraining for Kerala as early adopter.

The following table presents a simplified version of how the complex institutional environment enables and constrains the adoption of FOSS in the Kerala and Ethiopia.

Table 3. Institutional Influences on FOSS adoption in public sectors

Download as

PowerPoint Slide

Larger image(png format)

• Tables index

Veiw figure

View current table in a new window

View previous table

The table shows the combination of enabling normative and regulative institutions facilitates the adoption of FOSS in public sector organizations. The table suggests also, in the absence of regulative and normative institutions, the technology facilitates FOSS adoption once it has gained large installed base. However, in the latter case, the FOSS nature becomes irrelevant and the adoption process takes relatively longer time. Therefore, we argue that the viable approach for FOSS adoption in public sector is strengthening the regulative and normative institutions in favor of FOSS.

6. Practical Implications: the “middle way”

The Kerala case highlights a stage of how certain de-institutionalizing forces regulative and normative has helped to erode the legitimacy of the previously established institutions of proprietary systems and slowly cultivate and include one based on FOSS.

Politically, in Kerala the historically existing communist governments have explicitly rejected proprietary systems. Consequently, in 2005, the new government formulated a policy explicitly guiding government departments to adopt FOSS. These policies have faced a strong inertia at user level to practically realize the policy vision for two basic reasons. This is because there are no sanctions against the use of proprietary system, and human actors feel uncertain to make a change from a system they have been used to for many years. So, despite the policy, we saw most of the health facilities using MS products. The only FOSS based application in the health sector was the DHIS2 software, which is running on MS-Windows, despite also having the option of being run on Linux.

Scholars such as ^[13] emphasizes the need to incrementally bridge the gap between the formal institutions (the ICT policy) and the informal constraints (e.g. capacity and norms) on the ground. As the education system produces more FOSS aware students, and the private sector provides more opportunities for them to work in FOSS, cultivation ^[42] towards integrated IT platform can be seen to be ongoing in Kerala. This then contributes to the gradual changeover of systems in the public health sector as well. Moreover, the government has established the intermediary organizations (TPSs) to facilitate public sector user departments to changeover to FOSS solutions, a process, which will further accelerate the changeover. In this context, the state government can be seen to be acting as an institutional entrepreneur and placing their power and resources to facilitate this process of change cultivation.

However, in this paper we are not trying to promote the sole use of FOSS in the public sector, as history with respect to existing proprietary systems is part of our reality, and needs to be addressed, and more proactively taken advantage. In both countries, stakeholders acknowledge the advantages and disadvantages of both systems, and thus we believe a proposal that facilitates the integration of FOSS with the already existing proprietary based systems and work practices would be more appropriate than positioning one over the other. In Ethiopia, the current scenario is not visible to enable this integration, and requires working with normative institutions such as introducing explicit FOSS education in the current education system. We have noticed an initial technological pressure, which might result in change in the margins of the complex institutional environment. However, an important step towards widespread incremental change towards integrating FOSS with proprietary software could come by cultivating the normative institutions which are vital in creating awareness, moral obligations and changing the negative perceptions towards FOSS.

As the Kerala example shows, intermediary organizations like the TPS need to play a more active role in facilitating change processes and it can be taken as a lesson for the Ethiopian health care sector. More importantly, the current practices of public sector organizations such as tendering need to be expanded in scope so that both FOSS and proprietary systems can bid for, be evaluated, and may the “best system win”. The Ethiopian tender example where one option was shut out, we believe limits the opportunities of the public sector organization to take advantage of current technological developments.

The integration approach we propose thus involves more than a technical solution, but related to practices both at the level of decision making and also at the level of use. The DHIS2 use in Kerala provides a nice example of this, since while the application is based on FOSS technologies and is platform independent, at the clinics it is run on Windows keeping sensitively in mind the users preferences and capacities. However, the platform independence of the application provides the users with the option of a change over to another platform whenever and whatever the user chooses. The following figure depicts the “middle way” we are proposing.

Download as

• PPT
  PowerPoint Slide
• PNG
  Larger image(png format)

Veiw figureFigures index

•  NEW
  View larger figure in new window

Figure 1. The “middle way” for both FOSS and proprietary software

7. Conclusions

While there is a significant amount of rhetoric about the potential of FOSS applications to overcome the digital divide and to enhance the quality of services delivery, there are challenges to put this rhetoric into practical benefits that can accrue good results. There is lack of sound evidence that bring the macro-micro dynamics together so as to support the understanding of the real challenges in the wider institutional environment and their implication to FOSS adoption. The institutional perspective taken in this paper emphasizes the need to unpack and understand the macro-level regulative, normative and cultural- institutions in various settings to cultivate change process to create an environment that takes into account both FOSS and proprietary systems as preferred IT solutions for the public sector. In relation to this, the macro level institutions: policy, education system, stakeholders’ perceptions, and role of mediating agencies have all been identified as being important actors in enabling (and also constraining) these processes of change. Furthermore, at the micro-level the introduction of FOSS to an organization can stimulate change towards deinstitutionalizing the various institutional aspects that favors proprietary software. However, cultivating change towards a “middle way” technological platform, we argue, would be more sustainable if FOSS is properly introduced in the education system. A radical change can be achieved in the regulative institutions. Public sectors use of FOSS solution by itself can stimulate change in the education and regulative institutions.

Even though, we make such analytical distinctions of institutions for clarity, in reality, these are all intermingled and that they should be recognized as influencing each other.

By taking both macro- and micro level institutional analysis of the case studies, we contributed to the expansion of the analytical framework of institutions. The research set out with the assumption that FOSS adoption is more influenced by the surrounding institutions and that “network effects” may not have influence in FOSS adoption in public sectors if not combined with other institutional mechanisms. Network effects means “a product may simply be more valuable to each buyer; the more others have the product or service” [^[43] p.7]. As a result, we took a sociological institutional perspective to study those influences. By doing so, we tried to understand how stakeholders in organizations create meaning drawn upon institutional aspects to legitimize their rejection or acceptance of FOSS. However, following upon the case through time shows that technology by itself creates also pressure for its adoption once it gets large installed base, consequently creating enabling environment for its adoption. Therefore, we recommend, future IS studies that seeks to apply this analytical framework to take into account the fourth institutional pillar to have a more comprehensive analytical tool in their study.

Concluding on a more positive note, we would like to emphasize that FOSS needs to be actively taken into the agenda of public sector digitization efforts in developing countries. However, this agenda should not be built upon utopian idealism but on the practical needs. FOSS like proprietary systems is never “fully” free as there are always costs involved in their customization, capacity building and maintenance. However, by eliminating the license costs, it is significantly “more free” than proprietary systems and it fosters innovation as the source code is accessible. Thus, there is a need to carefully evaluate the pros and cons of the different options, and make informed choices keeping the broader aims in mind of building sustainable, scalable systems that can effectively contribute to improve service delivery in the public sector.

Acknowledgement

We acknowledge all respondents in Ethiopia and India.

Note

1. https://www.dhis2.org/inaction.

References

[1]	Cook, I. and G. Horobin, Implementing eGovernment without promoting dependence: Open source software in developing countries in Southeast Asia. Public Administration and Development, 2006. 26(4): p. 279-289.
	In article		View Article
[2]	Cook, I. and G. Horobin, Implementing eGovernment with out promoting dependence:open source software in developing countries in Southeast Asia. Public Administration and Development, 2006. 26(4): p. 279-289.
	In article		View Article
[3]	Camara, G. and F. Fonseca, Information policies and Open source Software in developing Countries. Journal of the American Society for Information Science and Technology, 2007. 58(1): p. 121-132.
	In article		View Article
[4]	Scacchi, W., et al., Understanding Free and Open Source Software Development Porcesses. Software Process Improvement and Practice, 2006. 11: p. 95-105.
	In article		View Article
[5]	Abbott, P., How can African countries advance their outsourcing industries: An overview of possible approaches. The African Journal of Information Systems, 2013. 5(1): p. 2.
	In article
[6]	Mengesha, N.T., Technology Capacity Development through OSS Implementation: The Case of Public Higher Education Institutions in Ethiopia. The African Journal Of Information Systems, 2010. 2(1): p. 2.
	In article
[7]	Effah, J. and G. Abbeyquaye, How FOSS Replaced Proprietary Software at a University: An Improvisation Perspective in a Low-income Country. The African Journal of Information Systems, 2014. 6(1): p. 2.
	In article
[8]	Twaakyondo, H.M. and J.H. Lungo, Open source software in health information systems: Opportunities and challenges. Tanzania Journal of Engineering and Technology, 2008. 2(1): p. 36-45.
	In article
[9]	Sheikh, Y.H. and A.D. Bakar, Open Source Software Solution for Healthcare: The Case of Health Information System in Zanzibar, in e-Infrastructure and e-Services for Developing Countries. 2011, Springer. p. 146-155.
	In article
[10]	Scott, W.R., Institutions and organizations. 2001: Sage Thousand Oaks, CA.
	In article
[11]	DeVaujany, F., et al., Applying and theorising institutional frameworks in IS research. Information Technology & People, 2014. 27(3).
	In article
[12]	Pishdad, A., et al. Identifying Gaps in Institutional Theory. in Proceedings of the 25th Australasian Conference on Information Systems, 2014. Auckland, New Zealand.
	In article		PubMed
[13]	North, D.C., Institutions, institutional change and economic performance. 1990: Cambridge university press.
	In article		View Article
[14]	Greenwood, R., R. Suddaby, and C.R. Hinings, Theorizing change: The role of professional associations in the transformation of institutionalized fields. Academy of management journal, 2002. 45(1): p. 58-80.
	In article		View Article
[15]	Sahay, S., et al., Interplay of institutional logics and implications for deinstitutionalization: case study of HMIS implementation in Tajikistan. Information Technologies & International Development, 2010. 6(3): p. pp. 19-32.
	In article
[16]	Palthe, J., Regulative, Normative, and Cognitive Elements of Organizations: Implications for Managing Change. Management and Organizational Studies, 2014. 1(2): p. p59.
	In article		View Article
[17]	Hsu, C., Y.-T. Lin, and T. Wang, A legitimacy challenge of a cross-cultural interorganizational information system. European Journal of Information Systems, 2015. 24: p. 278-294.
	In article		View Article
[18]	Suddaby, R., Challenges for institutional theory. Journal of Management Inquiry, 2010. 19(1): p. 14-20.
	In article		View Article
[19]	Hsu, C., Y.-T. Lin, and T. Wang, A legitimacy challenge of a cross-cultural interorganizational information system. European Journal of Information Systems, 2015. 24(3): p. 278-294.
	In article		View Article
[20]	Jepperson, R.L., Institutions, institutional effects, and institutionalism. The new institutionalism in organizational analysis, 1991. 6: p. 143-163.
	In article
[21]	Avgerou, C., Information systems and global diversity. 2002: OUP Oxford.
	In article
[22]	Oliver, C., The antecedents of deinstitutionalization. Organization studies, 1992. 13(4): p. 563-588.
	In article		View Article
[23]	Grisot, M., H. O., and A. Thorseng, Innovation of,in,on infrastructures: articulating the role of architecture in information infrastructure evolution. Journal of the Association for Information Systems, 2014. 15(special issue): p. 197-219.
	In article
[24]	Hanseth, O. and E. Monteiro, Understanding information infrastructure. Unpublished Manuscript, Retrieved on 6th September from https://heim. ifi. uio. no/~ oleha/Publications/bok. pdf, 1998.
	In article
[25]	Aanestad, M. and T.B. Jensen, Building nation-wide information infrastructures in healthcare through modular implementation strategies. The Journal of Strategic Information Systems, 2011. 20(2): p. 161-176.
	In article		View Article
[26]	Dahlbom, B. and L. Mathiassen, Computers in context: The Philospphy and Practice of System Design. 1993, Cambridge, Massachusetts: Blackwell Publisher
	In article
[27]	Maguire, S., C. Hardy, and T.B. Lawrence, Institutional entrepreneurship in emerging fields: HIV/AIDS treatment advocacy in Canada. Academy of management journal, 2004. 47(5): p. 657-679.
	In article		View Article
[28]	Hardy, C. and S. Maguire, Institutional entrepreneurship. The Sage handbook of organizational institutionalism, 2008: p. 198-217.
	In article		View Article
[29]	Walsham, G., Interpreting information systems in organizations. Vol. 19. 1993: Wiley Chichester.
	In article
[30]	Walsham, G., Doing interpretive research. European journal of information systems, 2006. 15(3): p. 320-330.
	In article		View Article
[31]	Orlikowski, W.J. and J.J. Baroudi, Studying information technology in organizations: Research approaches and assumptions. Information systems research, 1991. 2(1): p. 1-28.
	In article		View Article
[32]	Klein, H.K. and M.D. Myers, A set of principles for conducting and evaluating interpretive field studies in information systems. MIS quarterly, 1999: p. 67-93.
	In article		View Article
[33]	Creswell, J.W., Research design: Qualitative, quantitative, and mixed methods approaches. 2013: Sage publications.
	In article
[34]	Braa, J., E. Monterio, and S. Sahay, Networks of action: sustainable health information systems across developing countries. . MIS quarterly, 2004. 28: p. 337-362.
	In article
[35]	Walsham, G., Interpretive case studies in IS research: nature and method. European Journal of information systems, 1995. 4(2): p. 74-81.
	In article		View Article
[36]	Elliott, R. and L. Timulak, Descriptive and interpretive approaches to qualitative research. A handbook of research methods for clinical and health psychology, 2005: p. 147-159.
	In article
[37]	Walsham, G., What is Interpretive Research? . (n.d), University of Oslo: Retrieved from https://www.uio.no/studier/emner/matnat/ifi/INF5740/h04/.../Lecture_1.pp.
	In article
[38]	Henfridsson, O. and B. Bygstad, The Generative Mechanisms of Digital Infrastructure Evolution. Mis Quarterly, 2013. 37(3): p. 907-931.
	In article
[39]	Silva, L. and J. Backhouse. Becoming part of the furniture:the institutionalization of information systems. in IFIP TC8 WG 8.2 international conference on information systems and qualitative research. 1997. Philadelphia: Chapman & Hall, Ltd.
	In article		View Article
[40]	Wubishet, Z., Conceptualizing the Governance of Free and Open Source Software Development: A Framework Based on Case Studies of Three Software Projects in Norway, in Department of Informatics. 2011, Norway: Oslo.
	In article
[41]	Arthur, W.B., Competing technologies, increasing returns, and lock-in by historical events. The economic journal, 1989. 99(394): p. 116-131.
	In article		View Article
[42]	Aanestad, A., Cultivating Networks: Implementing Surgical Telemedicine., in Department of Informatics. 2002, University of Oslo: Oslo.
	In article		PubMed
[43]	Farrell, J. and G. Saloner, Standardization, compatibility, and innovation. The RAND Journal of Economics, 1985: p. 70-83.
	In article		View Article