Digital Public Goods Platforms for Development: The Challenge of Scaling

Abstract

The purpose of this paper is to explore digital global public goods (DGPG) as a foundation for theorizing platforms for development. Global public goods (GPG) are widely accepted as fundamental for socio-economic development due to non-rivalry, non-exclusivity and global relevance. However, the challenges of extending the ideals of GPG to the digital platform domain are poorly understood and further theoretical developments are needed to advance our current knowledge of this relationship. To theorize the challenges, we draw on the GPG, digital platforms literature and concepts related to paradoxes. We illustrate the value of these ideas in making sense of the case study of the DHIS2 digital platform for health information primarily used in developing countries. Furthermore, the case analysis provides some practical implications on DGPG platforms.

Full text

Full Terms & Conditions of access and use can be found at
https://www.tandfonline.com/action/journalInformation?journalCode=utis20
The Information Society
An International Journal
ISSN: (Print) (Online) Journal homepage: https://www.tandfonline.com/loi/utis20
Digital public goods platforms for development:
The challenge of scaling
Brian Nicholson, Petter Nielsen, Sundeep Sahay & Johan Ivar Sæbø
To cite this article: Brian Nicholson, Petter Nielsen, Sundeep Sahay & Johan Ivar Sæbø (2022):
Digital public goods platforms for development: The challenge of scaling, The Information Society,
DOI: 10.1080/01972243.2022.2105999
To link to this article: https://doi.org/10.1080/01972243.2022.2105999
© 2022 The Author(s). Published with
license by Taylor & Francis Group, LLC.
Published online: 23 Aug 2022.
Submit your article to this journal
View related articles
View Crossmark data

THE INFORMATION SOCIETY
Digital public goods platforms for development: The challenge of scaling
Brian Nicholsona,b , Petter Nielsenb , Sundeep Sahayb and Johan Ivar Sæbøb
aAlliance Manchester Business School, University of Manchester, Manchester, UK; bDepartment of Informatics, University of Oslo,
Oslo, Norway
ABSTRACT
In this article we consider the notion of digital global public good and articulate our
understanding of it. Against this conceptual foil, we examine the development of DHIS2, a
global health platform inspired by public goods, focusing on the paradoxes that arise in
the scaling process. We find that the scaling dynamics played out differently at the macro
and micro levels, giving rise to the following paradoxes: addition of new functionalities to
cater to the universe of users across the world (macro level) works counter to the needs of
users in particular locations (micro level); responsiveness to the requests of the donors with
a global view (macro level) distorts the production process, as the voices of users, situated
in remote locations in developing countries, are not adequately heard; the system needs to
be simultaneously relevant across the global (macro level) and the local (micro level), when
the former calls for decontextualization and the later (re)contextualization. We then discuss
challenges these paradoxes create with regard to attaining non-rivalry and non-exclusion,
the defining characteristics of a public good.
Introduction
Over the years we have seen shifts in the discourse
around information and communication technologies
(ICTs) for development (ICT4D). The initial discourse,
now characterized as ICT4D 1.0, had a supply-side
focus, viewing the poor as passive receipts of aid.
Subsequently, ICT4D 2.0 reframed the poor as active
producers and innovators, and correspondingly
advanced a demand-driven focus (Heeks 2008). Lately,
the “digital platforms for development” discourse shifts
the focus from standalone ICT applications to “plat-
forms” and how these may enable a greater “level
playing field” for developing countries and foster
locally desired socio-economic development
(Nicholson, Nielsen, and Sæbø 2021; Bonina et al.
2021; Nielsen 2017). Complementary to this discourse
is that of digital public goods – how platforms can
be made public goods. However, there is limited con-
ceptual understanding and empirical knowledge of the
challenges of scaling of digital platforms in a global
context, and the bearing they have on developing
them into public goods.
Most prior research on digital platforms involves
studies of commercial, for-profit platforms situated in
the regulative institutions of the Global North (see
for example Cusumano, Gawer, and Yoffie 2019;
Gawer and Cusumano 2014; Ghazawneh and
Henfridsson 2013; Parker, van Alstyne, and Choudary
2016; Tiwana, Konsynski, and Bush 2010). The poten-
tial for translating and contextualizing digital plat-
forms for the purpose of socio-economic development
remains understudied (Nicholson etal. 2019). In this
article our key goal is to theorize the challenges of
simultaneously scaling up digital platforms and devel-
oping them into public goods. Empirically, we focus
on health.
The relevance of global public goods in develop-
ment is well-established in the domain of health (see
for example Moon, Røttingen, and Frenk 2017; Smith
et al. 2003; Smith et al. 2003; Smith and MacKellar
2007; Yamey, Ogbuoji, and Kennedy McDade 2018).
Lately, it has been extended to the digital context.
Yamey, Ogbuoji, and Kennedy McDade (2018) posit
that Ebola and other recent outbreaks like Nipah in
India and Zika in Latin America have renewed atten-
tion to financing and delivering “global public goods
for health.” Initiatives driven by global health institu-
tions like the World Bank and World Health
© 2022 The Author(s). Published with license by Taylor & Francis Group, LLC.
CONTACT Brian Nicholson brian.nicholson@manchester.ac.uk Alliance Manchester Business School, University of Manchester, Booth St. W.,
Manchester M15 6PB, UK.
https://doi.org/10.1080/01972243.2022.2105999
This is an Open Access article distributed under the terms of the Creative Commons Attribution-NonCommercial-NoDerivatives License (http://creativecommons.org/licenses/
by-nc-nd/4.0/), which permits non-commercial re-use, distribution, and reproduction in any medium, provided the original work is properly cited, and is not altered, trans-
formed, or built upon in any way.
ARTICLE HISTORY
Received 11 July 2020
Accepted 22 March 2022
KEYWORDS
DHIS2; Digital global public
goods; digital platforms;
health information systems;
HISP; tensions; public goods

2 B. NICHOLSON ETAL.
Organization are also trying to promote digital means
for developing public goods. Furthermore, Digital
Square, a marketplace initiative in digital health, has
developed a Global Goods Guidebook (Digital Square
2019) and a Global Goods Maturity Model (Digital
Square 2020), reflecting the growing interests in digital
global public goods (DGPG) for health which has been
further catalyzed by the global COVID-19 pandemic.
Several open source systems have been launched to
support outbreak management, such as the Surveillance
Outbreak Response Management and Analysis System
(SORMAS), which is being used in Nigeria, Ghana,
Fiji, and Germany. SORMAS was developed during
the West African Ebola outbreak in 2014/15 as an
early warning and disease management system and
was migrated into an open source software application
in 2016. SORMAS displays many features of a DGPG:
it is free of charge, open source, independent from
tech companies, and interoperable with other platforms
such as DHIS2. However, there is a paucity of con-
ceptual work on DGPGs. We take an initial step
toward conceptualizing DGPGs in this article.
We believe such an analysis is crucial for both the
research and practice of ICT4D. Conceptual under-
standing of the nature of DGPGs and their scaling
related challenges will provide rich contributions to
ICT4D discourses, particularly on how the potential of
technology can be better materialized for development.
In our theorization, we focus on “paradoxes,” leveraging
them to develop a conceptual understanding of where
the dynamics of scaling up help and hinder the devel-
opment of global digital platforms as public goods.
Empirically, we take the case of the DHIS2 (District
Health Information Software Version 2), one of the
largest and long-standing digital platforms being used
for global health, which the HISP (Health Information
Systems Program) community strives to give more pub-
lic good characteristics (Braa, Monteiro, and Sahay
2004). The article is organized as follows: in the next
two sections, we present related literature on global
public goods and digital platforms and present our
approach to theorization. The section that follows pres-
ents the methodology and case context. The subsequent
sections present three vignettes that bring out the par-
adoxes that complicate efforts to develop global digital
platforms into public goods. The article concludes with
some implications for theory and practice.
Public goods perspective on digital platforms
The notion of public goods, originating in the econom-
ics discipline, centers on two principles: non-rivalry and
non-exclusion (Ostrom and Ostrom 1977; Samuelson
1954). Public goods are non-rivalrous, implying that
one individual’s consumption of the good does not
influence what is available for others. They are also
non-excludable, in the sense that no one can be excluded
from consumption of a public good. An oft-cited exam-
ple is that of a lighthouse, where one navigator’s use of
the light does not prevent other navigators from doing
the same. Many goods exhibit only one of these prop-
erties, often resulting in the tragedy of the commons
(Hardin 1968), which is commonly explained with the
following example: unrestricted access (non-exclusion)
to the commons – pasture belonging to the village as
a whole – leads to its degradation (rivalry). In her
critique of Hardin's pessimistic model, Ostrom (1990)
questions the expectation of depletion of common pool
resources when they are managed in a bottom-up, coop-
erative way by those most dependant on them. Based
on several empirical case studies, Ostrom shows that
under certain conditions, individuals govern themselves
collectively, and without market pressures or govern-
ment regulation, to obtain benefits, even if the temp-
tation to freeride is present.
DGPG in addition to being non-rivalrous and
non-excludable would also be available across the
globe (Kaul, Grunberg, and Stern 1999). Since DGPG
would be spanning geographies and social groups, we
posit that relevance should be of importance. Such
relevance can be created by leveraging the adaptability
offered by the digital. In Table 1, we sum up our
understanding of DGPG.
Development of DGPG is then a matter of design:
design of the technical system, and the design of incen-
tives. On the technical level, the digital technologies
offer myriad configural possibilities. They are adapt-
able, reusable, re-programmable, and re-combinable.
These qualities allow for the design of systems that
are inclusive and scalable. Furthermore, they could be
open platforms that host and incorporate complemen-
tary, derivative, and over-the-top innovations by users
and other parties (Bonina et al. 2021; Boudreau 2018;
Gawer and Cusumano 2014; Ghazawneh and
Henfridsson 2013; Nielsen and Aanestad 2006;
De Reuver, Sørensen, and Basole 2018; Roland et al.
2017; Tiwana, Konsynski, and Bush 2010; Yo o,
Henfridsson, and Lyytinen 2010).
Table 1. A denition of digital global public goods (DGPG).
Digital global public goods are digital goods designed as non-rivalrous,
non-excludable, locally relevant on a global scale, and displaying positive
network eects.
Digital Adaptable, reusable, re-programmable,
and re-combinable
Global Relevant locally and on a global scale
Public Goods Non-rivalrous and non-excludable

THE INFORMATION SOCIETY 3
With regard to incentives, our experience so far
with global platforms has been an overwhelming
emphasis on monetization and profits, (Cennamo and
Santalo 2013; Jacobides, Cennamo, and Gawer 2018;
Taplin 2017; Wareham, Fox, and Cano Giner 2014).
We posit that it is possible to design incentives that
accord with those of public goods.
The analytical lens of paradoxes
As Putnam, Fairhurst, and Banghart (2016, 72),
explain paradoxes are “comprised of contradictions
that persist over time, impose and reflect back on
each other, and develop into seemingly irrational or
absurd situations because their continuity creates sit-
uations in which options appear mutually exclusive,
making choices among them difficult.” Herein a con-
tradiction represents “bipolar opposites that are mutu-
ally exclusive and interdependent such that the
opposites define and potentially negate each other”
(70). Similarly, Smith and Lewis (2011, 386), define
a paradox as: “contradictory yet interrelated elements
that exist simultaneously and persist over time”
In a seminal paper on paradoxes and theory build-
ing, Poole and Van de Ven (1989) identify a paradox
as “concerned with tensions and oppositions between
well-founded, well-reasoned, and well-supported alter-
native explanations of the same phenomenon” (565).
They then identifying four different ways by which
the theoretical tension between the two opposing the-
ses could be leveraged:
1. accept the paradox and use it constructively;
2. clarify levels of analysis;
3. temporally separate the two levels; and
4. introduce new terms to resolve the paradox
(562)
These four approaches can be used in combination
to make sense of and bring about resolutions of par-
adoxes. Following Poole and Van de Ven (1989), we
identify paradoxes and leverage them for our
theorization.
Project background
This research was carried out under the aegis of the
global HISP, a network of North-South-South collab-
oration where the Department of Informatics,
University of Oslo (UiO) has a key role as the plat-
form owner. This collaboration represents the move-
ment in the health informatics domain to strengthen
health information systems in developing countries
(Braa and Hedberg 2002). A key output of HISP is
the DHIS2 digital platform, released as a free and
open source artifact.
We chose DHIS2 as our case partly because of the
authors’ extensive and long-term engagement with this
project, which has provided unique insights, experi-
ence, and access. Since its inception as DHIS Version
1 in the mid-1990s in South Africa, the DHIS2 has
grown in stature and maturity and now represents
one of the most important digital platforms globally
in the health and other sectors, such as education,
food security, water, sanitation, agriculture, and road
safety. The DHIS2 today is supported by several devel-
opment partners (such as Gavi, Global Fund, UNICEF,
and Gates Foundation) as a public good – central
funding to UiO for the development of the platform
should lead to benefits that are made available to all
(currently 70+ countries use DHIS2). UiO seeks to
build and release DHIS2 as a DGPG but faces many
practical challenges ensuring non-rivalry and
non-exclusivity, which has implications on its scaling.
Building and evolution of DHIS2 as a DGPG
As a fusion of participatory approaches to software
development and a health management philosophy of
decentralization, DHIS was strongly inscribed with
the needs of district health managers to design and
manage their information system themselves (Braa
and Hedberg 2002). The adoption of DHIS spread
over the years up to national coverage in South Africa
and, in the early 2000s, initiatives began in other
countries to adopt it. To take advantage of the grow-
ing internet penetration DHIS2 was introduced in
2006 taking the form of a web-based interface, incor-
porating novel functionalities based on the specific
implementation needs in new countries. The Indian
state of Kerala and Sierra Leone were the first imple-
mentations, and by 2010 Kenya was the first country
to implement a fully online and web-based system as
mobile internet was considered adequate at the district
level (Manya et al. 2012).
It was, and continues to be, a digital software plat-
form primarily to support decentralized routine health
management. The functionalities support all stages of
the information cycle, from data collection, through
processing, to analysis and presentation. Its spread is
a product of the innovation platform logic (Bonina
et al. 2021; Cusumano, Gawer, and Yoffie 2019); the
architecture is designed with a generic core that
enables local innovation. Anyone with internet access
can at any time download the most recent version of
DHIS2, the source code, as well as required libraries

4 B. NICHOLSON ETAL.
and third party products (such as Chrome or Firefox
browsers). DHIS2 also comes with a set of bundled
apps, developed by UiO or through its partners in
the South (such as HISP Tanzania, an independent
entity with close collaboration with UiO) available in
an “app store.” It is similar in concept to Apple App
Store or Google Play and some DHIS2 apps are also
available on these platforms too. The platform archi-
tecture allows local innovation as apps, increasing its
potential relevance globally.
Both the cause and consequence of the growth and
global scale of DHIS2 platform is its generic nature.
The process by which DHIS2 has become increasingly
generic is neither linear, intentional, nor has it fol-
lowed a strict pattern. However, over time, function-
alities, which may initially be developed to address a
specific problem in a particular context, are “polished
by diversity” into a generic and global version avail-
able for download (Sahay, Sæbø, and Braa 2013).
DHIS2 is composed of a core of generic and flexible
meta-functionalities, allowing customization to varied
contexts. The other defining process has been that of
platformization, which also was not a product of an
intentional strategy but grew out of efforts to respond
to increases in scale and to decrease dependencies in
an increasingly complex software application. At the
time of writing, DHIS2 consists of a stable core, appli-
cation programming interfaces (APIs), bundled apps
covering most use cases and apps developed by part-
ners and third-party developers available in the DHIS2
“app store.” The organizations in the DHIS2 ecosystem
have also grown over the same period.
Due to its openness and flexibility, it is impossible
to know the exact number of DHIS2 implementations.
It is known that ministries of health and other orga-
nizations in more than 100 developing countries use
DHIS2, together covering an estimated population of
2.4 billion people.1 In November 2020, the ministries
of health in 73 countries (primarily developing coun-
tries) used DHIS2, out of which 60 were nationwide
implementations, and 13 were in the pilot stage. In
addition, 22 Indian states used DHIS2. There is also
a range of other organizations using DHIS2 inde-
pendently for reporting in the countries they are
operating, including PEPFAR, Médecins Sans
Frontières (MSF), International Medical Corps,
Population Services International (PSI), and Save the
Children.
The DHIS2 Academies are a core part of the
DHIS2 community and crucial for the development
of the national and regional capacity to successfully
set up, design, and maintain DHIS2. The Academies
have three levels, including the Fundamentals,
available online and for free; Level 1 covering the
basic features of DHIS2; and Level 2 covering spe-
cialized topics, including disease surveillance, server
administration, and implementation strategies. The
Academies in 2020 were primarily online, and Level
1 attracted approximately 170 participants, and Level
2 attracted 400. The digital DHIS2 annual conference
attracted 940 participants globally, to share their expe-
riences from DHIS2 implementation and together
build knowledge from the various usages and settings.
As of November 2020, HISP UiO had 82 employees
working with the DHIS2 software and supporting its
implementation. This included 47 software developers,
out of which 15 were located at UiO (the remaining
in Spain, Vietnam, the US, and other countries). In
addition, UiO had an implementation support team of
23 (10 located at UiO) and 12 working with informa-
tion and support (10 are located at UiO). UiO supports
the implementation of DHIS2 in countries through a
network of 10 HISP groups. HISP groups are long term
and trusted UiO partners located in developing coun-
tries (currently in Bangladesh, India, Mozambique,
Nigeria, Rwanda, Sri Lanka, Tanzania, Togo, Uganda,
Vietnam). HISP groups engage in DHIS2 software
development, and they arrange national, regional, and
global capacity building activities including hosting and
arranging DHIS2 Academies. They play a key role as
a local capacity that can provide implementation sup-
port to ministries of health, health programmes, and
others in their country and region. Regarding funding
of the team at UiO and implementation projects in
countries, there are a number of financial partners
(donors), including the University of Oslo, The
Norwegian Agency for Development Cooperation
(Norad), The Global Fund to Fight AIDS, Tuberculosis,
and Malaria, The President's Emergency Plan for AIDS
Relief (PEPFAR), Bill & Melinda Gates Foundation,
Center for Disease Control and Prevention (CDC), the
vaccine alliance Gavi, UNICEF, and the World Health
Organization (WHO).
Methodology
We follow a similar approach to Roland etal. (2017)
in data collection and analysis. The data have emerged
from the authors’ individual activities, analyses, col-
lective discussions, and reflections concerning DGPG
and paradoxes related to DHIS2. The involvement of
the authors with HISP, DHIS2, and health information
systems spans contexts, processes, and several decades,
but only more recently has a focus developed on
DHIS2 as a DGPG.

THE INFORMATION SOCIETY 5
Our case study is interpretive (Walsham 1995,
2006) and data were collected during participant
observations during activities such as software devel-
opment, strategy development, international seminars,
discussions at conferences, implementations in mul-
tiple countries, discussions with funders, and partic-
ipation in or running training workshops.
We use three revelatory vignettes to identify the
paradoxes that have arisen in the scaling of DHIS2.
As Kotlarsky, Scarbrough, and Oshri (2014) explain,
a vignette is a tool to zoom in on, illustrate, and
examine key processes and episodes in a case study
They have a story-like structure with a chronological
flow and are limited in time, space, and the number
of actors involved (Miles, Huberman, and
Saldana 2013).
Vignette 1 is mainly based on participation in
regional meetings of monitoring and evaluation (M&E)
officers in three districts in India in 2018, where two
of the authors were present and engaged as participant
observers. This vignette could be taken to be an epi-
sode in a participant observation engagement that was
longitudinal in nature, involving contact with the field
site over a period of about two years and extensive
interviewing of key participants, coupled with access
to documentary evidence such as memoranda and
reports. Vignette 2 draws on authors’ active engage-
ment with prioritization debates and actions in UiO.
The authors are co-located with the DHIS2 develop-
ment team in Oslo, participate actively in development
projects and have regular daily contact as participant
observers including attendance at formal (e.g., DHIS2
development roadmap presentations) and informal
meetings (over lunch or coffee and social gatherings),
related presentations, and events such as the DHIS2
conference when the global community of DHIS2 users
are invited to Oslo. The authors also collected data on
ongoing development priorities by accessing the DHIS2
discussion forum2 and the internal DHIS2 development
Slack community discussion where functionality
changes are often discussed and reported. Furthermore,
some of the specifics that are reported in the vignette
concerning the introduction of the new tool for road-
map prioritization were derived from an interview that
was recorded and transcribed with one of the DHIS2
product leads. Lastly, vignette 3 is derived from the
longitudinal doctoral research on DHIS2 implementa-
tion conducted by Abyot Gizaw (2014), who is one of
the DHIS2 core developers now based in Oslo. Abyot’s
doctoral dissertation was supervised by one of the
authors, who acted as advisor, participant observer,
and carried out some of the interviews with Abyot in
India and Ethiopia.
In addition to participant observation, all three
studies from which we select the vignettes used
semi-structured interviewing following the interpre-
tive case studies approach. Interviewees were asked
to respond to broad questions and encouraged to
offer their own worldview and respond more broadly
than in a structured interview. The interviews were
supplemented by other data sources such as com-
pany documents, the minutes of meetings, and infor-
mal contact. The sites were visited regularly or
several times over a period of years. This study
thereby captures the process of change over time
including shifts in the action and perception of
the actors.
Vignette 1: The paradox of using
sophisticated tools for relatively simple
analysis
Context
Uttar Pradesh is the most populous state in India,
and with 200 million inhabitants is the most populous
sub-national division in the world. Administratively,
the state is divided into 75 districts and 800+
sub-district units (called Blocks) which become the
focal units for the delivery of health care services to
its population. Given the size of the state and its
historically poor health indicators, the Bill and
Melinda Gates Foundation (BMGF) established a stra-
tegic alliance with the state to support processes for
strengthening the health system, including those relat-
ing to health information systems (HIS). The imple-
mentation is managed by the India Health Action
Trust (IHAT) established in 2003 by the University
of Manitoba, Canada under a bilateral agreement of
the governments of India and Canada. IHAT in turn
contracted HISP India, an NGO, in 2015, to carry
out various HIS strengthening activities. The focus
was on creating a statewide central portal on the
DHIS2 which would host all state health related data
in one database, to enable stronger analysis and use
of information.
The vignette
The vignette concerns a visit of two Oslo researchers
in 2018 to observe regional meetings of M&E officers
covering several districts. In these meetings M&E
officers discuss their monthly health data (generated
from the DHIS2) and see how it can support
decision-making and follow-up in respective priority

6 B. NICHOLSON ETAL.
areas of districts. The vignette focuses on the use of
the Pivot Table feature of the DHIS2 for enabling user
defined statistical analysis.3
At the end of the meeting, the Oslo researchers
initiated an open discussion with the M&E officers
on the various output related tools in the DHIS2,
including the dashboard, analytical tools such as the
pivot table, and other features for generating output
reports, the ease of effective visualization, data quality
tools, and various others. The aim here was to under-
stand how these various output related tools were
relevant to the officers for their everyday use and
analysis, and how could it be improved to suit
their needs.
In general, the officers said the system was easy
to use, but they had the following complaints:
• Generating reports was a time-consuming
process due to poor internet connectivity. To
get around this bottleneck, at the sub-district
level, the sta entered data into Excel sheets
which were then imported into the Uttar
Pradesh Health Management Information
System (UPHMIS) portal. However, this was
a laborious time-consuming process, as mul-
tiple facility data had to be uploaded. While
this uploading process helped work through
internet constraints, it meant the data valida-
tion functionalities available at the point of
data entry in the DHIS2 could not be used.
• IHAT team took responsibility for validating
data monthly by correcting data entered in
the UPHMIS portal and the data recorded
on paper through local validation committees.
ere was limited ownership of the data by
the district doctors since they were not enter-
ing the data. e doctors also believed their
problems were elsewhere (lack of medical sta,
medicines, and equipment) and not directly
related to the HIS. As users were not able to
provide feedback through the system or view
inter-district or inter-block comparative data,
their motivation levels were low.
• ere were also basic problems with the data
conguration in the application. For example,
there were too many data elements to report on
(monthly dataset was 8 pages long), even though
some services relating to those elements were not
provided at the facilities. Similarly, in hospitals
the sta had to report data on services pro-
vided in the night, which never happened. is
resulted in many blanks or zeros in the reports,
which showed the facilities in a bad light.
• ere were reasonably well-established insti-
tutional processes around routine data man-
agement. Sub-district level block validation
committees made monthly data quality anal-
ysis. e M&E ocers had monthly review
meetings with the district magistrate (civil ser-
vant who is head of district administration).
For these routine processes, the M&E ocers
expressed the need for easy to use tools for
visualization through charts and bars, and to be
able to do easy export to Microso PowerPoint
les. ey also needed tools to drill down on
the data to perform root cause analysis, which
was currently not possible. ey would also
like to see more detailed error messages. For
example, they would get a message that “36
data elements are ignored,” but it was not
clear which were those elements. ey would
like to see the results of a validation analysis
in a summary table which gave in one place,
the errors, its type, source, and time period,
and what was checked and what was violated.
Sometimes it would seem that data were being
uploaded, but the users would not get to know
if the process has been completed or there has
been an error.
• Given the challenges of working with poor
internet connectivity, users said they would
also like the option to download only parts
of the raw data, which was not possible. They
also talked about layout issues, e.g., display
of other users’ favorites in the dashboards,
increased visibility of apps that were in a
corner.
• On the pivot tables, they believed that there
were too many options (such as on periods –
daily, weekly, fortnightly, etc.), while they
needed just one or maximum two options.
They also wanted easier to use information
on how to populate minimum/maximum val-
ues for conducting data validation.
• ey talked about issues in creating outputs,
for example, the HMIS report could be down-
loaded only as a PDF le, when they needed it
in Excel. In creating the monthly report, they
would like to just give the name of the month
and not the start and end dates. ey com-
plained about the inconsistent nomenclature
(such as “institutional deliveries” and “institu-
tional deliveries new”) which made it dicult
to select reports. ey also got confused about
the fact that the data list came in alphabetic
order while in the report there was no data

THE INFORMATION SOCIETY 7
entry order followed. In the reports, with the
facility code, they would also like to know the
corresponding district and block names, which
was not possible. ey also would like more
analytical outputs such as scorecards, league
tables, with more descriptive labels (not just
short names). ere were also challenges in
printing of reports, particularly in terms of
formats and completeness of printouts.
Analysis
In this vignette we see paradoxical consequences of
scaling at the macro and micro levels. While the
development team continued to add in their releases
of new features for strengthening outputs and anal-
ysis, the typical user in a district of a developing
country required more basic functionalities, and the
new features often detracted from the software’s
value for the user, e.g., numerous options for time
periods.
Following Poole and Van de Ven (1989), we clarify
the levels of analysis. At the macro-level, the devel-
opment team were seeking to cater to the universe
of users, including district users, researchers, and data
analytic experts in multiple country contexts. This
required them to continuously add new features, often
for increasingly sophisticated use. This process went
counter to the needs at the micro-level of the users
in district offices, who wanted specific and easy to
use functionalities for their everyday use. This para-
doxical relationship resulted in opposing scaling
effects. While making the product more comprehen-
sive helps the scaling at the macro level (such as
movement across countries and user groups), it proves
detrimental for varied local contexts, thereby con-
straining scaling processes. Resolving this scaling par-
adox would require effective advancements
simultaneously at both the levels of the macro and
micro, with mutually synergistic effects, described by
Gizaw (2014) as generative innovation.
Vignette 2: The paradox of prioritizing voices
that tend to be unheard
Context
Initial software development for the early versions of
DHIS2 (in 2006 and further to 2012), was carried out
primarily by masters and doctoral students who were
intimately involved in local implementations and
worked with the users of the information systems.
With the massive increase of DHIS2 implementations
over the last one and a half decades, this in-context
development style is no longer viable. Consequently,
the development process has been professionalized,
with up to 50 full-time developers organized in var-
ious product teams coordinated by the core team in
Oslo. Correspondingly, the number and heterogeneity
of users and organizations has grown, and the demand
for new development is far outstripping the availability
of resources. It has also become much more difficult
for developers, detached from sites of actual use both
culturally and geographically, to assess what should
be prioritized. In this context, for the continuous
development of DHIS2, much depends on the plat-
form development roadmap, which prioritizes user
requests for changes originating from different regions,
specific countries, and user groups. Inevitably, the
core team in Oslo cannot accommodate all user
requests neither can commensurate resources, critically
developer time, be dedicated to each request. In effect,
process for prioritization, which is inherently a com-
plex task, cannot satisfy everyone.
The vignette
The product lead of the DHIS2 analytics team
responded to the challenge of prioritizing requests in
what was thought to be an objective manner by devel-
oping a roadmap prioritization matrix. Most use-cases
need analytics functionality and a wide variety of
requests are directed to this team. The product lead
estimated that the analytics team can only accommo-
date about half the requests at any stage of the prod-
uct development cycle. The question facing this
individual is: “which requests should be prioritized,
coming from whom, and in which release cycle?” The
primary implementations of DHIS2 are users from
governments in low and middle income countries,
according to the product lead, who tend to not
actively voice their requests for changes in function-
ality. These groups are constrained by physical sepa-
ration often across great distance, limiting ability to
meet in person and develop social relationships. By
contrast, users from donor organizations and other
users in the West, tend to have closer proximity and
resources to visit Oslo and “make their voices heard,”
resulting in greater influence over the DHIS2 func-
tionality development. This mismatch led the product
manager to develop this “objective” prioritization
methodology.
The two axes of impact and origin provide the
basis for a combined score, with a certain threshold
for requests to be accepted on the DHIS2 platform
roadmap. The impact is assessed based on four

8 B. NICHOLSON ETAL.
criteria: perceived benefits of the request for different
user groups, global relevance, ease of implementation,
and the availability of developer resources. Origin of
the request is classified in the following order of
priority: internal request (highest score), ongoing
projects (thus tied to deliverables), partners, known
users, new users and unknown (such as being picked
up from the public discussion forum). For example,
a single new user will have to request something
assessed as having critical impact to make it to the
DHIS functionality roadmap, whereas a ministry of
health involved in an ongoing project can request
requirements assessed as having low impact but get
accepted on the roadmap. At least, this is the prin-
ciple in theory, in practice, the process of determin-
ing potential impact of new functionality is
problematic. UiO software developers are responsible
for this determination of impact, using several inputs
to aid them:
• First, some requests originate from the online
discussion forum for DHIS2 users, where it
is possible to quantify impact by counting
replies to a request, voting, and number of
“likes”. A forum administrator typically pro-
cesses several requests and formulates these
into “tickets” in the DHIS2 issue tracking
system.
• Second, developers attempt to document the
reasoning behind the request. is process is
facilitated by the group of experienced users
who commonly make requests and have good
habits of documentation. However, most users
tend not to provide detailed explanation of the
reasoning behind the request, which inuences
the outcome.
• ird, the origin of the user making the request
inuences the evaluation of impact.
A user who is well-acquainted with DHIS2 will
probably have good reasons for suggesting improve-
ments, even if the full reasoning behind it is not
immediately obvious to developers. This leads to a
major quality difference between the requests. A com-
pany with long-term ties to the core team and much
experience in using and deploying DHIS2 will provide
well-articulated and well-motivated tickets, making it
easier for the core team to work with the request. At
the same time, description of tickets coming from
users in the Global South tend to be relatively skimpy
on details required, and thus more difficult for the
developers to work with. Further, the ministries of
health of low and middle income countries are
typically not directly paying for the follow-through
on their requests, as these are met through a complex
mechanism of pooled funds from donors to the core
team in Oslo. Consequently, their voices tend to be
heard less than those directly paying for their requests.
The “objective” prioritization methodology for
ranking requests leads to a score between 0 and 1000.
However, the DHIS2 product lead estimated that the
scores of around half of the requests change at least
once. These changes can emanate from a further
round of prioritization considering the estimate of
effort required to implement the new functionality.
For example, implementation of demanding requests
depends on a very high score. Further, requests
deemed not so important can end up in larger groups
and receive a “bundled” score. This is typical for some
user interface requests, which may be minor such as
changes to font sizes. These would never be prioritized
to the roadmap for a single user but if bundled
together may be accepted onto the roadmap. Once
on the roadmap, with a score from the ranking exer-
cise, requests go through one more stage of prioriti-
zation that deals with requests with the same score.
To resolve these cases the various DHIS2 product
leads meet to agree on an order of priority.
Change requests are conditional on available
resources which in the case of DHIS2 were initially
funded by grants from Norad. While this core funding
has continued, other global donors and NGOs have
also joined to provide financial support. However,
these users often tie their funding to deliverables of
functionality serving their needs. While the function-
ality will be available to all, these users are in a very
different position compared to ministries of health
and health programs in developing countries without
any financial resources to invest. The product lead
estimates that 60-70% of requests come from HISP
groups and other partners in the Global South, while
the rest comes from international NGOs. The HISP
groups typically want stable features, while the NGOs
want more cutting-edge features.
Analysis
This vignette spotlights the paradox that while min-
istries of health in low and middle income countries
are the core target group for DHIS2, since HISP is
funded by development partners like Norad and
UNICEF and not them, they have limited influence
in shaping the prioritization of the development road
map. This mismatch then has implications as described
in vignette 1, where increasingly sophisticated features
are consistently added to the DHIS2, which may be

THE INFORMATION SOCIETY 9
of marginal relevance to the core target group. Various
factors contribute to this paradox. The scattered users
have weaker abilities than the international NGOs to
coherently voice their priorities in a way that their
influence is heard and acted upon. Furthermore, the
users have inherent difficulties (e.g., language,
resources) in articulating their needs and having their
voices head. On the other hand, donors’ voices are
supported by contractual stipulations and their rep-
resentatives’ trips to Oslo for lobbying activity leading
to high levels of priority and influence in shaping the
development trajectory of the DHIS2 platform. In
effect, the prioritization matrix is inherently
ill-equipped to deal with the many subjectivities
involved.
Following Poole and Van de Ven (1989), we again
clarify levels of analysis. DHIS2 scaling is taking place
across geographies and domains of usage, however,
the production process has distortions arising out of
the prioritization process that favors the donors at
the macro level, while at the micro level the users’
voices are not adequately heard. It has proven impos-
sible to remove subjectivities in the implementation
of the supposedly objective prioritization methodology.
Similarly, on the consumption side, there are chal-
lenges of unequal infrastructure, resources, and knowl-
edge. This paradox points to a counterintuitive
solution of sorts: deliberate constraining of scaling to
allow for the possibility of non-rivalry and
non-exclusivity.
Vignette 3: The paradox of building software
simultaneously relevant for global and local
contexts
Context
This vignette is based on the experiences of a core
development team member, Abyot Asalefew Gizaw,
who carried out DHIS2 application development both
at the country level (in Ethiopia, India, and Tajikistan)
and with the core development team at Oslo over the
last 14 years. In his doctoral dissertation, Gizaw (2014)
analyzed through the notion of “open generification,”
the paradox that arises in making the DHIS2 simul-
taneously relevant both for local and global settings.
This vignette brings together two examples from his
research, one of a success and the other of a failure.
The vignette
The development team of the DHIS2 is engaged with
designing generic technology that fits in multiple
contexts, trying to find a pragmatic balance between
global and local settings. The premise of this devel-
opment effort is that while software travels as a global
actor, its use is situated in multiple local settings,
characterized by their particular social, cultural, polit-
ical, and technical realities. The challenge is how to
bring these sets of processes into a virtuous cycle and
generate a continuous interplay that enables global
software to travel and for local use to be a success.
The first example is from India, where the HISP
India team in 2007 was working for a particular state,
engaged with building a dashboard based on the
DHIS2. At the time, the DHIS2 was at a very nascent
stage. This state’s commissioner of health, who was a
visionary and very interested in data analytics, invited
the HISP India team to design dashboards. The lead
developer from HISP India, literally sat in the com-
missioner’s office for several months, and he would
be given specific instructions on what kind of visu-
alizations were needed, going into micro details, e.g.,
color, location on the screen. To say the dashboard
was hardwired to the requirements of the state would
be an understatement.
Additionally, there were issues concerning the skill
levels of the Indian developers and the quality of the
software code being written. The local team had its
own software code writing style, and in general, it
did not practice modular and architectural design
principles, as was being promoted by the global team.
The limited communication between the global and
Indian teams, resulted in the local team working
within their own framework and practices. At a later
point, the global team attempted to refactor the local
dashboard solution and build a generic solution out
of it but could not succeed because of the code lim-
itations and inadequate documentation. Going through
the thousands of lines of code to refactor and restruc-
ture turned out to be a frustrating encounter, which
convinced the global team to abandon the local solu-
tion and develop a new dashboard from scratch. In
sum, the dashboard solution while becoming very well
embedded into the Indian state system, could not be
disembedded from that context, rearticulated, and
reembedded as a global generic solution.
The other story is from Ethiopia, around the same
time as the Indian case, concerning the development
of multidimensional attributes to data elements in
the DHIS2. With this functionality, different catego-
ries could be assigned to data elements (such as chil-
dren 0 to 5 years and 5-10 years), and respective
values noted against each category. Prior to this func-
tionality being provided, each category was treated
as a separate data element. The limit of such an

10 B. NICHOLSON ETAL.
approach was experienced by Gizaw when he was
designing the national health information system for
Tajikistan. In Tajikistan, each data element had an
extremely high number of categories and
sub-categories, leading to the national system having
more than 30,000 data elements. Catalyzed by this
experience, Gizaw was driven to find an appropriate
technical solution, which could then also be used for
his project involving the Ethiopian Morbidity and
Mortality system. This system also needed to be able
to report morbidity and mortality figures by multiple
categories of age and gender. Several factors contrib-
uted to the success of this functionality. One, the
developer (Gizaw) had a direct field experience (in
Tajikistan and Ethiopia) of the problem and the
urgent need to find an appropriate technical solution.
Two, subsequently Gizaw joined the global team in
Oslo, and was able to interact with the global team
to understand global design approaches and gradually
refactor his local solutions and make it more generic
and relevant for the global core. Three, Gizaw also
took generification as a central problem of his doc-
toral dissertation, and thought deeply of how to
address this challenge, both conceptually and prac-
tically, which helped to design a well thought out
and elegant solution. Four, the quality of the code
developed in the Ethiopian case was higher than in
the Indian example and was thus more easily amena-
ble to refactoring and generification.
Analysis
Following Poole and Van de Ven (1989), we again
clarify levels of analysis. DGPG must be relevant
simultaneously at the macro level for global setting
and at the micro level for multiple local settings.
To be relevant locally, the code must be deeply
embedded in the local context, and to be globally
relevant, it should be possible to disembed the code
from the local context and to circulate it across
multiple settings. This requirement is inherently
paradoxical. Between the local and global, there is
a need for continuous cyclical interactions.4 In
other words, scaling involves processes of embed-
ding, when going from the generic to multiple spe-
cifics; and disembedding, when coming back to the
generic from multiple specifics. The interaction
takes place in a broader contextual space charac-
terized by work practices, organizational structures,
infrastructures, standards, policies, and funding, as
well as political, cultural and societal values. Success
depends on several factors: the quality of the code,
the possibility of the developers to engage with
both local and global conditions to understand
competing requirements, and other institutional and
technical conditions.
Discussion and conclusion
In various ways the vignettes spotlight the paradoxes
encountered in the scaling of DHIS2. All three cases
called for clarification of levels of analysis, one of the
four methods identified by Poole and Van de Ven
(1989). In all the three cases, we saw that the scaling
dynamics played out differently at the macro and
micro levels. In the first vignette, we encounter the
paradox: addition of new functionalities to cater to
the universe of users across the world (macro level)
works counter to the needs of users in particular
locations (micro level). In the second vignette, we
encounter the paradox: responsiveness to the requests
of the donors with a global view (macro level) distorts
the production process, as the voices of users, situated
in remote locations in developing countries, are not
adequately heard. In the third vignette we encounter
the paradox: the system needs to simultaneously be
relevant across the global (macro level) and locally
(micro level), when the former calls for decontextu-
alization and the later contextualization. These para-
doxes create challenges regarding attaining non-rivalry
and non-exclusion, the defining characteristics of a
public good
We now proceed to discuss: (1) whether DHIS2 is
an DGPG, and (2) how paradoxes may be addressed
in relation to collective action and subsidiarity. Finally,
we summarize our contributions and draw implica-
tions of our research.
Is DHIS2 a model DGPG?
Ostrom and Ostrom (1977) noted that public goods
are usually supplied by the state, or some other col-
laborative network, which seeks to coordinate collec-
tive action on behalf of the public. In the case of the
DHIS2 platform, UiO has taken this responsibility
together with partners, including donors and minis-
tries of health. The DHIS2 app store mirrors the suc-
cess of commercial platform ecosystems such as those
around iOS and Android, reaping the benefits of pos-
itive network effects. However, our analysis of all the
three vignettes reveals the challenges of attaining
non-rivalry and non-exclusivity. In effect, DHIS2 has
the potential to truly become a DGPG, if these chal-
lenges are surmounted.

THE INFORMATION SOCIETY 11
Collective action and subsidiarity
Across all three vignettes, the more macro interests
of the donors appear incompatible with the smaller
players who become increasingly marginalized.
Furthermore, their capacity for collective action is
limited by structural factors.5 This asymmetry, which
keeps growing over time, challenges DHIS2’s status
as a DGPG. The problem is not insurmountable, how-
ever, as collective action and subsidiarity6 may offer
helpful mechanisms of governance. Føllesdal (1998)
interprets two main subsidiarity conditions related to
effectiveness and necessity: that action should be
taken at the level where it is most effective and that
action at the higher level should be taken when lower
levels cannot achieve the set goals by themselves. This
is in line with ongoing efforts by UiO to build
South-South community-based networks and thereby
decentralization into the Health Information System
Programme (HISP) network. The intent here is to
provide more opportunities for countries to have
greater influence in the global HISP-UiO center where
the development and fund allocation is carried out.
In this new regional HISP strategy, the plan is to
create South-South consortia of nodes and coalesce
them into regional nodes directly funded by develop-
ment partners (e.g., Global Fund) rather than for the
funds to be routed through Oslo. The Regional Hub
is the new organizational level of the HISP network,
agreed by the DHIS2 investment partners, including
Global Fund to increase capacity and coordination of
country-level technical assistance and other DHIS2
Implementation support across the HISP Groups
within a region. HISP Hubs will be governed by an
MOU (with UiO) with a defined Steering Committee
and this level of subsidiarity it is hoped will lead to
sustained collective action, which would provide cor-
rectives to the current asymmetries in the scaling
process.
Conclusion
There is much optimism regarding the potential of
DGPG; for example, the WHO’s Global Digital Health
Strategy says: “The collaboration will include building
on synergies, facilitating technical collaboration, and
developing quality assured and evidence based global
digital health public goods that can be shared and
used globally” (WHO. 2021, 31). This sentiment is
echoed by The UN Secretary-General’s Roadmap on
Digital Cooperation (UN. 2020) that calls for action
in the realm of promoting digital public goods to
unlock a more equitable world. The report states that:
“Digital public goods are essential in unlocking the
full potential of digital technologies and data to attain
the Sustainable Development Goals, in particular for
low- and middle-income countries” (8). Our study
identifies and analyses paradoxes that arise in the
development of DGPG, which will hopefully help
actualize the ideal.
The contribution of our study to practice is the
attention it directs toward the different scaling dynam-
ics at the micro and macro levels, and the challenges
of attaining non-rivalry and non-exclusivity.
Accordingly, our message for policymakers, consul-
tants, and other practitioners is that DGPG should
be understood as an ideal, a socio-technical accom-
plishment that is ongoing rather than as embedded
into a static portable technological artifact.
Future work would benefit from three main foci.
Firstly, attention to other DGPG in sectors beyond health
would broaden our knowledge of the specific implica-
tions and design considerations. Secondly, research look-
ing specifically at the supporting ecosystem building on
the insights of Jacobides, Cennamo, and Gawer (2018)
would enable in-depth analysis of the symbiosis and
challenges presented by the various supporting actors
and networks in a DGPG platform. Thirdly, future work
could consider how social responsibility may be realized
in a DGPG governance considering for example Zuboff’s
(2015) criticisms of the major digital platforms relating
to surveillance, privacy, and security.
Notes
1. https://dhis2.org/in-action/ (accessed July 8, 2022).
2. https://community.dhis2.org/
3. For more detail on pivot table in DHIS2 see https://
docs.dhis2.org/2.34/en/dhis2_user_manual_en/
analyze-data-in-pivot-tables.html
4. Positive network eects increase with adoption in a
self-reinforcing cycle and the scaling towards global
adoption adds contextual diversity necessary to
develop for global relevance. Concomitantly there is
a paradoxical eect that the platform scaling towards
serving the macro level priorities will become overly
generic and in the worst case scenario into a state
of “design from nowhere” (Suchman, 2002) that is
prohibitively dicult to re-program, adjust, or local-
ize thus challenging the ideals of non-exclusion and
non-rivalry.
5. e problems of collective action were theorized by
Olson (1989) in a treatise on the mechanisms for
groups of individuals to act in their common interest
for the realization of public goods.
6. Subsidiarity concerns the allocation of authority, power,
and tasks in a political order and about determining
at what level of government – or governance – these
should reside (Føllesdal 1998).

12 B. NICHOLSON ETAL.
ORCID
Brian Nicholson http://orcid.org/0000-0002-6729-9874
Petter Nielsen http://orcid.org/0000-0003-3723-6976
Sundeep Sahay http://orcid.org/0000-0002-4374-9551
Johan Ivar Sæbø http://orcid.org/0000-0001-9873-4544
References
Bonina, C., K. Koskinen, B. Eaton, and A. Gawer. 2021.
Digital platforms for development: Foundations and re-
search agenda. Information Systems Journal 31 (6):869–
902. doi: 10.1111/isj.12326.
Boudreau, K. J. 2018. Amateur crowds and professional
entrepreneurs as platform complementors. (NBER
Working Paper Series No. 24512). Boston, MA: National
Bureau of Economic Research.
Braa, J., and C. Hedberg. 2002. e struggle for district-based
health information systems in South Africa. e Information
Society 18 (2):113–27. doi: 10.1080/01972240290075048.
Braa, J., E. Monteiro, and S. Sahay. 2004. Networks of ac-
tion: Sustainable health information systems across de-
veloping countries. MIS Quarterly 28 (3):337–62. doi:
10.2307/25148643.
Cennamo, C., and J. Santalo. 2013. Platform competition:
Strategic trade-offs in platform markets. Strategic
Management Journal 34 (11):1331–50. doi: 10.1002/smj.2066.
Cusumano, M. G., A. Gawer, and D. B. Yoe. 2019. e
business of platforms: Strategy in the age of competition,
innovation and power. New York: Harper Business.
De Reuver, M., C. Sørensen, and R. C. Basole. 2018. e
digital platform: A research agenda. Journal of Information
Tech nolo g y 33 (2):124–35. doi: 10.1057/s41265-016-0033-3.
Digital Square. 2019. Global goods guidebook (Version 1.0).
Accessed February 18, 2021. https://static1.squarespace.com/
static/59bc3457ccc5c5890fe7cacd/t/5ced6f3c7817f7e261ddb-
c0a/1559064401781/Global-Goods-Guidebook_V1.pdf
Digital Square. 2020. Global goods maturity. Accessed
February 18, 2021. https://wiki.digitalsquare.io/index.php/
Global_Goods_Maturity
Føllesdal, A. 1998. Survey article: Subsidiarity. e Journal
of Political Philosophy 6 (2):190–218.
Gawer, A., and M. A. Cusumano. 2014. Industry platforms
and ecosystem innovation. Journal of Product Innovation
Management 31 (3):417–33. doi: 10.1111/jpim.12105.
Ghazawneh, A., and O. Henfridsson. 2013. Balancing platform
control and external contribution in third-party development:
e boundary resources model. Information Systems Journal
23 (2):173–92. doi: 10.1111/j.1365-2575.2012.00406.x.
Gizaw, A. A. 2014. Open generication: e case of District
Health Information Software. Doctoral dissertation,
University of Oslo.
Hardin, G. 1968. e tragedy of the commons. Science 162
(3859):1243–8. doi: 10.1126/science.162.3859.1243.
Heeks, R. 2008. ICT4D 2.0: e next phase of applying
ICT for international development. Computer. 41 (6):26–
33. doi: 10.1109/MC.2008.192.
Jacobides, M. G., C. Cennamo, and A. Gawer. 2018. Towards
a theory of ecosystems. Strategic Management Journal 39
(8):2255–76. doi: 10.1002/smj.2904.
Kaul, I., I. Grunberg, and M. Stern. 1999. Global public
goods. In Global public goods: International cooperation
in the 21st century, eds. I. Kaul, I. Grunberg, and M.
Stern, 450–98. Oxford, UK: Oxford University Press.
Kotlarsky, H., I. Scarbrough, and Oshri, J. 2014. Coordinating
expertise across knowledge boundaries in oshore-outsourcing
projects: e role of codication. MIS Quarterly 38 (2):607–
28. doi: 10.25300/MISQ/2014/38.2.13.
Manya, A., J. Braa, L. H. Øverland, O. H. Titlestad, J.
Mumo, and C. Nzioka. 2012. National roll out of District
Health Information Soware (DHIS 2) in Kenya, 2011:
Central server and cloud based infrastructure. In
IST-Africa 2012 Conference Proceedings. Vol. 5, eds. P.
Cunningham and M. Cunningham, 1–9. Dublin, Ireland:
International Information Management Corporation.
Miles, M. B., A. M. Huberman, and J. Saldana. 2013.
Qualitative data analysis: A methods sourcebook. 3rd ed.
ousands Oak, CA: Sage.
Moon, S., J.-R. Røttingen, and J. Frenk. 2017. Global pub-
lic goods for health: Weaknesses and opportunities in
the global health system. Health Economics, Policy, and
Law 12 (2):195–205. doi: 10.1017/S1744133116000451.
Nicholson, B., P. Nielsen, and J. Sæbø. 2021. Digital plat-
forms for development. Information Systems Journal 31
(6):863–8. doi: 10.1111/isj.12364.
Nicholson, B., P. Nielsen, J. Sæbø, and S. Sahay. 2019.
Exploring tensions of global public good platforms for
development: The case of DHIS2. In ICT4D 2019:
Information and Communication Technologies for
Development, eds. P. Nielsen and H. C. Kimaro, 207–17.
Cham, Switzerland: Springer.
Nielsen, P. 2017. Digital innovation: A research agenda for
information systems research in developing countries. In
ICT4D 2017: Information and Communication Technologies
for Development, eds. J. Choudrie, M. S. Islam, F. Wahid,
J. M. Bass, and J. E. Priyatama, 269–79. Cham,
Switzerland: Springer.
Nielsen, P., and M. Aanestad. 2006. Control devolution as
information infrastructure design strategy: A case study
of a content service platform for mobile phones in
Norway. Journal of Information Technology 21 (3):185–94.
doi: 10.1057/palgrave.jit.2000064.
Olson, M. 1989. Collective action. In e invisible hand,
eds. J. Eatwell, M. Milgate, and P. Newman, 61–9.
London: Palgrave Macmillan.
Ostrom, E. 1990. Governing the commons: e evolution of
institutions for collective action. Cambridge, UK:
Cambridge University Press.
Ostrom, V., and E. Ostrom. 1977. Public goods and public
choices. In Alternatives for delivering public services:
Toward improved performance, ed. E. S. Savas, 7–50.
Boulder, CO: Westview Press.
Parker, G., M. van Alstyne, and S. Choudary. 2016. Platform
revolution: How networked markets are transforming the
economy and how to make them work for you. New York:
W. W. Norton.
Poole, M. S., and A. H. Van de Ven. 1989. Using paradox
to build management and organization theories. e
Academy of Management Review 14 (4):562–78. doi:
10.2307/258559.
Putnam, L. L., G. T. Fairhurst, S., and Banghart, S. 2016.
Contradictions, dialectics, and paradoxes in organizations:
A constitutive approach. Academy of Management Annals
10 (1):65–171. doi: 10.5465/19416520.2016.1162421.

THE INFORMATION SOCIETY 13
Roland, L. K., T. A. Sanner, J. I. Sæbø, and E. Monteiro.
2017. P for Platform. Architectures of large-scale
participatory design. Scandinavian Journal of Information
Systems 29 (2):3–34.
Sahay, S., J. Sæbø, and J. Braa. 2013. Scaling of HIS in a
global context: Same, same, but dierent. Information
and Organization 23 (4):294–323. doi: 10.1016/j.infoan-
dorg.2013.08.002.
Samuelson, P. A. 1954. e pure theory of public expendi-
ture. e Review of Economics and Statistics 36 (4):387–
9. doi: 10.2307/1925895.
Smith, R., R. Beaglehole, D. Woodward, and N. Drager, eds.
2003. Global public goods for health: Health economics and
public health perspectives. Oxford, UK: Oxford University
Press.
Smith, R. D. 2003. Global public goods and health (edito-
rial). Bulletin of the World Health Organization 81 (7):475.
Smith, W. K., and M. W. Lewis. 2011. Toward a theory of
paradox: A dynamic equilibrium model of organizing.
Academy of Management Review 36 (2):381–403.
Smith, R. D., and L. MacKellar. 2007. Global public goods
and the global health agenda: Problems, priorities and
potential. Globalization and Health 3 (1):1–7. doi:
10.1186/1744-8603-3-9.
Suchman, L. 2002. Located accountabilities in technology
production. Scandinavian Journal of Information Systems
14 (2):91–105.
Taplin, J. 2017. Move fast and break things: How Facebook,
Google, and Amazon have cornered culture and under-
mined democracy. Sydney, Australia: Pan Macmillan.
Tiwana, A., B. Konsynski, and A. A. Bush. 2010. Platform
evolution: Coevolution of platform architecture,
governance, and environmental dynamics. Information
Systems Journal 21 (4):675–87.
UN. 2020. Report of the secretary-general roadmap for
digital cooperation. Accessed July 19, 2022. https://www.
un.org/en/content/digital-cooperation-roadmap/assets/pdf/
Roadmap_for_Digital_Cooperation_EN.pdf
Walsham, G. 1995. e emergence of interpretivism in IS
research. Information Systems Research 6 (4):376–94. doi:
10.1287/isre.6.4.376.
Walsham, G. 2006. Doing interpretive research. European
Journal of Information Systems 15 (3):320–30. doi:
10.1057/palgrave.ejis.3000589.
Wareham, J., P. Fox, and J. Cano Giner. 2014. Technology
ecosystem governance. Organization Science 25 (4):1195–
215. doi: 10.1287/orsc.2014.0895.
WHO. 2021. Global strategy on digital health 2020-2025.
Geneva: World Health Organization.
Yamey, G., O. Ogbuoji, and K. Kennedy McDade. 2018. We
need a consensus on the denition of “global public
goods for health.” Accessed December 3, 2021. https://
www.brookings.edu/blog/future-development/2018/11/20/
we-need-a-consensus-on-the-definition-of-global-pu
blic-goods-for-health/
Yoo, Y., O. Henfridsson, and K. Lyytinen. 2010.
The new organizing logic of digital innovation: An
agenda for information systems research. Information
Systems Research 21 (4):724–35. doi: 10.1287/
isre.1100.0322.
Zubo, S. 2015. Big other: Surveillance capitalism and the
prospects of an information civilization. Journal of
Information Technology 30 (1):75–89. doi: 10.1057/
jit.2015.5.