Appendix: Resources and Tools

This appendix lists additional resources and tools by module topic. This list will surely be incomplete, as technology innovation is dynamic and open approaches are being refined in new DPG use cases.

We look forward to your recommendations of new resources and tools you've found particularly useful in your DPG project!

Resources and Tools: Introduction

Engaging Open Source Networks

FUTURE WORK: It would be great to offer some information here on how to find associations or networks for open source, and how to access global networks if local ones are not strong yet. There are so many resources out there. Note that in the introduction, we already offer the advice to look in Appendix: Resources and Tools for some suggestions on this. In Europe, there is the Open Source Observatory. But it would be good to present similar resources for Africa, South America, India, and Southeast Asia.

You might also start by connecting with your local university, especially if there's a computer science or data science program. Open source and open data are also heavily relied upon in other disciplines, like physics and public policy programs and business schools. DHIS2's early focus on building academic and regional networks is a great example here. Academic institutions are another source of useful national and international networks. You're also likely to find talent and support at any sort of commercial start-up accelerator or incubator, which if not physically local might still be accessible and helpful to you online.

Benefits of Open Source

• The World Bank report Open Source for Global Public Goods (2019) gives an overview of the benefits of open source, along with sensible operational advice -- especially for those working in resource-constrained environments -- and a few case studies around Identification for Development (ID4D). It reiterates many of the same points we note here, such the benefits of open APIs and a modular architecture.

• Benefits are also highlighted in the article Open Source Software Finds its Sweet Spot in the Public Sector.

General How-To Guides

• The Standard for Public Code, listed as a DPG itself, "gives public organizations a model for building their own open-source solutions to enable successful future reuse by similar public organizations in other places. It includes guidance for policy makers, city administrators, developers and vendors." It lists straightforward tips, from how to welcome new contributors to the importance of maintaining version control, and also includes links to good additional resources.

• Federal Source Code Toolkit: This is a United States government-wide project facilitated by the Code.gov team to produce "how to" documentation pertaining to federal source code and open-source software. It provides guidance to agencies for creating and maintaining federal source code inventories and open-source repositories. It's a mix of high-level and very specific tips and includes links to good additional resources.

Resources and Tools: Community

Project Archetypes

This 2018 slide presentation of project archetypes is a useful short summary of the concept. Use your keyboard arrows to move through the slides.

Community Health

Mozilla, the non-profit managed company behind the Firefox web browser and other open, web-focused products, recently published a report on its numerous, varied contributor communities (see the .pdf version). This report posits a vision for comprehensively understanding open-source health, following a rather academic approach called the Open Source Ecosystem Health Operationalization (OSEHO) framework, and applies an abbreviated version across its main communities. The network analysis visualizations in this report are particularly powerful.

For those who want to go deeper into community health, we recommend a review of this OSHEO framework. Talking through the paper's understanding of broader project ecosystems -- noting that project health does not necessarily equate with ecosystem health -- can be particularly useful to teams looking to build an open-source product whose success in adoption and contribution depends on a broader ecosystem.

Creating your own open-source community

There's a rich set of online materials about how to create and nurture a thriving open-source community. Some of our favorites include:

• The EU's Guidelines for Sustainable Open Source Communities in the Public Sector (2020). This aligns with the recommendations covered here, from a needs and readiness assessment to planning for long term sustainability. It also includes a lits of key considerations to building your own open-source community.

• Producing Open Source Software: How to Run a Successful Free Software Project reviews the nuts and bolts of starting an open-source project, as does the TODO Group's Starting an Open Source Project. RedHat's Guidebook for open-source community management: The Open Source Way 2.0 is another general guide that also includes a 'Community 101' primer.

• The Mozilla Foundation's Open Leadership Training Series includes some particuarly useful tips about understanding and building to contributor types, or personas. Remember, your community is not necessarily all about coding! Community members can write documentation, localize content, answer questions and provide product support (Mozilla's product support is largely volunteer-driven), help you market the product or service, and more.

• The Open Source Guide to Building Welcoming Open Source Communities does just what the title suggests and dives more deeply into some of the niceties around community building (and includes guides to related topics like governance and leadership). The TODO Group has published a similar guide, Building an Inclusive Open Source Community.

• Crowdsourcing data collection can also require attention to community development and management, such as for volunteers collecting data or managing other data preparation and maintenance tasks. In order to help its volunteer communities around languages and voice data grow quickly and independently, the open-source, open-data project Common Voice published a 'community playbook'. This guidance helps Mozilla track data collection around the globe and ensure high quality while letting independent, local efforts grow without much centralized control.

  Unfortunately, participants in online communities exhibit the same destructive behavior we see in the physical world. Marginalized, vulnerable community members are most frequently targeted. Clear community participation guidelines can help fend off some of these behaviors, and their enforcement builds trust within a community.

• Mozilla's Community Participation Guidelines (CPG) is a great model to consider copying for your own open-source project. Mozilla's CPG is based on existing best practices and a good amount of hands-on experience and research into creating more inclusive contributor communities. Note that it includes a clear structure for reporting problematic community behavior and what to expect as part of this process.

• The DPG OpenMRS has a good code of conduct that they adapted from the Ubuntu open-source project. Mozilla's 2020 analysis of its contributor communities also provides insight into how to support diversity and inclusion.

• Lastly, the freely available and widely adopted Contributor Covenant code of conduct has been translated into almost three dozen languages.

Don't be put off by the thorough guides we cite above and feel that managing an open-source project requires significant investment in community development and governance. Deep investment isn't necessary for every project type. For those where it makes sense, you should approach community development in phases and 'right size' investment to what's needed.

For example, the DPG AIAgro's machine learning algorithms are available on GitHub, with a simple overview of their project on that makes it clear what they plan to work on, how to contribute, and how to join the community discussion on Discourse. If we had to peg this as an archetype, it's probably most akin to the Rocketship to Mars type. They're open to anyone participating, but they're unlikely to invest in bringing people onbaord unless they are clearly aligned and have needed skills. They are following open-source best practices in order to create trust around their product, but they don't need to build for a broader mass audience.

As another example, the DPG Primero created a global, inter-agency governance structure only when the platform had matured enough to merit such formalized oversight. The OpenSRP DPG publishes a very readable, straightforward overview of how its governance, contribution process, and community management work.

For those projects that are mature or require significant community development and would thus benefit from a community manager, note also that a community manager's role can be more broadly defined to include adjacent work like documentation, running trainings, and managing key partners, as well as typical community management tasks like ensuring new contributors can find appropriate work to do. For an example, see a recent job posting for a community manager from the the team behind the Kobo Toolbox DPG (accessed Sept. 2021).

Clear guidance around how to contribute and what the project is looking for with contributions is as important as community governance and management. The UNICEF Innovation team maintains a public repository of best practices and resources around working 'openly' in creating and managing digital public goods that includes some tips on how to write good contributor guidelines to help direct participants into your project's particular needs and workflow. It also includes some tips on documentation, which, again, is another area for community contribution.

Regarding external financing, the Guidelines for Funding Open Source Software Development was written with an audience of public and private foundations in mind and will give you a good sense of what many funders are likely to look for in a proposal that includes open-source software development. Many of the points in these guidelines also show up in practical recommendations in this paper, but you might still benefit from glancing at this as you plan for your DPG.

Resources and Tools: Policy

Integrated Policy Approaches

The World Bank pubished a background paper Estonian e-Government Ecosystem: Foundation, Applications, Outcomes that's a thorough overview of the integrated factors -- policies, institutions, technologies and more -- that helped Estonia create a successful e-government service ecosystem.

Public Domain

The Open Source Initiative provides a simple explanation of the problems of public domain software

Trademark

The UNICEF Innovation team's repository of best practices and resources expands on our description of the
relationship between open source and trademark protection and includes a brief case study and links to useful trademark policies and additional readings. We particularly like the Linux Foundation's tips on how to create a trademark program to encourage compatibile, 'conforming' products. (Note that conforming does not automatically equate with certification, which requires an higher level of scrutiny and testing and -- for most jursicitions - an additional set of legal requirements).

Security

It's a given truth -- unfortunately borne out by real world evidence -- that computing systems can never be fully secure. This is true not only becuase of how software (and hardware) works but also because of the economics of the IT industry, misaligned incentives and externalities, little liability for vendors, human nature, the complexity of today's systems, and so much more. Secrets and Lies: Digital Security in a Networked World (2000), by renouned security expert Bruce Schneier, is a good dive into why security is hard. The OECD's recent report, Understanding the digital security of products: An in-depth analysis, provides a timely overview of the "dynamics that shape the digital security of products in various markets", especially the dynamics across the value chain behind digital products. It also outlines suggested responses for policy makers, some of which make sense at an agency level. It's an excellent paper and recommended reading.

The paper Threats, Risks, and Mitigations in the Open Source Ecosystem is a great overview of how to think about security from the perspective of an open-source ecosystem (here, they use ecosystem to describe the set of things that comprise a specific open-source project, such as developers, end users, technical architecture, and package libraries).

Regarding the ongoing conversation over security and open source versus closed source, we like David Wheeler's much noted essay. Bruce Schneier has also written frequently on the same topic.

The Open Source Security Foundation publishes free EdX courses on best practices in developing secure software and hosts a related open community.

Similar to the Principles for Digital Development on Privacy and Security](https://digitalprinciples.org/principle/address-privacy-security/), the Open Reference Architecture for Security and Privacy lists its own set of key principles along with a list of FOSS security and privacy applications.(https://security-and-privacy-reference-architecture.readthedocs.io/en/latest/security-sbbs.html)

A few security questionnaires we've come across that you might find useful as you evaluate working with vendors include:

• Although this security questionnaire is from the state of New Jersey in the United States and references local and national laws, it's extremely comprehensive and is still a useful model.

• Google publishes several security questionnaires that are also supported by an adaptable interactive questionnaire application.

• The United States National Institute for Standards and Techology (NIST) publishes a security testing technical guide that gives an "overview of key elements of technical security testing and examination, with an emphasis on specific technical techniques, the benefits and limitations of each, and recommendations for their use."

• SAFETAG is a security auditing framework and evaluation template aimed at advocacy groups that might be more 'right sized' for capacity limited DPGs.

• As noted in the paper, the DPG OpenMRS pared down several well documented and well used security standards, to create a security assessment that made more sense for their on-the-ground circumstances. The report is a good overview of that process and the results.

Also as noted in the paper, the UNDP's guidance note "Managing Risks Across UNDP Programming and Operations" is a useful reference, aimed at helping its programming and operational staff manage risk across the UNDP enterprise.

Lastly, some thoughts on cultural and security considerations when coding in the open.

It's important to think through the cultural shifts required for an open project to succeed. Regulation, policies and processes can set the boundaries of an environment and influence behaviour, but the execution is still up to individual human choice.

open-source co-development often requires new tools and processes, and that change must be supported by the organization's culture. At its heart, open-source collaboration requires communicating and coding in the open. This transparency brings the benefits outlined throughout this document, but it also opens the project -- and its human participants -- to feeling vulnerable to more criticism and being called out more easily for mistakes. open-source collaboration can be a significant change for a team or organization (recall our recommendation to consider if there is a low-risk project you can take on as an 'primer' open-source experiment!). Recognize that change feels like a loss to many -- a loss of stability and what they knew about how to work -- and they will need leadership and guidance. Be sure to keep conversations going in your team about how well your organizational culture supports their needs.

One of the greatest fears of many developers is to jeopardize a project's security and potentially harm real people. Many might worry that open-source code is itself a security vulnerability. What if a mistake is made in the open? How can an agency decide what code should stay proprietary because of security concerns?

The UK government has publicly wrangled with these issues and come up with useful guidance. It's notable that their stance on how much code to develop through an open-source model has changed from "most" to "all, with very limited exceptions". In short, their experience taught them that open sourcing code was actually a great way to confirm and enhance security, perhaps even particularly for code related to managing security. When following and enforcing strong security design, such as ensuring configuration files are kept separately from code, they found that open peer review improves security.

The UK's guidance Security Considerations When Coding in the Open is a concise, clear checklist for developers and program managers that links to other useful resources, such as how to manage software dependencies and the value of automated style enforcement. These checklist items include:

• Open the code early
• Don't rely on closed code as your only security measure
• Follow good development practices
• Keep keys and credentials closed
• Assume accidental publications are compromised
• Deal with security vulnerabilities

Their approach to when code should be kept closed is similarly straightforward:

• Data and code related to keys and credentials
• Algorithms used to detect fraud
• Unreleased policy should be kept closed

Resources and Tools: Adoptability

The Open Source Maturity Model is another way of evaluating an open-source product for adoption. It covers the same points we review in the paper, but it has more of a process-oriented approach that also includes scoring and weighting. More background is in this article by Bernard Golden in Technology Innovation Management Review, (May 2008).

Resources and Tools: Procurement

This panel discussion about agile development and modular contracts includes public sector employees from the state of California and 18F, discussing great insights about the challenges and lessons learned in their revamp of California's Child Welfare digital system.