This year, the UNICEF Venture Fund celebrates five graduating companies from a recent investment round. For the first time, many of these companies are exiting from the Venture Fund having already earned recognition as Digital Public Goods (DPGs). With the support of a cross-sectional team of mentors, these graduating companies worked to achieve compliance with the DPG Standard.

The Digital Public Good Standard offers a nine-point baseline for evaluation and recognition of Open Source software, content, data, and standards that adhere to privacy and other applicable laws and best practices, do no harm by design, and help attain the Sustainable Development Goals (SDGs). Once a solution is recognised as a digital public good it is discoverable on the DPG Registry.

This recognition acknowledges their use of vetted Open Source licenses, useful documentation, and adherence to relevant best practices and local data protection laws. What makes this achievement a first for the Venture Fund is that these recognitions were achieved by the companies during the investment round. Typically, companies that go on from the Venture Fund achieve recognition after a year or more of graduation. This new shift is made possible by the growing investment in Technical Assistance at the Venture Fund and the leadership of a robust team of mentors.

This article introduces the Technical Assistance mentoring programmes offered by the UNICEF Venture Fund, the addition of new mentors in the last year, the shift of mentor focus around the DPG Standard, and the results achieved to date from the latest graduating Venture Fund cohort.

Origins of Technical Assistance at the Venture Fund 🔗

The Venture Fund offers different areas of Technical Assistance to start-up companies who apply and are selected to receive early-stage seed investment by UNICEF. Originally starting in 2018, the Technical Assistance programmes only included Business Development and Open Source. Over the years, we have piloted and pivoted mentorship models with input from our portfolio of startups. Today, the Technical Assistance programmes cover a range of topics across an experienced team of mentors, depending on the relevance to the start-up companies:

• Blockchain with Arun Maharajan and Alex Sherbuck (former)
• Business Development with Jamil Wyne and Philippa Martinelli (former)
• Evidence of Impact with Milena Bacalja Perianes and Jennifer Sawyer
• Data Privacy & Security with Lydia Kwong
• Data Science & A.I. with Daniel Alvarez
• Open Source with Justin Wheeler, Abigail Cabunoc Mayes (former), and Vipul Siddharth
• Software Development with Iván Perdomo

The mentors work closely with the experienced team of portfolio managers (Meghan Warner, Kennedy Kitheka, and Madison Marks) to guide and coach Venture Fund companies to achieve their targets and success indicators during the investment round.

Starting in 2021, the Venture Fund broadened the Technical Assistance programmes to include Software Development, Data Science & A.I., Data Privacy & Security, and Evidence of Impact. This was a marked change in growing the support and expertise made available to start-up companies during their investment round. However, as the team of mentors and Technical Assistance offerings expanded, there was a growing need to bring a common rallying point across all programmes. How could the mentors ensure their Technical Assistance programmes complemented one another without duplicating topics or repeating conversations?

Further complementing the core Technical Assistance programme, specialized workshops were held by like-minded institutions outside the Venture Fund’s core team of mentors , along with personalized mentorship sessions. The recent Blockchain Cohort, for example, benefitted from targeted mentorship from AW3L, a blockchain consulting firm that share many of UNICEF’s values around leveraging blockchain for social impact.

“Blockchain has immense potential, but it remains just a tool and its impact is dependent on what we do with it. That’s why it is crucial to have local entrepreneurs on the ground building use-cases that solve real problems unique to their geography. We are therefore extremely happy and proud to support UNICEF and its portfolio companies to tackle real-world problems in emerging markets by utilizing blockchain technology.”

Martijn van de Weerdt, Founder, AW3L

How the DPG Standard unified the mentoring streams 🔗

The DPG Standard became a common rallying point for the UNICEF Technical Assistance programmes. As our mentoring programmes increased and topic areas broadened, we needed coordination and a synchronized stream of Technical Assistance programmes. In the last year, the Venture Fund reviewed its workplan development and strategy to enable more solutions to achieve recognition as a digital public good at or near the graduation point for a Venture Fund portfolio. The most recent graduating cohort, the 2021 Blockchain cohort, represents this improved alignment, with 4 of 5 companies receiving recognition of their products as digital public goods by their graduation this year.

How does recognition of an open solution as a Digital Public Good help Venture Fund startups? It is an acknowledgment by the Digital Public Goods Alliance of a commitment and adherence to best practices and steps taken to protect data privacy and do no harm. Additionally, recognition as a DPG unlocks stronger potential for adoption and deployment of the solution by global stakeholders by providing greater visibility in a public roster of open solutions that adhere to best practices and standards. The recognition of 80% of an off-boarding Venture Fund portfolio speaks to both the intrinsic capabilities of the companies and the value of the Technical Assistance programmes and mentorship provided to them by the Venture Fund.

While past Venture Fund companies have received recognition as digital public goods before, this is the first time that a company achieved the recognition at the time of their graduation from the Venture Fund. Aligning the Technical Assistance programmes around the DPG Standard provided common frameworks and mental models for the diverse team of mentors to support the companies and help them achieve the Standard as an important part of their product development lifecycle.

“As an early-stage startup, we struggled with a clear business model. Especially in the last six months of the investment, support from the mentor network helped in building clear business growth and impact metric plans. Also a year ago, we were very heavy on the tech side but lacked considerable planning on network and visibility growth. We have developed a customer persona and a pricing model, and now have a clearer vision of our Total Available Market, Serviceable Available Market, and Serviceable Obtainable Market (TAM, SAM, and SOM) models.”

Rumee Singh, Co-Founder, Rumsan

Further, farther, together 🔗

What comes next? The Technical Assistance programmes at the UNICEF Venture Fund are gearing up for additional cohorts benefiting from our seed-stage investment: a Data Science & A.I. cohort and an upcoming Blockchain cohort. These early-stage companies undergo a technical assistance programme involving a technical and strategic workshop series and monthly mentorship meetings. Graduates of our seed-stage investment that  have received additional capital through our Growth Funding to take their solution to the next level of impact also benefit from customized mentorship to support their evolution from good prototype developments to solutions that can be implemented and scaled, with sustainable business models and proven pilots.

Additionally, mentors are developing digital toolkits to enable Venture Fund companies and anyone to read up and study best practices for building and sustaining digital public goods. Most of these toolkits will be released digitally online under Open Source licenses. You can find three of these toolkits below:

• Data Science & A.I.
• Drones
• Open Source

Since the first Technical Assistance programmes were launched in 2018, the Venture Fund has seen improved results that correlate with the Technical Assistance programmes. In the most recent Blockchain 2021 cohort, across 500+ hours of mentoring, the cohort collectively reached over 700,000 beneficiaries, raised $4M in follow-on funding, and 4 of 5 graduating companies were recognized as a digital public good before graduation. This also marked a new record of external contributors, with a total of 39 people who contributed to repositories across all portfolio companies. The expert guidance and coaching provided by the team of UNICEF mentors aids the start-ups in achieving new record heights.

“UNICEF’s support helped Xcapit build value, with a premium put on discovery, iteration, survey, and experimentation with the end user. The guidance at the right time is priceless. It prevented us from facing a major problem in the future when our blockchain UNICEF mentor guided us when we were deciding the technology to create our wallet. Changing our mindset to become a fully open source company was also challenging. We had the best guidance we could ask, and we successfully overcame the difficulties and doubts, understanding the benefits of open collaboration.”

Antonella Perrone, COO, Xcapit

Contribute to Technical Assistance knowledge and mentoring 🔗

The UNICEF mentor toolkits are open source and you can also participate. The toolkits are currently accepting contributions for UI/UX and front-end development, as well as content curation and authorship. Get involved with the toolkits by participating via GitHub:

• UNICEF Inventory theme (see “good first issues”)
• UNICEF Open Source Inventory
• UNICEF Data Science & A.I. toolkit

With the Digital Public Goods Alliance, we built upon our learnings and successes from portfolio companies and created the DPG Accelerator Guide as a collection of resources for accelerators to also support local ventures in developing digital public goods, setting them up for scale and impact.

This post is a reflection on the past year in my work with the UNICEF Venture Fund. We integrated new open source tools to capture metrics and data about open source repositories connected to UNICEF portfolio companies and created a shortlist of key metrics that map to business sustainability metrics. Now, we are better positioned to look back on past, current, and upcoming portfolio companies and mentor support programs.

As we move into 2022, this post covers my current thinking on these points:

1. Defining investments.
2. How do these investments impact sustainability?
3. CHAOSS metrics as an open source tool for an investment lens on sustainability.
4. What next?

Defining investments. 🔗

When we talk about investing in open source, what do we mean? What are the known inputs? What are the expected outputs? “Investments” and “investing” are broad terms. Investments typically mean sizeable financial injections of support and growth, but can also include non-financial investments too. Investments can also take the form of both time and energy (i.e. electricity and digital infrastructure).

The UNICEF Venture Fund provides equity-free funding for start-up companies building open source solutions of interest to UNICEF. All the start-up companies are registered companies in UNICEF program countries. As part of the Venture Fund’s location in the Office of Innovation, it is also a vehicle for UNICEF to explore frontier technology areas through the investments. When a start-up company is receiving investment from UNICEF, the company receives both funding and tailored mentorship about business and open technology.

A question I want to know is, what is the impact of the received funding plus guided mentorship? How does this approach enable the companies to be successful after graduating? What discoveries or knowledge could be shared with others to assist the development of their own open programs?

To summarize, an investment can be financial or non-financial. Financial investments include direct funding, grants, venture capital, fellowships, or any other exchange of capital. Non-financial investments include time spent in coaching sessions, personalized content for companies, and shared digital infrastructure. Neither list is exhaustive.

How do these investments impact sustainability? 🔗

Data makes introspection easier. Bitergia’s Cauldron.io was a champion tool for kickstarting an open source metrics strategy for the UNICEF Venture Fund. Its introduction as a tool opened up a wider span of data to look at. There are new opportunities to ask questions and explore growth, scale, and sustainability.

In order to come to a conclusion on sustainability impact, we need streamlined data to test a thesis. The Venture Fund team improved internal processes to how metrics are collected from portfolio companies. The team is unifying behind fewer tools and methods to ensure we see the same data and have the same view of the data points we measure. This also provides a fresh opportunity to review how we measure open source impact across portfolio companies. Many have dashboards on Cauldron.io, but data needs a storyteller for it to make meaning. So, the next step is to ask questions with this new data and frame a thesis to measure and test the sustainability of Venture Fund investments into open source.

Many have traveled before me on the same trail of thought. I started first with the Community Health Analytics Open Source Software (CHAOSS) project and its metrics releases. This served as the initial point of brainstorming to frame questions and different scenarios of risk, evolution, DEI, and value.

CHAOSS metrics as an open source tool for an investment lens on sustainability. 🔗

I reviewed the latest release of CHAOSS metrics and narrowed down four metrics I want to measure in the next year. I also shared thoughts on why collect this data and how to do it. This blog post is no more than me wondering out loud, to help me frame an analytical approach for this metrics strategy.

The four metrics are detailed below:

1. Contribution Attribution
2. Contributors
3. Collaboration Platform Activity
4. Labor Investment

Contribution Attribution 🔗

Question: Who has contributed to an open source project and what attribution information about people and organizations is assigned for contributions?

chaoss.community/metric-contribution-attribution/

This metric is insightful because it is targeted deeply into team and project culture. This metric is a good representation of how much the project leans into an open source model of building their project. This work ethos and intention to forge on an open source path is difficult to understand at times. If a team takes care to attribute their software dependencies and other contributors to their code (if any), this is a good sign that the team accepts collaboration as a value and encourages working with others.

I would measure this across two types of contributions: attributions for software dependencies including those with permissive licenses, and for any other direct contributors to the code and how they are recognized for their participation. This could be filtered in a red-yellow-green light approach:

1. Red: No attributions are made, or all attributions are inadequate.
2. Yellow: One of two attributions are made, or one attribution type is inadequately attributed.
3. Green: All dependencies and used works are correctly attributed.

Contributors 🔗

Question: Who are the contributors to a project?

chaoss.community/metric-contributors/

This metric explores a more human dimension of the people and participants to an open source project. The metric defines contributors and contributions broadly, as “anyone who contributes to the project in any way.” Understanding the people participating in a community, their motivations, goals, and why they choose to be in that community is important to understand sustainability. Otherwise, you may lose out on good opportunities to attract contributions from people who are already engaged, and new engagements may be difficult because of a mismatch of expectations.

This metric is more a means than it is an end; that is, it provides opportunities to ask more questions than provide detailed answers. Nevertheless, it does provide some guidance towards understanding contributors in a project, and it can lead to some concrete actions based on gathered insights. For example, this metric will enable deeper looks in areas of diversity, equity, and inclusion.

Since I work with start-up companies with small, lean development teams, I look to understand the motivations of the developers working on their projects and where the motivations may align with another open source solution. This enables the two communities to leverage their combined brainstorming for meeting complimentary goals around development and innovation.

To collect this data, I would have the team define what areas of contribution they seek for their open source solutions and then map those desired contributions to a specific project area or different team members. This enables a form of consistent accountability for checking expectations with reality and understanding team capacity. Each area could be a key-value pair, where the value is the project area, team lead, or delegated team member for the type of contribution solicited.

Collaboration Platform Activity 🔗

Question: What is the count of activities across digital collaboration platforms (e.g., GitHub, GitLab, Slack, email) used by a project?

chaoss.community/metric-collaboration-platform-activity/

Collaboration platform activity is one effective proxy metric for community engagement if measured accurately. The metric does not define collaboration as much as it provides a data structure to measure it. It abstracts collaboration into key data points like timestamp, sender, whether the platform has threaded or non-threaded discussions, data collection date, and platform message identifier. To a degree, collaboration can be abstracted out in this way: a person takes any given action at a given time in a given way, and this action is measured as project-related activity on the collaboration platform.

There are a few possible approaches to collecting this data from UNICEF Venture Fund companies. Each approach does not cancel out another, but each approach could be combined with the others:

1. Measure common git activity like commits, issues, pull/merge requests. We already measure this data, but use it only in connection to validating Venture Fund workplans for each team with UNICEF portfolio manager(s).
2. Count communications like comments, reviews, public messages, and other outreach. Communications strategies and tools are typically inferred from common git activity. Measuring for engagement and stratifying those metrics into a smaller group could allow for deeper insights to the evolution of early-stage open source communities.
3. Make community hubs first-class citizens in the data curation process to infer about informal engagement. Both open source projects and UNICEF Venture Fund portfolio companies use a variety of tools to communicate, especially in view of COVID-19 and its seismic impact on how we work. Platforms like Discord, Telegram, Mattermost, Slack, Rocket.chat, Matrix, and others are focal points where projects collaborate, ask questions, and support others. Bringing this data stream into the mix offers deeper insights into how teams engage and build community around their work, and also guidance on when to push for contribution opportunities at the right time.

The satisfaction of these three options in their totality is not enough. To leverage the fullest impact, these metrics must tie into each other, and need to be connected back to a narrative. Why is this data being collected and what actions are influenced by the knowledge of this data? The data collection enables the evaluation of sustainability and understanding the birth, growth, and evolution of an open source technology product. Influenced actions can include moving more human resources (i.e. contractors or staff) to support a project, adopting a new open source best practice, and/or engaging new customers, talent, or other leads based on participation in the community.

Measuring collaboration platform activity is not black and white. Many new questions would likely come forward as part of measuring this activity. Yet this is the point—it lays the foundation for the next layer to the data collection, analysis, and reporting process around sustainability.

Labor Investment 🔗

Question: What was the cost of an organization for its employees to create the counted contributions (e.g., commits, issues, and pull requests)?

chaoss.community/metric-labor-investment/

This metric is perhaps the most ambitious of the group. How do you measure labor investment into an open source project? Or literally, the number of person-hours that go into software design, development, co-creation, and community management? It feels like a gargantuan effort, but there may be better ways to measure this in connection to other data the UNICEF Venture Fund is already connected about the businesses.

Measuring labor investment impacts two narratives: the rate of development on the open source work, and the impact of UNICEF investment into a company backing an open source work.

Firstly, understanding the rate of development on an open source work is easier to infer by understanding who is allocated on a project and how much of their time they dedicate to it. If a team of three contributors spares a few hours a week, it will mean something different compared to a team of five engineers spread across different disciplines working full-time. Mapping the labor investment for open source projects supported by UNICEF would enable better planning by understanding the typical labor investment in open source workplan tasks as piloted by other Venture Fund portfolio companies.

Secondly, this gives us a new way of talking about the impact of UNICEF Venture Fund investments as an investment not only in software products but also in labor. It gives us insight into the investment of labor in software engineering talent among portfolio companies. How does this measurement change over time of the investment? Do projects receive more or less investment of labor during the 12 month period we work with them? This could also be used as a proxy metric for the impact of our unique mentorship and coaching opportunities.

What next? 🔗

Knowing is half the journey. Even if the knowledge is not yet firmly rooted. The analysis and introspection are from me as an individual working among the UNICEF Venture Fund and do not represent the views and beliefs of UNICEF or the UN in any capacity. My intent is that by sharing this analysis in the open, it allows for a space where conversation can spark where it could not before. It also invites others to share ideas, feedback, and constructive criticism of an emerging metrics strategy for investments made into the open source ecosystem.

Next, more layers can be added and internal and external validation can help to keep this moving forward. An implementation plan would be the next step to follow this post. The implementation plan considers the process of how start-up companies move through the Venture Fund from start to finish. Who interacts with the companies and when? At what point is a company ready to begin building in a new metric or count in their monthly metrics? Do they understand the implications and assessments of these metrics? At what points in the process is data already being collected? Could these new data requests be added to existing requests? And so on.

I hope to formalize some of this new reporting and metrics strategy in upcoming cohorts in 2022, as part of a renewed effort into communicating how our open source investments tie into sustainable impact towards the U.N. Sustainable Development Goals.

This post will serve as a milestone marker on the metrics strategy discussion in the coming one to two months. See you in 2022.

Featured photo by Edward Howell on Unsplash. Modified by Justin Wheeler. CC BY-SA 4.0.

The UNICEF Innovation Fund invests exclusively in Open Source technology – with today’s rapidly evolving innovation landscape, Open Source software, hardware, data, and content not only create value and generate revenue, but also ensure greater collaboration and impact. This reflection is a look back at Open Source activity and participation stemming from the UNICEF Ventures Team from June 2020 to date (July 2021).

By the end of this article, you will have a better understanding of the evolving and forward-thinking approach to Open Source taken by the UNICEF Office of Innovation.

This article looks at a few aspects of Open Source engagement at the Innovation Fund:

1. Support models
   1. Legal & policy
   2. Building and leveraging from the community
2. Case study: Cloudline and upstream engagement

New to Open Source at UNICEF? 🔗

If you are hearing about the UNICEF Open Source Mentorship programme for the first time, check out this introduction post to get important context behind why UNICEF invests in Open Source mentorship and support for Innovation Fund portfolio teams:

/blog/2021/07/unicef-open-source-mentorship/

Innovation Fund support models 🔗

Start-ups receive both funding and customized mentorship during their 12-month investment period with the UNICEF Innovation Fund. Since the Innovation Fund launched in 2016, the Innovation Fund team noted the impact of hands-on guidance to help start-ups understand how to work open and lead open. Start-ups receiving Open Source support were better equipped to develop sustainable business models that made Open Source intellectual property work with them instead of against them.

By the end of the 12-month investment cycle, graduating companies achieve the following milestones in place with their projects:

• Solid understanding of Open Source licenses and different business models depending on a permissive or copyleft strategy.
• Laying foundations for growing or participating in friendly, inclusive communities.
• Documentation site to showcase their Open Source work, and how to get involved.
• Continuous Integration pipeline to test new changes in the code-base before they are added, and avoid common human errors.

Across these milestones, three themes of support have emerged as as most essential in the past year: legal & policy, building and leveraging from the community, and building in the open.

Legal & policy 🔗

The UNICEF Innovation Fund is unique in Venture Capital on its open-first investment strategy. Start-ups receiving UNICEF funding are obligated to either create their own Open Source works or contribute to existing Open Source works. This leads start-up teams to ask more questions: how does this work in a legal sense? How do you establish a sustainable business model with Open Source dependencies and the different types of license models that exist (e.g. permissive and copyleft)? These are the questions that start-ups receive tailored guidance on from the Open Source Mentorship programme.

How did the Open Source Mentorship programme support both start-ups and UNICEF Country Offices receiving funding from the UNICEF Innovation Fund? The programme improved business and legal resources and referrals for managing Open Source intellectual property. This was primarily done by creating a self-serve knowledgebase of legal, governance, and tech policy: the UNICEF Open Source Inventory. The Inventory was created in close consultation with start-ups receiving UNICEF funding, leading industry experts in areas such as Open Hardware and open design, and other existing Open Source communities of practice.

Building and leveraging from the community 🔗

Over the past year, we also saw more upstream collaboration. UNICEF Innovation Fund start-ups collaborated on existing projects like the PX4 Drone auto-pilot software instead of reinventing the wheel themselves. This enabled the work done with UNICEF funding to go further and impact the wider ecosystem, instead of an individual project with highly-specific use cases.

Furthermore, as the Innovation Fund portfolio continues to grow, new inductees in the Open Source Mentorship programme are able to build on top of work done by previous portfolio companies. This accelerates the rate of development for the new inductees and gives them a model of success to look towards during their engagement with UNICEF.

For example, two companies from the 2019 Drones cohort created documentation websites that were used as models for the 2020 Generation Unlimited cohort. qAIRa from Perú and Rentadrone from Chile created documentation websites using the popular toolchain Docusaurus, created by Facebook’s Open Source Program Office. The work of qAIRa and Rentadrone was leveraged as models by VRapeutic and I-STEM in the 2020 Generation Unlimited cohort. Using graduated companies as models accelerated both technical and content development for the new teams when they had relatable models to use in building their own Open Source documentation websites.

Innovation Fund case study: Cloudline and upstream engagement 🔗

Cloudline Africa (South Africa) operates small-scale autonomous airships that have longer endurance and range than current commercial drones; their solution will help deliver medical supplies to hard-to-reach communities and reduce operational costs in the last-mile.

Four highlights from Cloudline’s period with the Innovation Fund are below:

• The team launched the airship with a payload capacity of 10 kgs with a 50 km range.  
• Full endurance capability (40km/h) along with automated waypoint flying. 
• Contributed flight control software to the PX4 upstream community by introducing a new mode of aircraft to the community in the form of airships.  
• Cloudline received the Fast Company South Africa Most Innovative Company Award 

“Our greatest triumph of the year was the flight of our pre-production airship. Capable of a 10kg useful payload and a 50km range, this aircraft is ideally suited to medical logistics and other high-value scheduled deliveries.” — Spencer Horne, Co-Founder

Going upstream 🔗

Contributions made to another popular upstream community was another major highlight of the Open Source Mentorship programme. Furthermore, the contributions were not casual “drive-through” contributions; they were consistent and focused broadly around the ecosystem instead of a single repository of source code.

During the mentorship programme, Cloudline added 61 commits across four repositories. The summary of their contributions were adding a new vehicle type to the PX4 auto-pilot software: airships. The team first opened a discussion on the PX4 community forum. After getting feedback from a developer, they proceeded to add the Cloudline airship into the upstream software. This was followed by documentation additions with controller diagrams and simulation instructions. Through their contributions, a wider network of developers can simulate and interact with airships similar to the one created by Cloudline.

But the contributions did not stop at code. Cloudline developer Anton Erasmus delivered a deep dive presentation at the PX4 2020 virtual contributor summit. He explained to other developers about how to leverage the multicopter control system, as used in the Cloudline airships and other popular drone devices. This outreach step is important in growing awareness in the existing community for new introductions to the common software, and how both Cloudline and the PX4 community could help each other in achieving their similar yet different goals.

What is next for the Innovation Fund? 🔗

What does the next year ahead look like for UNICEF’s Open Source Mentorship programme? Stay tuned for the final post in this series, which will explore on-going work to standardize the mentorship curriculum, detail how Innovation Fund companies are being coached in becoming Digital Public Goods, and the research and development for an Open Source Program Office at the UNICEF Office of Innovation in 2022.

Special thanks for content and data collected in this post: Sanna Bedi, Zenani Orengo

2020 saw the launch of a formalized Open Source Mentorship programme for the UNICEF Innovation Fund, built up on two years of work from RIT LibreCorps expertise and consulting.

The Open Source Mentorship programme includes five modules about Open Source intellectual property and communities delivered across twelve months. UNICEF grantees are matched with an experienced Open Source Mentor to guide them through the modules. The mentorship takes an interactive, guided approach to understanding the unique context that each team and product exist within. The assigned Open Source Mentor provides specialized advice and training:

• Tailored feedback based on business models
• Existing local user communities
• Best practices for collaborating together with others on similar challenges.

The geographic diversity in the UNICEF Open Source Mentorship programme is unusual for technology incubators or accelerator programs. All funded projects come from UNICEF programme countries. The UNICEF Innovation Fund provides equity-free funding for Open Source solutions from local innovators and entrepreneurs solving local problems. To date, the Innovation Fund has invested in teams from over 57 countries. Argentina, India, Iran, Kenya, Mexico, Nepal, and Rwanda represent the most recent incoming cohort in July 2021.

But why does this kind of work matter to UNICEF or the United Nations?

UN Roadmap for Digital Cooperation 🔗

In June 2020, the United Nations Secretary-General released the UN Roadmap for Digital Cooperation, a call for action and a vision with several key considerations:

• An Inclusive Digital Economy and Society
• Human and Institutional Capacity
• Human Rights and Human Agency
• Trust, Security and Stability
• Global Digital Cooperation

The report explores the impact technology has in each key area:

“Digital technology does not exist in a vacuum – it has enormous potential for positive change, but can also reinforce and magnify existing fault lines and worsen economic and other inequalities. In 2019, close to 87 per cent of individuals in developed countries used the Internet, compared with only 19 per cent in the least developed countries.”

UN Roadmap for Digital Cooperation, June 2020

Open Source Mentorship enables digital cooperation. 🔗

Therefore, the conception and development of Open Source Mentorship is inspired by the Roadmap, in four key aspects:

1. Digital Public Goods: To encourage knowledge transfer and collaboration on practical, everyday advice on building technology projects in line with the Digital Public Good Standard.
2. Digital Capacity-Building: Empowering others with the skills and information they need to be bringers of Open Source change and innovation in a disruptive and competitive Venture Capital ecosystem.
3. Digital Trust and Security: Providing a holistic view of Open Source intellectual property that is influenced by, but not bound by, quarterly earnings reports and share prices. Understanding the commitments of Open Source licenses and technology, and how trust is earned and lost in Open Source products and communities.
4. Global Digital Cooperation: Designing and structuring communities to be healthy and collaborative in nature, united in resolving common challenges and problems.

I joined the UNICEF Innovation team in June 2020, although this is not the first time I have worked with UNICEF Innovation. I have had some opportunity to write about Open Source, but my personal blog has been quiet! So, this felt like the right opportunity to talk about what I am up to these days.

The Open Source Archetypes report (below) provides nine archetypes common among Open Source projects and communities. These archetypes provide a common language and perspective to think about how to capture the most value of Open Source in various contexts.

Open Source Archetypes (May 2018)Download

This article covers the following topics:

1. How Open Source Archetypes align with my experience
2. How I use Open Source Archetypes at UNICEF
3. Unanswered questions

How Open Source Archetypes align with my experience 🔗

The Open Source Archetypes report is useful to me because it aligns with my own experiences and encounters with common Free and Open Source Software projects. An advantage of taking my alma mater’s Free and Open Source Software and Free Culture Minor is experiencing what real Open Source projects are like long before I entered the industry. The projects and organizations I contributed to and interacted with all ran their projects in one of the nine models identified in the report.

The Open Source Archetypes report speaks to my personal experience either using or contributing to projects like Fedora, Kubernetes, SpigotMC, MusicBrainz, and various independent projects. The value of Open Source for any project is in meeting the goals of the intended audience. By itself, “Open Source” is a broad term, even if it does have a legal definition. My experiences taught me the importance of how different Open Source projects meet the needs of different audiences, or even different combinations and balances of audiences. The Open Source Archetypes report creates language for something I previously only understood through direct experience.

When I first read the report earlier in 2020, I knew it was relevant to my work. But how could I begin to integrate it into the Open Source Mentorship programme I manage for the UNICEF Innovation Fund?

How I use Open Source Archetypes at UNICEF 🔗

The UNICEF Innovation Fund provides early stage funding and support to frontier technology solutions that benefit children and the world. Most teams in the Innovation Fund are from countries where UNICEF has an ongoing country programme.

A requirement for solutions we fund is that they must be Open Source. I have seen many different types of projects and business models since I started working as a part-time consultant for UNICEF in 2018. As exciting as this is, it was challenging to understand the best way of supporting each team and their Open Source projects. Each team and project had differences unrelated to their source code, but closely tied to their business models and impact they wanted to have through their work.

So, the Open Source Archetypes report have me language. It gave me examples and explanations of how Open Source can work to teams who had little to no prior experience of Working Open. I take the unique context and details I understand about each team I work with, and contextualize what they are doing compared to the different models in the report.

The feedback I received so far on the report with the 15+ teams I currently work with is mostly positive. Some teams exclaimed this report was what they wish could have read months before because it resolved many of their doubts. Others were more overwhelmed, and needed extra time to read and review.

For my role as a mentor, the Open Source Archetypes report gives me cues for how to best support and direct each team I work with. The task of building an Open Source community or participating in an existing one is not a small task. Whether it is documentation, project management, quality assurance and testing, or community engagement, I have yet to see any small team accomplish all of these things at once. So, identifying which archetype a team best identifies with gives me a cue to guide the teams on their path forward. It gives me context for how to make Open Source something that works for them instead of against them.

Unanswered questions 🔗

I have great appreciation and gratitude for the folks at Mozilla and Open Tech Strategies who compiled this report. But it was written over two years ago, and like all things in life, things can change. So, while I look comfortably from the position of hindsight, there are some critiques and missing components to the Open Source Archetypes reports.

My unanswered questions are below.

Does the Linux kernel (and subsequently, Linux distributions) represent another unwritten archetype? 🔗

The report explicitly avoided using the Linux kernel as the basis for any archetype:

In some ways the Linux kernel project could be considered “Wide Open”. However, both technically and culturally, Linux kernel development is sui generis and we have deliberately avoided using it as the basis for any archetype.

Open Source Archetypes, Page 17

Contextualizing a project like Linux is hard. There is a lot of history to a project that first launched over email in 1991. There are many “yes, but"s about decisions made 10 or even 25 years ago that would not replay the same way in 2020.

Yet this is important work. Linux represents not just the kernel, but also large, decentralized sub-units of other systems that integrate the kernel in order to make it useful (e.g. Ubuntu, Fedora, Debian, Arch Linux, you name it). These sub-communities include large entities and corporations, spanning multiple countries and organizations of various sizes.

The Linux kernel communities are worthy of a deeper look, possibly in order to define a new archetype.

How can Open Source Archetypes better fit the social/humanitarian sector? 🔗

The archetypes shared in the report largely focus on business sustainability. In other words, the report is biased towards Mozilla’s interest in funding the research in order to better understand how to support a commercially-successful Open Source project. To me, there seems like a gap in models that often work for Open Source projects perhaps like U-Report and Ushahidi.

This is an area of interest to me, and likely others in the UN and NGO space. The report could do more to address these kinds of projects.

How would you teach Open Source? 🔗

To conclude, the Open Source Archetypes report is an invaluable tool that provides me language and context for teaching others about Free and Open Source Software.

How would you teach Open Source? What models, research, or tools would you use to inform an Open Source mentorship or education programme? Share your thoughts below in the comments!

Managing an open source project is challenging work. The challenge grows as a project grows. Eventually, a project may need to meet different requirements and span across multiple repositories. These problems aren’t technical, but are important to solve to scale a technical project. Business process management methodologies such as agile and kanban bring a method to the madness. Developers and managers can make realistic decisions for estimating deadlines and team bandwidth with organized development focus.

At the UNICEF Office of Innovation, we use GitHub projects boards to organize development on the MagicBox project. MagicBox is a full-stack application to serve and visualize data for decision-making in humanitarian crises and emergencies. The project spans multiple GitHub repositories and works with multiple developers. With GitHub project boards, we organized our work across multiple repositories to better understand development focus and team bandwidth.

Here’s three tips from the UNICEF Office of Innovation on how to organize your open source GitHub projects with the built-in project boards on GitHub.

Bring development discussion to issues and pull requests 🔗

Transparency is a critical part of an open source community. When mapping out new features or milestones for a project, the community needs to see and understand a decision or why a specific direction was chosen. Filing new GitHub issues for features and milestones is an easy way for someone to follow the project direction. GitHub issues and pull requests are the cards (or building blocks) of project boards. To be successful with GitHub project boards, you need to use issues and pull requests.

The UNICEF MagicBox team uses GitHub issues to track on-going development milestones and other tasks to revisit in the future. The team files new GitHub issues for development goals, feature requests, or bugs. These goals or features may come from external stakeholders or from the community. We use the issues as a place for discussion on those tasks too. This makes it easy to cross-reference in the future and visualize upcoming work on one of our projects.

Once you begin using GitHub issues and pull requests as a way of discussing and using your project, organizing with project boards becomes easier.

Set up kanban-style project boards 🔗

GitHub issues and pull requests are the first step. After you begin using them, it may become harder to visualize what work is in progress and what work is yet to begin. GitHub’s project boards give you a platform to visualize and organize cards into different columns.

There are two types of project boards available:

• Repository: Boards for use in a single repository
• Organization: Boards for use in a GitHub organization across multiple repositories (but private to organization members)

The choice you make depends on the structure and size of your projects. For the UNICEF MagicBox team, we use boards for development and documentation at the organization level, and then repository-specific boards for focused work (like our community management board).

Creating your first board 🔗

Project boards are found on your GitHub organization page or on a specific repository. You will see the Projects tab in the same row as Issues and Pull requests. From the page, you’ll see a green button to create a new project.

There, you can set a name and description for the project. You can also choose from templates to set up basic columns and sorting for your board. As of writing, the only options are for kanban-style boards.

After creating the project board, you can make adjustments to the project board as needed. You can create new columns, set up automation, and add pre-existing GitHub issues and pull requests to the project board.

Now, you may notice new options for the metadata in each GitHub issue and pull request. Inside of an issue or PR, you can add it to a project board. If you use automation, it will automatically enter a column you configured.

Build them into your workflow 🔗

After you set up a project board and populate them with issues and pull requests, you need to integrate them into your workflow. Project boards are effective only when actively used. With the UNICEF MagicBox team, we use the project boards as a way to track our progress as a team, update external stakeholders on development, and estimate team bandwidth for reaching our milestones.

If you are an open source project and community, consider using the project boards for development-focused meetings. Additionally, it helps to remind yourself and other core contributors to spend five minutes each day updating progress as needed. If you’re at a company using GitHub to do open source work, consider using project boards as a way to update other team members and encourage participation inside of GitHub issues and pull requests.

Once you begin using the project board, yours may look like this!

Open alternatives 🔗

GitHub project boards require your project to be on GitHub to take advantage of this functionality. However, there are other open source alternatives available. You can use tools to replicate the same workflow explained above. GitLab Issue Boards and Taiga are good alternatives that offer similar functionality.

Go forth and organize! 🔗

Now, you can bring a method to the madness for organizing your open source project. These three tips for using GitHub project boards encourage transparency in your open source project and make it easier to track progress and milestones in the open.

Do you use GitHub project boards for your open source project? Have any tips for success that aren’t mentioned in the article? Leave a comment below to share how you make sense of your open source projects.

My internship at UNICEF is unique: I support open source community engagement and research as my primary task for the MagicBox project. For years, I’ve done this in open source communities in my free time (namely SpigotMC and Fedora), but never in a professional role. As I navigate my way through this exciting opportunity, I plan to document some of the experience as I go through blogging. My intent is that my observations and notes will be useful to someone else in the humanitarian open source space (or maybe to a future me).

But first, what does “open source community engagement and research” really mean?

What am I actually doing? 🔗

“Community engagement” is a buzzword phrase for the open source movement in the 2010s. Often, we hear about “community engagement” or the work of those “leading communities”, but it’s an abstract concept. In other words, building communities of humans and people is hard. There is no one-size-fits-all solution for any community. Every community has its own unique needs and goals. This means different methods of management and communication work better for some communities than others. My job is to help light the way for what this pathway means for the MagicBox team.

Since I started in January, a lot of my time so far was spent learning. What is MagicBox? What are we trying to deliver to our stakeholders? To the open source community? How does our data pipeline piece together? All these questions and more, I’ve tried to answer to different levels of success.

What’s next? 🔗

Now, I’m beginning to take a more hands-on role with the work, with a clear vision of what I want to do. The next few posts to come will dive deeper into what I’m up to.

If you have questions or are interested in keeping up with what’s going on, feel free to leave a comment here or subscribe to my blog to automatically receive future updates.

Opinions and views in my blog are my own and do not reflect the views of my employer.