Helping teams discover smarter ways to use their technology, watching them get excited about fresh approaches, and seeing siloed projects evolve into open, collaborative communities — it’s a process that never gets old. So when the chance came to work with the ITU Telecommunication Development Bureau (BDT) — the development arm of the United Nations agency specializing in digital technologies — I jumped at the opportunity to join a GitHub Skills-Based Volunteering project to help them out.
The plan was simple: Lead a six-month workshop with developers, maintainers, and key stakeholders to support their transition from a closed, Azure DevOps environment, managed solely by their internal team, to an open source community that would be accessible to global partners.
The goal was to empower others to build on their technology and to create opportunities for partners and the wider community to contribute back.
For UN organizations and nonprofits especially, the benefits of open sourcing can be significant. These groups often operate with limited budgets and small teams, so tapping into the open source ecosystem allows them to scale their impact far beyond internal capacity.
After six months of demos, presentations, workshops, and feedback sessions, BDT successfully expanded its expertise in open-sourcing software products by reviewing best practices for developing and publishing software documentation, including guidelines on contributing to software projects. They also gained expertise in selecting appropriate licenses and creating the necessary supporting documentation. Additionally, they acquired skills in managing contributions, ensuring repository security, and received valuable advice on various aspects of open-sourcing software. If you’re looking to make a similar transition, here’s how we went about the journey from start to finish.
1. We did our research.
We looked at open source repositories we liked (and didn’t like) and figured out what learnings we wanted to incorporate into our own.
When someone lands on your repository, they should be able to very quickly check out your README and know what your need is and why they should get involved. Show off what the benefits are to them and the greater community. Explore how they build their issues, how their communities operate, what their guidelines are. Pretend you want to contribute to their project: what did you struggle with and how could you improve upon it?
I went through a lot of different repositories with the team — from ones that were brand new to ones that were very mature — and this gave them an idea of the wide spectrum of what’s out there. If you’re not sure where to start, a couple of favorites for inspiration include Ersilia and Terraform, which are also good examples of really vibrant and involved communities.
2. We refined our open and public mindset to apply it in the software domain.
We examined the code and applied our learnings.
Now that you’ve been inspired by other repositories, it’s time to tackle your own. First, you’ll need to dig into your code and decide what can be turned public and what needs to be scrubbed. You can keep sensitive information private by sanitizing internal references, removing or replacing what is commercially or incompatibly licensed, and creating sample data where needed. When you do use sample data, it’s important to also include a guide on how the data should be formatted so that people can easily input their own.
Once you’ve clearly identified what information is safe to make public, it’s time to put your research into action. GitHub offers some excellent guides to help you get started, but as you shape your project, make sure you’re addressing these key questions: Why should someone want to contribute? Is there a clear onboarding guide they can follow? What workflows and processes are in place to support their success?
Be sure to include these two pieces of documentation:
- “Getting Started” guide: This should include information on how to prepare your local environment from scratch so that new developers know exactly what to install to be ready to contribute.
CONTRIBUTING.mdfile: This is a guide on the expectations and responsibilities when someone is contributing to a project.
As you’re putting together your processes and workflows, one thing to not forget is the need for automated tests. When you start having external developers contribute, you need to ensure code quality; that’s where testing and linting comes in. I recommend this guide on continuous integration to get you started.
3. We figured out our licensing.
If you don’t select an open source license for your project, other people can’t legally use it! One of the best resources for figuring out which open source license to choose is the aptly named choosealicense.com. Some open source licenses put almost no obligations on users (e.g. the CC0 license), while others require giving attribution (e.g. Apache 2.0, BSD or MIT licenses) or sharing of source code (e.g. GPL or AGPL licenses).
You’ll want to think through whether your chosen license is compatible with the licenses of all the dependencies in your project, and make sure it helps the open source community utilize your project as well. For example, if you envision your project being embedded in other people’s projects, this will impact what kind of license you choose.
What was best for ITU? The team ultimately settled for BSD-2, as they were looking for a permissive license that would also be very clear that redistribution of the source code and binary must come with attribution.
4. We started engaging with the open source community.
To get contributors in the door, think about any “small papercuts” your project may have. Set these up as easy wins that allow a contributor to jump in quickly and get familiar with the code base. These can each be turned into a GitHub issue and tagged with good first issue, which helps developers who are new to open source or just new to a repository identify the projects that are ideal for newcomers.
Take this with you
BDT collaborated with GitHub to explore how best to open-source its software products. Recognizing the opportunity that open source presents to enhance global access, inclusiveness, and collaboration, the team aimed to make software tools more widely available and engage a broader community of developers. Through this collaboration, the team received guidance on aligning their repositories with open-source best practices and participated in practical sessions to learn how to manage contributions and collaborate with external developers. This structured approach helped establish a strong foundation for open-source engagement. Building on this progress, the ITU team is committed to open-sourcing additional software products and is now better equipped to continue this work with clarity and confidence.
Going from private to public can be daunting, but by taking it one step at a time, you can shift your way of thinking and see your project grow.
Get involved
Looking for ways to give back to open source projects? Check out For Good First Issue, a repository of social impact and open source projects where you can lend your skills. From fighting climate change to solving world hunger, your efforts will contribute to creating a better future for everyone. Together, we can drive positive and lasting contributions to the world, one commit at a time.
The post From private to public: How a United Nations organization open sourced its tech in four steps appeared first on The GitHub Blog.
Source: Read MoreÂ