Public-Sector Code-Sharing Communities
Authors: David Eaves, Lecturer in Public Policy; Harvard Kennedy School; Lauren Lombardo, Master in Public Policy 2021, Harvard Kennedy School; Nicolas Diaz 2020, Master in Public Policy, Harvard Kennedy School
Open-source communities have existed in nongovernment spaces for over 40 years. Many of these communities organize around a proposed solution and over time create their own community engagement practices and governance models, or sets of rules, customs, and processes that outline how decisions are made.
Governments have become interested in emulating the success of these communities and have begun using and participating in open-source. As governments share more code, they need to decide what type of community they want to build. A government must be able to answer questions like: Where will the code be shared and who can access it? How will project contributions be managed? What is the authorized use of this code and what licensing considerations must be discussed?
This article focuses on what we see as the first big question: What type of community engagement should a project have? We examine two cases — that of Alberta Health Services/ Ontario Digital Service, and that of the Nordic Institute for Interoperable Solutions (NIIS) — to understand how they made this choice.
Community Engagement Spectrum
Community engagement refers to the ways in which the code’s publisher interacts with other teams or with members of the public. Figure 2.1 outlines three possible levels of community engagement that exist on a spectrum ranging from no engagement to formalized engagement.
“No community engagement” would just make the code open to the public. This allows other government agencies or nongovernment actors to see the code; however, there is no clear way to contribute to the source code or influence its future direction. The advantage of this is that it establishes transparency and moves towards the creation of a digital public good. Through this approach, the publisher of the code can avoid any administrative costs that come with opening the project to collaborators. However, the publisher then forgoes the opportunity for shared knowledge and community insight.
On the other end of the spectrum, a “formal community” requires a set of norms and rules by which decisions are agreed upon, clear expectations and pathways for community input, and some level of shared control over the source code. This allows for diversified operations (and in some cases, financial) support as multiple people take on the responsibility of moving the project forward. This route also requires a more robust administrative commitment.
As shown in the following case studies, governments can choose any spot on the spectrum that best satisfies a variety of local criteria. These local factors can include intended control over the project’s future, willingness or need to share operating costs, desire for publicity, and political or diplomatic goals.
There is no “correct” place to be, and a formal community should not be seen as the ultimate end goal for every project. The case of Alberta Health Services highlights a scenario in which a formal community was not an ideal choice. Alberta’s goal was to quickly share code such that other communities could leverage it as a resource during the height of the COVID-19 pandemic. Attempting to establish a formal community would have created burdensome bureaucratic roadblocks and inhibited their real goal (COVID-19 response).
It is also important to note that two organizations could choose the same spot on this spectrum (i.e., formal community) yet define the parameters of that community differently. Our case study of NIIS describes a different type of formal community than the one enacted by their peers at the Bangalore-based Modular Open Source Identity Platforms (MOSIP). While these parameters are important, the type of community must be established first and is the focus of our case studies.
Case Studies
The following cases outline each end of this community framework: Alberta Health Services and Ontario Digital Service as an example of no community engagement and NIIS as an example of formal community engagement. While we have not included a case on Notify, a project of the United Kingdom’s Government Digital Service (GDS), we see that as a great example of an informal community, as shown on the spectrum below.
Community Engagement Spectrum With Examples
Through these examples, we’ll provide more information about what questions a government should consider, what factors influence its decision, and the political ramifications of governing open-source communities.
