Understanding Platform Ecosystems for Development: Enabling Innovation in Digital Global Public Goods Software Platforms

Purpose - While the potential of digital platforms for socio economic development is recognized, limited knowledge exists on the development of these platforms beyond the literature that is focused on commercial for-profit business models in the Global North. Platforms that host application ecosystems have the most potential for value creation for the platform owner and all users. However, little is understood about how public-sector platform owners can enable the creation of application ecosystems where traditional economic incentives for 3 rd party, generic application development are not so explicit. Drawing on case study data drawn from the recent proliferation of third-party applications in the district health information software (DHIS2) digital platform, the authors propose themes influencing the innovation by 3 rd party application developers for a digital global public goods (DGPG). Design/methodology / approach - The paper draws on a study of the DHIS2 that is implemented in over 80 countries globally. The platform operates a free and open source (FOSS) philosophy, has a core application that can be downloaded for free, and an app hub containing supplementary, generic 3 rd party developed applications. The platform core is supported by University of Oslo and major international donor organizations to support its implementation in contrast to the business models of commercial digital platforms that require explicit monetization. Following a thematic analysis case study methodology, this paper investigates the motivators of complementors to create innovative apps thus creating a virtuous cycle of value generation for the platform. Findings - The data reveal that there are three themes that exist in the decisions by 3 rd -party developers to produce generic applications within the DHIS2 platform; boundary resources, networks for innovation, and enlightened self-interest. Working in concert, these themes influence the complementor to create a generic application that can be applied across thousands of DHIS2 databases and generate value for the platform and all users equitably. Originality / value - This paper offers a new theoretical perspective to illuminate the motivators for contributors to digital innovation platforms for development. In parallel, it draws practical implications for public-sector and DGPG platform owners seeking to develop application economies.


Introduction
Digital innovation platforms provide the foundational elements for innovation in the form of applications or components that can be built upon [1].The essential challenge for platform providers is to continuously maintain and nurture an innovative ecosystem around the platform [2].A classic example is the Android operating system, where a stable core is maintained that allows for periphery applications to be supported.This "application ecosystem" enables many innovators to develop complementary applications or services within the digital platform ecosystem [3].Applications can be highly specific to a single end-user or generic to a broad range of end-users.Innovation platforms have the unique ability to create extensive platform ecosystems while also enabling 3 rd party application developers, complementors, to address local challenges [4].
Digital Platforms have three key properties: they are enabled by technology, facility interactions between users and user groups, and allow users to perform certain actions [3,5].Jacobides and colleges [6], point out that the key goal of a platform is to facilitate interactions between platform participants.Platform owners have the challenge of developing and maintaining an innovative ecosystem which can utilize the expertise and ingenuity of a diverse developer community [2].An open platform ecosystem enables both core and third-party developers or complementors to co-create new applications to address the requirements of an every growing and increasingly varied community of users [7].However, complementors must see sufficient incentives and value, while being able to overcome technical and knowledge boundaries, to contribute to innovation within the platform ecosystem [8].An application ecosystem built around a common platform core that does present sufficient value to complementors while minimizing barriers is best positioned for growth and adoption [6].
From a technical perspective, a platform must possess a "layered" architecture with a modular design [4].Architecture refers to structure of the inner system, the components and how they perform [9].Typically, these would commonly be referred to as the "back-end", "front-end", the application programming interface (API), and/or standard application kit (SDK).A layered architecture is defined by generic core components with a low degree of variability, complementary or periphery applications with higher variability, and an interface between the two [10].The modular design of the platform refers to the development of small, reusable components with a welldefined user interface [10,11,12].
Innovation platforms provide the foundation for which applications or components can be built upon.Again, a classic example is the Android operating system, where a stable core is maintained that allows for periphery application to be supported.Mandel [13] describes this as application economies, or "a collection of interlocking innovative ecosystems where each ecosystem consists of a core ecosystem, which creates and maintains a platform and an app marketplace."In the application economy multiple individuals, groups and organizations -eg.developers, companies, or governments-are able to create, launch, and maintain their own applications.Innovation platforms enable a large number of innovators to develop complementary applications or services within the platform ecosystem by providing technical foundational elements [3].Applications can be highly specific to a single end-user, such as an application that aids community health workers in Zambia in diagnosing Malaria, or highly generic to a broad range of end-users, such as Whatsapp [4].
Global Digitcal Public Goods (GDPG) -Specifically, in the context of low and middle-income countries, innovation platforms can lend to the creation of application economies and the development of tools to address local challenges [14].In the winter of 2017, a consortium of development multilaterals and donors aligned on digital investment principals to ensure continued investment in platforms operating in developing countries.These platforms must meet the criteria of a GDPG to be eligible for donor support.According to Digital Investment Principles [15], "Global Goods are digital health tools that are adaptable to different countries and contexts.Mature digital health global good software is software that is (usually) Free and Open Source Software (FOSS), is supported by a strong community, has a clear governance structure, is funded by multiple sources, has been deployed at significant scale, is used across multiple countries, has demonstrated effectiveness, is designed to be interoperable, and is an emergent standard application" Although the merit of GDPGs is acknowledged, Smith [15] contends that there is no commercial incentive to create them.National government, donor, and multilateral agency provision of public goods is provided through taxation and licensing, and their very nature means that market-based mechanisms of competition, profit, and selectivity cannot be applied.Hippel and Krogh [17] explore potential motivators for developers to make contributions to FOSS public goods.They point out that the cost of losing property rights to innovation must be outweighed by the benefit of diffusion of the innovation.Contributors need to face "low rivalry conditions" meaning the diversity of the contributors diffuses a rivalrous nature.They also report that contributors to FOSS develop a sense of ownership and control over their product that is not typically the case in more commercial products.This research in many ways is a test of these assertions by Hippel and Krogh.
Much has been written on the market-orientation, competition, pricing strategies, and mechanisms of platforms that enable complementor application development [18].Digital platform owners must create a business model in which complementors see clear incentives to create, distribute, and sustain platform innovations [1]; however, where traditional market incentives are lacking, creating incentives has proven to be particularly difficult.This becomes an inherent challenge for public sector digital innovation platforms [17,19].For platforms where profit is not the main goal, the challenge is for the platform owner to be able to align the self-interest of the complementors to the health and mission of the platform ecosystem [17,20].There is a paucity of research into what these incentives may be, and in response to this gap, the objective of this paper is to identify themes in the creation of complementor applications for public sector digital global public good innovation platforms.
In order to do this, we examine the recent proliferation of generic, complementor applications in the free and open source District Health Information System 2 (DHIS2) innovation platform in its role as a national health management information system (HMIS).Some 67 mainly low-and middle-income countries have adopted DHIS2 as their central digital platform for their health system [21].DHIS2 has a core database and application programing interface (API) developed and maintained by the Health Information System Project (HISP) headquartered at the University of Oslo.Beyond the core is a continuously increasing number of third-party developed applications that are developed with little or no involvement from the core development team in Oslo.These periphery, generic applications are by nature more reusable across countries and contexts and increase the value of the platform as a whole to all users [14].
Research question: What are the themes that emerge in the principal considerations by complementors who decide to develop generic, publicly available applications for a FOSS, public good platform?
In what follows we define our methods of identifying leading third-party, generic applications in the DHIS2 ecosystem, and we follow that with the identification and justification of the themes that exist in generic complementor application development.

Methods
This paper employs a qualitative thematic analysis to detect and identify principal considerations that influence behaviors, actions and thoughts of the platform complementors [22,23].Thematic analysis is a method for identifying, analyzing, and reporting patterns (themes) within a data set [24].Thematic analysis allows for the description of implicit and explicit ideas via a coding and data reduction process that links raw data with concepts.The various concepts are then linked to broader themes via an inductive (derived from the data) approach as well as a priori approach stemming from the investigator's prior theoretical understanding of the phenomenon under study [25].
We initially identified five suitable case studies from the 3 rd party applications that were submitted to the "Application of The Year" competition at the 2019 DHIS2 Annual Conference.The DAC is the largest annual gathering of leading DHIS2 implementers and developers with dozens of use-cases and user stories, innovation highlights, technical sessions, networking events, micro-trainings, and feedback sessions over the course of four days.Of the18 application submitted, three were selected as finalists based upon their impact, accessibility, and quality.The five applications presented in this research include the three finalist and two additional applications.These five were selected based on three criteria.First, each of the applications were publicly available, meaning the application was published in the DHIS2 application repository, freely available to all, and the source code was open and accessible.Second, the primary author of this research has had long-term involvement and access with the application developers to be able to produce rich, contextual data.Third, these case studies match with Gerring's [26] classification of an "extreme case" or a case that is, "considered to be prototypical or paradigmatic of some phenomenon of interest."By focusing on "extreme," idealized case rather than representative case selection we are better able to apply the findings to the generation of theoretical concepts such as themes [27,28,29].

Data Collection
Data was collected through document analysis, presentation analysis, interviews, and survey analysis.First, we conducted a review of the submitted material for the "App of the Year Competition."This included a video tutorial of using the application itself and a short description of why the application was developed, who uses the application, and what its impact has been.Next, we conducted a written survey of the applications principally to assess the motivations and expectations for making the application.Finally, we conducted ten follow-up interviews, five with the lead application developers themselves, and five more with the manager of the organization that created the application.All participants in the research gave verbal and written acknowledgement of willingness to use their responses in this research.

Data Analysis
A three phase data reduction process was utilized to identify the prevailing themes presented in this research.First, after collection, the data was tabulated so that it could be coherently analyzed.For example, as each interviewee was asked the same questions those questions were collated together so that variation across answers could be discerned.The second phase involved highlighting key excerpts from the text that contribute to the study's question [30].The third stage creates a reasonable and logical chain of evidence through data coding to derive concepts (see figure 1) upon which apriori theory is applied to deduce the final themes [24].This process is an inductive approach in that collection starts with precise content then applies broader generalization and ultimately leading to theory generation.This process largely safeguards that the themes are linked to the data [31].

Case Description
District Health Information Systems (DHIS2) -Here we use the example of the free and open source DHIS2 as an innovation platform in its role as a national health management information system (HMIS).DHIS2 has a core database and API developed and maintained by the Health Information System Project (HISP) headquartered at the University of Oslo.The core development team also develop and maintain a suit of "core" generic applications that are the minimal tools necessary for an HMIS.These are: data capture applications, analytics applications, such as dashboards, pivot tables, charts, and maps, and social analytics and messaging applications which enable users to directly communicate with each other enabling commentary around the data analytics.There are also data quality application as well as meta-data configuration and user management applications.These applications reuse common components and exist on top of a stable application programing interface (API) forming a layered, modular architecture.Beyond the core is a proliferation of locally developed applications that are developed with little or no involvement from the core development team [14].These periphery applications can be generic and, thus, more reusable across countries and contexts or highly specialized for a specific enduser or function [14].In the case of DHIS2, while the core development does receive long-term support from a consortium of international aid donors and multilaterals, the generic applications that are developed outside of the core by platform complementors do not receive the same level and duration of financial support.Often these periphery applications are developed with time bound project funding.In essence, by making a generic application that can be installed in any DHIS2 instance, the developers are pledging to support the application (improvements and bug fixing) indefinitely without any guarantee of continued funding.
Building on the DHIS2 case-study, one can begin to form linkages between digital platforms and the concept of global public goods.DHIS2 being a free and open source platform means that there is a non-rivalrous nature.In other words, the use of the platforms by one individual does not prevent that of another.Likewise, no single institution or person can be excluded from the use of the platform."Free", in this case, does not only mean no cost to obtain, but also the broader sense of freedoms such as choice or freedom of speech [32].These notions touch on another element of public goods in that they are often centered in basic human rights such as the right to health care or the right to education.The "global" element comes into play in several regards.First, is the scale of adoption with the tools and services in DHIS2 now covering approximately 2.28 billion people globally [21].The second is the degree of country ownership.Some 67 countries have deployed DHIS2 as their central digital platform for their health system.DHIS2 is also global in terms of its development.While a relatively small core team is in Oslo, there exists a vast distribution of developers implementing core application and creating complementary, peripheral applications.Finally, the last element of global is the global network of the implementation community.DHIS2 maintains a central, web-based community of practice (CoP) where implementers across the globe can ask question, find answers, and share resources and best practices.
This research further focuses on five "extreme" cases of generic, publicly available applications that have been made for the DHIS2 platform ecosystem: Interactive dashboards -In late 2016, HISP Tanzania, based in Dar es Salaam developed the Interactive Dashboard application.This dashboard application was in response to specific requests from the Tanzanian Ministry of Health for a more flexible dashboard application than the core dashboard application produced by UiO.The Interactive dashboard application allows users to "bookmark" dashboards, toggle between different visualization types and dimensions, and user messaging is tied to single dashboard items.The application was developed utilizing the same API endpoints and resources as the core dashboard, and it was posted to the DHIS2 App Hub making it freely available.The interactive dashboard also formed the foundation for the 2018 rewrite of the core, UiO produced Dashboard application.
D2D -Starting in 2017 the Ministry of Health in Mozambique began capturing daily morbidity and mortality data against individual patient in DHIS2.This frequency and granularity are critical in disease control and prevention.However, the data is also required to be aggregated to a monthly dataset in a separate instance of DHIS2.In the health facilities this meant that data had to be captured twice, which was overly burdensome.Saudigitas, a Mozambique DHIS2 implementation and development company, in response to this inconvenience to the users, developed the D2D application in 2018 which enables administrators to pull individual data from one instance of DHIS2 into aggregated data in another.This eliminates the need for data to be entered by the clinician in two separate instances.The application utilizes core code libraries and user interface (UI) templates to produce a generic solution that can be downloaded and installed by the DHIS2 community without any intervention or support from Saudigitus.
DHIS2 Data Import Wizard -In 2018 a team based in at the NGO HISP Uganda developed the DHIS2 Data Import Wizard.This application was developed to enable intuitive excel, csv, or API imports of data into DHIS2.While this is a functionality covered in core applications, the core application has long been understood to be poor performing and difficult to use by community and core developers.Yet, the roadmap for core development has required development resources to be put in other applications and functionalities.Appreciating this gap and in a need to address their own issues with importing data from several projects, HISP Uganda over the course of 18 months developed a generic application for user-friendly and intuitive data import.In-fact this application won the application of the year popular vote during the 2019 DHIS2 Annual Conference.
DHIS2 Web Excel Importer -In 2017 HISP India faced the same issues with routine importing data from excel into DHIS2 as HISP Uganda.They developed the DHIS2 Web Excel Importer to address this problem.The application automatically reads the column header in excel and aligns this with the proper DHIS2 import format.Much like the DHIS2 Data Import Wizard application, this functionality represents a dramatic improvement over the core, HISP UiO produced Data Import Application.This a generic application which can be used to import data to any DHIS2 aggregate systems and can be easily downloaded and configured by another country or project without the direct involvement by the original developers.The application utilizes core API endpoints and data stores and is publicly available on the DHIS2 App Hub.
Advanced Metadata Export Application -The University of Catalonia in 2018 developed The Advanced Metadata Export app which allows users to share and exchange metadata with other DHIS2 instances, gathering all necessary dependencies (e.g., global DHIS2 instance with many different metadata and local, country instances specialized only in particular disease).In addition, the app also allows packaging specific metadata for migrating them between different instances in the same organization (e.g., pushing metadata from development to production instance).This application introduces completely new functionality to DHIS2 while utilizing core code and user-interface libraries.

Thematic Analysis:
Table 1 shows the identified themes, their description, and component concepts.These themes were identified via an inductive, a priori approach and mapped to the underlying data in figure 1 • Global platform perspectives by complementors prompts generic innovation with the intent of increasing the value of the platform as a whole.As platform providers, this subsequently increases their value/services they can provide to their clients by being able to utilize their own and innovations supplied from other complementors.

Boundary Resources
The data analysis revealed the existence of key platform owner provided resources as necessary for developing generic innovative applications in the DHIS2 platform ecosystem.These boundary resources are both technical and social in nature and allow for periphery applications to extend the functionalities of the platform beyond what is perceived or possible to be done by the platform owner [33].These boundary resources operate not as isolated elements, but as an integral part of the platform infrastructure maintained by the platform owner [34].
Technology boundary resources, provided by the platform owner, give the ability for platform complementors to create new applications via accessible technical resources.These exist as open platform resources (APIs, SDKs, code libraries, user interface standards and templates, app stores, etc) which form the platform technical boundaries that define the degree to which complementors are able to co-create and innovate within the platform ecosystem [35 ,36].
Knowledge boundary resources are resources that furtherer regulating the ability of complementors to innovate and create value within the platform ecosystem [37].Knowledge boundary resources seek to provide the practical knowledge and understanding necessary for complementors to access and utilize the technical boundary resources [37,38].More difficult to scale than technical boundary resources, knowledge boundary resources can be guidelines, programming tutorials, information portals, online courses, workshops and co-innovation projects.Platform owners who adopt open development standards such as common programing languages, code libraries, and methods which often already have third-party developed wikis, courses, and books can lower the barriers for complementors to co-create with the platform and minimize the number of platform specific knowledge boundary resources [37].

Networks for Innovation
The data exposed that social networks for promoting, sharing, and even refining innovations are a key theme in complementors' decisions to develop generic applications.The networks are engaged through platform owner provided physical events, conferences, and digital communities of practice as well as across complementor own internal networks.
Network effects are a unique property of digital platforms where increasing the number of users increases the platform's value to the platform owner and all users.Essentially, the more users the larger the user networks and often the number of complementary innovations.New network effects appear as a third-party complementors make new connections with an increasing distributed group of users.These connections encourage third-party firms to create complementary innovations.These innovations thus attract more users to the platform which prompts more innovation from complementors, and a virtuous cycle of value creation emerges and continues, ideally, indefinitely [1].Network effects can be direct or indirect.Direct network effects form when a technology benefits a user by enabling them to connect to many other users and complementors.The potential benefit of the platform to the user increases as the number of users and complementors increase in the platform [39].Indirect network effects form when one group of users tangentially effects a different group of users in a positive way.This is essentially when the number of users grow in one group the benefit and number of users can grow in a different group [39,40].
Communities of practice (COP) are defined by Wegner et al [41] as, "…groups of people who share a concern, a set of problems, or a passion about a topic, and who deepen their knowledge and expertise in this area by interacting on an ongoing basis."The roles of individual COP members are not set, they are fluid and informal in which users should feel no risk in contributing, and much like a platform in general, the more members and contributors to a COP the more value that is generated for all users [42].Wenger and Snyder [43] argue that a community of practice to be most successful must be guided by strategic objectives that are defined by the central sponsor.In the case of DHIS2, the University of Oslo sponsors both virtual and physical communities of practice.
Enlightened self-interest is an ethical philosophy which proposes that a person who acts to serve the collective interests of others or the interests of groups that they belong are, in essence, serving their own interests.Enlightened self-interest is a response to the classical economic premise that acting solely on an individual's self-interest is the best way to maximize profits and generate value [44].It also differs from altruism in that it does not compel one to pursue the interests of others at the expense of their own interests [45].In the seminal work on contributors' motivations for open-source software development, Hippel and Krogh [17] reveal that along with producing a software product, open-source contributors also generate collective resources such as knowledge, networks, relationships, goals, and even ideologies.These collective resources over time become a reward and motivator unto themselves and contributors stop regarding participation as costly, but rather beneficial [46].Contributors get benefits from increasing the value of the platform and subsequently increasing the value/services they can provide to their clients-a repeated theme we see in the data."It depends on the kind of application, but generally it is easier to develop generic apps because most of the time you will work with DHIS2 API without hard coding "Developing generic apps is easier than doing custom application, all apps development originally starts from the generic requirements and code libraries . ..for some occasions, within the generic application, the clients do ask for specific requirements, which result into forking the generic app back into project-specific app customization and versioning, which adds on to development effort and the maintenance.""The improved bed API documentation for e.g.changes in API endpoints per version upgrade will be good to align the APIs used in the app to the latest DHIS2 versions "For apps development, what we need (from UiO) as support overtime is an up-to-date, effective, efficient, and well-documented API" "We are now able to improve our internal development capacity and reuse components across applications."

Technology Resources
"UiO has a roadmap which they follow so it could take a long time for requests to be worked on especially if the request is new or complex.Often, we need a quick solution, and cannot wait the time it takes for request to be processed and approved" "Adherence to project schedule and timelines, and difference of priorities [from UiO] are the key reasons behind developing the required application"

Knowledge Resources Boundary Resources
"Customers need timely solutions to solve their problems, and realizing the amount of organization that use DHIS2, there is a great demand for the (core) developers, so for an optimization of the time we develop by ourselves." Excerpts from the data Coding Concepts Themes

Discussion
The importance and enabling of the technology boundary resources played a prominent role in the responses from application developers.In the case of Interactive Dashboard and the DHIS2 Data Import Wizard application, the developers utilized and built on top of pre-existing APIs and reusable components while the DHIS2 Web Excel Importer consumed standard code libraries and preexisting applications.In fact, the developers from both the Interactive Dashboard and the DHIS2 Data Import Wizard stated that generic application development is easier to develop than a custom, client specific applications because they can focus their efforts on creating the new functionality while reusing existing resources for functionality shared across other applications.The DHIS2 Web Excel Importer developers voiced concerns that when client requirements become more specific, the application becomes more custom and ultimately harder to develop and maintain.There is then an appreciation that reuse of "We produce a global solution that answers the request of a certain client.However, sometimes other customers, "have the same problems and don't know", so we can show them the problem and have their proposed solution.The best part of this is that each customer can evaluate the solution in their own perspective and bring up suggestions of requirements that are extremely useful for everyone else, so that everyone involved can strengthen their information systems."

Indirect network effects
"It also increased visibility to the organization, (and) the application should support the whole community." Communities of practice "The advantages for developing a generic application is you can involve the community and the application supports the community." "The advantages of developing a generic application is that is sharable among different users of DHIS2 and contribution to the whole community of DHI2 (potential candidate for "core" DHIS2 functionality)" "A client requests a functionality and for him what matters is having his problems solved.As service providers (supervisors, developers, etc.) what has been done is to take up the problem and study its impact on a more global perspective, verifying whether it is true or not in other countries/organizations.Depending on the outcome of their evaluation is decided to develop or not a generic" "The generic application becomes project agonistic and give the flexibility of working seamlessly across projects performing the required functions on different databases"

Enlightened selfinterests
Excerpts from the data Coding Concepts Themes technology resources not only makes the initial development easier, but also make the application more able to be sustainably maintained over time.When asked, "what kind of support you expect to receive to maintain the applications", again, technology boundary resources (specifically the API) is clearly a principal concern for enabling development of applications.All case-studies interacted directly with the API and were completely dependent on its stability and continued maintenance by the platform owners.Therefore, any changes or errors in the API would have cascading negative effects on the functionality and performance of their applications.
UiO product managers produce a core application development roadmap that outlies the short-and longer-term development priorities and timeline for development.The roadmap is driven by community needs and allows for open community submissions, voting, and feedback.The product management team selects from the community submission those features that will have the most impact to the greatest number of users, considers votes/popularity, and technical feasibility.However, on average community submissions are nearly twice that of what core developers can address, and new submission, if approved for development, will take at least 6 months, but more likely a year or more to be released.Because the roadmap is open and the priorities for core development are communicated publicly, 3 rd -party application developers have the knowledge necessary to determine if there is a need to develop a new application.In this way, a clear roadmap and development timeline drives how and when complementors develop new innovative applications.Three of the case studies expressed that the knowledge of the roadmap and its inherent priorities and timeline where major deciding factors in the appreciation that they would need to develop their own application.
As described in the methods section, at the 2019 DHIS2 Annual Conference (DAC), UiO introduced an Annual Application Competition.The finalists presented/demoed their application in a plenary session and the community members at the DAC voted for their favorite application which was named the "DHIS2 Application of the Year."When asked what the benefits to your organization are in making a generic application Charles Olupot, from HISP Uganda, and the winner of the application competition responded, "It also increased visibility to the organization, (and) the application should support the whole community." Certainly, presenting in front of over 400 DAC participants and winning the popular vote elevated the perception of HISP Uganda.The community of practice present at the DAC prompted this but the effects lingered on in the web-based COP.This COP includes the digital space community.dhis2.org(launched by UiO in 2018) which hosts many topical forums, Q&A and support channels, a 'marketplace' with job and project postings, and announcements from the core development team.The application competition finalists and winner were immediately posted to community.dhis2.orgafter the DAC.Within one day, 587 additional community members had viewed the post and a conversation thread developed where several organizations requested use of the applications.Interestingly, a bug and new suggestion for improvement were made for Olupot's application as well.In this example, we can see the COP (both physical and digital) enabling many indirect network effects for application developers.It serves as a stage for them to promote their innovations beyond their known networks, and it encourages application developers to produce high quality, generic applications that can be utilized and refined by a larger user base.
In all the case studies, the application developed was to be used by different DHIS2 instances/data bases.While these databases did not connect, the users of each directly benefited by the existence of each other, forming indirect network effects.The initial intent for the applications were, for them, to be deployed to only the instances that each organization supported.However, by making the application generic and publicly available it has formed additional network effects with platform users that have no connection to the instances for which the application was developed.
The situation described by the developers of the D2D application also highlights the role of indirect network effects that a platform can enable multiple user groups to contribute to the development and refinement of the same application.While each individual client's use of the application is independent, each benefit from the existence of the other by contributing functional design requirements that the application developer disembeds into generic functionality that address the collective needs.A client may not even appreciate the existence of a certain need while others already have.This need can be addressed, and the application redistributed to all clients.
Consequently, this has the potential to preemptively address an issue for several clients based upon the experiences of one-in effect developing a generic solution to fit all users.
In our case study evaluation, we saw a repeated theme of independent contributors voicing an intrinsic need to develop a product that may be applicable far beyond their own use-cases.We called this concept a global platform perspective.As evident in the data, the developers of all the applications in the case studies made deliberate decisions to make the applications generic and publicly available because they appreciated that the application could present a global solution.There were subtle nuances to this perspective, however; for example, the developers of the Advanced Metadata Export Application hoped that by increasing the global user-base of the application HISP UiO would consider taking up the long-term support of the application.Additionally, the developers of the D2D and the DHIS2 Web Excel Importer both expressed that by solving global problems they were increasing the utility of DHIS2.With their business tied to the utility of larger DHIS2 platform, and acting in good faith, they benefit both from presenting global applications as well as using applications in their own projects developed by other complementors also acting in good faith.This phenomena unto itself is some sort of new network effect derived not from personal connections but from shared benefit from expanding the platform utility.Here we see a culture of openness, concern for the global good, and sharing propagated around the platform where individual contributors do not regard developing global solutions as overly costly.
These use-cases represent ideal scenarios.Many motivators and influences in the decisions by other complementors have not been analyzed or appreciated.Certainly, powerful forces exist that create tensions between creating an open, generic application or a project specific, closed application.This research is relatively one-sided, focusing on the motivators for generic, open application development.These tensions are not explicitly described here in detail, but further research could be able to present a more wholistic picture.

Conclusion
This paper presents the perspective of complementors to a FOSS, GDPG platform who decide to develop generic, openly available applications.The many considerations that go into the complementor's decision to develop these applications can be distilled down to clear concepts and themes.This research does partially address the dearth of research on innovation drivers (economic, social, technological, etc.) of GDPGs.As GDPGs continue to grow in number, scale, and scope, additional research will be necessary to describe their unique properties.We also see these GDPGs receiving increasing focus as every country around the world responds to the global Covid-19 outbreak.GDPGs offer many countries, especially low and middle income, out-of-thebox solutions to monitoring and containing these kinds of outbreaks.This increasing focus and implementation will surely drive additional innovation and virtuous value generation within the platforms.

Figure 1 :
Figure 1: Data reduction: Mapping of themes to the data