Introduction to Open Source for Nonprofits and Social Sector Organizations

Skill Level: beginner

Prerequisites: none

Intended audience: developers and decision-makers within the social sector

Introduction

Open source (OS) software can be used to improve collaboration, increase efficiency, and reduce costs for an organization. When there are minimal restrictions on how it can be distributed, adapted, and reused, it can also be adopted by other social sector organizations, ultimately accelerating work being done to achieve the Sustainable Development Goals (SDGs).

Why should social sector organizations open source?

Collaboration and knowledge sharing: OS software and platforms allow people to collaborate and share knowledge in real-time. By utilizing OS platforms, individuals and organizations can work together to develop and share resources that aim to create positive change.
Cost-effective solutions: OS software can be free or available at a low cost, which can help make sustainable development solutions more affordable and accessible to people and communities around the world. However, it is important to note that there will still be some financial costs as well as an investment of time and resources.
Scalability: OS solutions are often designed with scalability in mind, making it easier for organizations to grow and expand their impact in a way that is measurable through monitoring and evaluation.
Transparency and accountability: OS is developed in a transparent and collaborative manner, which means that anyone can review the code and suggest improvements or modifications. This can increase transparency and accountability in decision-making, which can be especially critical when working with or for governments.
Localization: OS software and platforms can be easily localized and adapted to meet the unique needs of different communities and regions. This can help ensure that sustainable development solutions are tailored to the specific context and needs of the people they are intended to serve.
Flexibility and customization: OS software is highly customizable, which means that it can be adapted to meet the specific needs of an organization. This flexibility can also help governments avoid vendor lock-in and maintain control over their IT infrastructure.
Interoperability: Open standards and protocols common in OS software can help nonprofits and social sector organizations more easily integrate their solutions with other systems, improving efficiency and collaboration.
Data sharing and analysis: OS platforms and tools can be used to collect, analyze, and share data on sustainable development indicators. This can help track progress towards your impact goals and inform policy decisions and resource allocation.

How to open source

To get started, you can first identify areas where OS software can be used and evaluate options for procurement or identify projects within your organization. Once a project or product has been identified, you will begin customizing and configuring it to meet your specific needs. This may involve modifying the software code, adding new features, or integrating it with other software tools. Check out the seven questions to ask before open sourcing reference for more information. It will guide you through questions such as “Is there an approval process to help developers introduce new open source software (OSS) into our organization?"

In terms of change management, training of staff and volunteer recruitment are important to ensure continued collaboration and engagement. This may involve providing online training resources, hosting in-person workshops, or hiring consultants to provide training and support. Workshops to introduce OS can also involve fostering a culture of encouraging staff and volunteers to contribute to the development of other OS software in the social sector.

To make the most of OS software, social sector organizations should:

Identify specific needs and look for relevant solutions within the OS ecosystem.
Evaluate the quality, reliability, and security of the identified solutions, including the strength and responsiveness of your communities.
Invest in capacity building and training to ensure staff can effectively implement, customize, and maintain these solutions.
Engage with the developer and user communities of chosen solutions, both to learn from others and to contribute your own experiences and insights.
Monitor and evaluate the impact of using OS software and DPGs on their operations and overall mission. Refer to the MERL (monitoring, evaluation, research and learning) Center — a community creating resources about the intersection of MERL and OS, as well as data science and human-centered design — for more information.

Open sourcing your project on GitHub

The first step to begin open sourcing your project on GitHub will be to create a repository or "repo". This is where all of your code, files, and revision history will live. For step-by-step instructions on how to set this up, take a quick look at this guide.

Documentation for newcomers

Repository section	What should live in the section
README.md	Details and description about the project and community, including how to install and use the project. Links to LICENSE.md and CONTRIBUTING.md should be in this section.
CONTRIBUTING.md	Contribution guidelines and helpful hints of how developers can get started.
DEVELOPMENT.md	Guidelines on setting up the development environment.
CODE_OF_CONDUCT.md	Behavioral expectations for contributors and members of the community. Contributor Covenant is an example that is used in a number of projects.

Project organization: roadmap

Like any project, you will need someone (or a group of people) to build out a vision for the project in the short-term and long-term. Some of this will be big picture planning — like creating strategies — and some tasks will be smaller but no less important. It’s these types of everyday tasks that ensure your project stays on track. This planning doesn’t have to be done by someone with a technical background, it can also be done by someone with project management skills. They can begin with some of the following:

Documenting a roadmap and planning sprints
Creating issues and keeping projects organized
Grooming the backlog by prioritizing issues
Creating metrics for monitoring and evaluation as well as for measuring impact
Being ok with saying no to some feature requests; only plan what you can realistically achieve
Being open and transparent with your community about the roadmap and what requested features have been planned

Project organization: project boards, issues & labels

An article on the different templates that can be used for a new project on GitHub

It’s key to keep your project board well organized so that things like rotating volunteers, high turnover rates, or periods of low production won’t disrupt the work that’s been put in. If someone new stepped into the project today, they should be able to understand the way the project was structured and know how to continue working in a cohesive manner. Luckily, issues and labels are here to help with just that. Issues help you track work, manage feedback, and communicate with colleagues. Labels can help you categorize issues, pull requests, and discussions. Here are some commonly used labels:

Epic - a large body of work that is then broken down into smaller tasks or user stories
Good first issues - a good issue for first-time contributors
Bug - an unintended behavior or problem
Feature - a piece of software that serves a functionality or capability
UX - stands for user experience and describes how someone would interact with the product
API - stands for application programming interface which refers to the way two or more programs or applications communicate with each other

Pro tip: You can configure automatic workflows, which help keep the status of classic project cards in sync with the associated issues and pull requests. Automation can decrease the amount of manual work needed when an organization has limited resources.

Building and engaging with your community

Defined roles

When newcomers join your project, you want to make sure that the roles within the project are clearly defined and documented (example ROLES.md); check out a quick example. Some projects just have two roles — such as a contributor and maintainer — while other projects also have a third role working between them — an approver or committer.

Maintainers

Maintainers can be seen as the “owner” of the project as they’re guiding project direction and building out the roadmap. They’re the key decision-makers who are responsible for reviewing and accepting or rejecting pull requests from contributors. They also have administrative access to the project's repositories. Most projects have a few key maintainers who are doing the majority of the work.

Contributors

A contributor has some sustained level of contribution to the project — from just 1 or 2 PRs or contributions, all the way up to sustained contributions over a few months. They can contribute to the project in any way, including coding, writing documentation, creating issues, or participating in discussions. Contributors do not have commit access to the project's repositories, but their contributions are reviewed and, if accepted, merged by the maintainers. These are people who are excited about growing your project and making it better for your users. Examples of these could be:

Experts from your organization
First-time contributors
Designers
Volunteers working in different issues
Product Managers

Approvers or Committers

An approver or committer is someone who has been involved long enough or is expert enough to approve commits from everyone else. Committers are contributors who have shown consistent and valuable contributions to the project. They have been granted commit access to the project's repositories but are expected to use this access responsibly.

Users

Those who just want to install and use your OS software. They can be from a variety of backgrounds such as:

Backend Developer
UI Developer
DevOps Admin
Frontline Aid Worker
Operations Lead

Communication: working groups

An OS working group can include software developers, industry professionals, hobbyists, and anyone interested in promoting and contributing to the OS community. They work collaboratively to develop OS software, which is then released under an OS license, allowing anyone to view, modify, or distribute the source code. They play a crucial role in the OS ecosystem by fostering collaboration, promoting the use of OS software, and facilitating the sharing of ideas and resources. Working groups are especially useful when working on complex projects, and can benefit from asynchronous working styles as well as detailed documentation for those working in different time zones.

Communication: tools

It’s helpful to encourage asynchronous communication — especially when you have people working in different time zones. Useful tools that can create this type of working environment include:

Slack
Repository issues and comments
GitHub Discussions — such as this example
Google Docs
Email distribution lists

Encouraging community growth

“Build it and they will come” is not always true. We’re in an age where people are suffering from information overload, and it can be difficult for your project to be found organically. Here are a few ways to ensure the right users and contributors find your project:

Partner with larger organizations through volunteer initiatives; like this example
Partner with a university course over a semester
Promote your project through social media channels and targeted marketing
Hold speaker or lab sessions at conferences
Create a website for people to learn about the project (this can be developed once it’s more established)

Communication is key

To have a successful OS project and a thriving community around it, clear communication is essential from the very beginning. The leader of this initiative needs to factor this in as they’re defining the community and setting expectations. One great way to do this is by ensuring that everything related to your work is documented and recorded, such as how a new volunteer can contribute. There are great tools that can help with this, such as using templates from other existing OS projects. A few things to always keep in mind:

Define the community and expectations around your OS project and set communication guidelines. Good documentation is huge! Consider language localization when developing this to increase accessibility.
Asynchronous communication such as the Discussion board, Slack Channels, or Discourse can drive successful collaboration.
Consider conducting an audit to ensure that your communication style aligns with OS principles and the community.

When establishing communication guidelines, these are a few key questions to consider:

Are you accepting contributions or just open sourcing the code without a desire for input? Not wanting input is entirely okay, but just make sure that’s clearly set out in the README so potential contributors aren’t surprised or disappointed.
Where and how should users report bugs? Outlining this at the beginning will help reduce friction when problems arise.

What's next: become a Digital Public Good

Led by the Digital Public Goods Alliance, Digital Public Goods (DPGs) are open source software, open data, open AI models, open standards, and open content that adhere to privacy and other applicable laws and best practices, do no harm by design, and help attain the Sustainable Development Goals (SDGs). There are nine indicators in the DPG Standard that are used to determine whether a solution is a digital public good and regular auditing is done to review the DPGs. The DPG Standard establishes the baseline requirements that must be met in order to earn recognition as a digital public good (DPG). This standard is designed to complement other relevant principles such as the Principles for Digital Development and is applicable to DPGs in all sectors across the SDGs. The DPG Standard is itself an open project, open to contribution on GitHub, and developed in collaboration with organizations and experts.

Once an open source project nomination is submitted, it undergoes a technical review against a baseline of 9-indicators that serve as a minimum standard that all digital public goods must meet. Once the technical team reviews and approves that the documentation meets the standard, it gets added to the DPGA registry.

Seek sponsorship and funding for your project

If funding is a key barrier to your organization adopting OS, there are a number of opportunities you can look to for support. Funders aim to invest ahead of the curve in new categories, projects, and people to ensure OS thrives and developers have the choice to contribute full-time to the projects they care about most. A few general opportunities include:

GitHub Sponsors is a way for organizations and individuals to directly fund OS maintainers globally. To enable sponsorships on your GitHub account, you can get started here.
The GitHub Accelerator is a cohort-based education program with expert guests that talk about OS funding paths and explore the needs of individual projects. Start your application here.

If you’re working on a project that relates to a specific SDG, there are also sponsorships and accelerator programs that cater directly to these such as:

The World Food Programme (WFP) Innovation Accelerator, which sources, supports, and scales high-potential solutions to end hunger worldwide. They provide WFP staff, entrepreneurs, start-ups, companies, and NGOs with access to funding, mentorship, hands-on support, and WFP operations. Apply here.
The UNICEF Venture Fund’s mission is to invest in early-stage tech solutions that support children and youth. They provide funding as well as a year of mentoring. Get started with an application here.

Resources

For more information on:

Special thanks to Belinda Vennam (@bvennam), SKi Sankhe (@megamanics), Joshua Ku (@therealkujo) on developing and leading the Open Source training together with the United Nations Office of Information and Communications Technology (OICT).