Co-Creating Open Source Communities
During our latest project with Wellcome Trust we (Simon and myself) were tasked with designing the blueprint for a new “STEM-ware” community (open source software used for science, technology, engineering and mathematics). Our goal was to design a community of practise around health data, I will more about the complete project in another blog. In this article I will focus on the simple and powerful method we used for understanding complex value flows in existing open source communities and designing new ones.
Research
The work of Elke den Ouden and Rens Brankaert on designing value flow models was my starting point. This excellent framework is a great place for service designers or product designers to communicate and think about meaningful impact. Value flow models involve visualising specific interactions in networks to understand roles and relationships, drawing one offers a view of how both financial and other assets are converted into value. The main elements of the model are the actors who play the different roles in the ecosystem and the value flows in the ecosystem.
We began by researching existing communities we knew about and were part of. The Open Street Map community provided a great starting point. This is an open data project (competing with Google Maps) supported by a vast ecosystem of open source software. Mapbox, a private company has built software for beginners to make edits to the shared mapping data. Microsoft provides satellite imagery to be traced for roads and buildings. These assets are then used by NGOs and local communities to map their surroundings and where they are working. The Missing Maps community brings together beginner and expert mappers over Pizza to draw over satellite imagery. Microsoft and Mapbox then use this new data in their projects. In August, Uber announced they were adding data to improve the accuracy of their routing and to not be dependent on other commercial providers.
We then mapped HDX, a humanitarian data sharing which Simon has been part of since 2015; Phenoimageshare, a short-lived academic STEMware, Data Collaboratives, a new partnership between UNICEF, MIT and Omidyar Group; Airflow, a community for workflow management created by AirBNB. As a contrast to open source software communities, we mapped Datavant, a private company which provides anonymisation software for health data and the UK BioBank. I did not know about the BioBank before the project, it is a large long-term study in the UK which is collecting genetic, phenotypic and EHR data from 500,000 participants to investigate the contributions of genetic predisposition and environmental exposure to the development of disease.
Below is the life journey of a few of these projects:
- Airbnb created airflow and donated it to the open source community and it has been adopted across many industries including by Allen Cell institute. This software was released as a more fully developed version than most.
- Protege and Genestack represents successful transition of academic software to a sustainable future through commercialisation or building and active engaged community. They were initially released as minimum viable products (MVP).
- PhenoImageShare is example of what happens to many STEM open source software that is written for specific use case and development stops when funding is removed
Mapping these communities helped us understand how public - private partnerships worked, and how much of the STEM open source software is created alongside applied projects and funded for short amounts of time.
Conducting the Workshop
We held a workshop to share and build upon our findings with Team Wellcome. In the first part of the workshop, we shared what we had learnt and then broke up into groups of three. Each group drew up two communities, which were as different from each other as they could be and shared back. The first group drew up Algorithmic Justice League and Numpy and the second team drew up Jupyter Notebook and Brigham Women’s Hospital innovation setup. We then discussed the similarities and differences between the communities and shared the principles of what makes up a good community.
In the second part of the workshop, we walked over to our theme wall, discussed the 10 areas which had emerged from our research (more about this in another post) and did a dotcracy exercise to shortlist them down to three. Everybody was really animated at this point of time!
Finally, we broke up into two groups and starting drawing ideas for new communities based on the three topics which had been selected. This time we used stickers which had little drawings to represent our user groups.
One of the group members drew a community which they had in their mind for a long time. Using the new schema and stickers helped them express their idea to the whole group. The other group started drawing the value flow for one topic and rolled another one in, concluding that the topics while seemingly distinct actually represented two sides of the same coin. Overall, everybody enjoyed themselves and we scheduled a second session to continue the activity. Also, just in case somebody got stuck, we also had 10 prompts ready!
Learnings
This was a three hour workshop and we think this activity is more suited for a half day workshop.
Finally, I would like to share the 10 principles for STEM open source communities that we identified. Hopefully they are helpful for you if you ever design one of these. They seem like useful things to bring into the world! :
1. Solve specific problems, do not create only tools
2. Have a start up feel, start small
3. Be close to problem epicenter or have a connection
4. Make it extensionable, so companies can adapt it for their internal use
5. Have an open process of commits and updates
6. Supporting the wider community via events and training
7. Find the right people in the right org, Bring big partners on for early wins
8. While private companies can be an important source of support, be careful that the engagement benefits the project
9. Make it work for the first members of the data-club
10. Do not create silos and duplicate, instead support what’s working
—
Thank you to Katie Taylor for the encouragement to write this post.
