Opening a UN Development Unit's Codebase

The ITU Telecommunication Development Bureau (BDT), the development arm of the UN's digital technology agency, recently took its software from a private Azure DevOps environment to a public open source community. The goal was to let global partners and outside developers build on the bureau's tools, and then contribute fixes and features back. For a nonprofit operating with a small team and tight budget, that external capacity can multiply impact.

The transition took six months of workshops and reviews covering documentation, licensing, contribution management, and repository security. The steps below reflect what BDT and its GitHub Skills-Based Volunteering partners learned along the way.

Start by Studying Other Repositories

Before touching your own code, look at how successful open source projects are structured. Review their READMEs, issue templates, community guidelines, and contribution workflows. Ask what would draw you in as a potential contributor and what friction you hit along the way.

The BDT team surveyed everything from brand-new repositories to mature ones like Kubernetes. For active, welcoming communities, Ersilia and Terraform are solid examples. A new visitor should be able to read the README and understand immediately why the project exists and why their involvement matters.

Prepare the Code and the Docs

Once you know what a good project looks like, inspect your own code. Decide what can be made public, sanitize internal references, remove or replace commercially or incompatibly licensed components, and create sample data where needed. If you supply sample data, include a format guide so outsiders can substitute their own.

While shaping the public repository, answer three questions: Why would anyone contribute? Is there an onboarding guide? What workflows support early success? Two documents are essential:

  • "Getting Started" guide: Steps for preparing a local environment from scratch, listing everything a new developer must install.
  • CONTRIBUTING.md: The expectations and responsibilities for anyone submitting work to the project.

Plan for automated tests and linting before opening the repo. With external contributors, continuous integration is the only reliable way to enforce code quality. Workflows will need to define how contributions are reviewed and merged as the maintainer team changes.

Choose a License That Fits

Without an open source license, others have no legal right to use your code at all. choosealicense.com is a practical starting point. The main trade-off is between permissive licenses like CC0, which put almost no obligations on users, and licenses like Apache 2.0, BSD, or MIT, which require attribution. Copyleft options like GPL or AGPL go further, forcing downstream users to share their source code as well.

Check that your chosen license is compatible with every dependency in the project. Also consider how you expect the code to be used: if you want it embedded inside other products, a permissive license matters more than if you plan to distribute it standalone.

BDT chose the BSD-2 license. It is permissive enough for broad adoption while requiring clear attribution whenever the source or binaries are redistributed.

Invite the First Contributions

With the repository public, list small, low-risk problems as a good first issue. These easy wins let newcomers navigate the codebase and build confidence before they take on larger features. File each as a GitHub issue so the path in is obvious.

BDT has committed to open-sourcing additional products on the strength of this process. The bureau's team is now equipped to manage outside contributions and collaborate with external developers more broadly, both for its current tools and its pipeline of future releases. A shift from private to public is significant, but it becomes manageable by handling documentation, licensing, and initial issues as separate and deliberate stages.