Keywords

1 Introduction

Discourses around digitalization have become central to research and practice concerning ICT for development (ICT4D). A contemporary ICT4D digitalization research agenda focuses on the notion of “development 2.0” referring to ICT for digital production and innovation offering grassroots development [8]. This paper contributes to a stream of related literature that focuses on exploring the significance of digital platforms in relation to socio-economic development [10].

Digital platforms are broadly defined as multi-sided markets based on value-creating interactions between external producers and consumers, with the platform core serving as a mediator between the multiple sides of the market. Much of the extant literature on digital platforms has emerged from studies of commercial and public sector platforms situated in the regulative institutions of the global North [6, 7, 12] and the potential for “translation” of these platforms for the global South and the development impact remains understudied. The potential for open digital innovation platform designs to facilitate the ideals of global public good (GPG) such as non-rivalry and non-exclusivity remain understudied.

Our aim is twofold: firstly to improve the current understanding of global public good digital innovation platforms in the context of strengthening health information systems in the global South. Secondly, to contribute to accelerating inclusive innovation through participation of people in the countries themselves. However, we argue that the ideals of GPG are challenged in practice. This paper is guided by the following research question:

“How can global public good platforms facilitate inclusive innovations by enabling effective participation in strengthening health information systems?”

The empirical basis is the case of the University of Oslo Health Information System Programme (HISP) and the open source platform District Health Information Software (DHIS2). We examine this platform through the lens of an organizational tensions framework [11]. This framework recognizes organizations as conflicted sites of activity and takes as its starting point the ‘dilemmatic’ nature of organizing arising from the paradoxes, contradictions and ironies. The paper is organized as follows: in the next section literature on digital platforms is reviewed and the conceptual framework presented. The next section presents the methodology and case description. The findings and analysis is divided into four vignettes that illustrate the tensions of GPG platforms. The paper concludes with some implications.

2 Relevant Literature

This section is divided into two parts. In the first, we present our conceptualization of digital platforms relevant to DHIS2 and the notion of digital innovation platforms as global public goods. In the second section, the notion of tensions and paradoxes is presented as the analytical framework.

2.1 Digital Platforms

Koskinen et al. [10] broadly identify two types of digital platforms: transactional and innovation. The first category relates to platforms where the main purpose is to facilitate transactions between different organisations and individuals, such as buyers of accommodation with sellers (Airbnb), drivers with passengers (Uber), news, videos and updates (Facebook) etc. Our focus in this paper is on digital innovation platforms that produce content, products or services developed by one or more parties, and which serves as the foundation upon which a larger number of actors can build further complementary innovations. This potentially generates self-reinforcing network effects [4, 6, 7]. An example of a digital innovation platform is the Google mobile operating system ‘Android’ that facilitates third party developers to build applications. Similarly, open source Linux allows for creation of applications across various different devices.

This example of open architecture corresponds to DHIS2 which allows Apps to be developed freely and linked to the core platform architecture. Two main inter-connected discourses relating to digital platforms are relevant: innovation studies and ICT for development. There is evidence that digital technologies are taking on platform features of “build once and use multiple times,” creating innovation opportunities that are more socially inclusive. This promises the possibilities for developing country organizations to participate directly in software feature development and direct the use of the platform to address locally relevant problems. However, materializing these innovations in practice across heterogeneous settings is a non-trivial task, involving technological as well as institutional and social innovations. Strategies for this materialization necessarily need to be different from that involved in commercial platforms because of a very different context. Understanding these differences is significant because most extant research addresses software platforms in the commercial sector, with an emphasis on markets in the global North [e.g. 4, 6, 7, 12]. Research in this domain has contributed primarily to the academic and practitioner literatures on design, drivers, business models and regulation of commercial platforms. This focus is unsurprising given the overwhelming dominance of major global platforms such as Apple, Amazon, Facebook, Google and Microsoft [15]. However, even the focus on the specificities of public sector organisations has focused on the global North [2, 5].

Kaul, Grunberg and Stern [9] identify two main characteristics of global public goods. First, is the characteristic of non-rivalry and non-exclusivity. Second, the benefits are quasi universal across groups of people, social groups, geographies, and generations. Considering open digital innovation platforms, licenses allow users to freely run the program for any purpose, modify it as they want, and to freely distribute copies of either the original or their own modified version. However, to date the notion of GPG applied to digital innovation platforms remains under researched.

2.2 Analytical Framework: Organizational Tensions

A growing body of literature focuses on articulating contradictions and tensions in various organizational settings [16]. This literature contrasts with a view of organizations as stable, consensus driven and rational in favour of a recognition that dualities, ambiguity and contradiction are inevitable normal facets of organizations [13]. An organisational tensions framework recognizes organizations as conflicted sites of activity and takes as its starting point the ‘dilemmatic’ nature of organizing arising from the paradoxes, contradictions and ironies which naturally exist in organizations [18]. There is limited consensus on whether tensions are positive or negative. Wendt [17] for instance argued that tension is detrimental to organizational productivity but more recently Tracy [16] posits that the impact of tensions (whether positive or negative) rests on the way it is managed. However, in many cases, contradictions come with an underlying potential for change.

A contradiction involves an either–or choice between two opposing alternatives; a paradox is a dilemma that demands impossible choices between non-existent or mutually exclusive options. Related to the discourse on contradiction and paradox is the dialectical view, which allows for the merging of opposites by embracing both poles as ‘both–and’ options [13]. Here, dualities are seen as bi-polar opposites that often work against each other; rather than being simple alternatives between mutually exclusive options, the choice to focus on one pole or the other elicits tensions. Putnam and Boys [13] describe dialectics as interdependent opposites aligned with forces that push-pull on each other like a rubber band and exist in an ongoing dynamic interplay as the poles implicate each other.

To explore contradictions, paradoxes and their resolution (or not, as the case may be) in our field data, we draw on Lewis’ framework [11] summarized in Fig. 1 below.

Fig. 1.
figure 1

Paradox framework [11]

Full size image

In this framework, the tensions are expressed using the Taoist notion of yin and yang, implying that the masculine and feminine can co-exist and paradoxically conflict. Cycles of reinforcing repercussions act to embed the opposition. The third component of the frame is management action that may take place to resolve the tension.

3 Methodology

In this section, we present the research method firstly by providing description of the case followed by the approach to data collection and analysis.

3.1 Case Description

This research was carried out under the aegis of the global Health Information System Program (HISP), a network of North-South-South collaboration where the University of Oslo, Norway (HISP UiO) has a key role in coordinating the network. This project comprises people working in the health informatics domain with the ambition to strengthen health information systems in developing countries [1].

Technically, anyone can at any time download the most recent version of DHIS2, the source code, and all required libraries and needed third party products (such as Chrome or Firefox browsers). DHIS2 also comes with a set of bundled apps, developed by UiO or through their partners in the South (such as HISP Tanzania for example). Thus, DHIS2 fits well the criteria of being a GPG as downloading the software does not hinder or reduce the possibility for others to do so (non-rivalrous), it is not possible to prevent anyone from downloading it (non-excludable) and it is available more-or- less worldwide. The DHIS2 platform is used in 65 countries worldwide, 4500 participants have been trained at DHIS2 academies and approximately 2.3 billion people are covered by DHIS2, roughly equal to Facebook users in 2018 (statista.com).

3.2 Data Collection and Analysis

The data collection emerged from the authors’ individual analyses and collective discussions and reflections concerning paradoxes and tensions across different DHIS2 implementation settings. The case study is interpretive [19, 20] and data was collected during participant observation in implementations and training workshops. We present four vignettes from these combined experiences from respective implementation sites and user groups. The commonality is the use of the same software DHIS2 platforms across sites and over times. These experiences are articulated as vignettes, each reflecting particular tensions, and the efforts involved of the implementation teams in trying to address these tensions. Creating these vignettes has also involved studying existing HISP research papers and PhD theses and reinterpreting them using the lens of tensions.

4 Case Study and Analysis

The case study and analysis are presented below in the form of four main tensions that were experienced in the field. The tensions are identified and an analysis presented of how these contradictions play out and efforts towards their resolution.

4.1 Tension: Serving Those that Can Pay for Functionality vs. Those that Cannot

Software platforms such as DHIS2 are not static but continuously evolving to keep up with the development of technology as well as ever-changing user needs. While any released version of the DHIS2 meets the characteristics of a GPG, the roadmap and the priority regarding the path of the future development of DHIS2 is managed and decided by UiO. The roadmap is balanced against available resources, and who pays what into the core development. Given this uneven nature of financial commitments, the core team cannot accommodate all requests equally and at the same time. Initially, DHIS2 was developed to serve the needs of ministries in a few developing countries and the software development activity carried out primarily by PhD and Masters students with funding from the Norwegian Research Council, Norad and the University of Oslo. Prioritization of functionality was based on whether a requirement was generic, relevant across countries and use cases. Today, DHIS2 is used by numerous ministries of health in addition to donors and NGOs with different use cases.

The tension is evident in the development of the DHIS2 software that unfolds through projects directly funded by donors and NGOs paying for particular functionality to be implemented. Other actors such as ministries of health or their representatives do not have the same financial “muscle” to influence the roadmap. Thus, while the product is broadly a GPG, the process of deciding the roadmap is both rivalrous and excludable as the roadmap and the next release can only provide a limited number of new functionalities. This is already seen in the development process.

Reinforcing cycles are evident in the processes for suggesting new features or the path of development. Firstly, the core team of developers are responsible for deciding the priorities by balancing changes according to perceived benefits of various user groups, ease of implementation, and, crucially, availability of funding. The funding does not only relate to direct investments in developer time, but also enables access to developers often involving travel to interact with the core team in Oslo. This concurs with Roland et al. who write: “International NGOs with relatively deep pockets are able to travel and sit down with the core software developers in Oslo, and therefore have the opportunity to invest in more face time to make sure their requirements are well understood and recognised in future development of the software” [14, p. 22]. Secondly, countries investing in implementing DHIS2 have few incentives to contribute to the future development of the global good and this is also the case if global donors are the basis for the investment. In a similar way, when a global organization wants to contribute to platform development, they typically prioritize what they need for their own organization, which does not necessarily coincide with the needs of other countries.

To manage this tension, the developers seek to incorporate in the core such functionalities which can be considered generic and thus can be made relevant for other users. Further, there is also the effort of the core team to access funding for larger projects to also include resources to support the general DHIS2 platform. Initiatives like the DHIS2 Roadmap Country Advisory Team (RCAT) were created to increase the likelihood of requirements from the ministries of health being prioritized on the roadmap. Further, Norad is still an important funder of the core developer team and there are ongoing negotiations concerning the establishment of funding mechanisms from the donors that would fund the DHIS2 core development directly rather than channel funding to the country level.

Despite this challenge of prioritization, there is still a strong impetus to keep the global core generic, and which can support the development of apps as independent commodities without influencing the core. Increasingly, resourceful actors such as Populations Services International (PSI) develop their own apps for specific needs, but how much these Apps also retain the GPG characteristics remains uncertain. One way to compensate for the lack of incentives is to add a percentage fee for consultancies/technical assistance that goes to GPG development of the core. The tension highlighted here is in their efforts to enhance the generic nature of the platform set against new independent developments which may not share GPG ideals.

4.2 Tension: DHIS2 as a Flexible and Generic Software vs. an “Appliance”

DHIS2 is designed with the flexibility to be locally adaptable, i.e. to accommodate variations across different user groups and use cases. The philosophy of local user adaptation has been a key development priority from the start of its development process in 2004–05. With global scaling, the generification process has added much more functionality to be able to cater for the increasing number of use cases (from aggregate to case-based, for instance), and made this functionality generic enough to cater for variations in use cases (from tracking “beneficiaries” earlier to currently track any “entity”). This arguably seeks to technically develop DHIS2 as a GPG.

The benefit of generification and resultant flexibility is dependent on, and sometimes offset by, an increased level of skills needed to properly take advantage of it. The result in the case of DHIS2 is that it is not an “appliance” meaning it is not ready to use for all cases. It is often described as a flexible “empty shell” which requires significant resources and expertise to set up and become operational. Thus, start-up costs are high because there is a need to source skilled technicians for customization and specialists to train staff. It is also a normal requirement for users to attend DHIS2 Academies to invest in capacity building while at the same time remaining dependent on external technical assistance.

Reinforcing cycles are shown in several user groups developing their own apps because the bundled apps are not sufficient to their specific needs. Secondly, only a few of the HISP nodes are relatively competent and self-reliant in terms of managing DHIS2 (South Africa, India, and Tanzania for example) but the lack of compatible skills between these “intermediaries” and the ministries of health reinforces the tension. Ministries typically do not have the necessary skills and resources to fully take ownership of the application and this continues a dependence on the intermediary. So while the product DHIS2 seeks to become a GPG, the expertise needed is not GPG due to the software’s generic nature, which increasingly requires more expertise, infrastructure and resources to get it running.

The DHIS2 core team has tried to counter this challenge of creating more and more generic functionalities, but this keeps the need to build capacity and guidelines of use as a moving target, constantly requiring work and more resources. To help address this challenge, an online academy on DHIS2 fundamentals has been set up, which meets the characteristics of a GPG in terms of being open and free of cost, but so far only available in English (work is underway for French and other languages). More work is thus required to make it freely and non-exclusively available.

One episode exemplifying several of the tensions brought up in this paper is from Uganda, as reported by Roland et al. [14]. A new feature of DHIS2 was under development, and input from several countries were sought to make this as generic as possible. At the same time, this input was of course rooted in some particular demands in the various countries. In Uganda this led to a tension between solving something locally, quick, and building a generic product over time. The local project staff in Uganda revealed that “It is frustrating to have to wait for a new ‘global release’ every time a requirement or change has been suggested.” [14, p. 19]. So while the developers thought they were accommodating the request by making a generic feature for the use case in Uganda, the local staff felt that their specific and immediate needs were sacrificed.

4.3 Tension: Supporting the Platform Core vs. Supporting Innovation in the Fringes

The substantial investments in the DHIS2 software including the apps derived from it are directed towards and largely consumed by the UiO core activities. While the DHIS2 platform is an open platform and provides its own open access app store, it does not appear as a particularly generative platform in terms of spurring innovation by a broad range of contributors outside UiO. While the attributes of the platform may be conducive for innovation, its broader socio-technical generativity in terms of incentives, human capacity, access to innovation networks where new attributions of technology can develop, are weak and untapped across developing countries. While there may be incentives to develop apps that solve local needs, there are few if any incentives to develop these into more generic apps. The route towards convincing the UiO developers to make locally developed apps or changes in the open source code as a part of the core is long.

This tension is reinforced by DHIS2 being developed independently from UiO into systems for other domains such as road accident reporting in Tanzania and civil registration in Tajikistan. These forks are developed based on substantial changes in the core and tailored for one country or use case. There are few if any resources available to invest in making the system generic for wider application.

Managing this tension, or rather to actively promote fringe innovation, is the very idea of the platform architecture of DHIS2. A relatively stable core and boundary resources are, in theory, supposed to make it easier for third party developers to build on it. A few resourceful NGOs are in fact actively exploiting this to create their own custom apps, but governmental actors have been slow to utilize this potential. App development academies have been held, building this capacity in several countries. Still, a trade-off remains for ministries between adapting something that is free but not perfect, and finding resources to venture into app development.

4.4 Tension: Global vs. Local Accountability

The license of DHIS2 (based on BSD) in summary states that use is at your own risk and responsibility. It can be downloaded, reconfigured and re-programmed by anyone and for anything. Apps developed can be made with varying quality and for a wide range of purposes, some of which may be malicious. While UiO is accountable to the projects they are directly involved in, it is debatable whether they also are accountable to the various implementations of DHIS2. For example, how much should the UiO team strive to ensure secure and ethical use of DHIS2? This relates to making the software itself secure, but also its various server configurations as well as standard operating procedures ensuring that local customization is following security by design. There are cases of countries losing their data in DHIS2 because of poor management and there is a considerable risk that DHIS2 is used in poor implementations.

Platforms are commonly considered as underlying infrastructure that facilitate the implementation of applications. Platform owners typically are not accountable for the applications because they have not constructed them and because they do not control them. In the case of a platform as a GPG used within public health in developing countries, accountability of platform owners and developers for implementation and ethical use is undefined. The accountability of the global product related to the local development is unclear. There are also legal questions about which jurisdictions this falls within, and the means by which a global community provides support. The first point relates to reinforcing cycles related to server space, which is a challenging problem for most adopters of DHIS2. With limited capacity locally, a cloud based solution is generally adopted with an overseas provider (e.g. Amazon). Although the legal implications such as sovereignty may not be the GPG platform owner responsibility to engage in there is a role for advice to perform informed decisions. The latter concerns the various channels of communication for the user and implementer community. What is the responsibility for being an editor in these channels for the developers of the GPG, when they also host the various email lists etc.? A recurrent theme in country implementation can be to collect data on various user groups, such as key populations related to certain diseases (sex workers, for HIV for instance), or for any social program use. For instance, while in Norway it would be illegal to collect data about patients not directly related to health care, there have been instances where such data is collected in other countries. Examples can be religion, caste, or in general any minority. Such data has the potential to be misused.

The approach to this tension is perhaps the least mature, driven partly by ignorance or lack of interest by actors (funders, implementers, users), partly by UiO drawing a line of responsibility through the software license. However, some guidelines have been created ad-hoc for various countries, and a server academy has been developed to mitigate the worst examples of server and back-up management.

5 Discussion and Conclusion

The analysis offers a focus on tensions in GPG digital innovation platforms. To summarize on how can GPG platforms facilitate inclusive innovations, we present the table below (Table 1).

Table 1. Summary of Tensions, Reinforcing Cycles and Management “Countermeasures” in the DHIS2 Case
Full size table

This paper offers new insights into the particular design considerations of a GPG digital innovation platform going beyond the prescriptions of the mainly commercial platforms literature from the global North [3, 4, 6, 7, 12]. The main difference is in tension 1 - the recognition that some users have limited capacity to pay for the service so it is downloaded for free and there is lack of any explicit desire to monetize the platform by the owners. Thus the network effects between the participants display some unique characteristics in a GPG where the incentives of the platform “owner” are socio economic development rather than the “platform monetization” discussed in Parker et al. [12]. It remains an ongoing effort in the sense that building incentives to share among platform users is sometimes problematic. Cultivating a GPG mindset in the users as well as platform owners is necessary which may imply a cultural change. Regarding tension 2 there are some similarities with the commercial literature. For example, commercial digital innovation platforms such as SAP face the same problems of generification and localization as DHIS2 but in the case of SAP this is traded off with willingness of clients with deep pockets to pay for unique customisation. The attempts to manage tension 2 and 3 by offering free documents, UiO run academies demonstrate that the DHIS2 knowledge is in itself not a GPG. However, the DHIS2 digital innovation platform fulfils many of the characteristics of a GPG but the total cost of ownership is not zero This DHIS2 knowledge remains very specialist and a source of commodity livelihoods that is sold in the marketplace by consultants, app developers, trainers etc.

This paper also builds on the existing literature on DHIS2 such as Roland et al. [14]. Roland et al. have identified some of the tensions of participation but did not explicitly identify tensions of GPG. The tension 4 in particular has been given limited attention regarding the ethical considerations of maintaining a GPG digital innovation platform.