In May 2018, Mozilla and Open Tech Strategies released a 40-page report titled, “Open Source Archetypes“. This blog post is a recap of how this report influences the Open Source Mentorship programme I lead at the UNICEF Innovation Fund.
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.
This article covers the following topics:
- How Open Source Archetypes align with my experience
- How I use Open Source Archetypes at UNICEF
- 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!
One comment