How to bring open source to a closed community

This is (roughly) a transcript of my talk at Strange Loop this year! At least, it’s what I meant to say. Watch the video for all the fun Canada facts and nervous rambling.

Slides made using reveal.js. Screenshots captured using Decktape

First off, I want to thank the organizers for this opportunity. Strange Loop is such an amazing conference – I can’t believe I fist attended with an opportunity grant two years ago. The friendships and community I’ve built here have been amazing.

Let’s get started!

Hi, I’m Abby! This is me. I work for the Mozilla Foundation as Lead Developer of Open Source Engagement. This means I with with the open source projects and community around the different programs at the Mozilla Foundation including Open Science, Internet of Things, Women and Web Literacy, Learning and Advocacy.

Also, I’m from Toronto. This is important because Toronto is great.

A bit of history: I came to Mozilla because of the Mozilla Science Lab. Before Mozilla, I was working in research labs where we were dealing with so much data and analysis. It was easy to see how the openness and collaboration available on the web could make science better.

At Mozilla, our mission is to ensure the Internet is a global public resource, open and accessible to all.

The Science Lab is applying Mozilla’s mission to a specific community of practice. Most of the work I’m covering today was done within the Mozilla Science Lab.

So, today we’re talking about bringing open source to a closed community. Slight disclaimer: this is my story! This is not a how-to that will work for everyone.

The past eight years of my career, I’ve been working on open source projects for researchers and thinking of ways to bring more open source to academia. I want to share some of the lessons I’ve learned and hear from you as we start to expand to other Mozilla Foundation programs.

My story starts with open source. I actually wrote open source code for years before I fully understood this movement.

I find it’s helpful to look at origins of terms and words to help give some cultural context around what this meant at the time.

‘Open source’ is interesting because the free software movement predates this term by over a decade.

In 1997, Eric Raymond published an essay on the state of free software at the time, “The Cathedral and the Bazaar”. He saw two types of free software:

• The Cathedral is a public space where anyone is welcome to attend a service, but the experience is put on by a small group of people in charge. They decide what happens and when. This is like a development team working on software among their trusted group, then releasing a new version to the public.
• The Bazaar is an open space where people come along, setup tables and start bartering and selling whatever goods they have. Anyone can come and shape the experience in this space. Raymond saw this happening in Linux at the time, a diverse group full of differing agendas that was able to work together to build a stable system.

Also, I can’t be sure, but it looks like there might be a fire in this Bazaar. Metaphor for open source? :)

This essay inspired the Netscape Corporation to release the Netscape browser suite as free software the following year. This became the basis of the Mozilla Project and inspired the term open source.

I don’t know if you all remember the early 2000s, but there were no browser wars then – Internet Explorer was everywhere. The fact that a group of passionate open source contributors were able to come together and build Firefox, the browser that toppled the giant, was really amazing.

At the heart of open source is the idea that a diverse group working on a problem is better.

But how do we get there? How do we work in a way that brings this diverse group together in the first place?

At Mozilla, we call this “Working Open”, being public and participatory. This requires structuring efforts so that “outsiders” can meaningfully participate and become “insiders” as appropriate.

For me, this way of thinking helped me understand what open source should look like in our day-to-day work.

For the official definition of open source, the Open Source Initiative has ten points outlining what exactly open source software is. Having this comprehensive definition along with the OSI has helped the open source movement stay strong today.

The next part of my story is Science! I worked in research labs writing scientific software for most of my career.

Sometimes, trying to participate in research can feel like this. As soon as I left academia I lost access to most published research in academic journals. Even within academia, institutions can feel like ivory towers where only the invited few can participate.

These drawings are by John McKiernan for “Why Open Research?”

On the other side of the wall, there can be a lot of fear around getting scooped or someone stealing your data. This stems from a lack of knowledge around open licensing options.

Contrasted with my experience in open source, this helped me see that on both sides of the wall, there’s a need for culture change if academia is going to work openly.

One of the first projects I worked on when I joined Mozilla Science was Collaborate, a collection of open source software for scientists. This was a great way to highlight some of the work going on in this community, but after watching these projects for awhile, I learned that researchers weren’t very good at open source.

In general, the projects weren’t as welcoming as they could be. Sometimes, requests from potential contributors for more information would be ignored for weeks. This list of projects still exists today and helps the open science space tremendously, but we thought we could make this better.

This brings us to the final part of my story (and most of this talk): Fueling the movement.

I couldn’t find a definition of ‘movement’ that I liked, so I defined it here as “mobilizing a community around a shared purpose”.

One of my favourite visual representations of a movement is a this clip of a dancing guy fro Derek Siver’s TED talk on leadership and movements.

One guy dancing enthusiastically slowly mobilizes those around him. Once you hit critical mass, you have a movement! You watch him change the culture here in a few minutes.

This is a figure from Marshall Ganz’s essay “Public narrative, collective action, and power”. A key part of a movement is mobilizing people to action. This diagram shows how we need both the strategy and narrative (head + heart) to take action.

Working with researchers, many of them want to be working open and collaborating more – you can see how many open source for science projects wanted to be listed in ‘Collaborate’. However, there’s a lack of knowledge or strategy around how to do this effectively. This is when we realized we need to make resources outlining the steps involved in running an open source project.

So we started to think about how we can best fuel the open source movement within academia. I think we can summarize it in these three steps:

1. Resources: Creating the resources needed to mobilize others
2. Leaders: Selecting leaders in our community. Use the resources we created to mobilize them.
3. Mentorship: Helping our leaders mobilize others through mentorship.

First up, resources!

To create resources, we did an exercise focusing on the “Working Open” aspect of open source. How do outsiders become insiders on our projects? We’re going to do this exercise now as the audience participation section of the talk!

Think of a place you felt welcomed the first time you visited. This can be in person or online. I’ll give you a minute to think of a place in your head.

Okay, what places did you think of?

Some of the answers:

• Strange Loop
• Canada
• College
• Niagara Falls

Now, what made it welcoming?

Some of the answers:

• Strange Loop
  • Everyone is friendly and wants to know where you’re from and what you do. >> friendly, human welcome
  • Food and snacks. >> takes care of our needs
  • Smaller Preconf events >> makes it easy to find connections
  • Opportunity grants >> makes it easy to get involved
• College
  • Orientation week >> orient people to their new environment, show them where they can get involved and make friends

How can we apply these to software projects?

Some of the answers:

• friendly, human welcome
  • say hi and welcome new people in chat, mailing list, etc
• take care of our needs
  • clear installation instructions, contributing guidelines
• make it easy to get involved
  • good README, starter issues for new people

We went through this exercise and came up with a bunch of ways to make open source projects more welcoming. We came up with these seven points and put together handouts for each point.

I think we came up with a lots of these in the exercise we just did!

1. Public repository: make sure your code, history, and discussion is public and available on the web.
2. Open license: this goes back to the official Open Source definition. Make sure your code is licensed in a way that others can legally contribute and remix your work.
3. README: Especially with GitHub, this is often the people’s first introduction to a project. Be welcoming!
4. Roadmap: At the very least, break down what you plan to do in issues. This way people know how can get involved and what work you’re looking for.
5. Code of Conduct: Collaboration is hard and collaboration with a diverse group can be messy. A code of conduct is a good step towards making people feel safe and outlining the behaviour expected in the group.
6. CONTRIBUTING.md: This is another file that has become more important because of the GitHub experience. Your contributing guidelines can outline how a new contributor can participate in your community.
7. Mentorship: This is a larger topic that covers both the attitude and strategy needed to make something welcoming and fuel a movement.

I’ll be sharing more about each of these steps later in the talk.

Next part of ‘Fueling the Movement’ is investing and mobilizing leaders. We can use the resources we just created to mobilize some of our more involved community members.

We did this at our first Working Open Workshop in February in Berlin. We brought together some of our existing project leads and more active community members. This was a group of people passionate about what we’re doing and eager to learn skills that would help their work be more open.

We put on a two day workshop going over most of the lessons from the Open Source Checklist. We built in lots of time for group work where participants could start applying the lessons they’ve learned to their open source projects.

This was a great start, but we wanted to keep up momentum after the workshop. We’ve all done weekend courses and workshops where we leave with the best intentions, but then life gets in the way and we forget. To combat this, we offered 1:1 mentorship after the workshop.

We planned this workshop to happen three months before our Global Sprint, a two day hackathon on open source and open data projects. The 1:1 mentorship would occur over the three months preparing the projects for the Sprint.

Now we’re going to draw out the movement in action!

We start here with Abby (that’s me!) and Aurelia, Community Lead for the Mozilla Science Lab. Aurelia is also a strong open source developer in her own right. The two of us decided to offer mentorship to all Working Open Workshop (WOW) participants.

27 people attended WOW.

25 of them signed up for 1:1 mentorship. We called this group the Open Leadership Cohort (OLC).

We met with each project every two weeks for a quick 30min check-in.

We started our mentorship meetings by setting goals. WOW was fresh in their minds! We helped set goals around:

• Their community: what do they want their contributor base / user base to look like?
• Their product: Will they ship a new feature or release an MVP at the sprint?

Then, we set a loose plan around how to accomplish this over three months. This set us up to be able to do lightweight check-ins every two weeks to see how things are going and where we need to troubleshoot.

As soon as we started, 8 new people were added to the program since many projects had co-leads who wanted to join in.

The yellow nodes are all the people that made significant contributions to mentored projects at the Global Sprint at the end of this round of mentorship. The contributions were significant enough that the project lead decided to give them a shout-out on the Mozilla Science Project Call.

It was great to see the project leads start to engage and mentor new contributors on their projects.

For a bit more background on the Global Sprint, here’s a picture from our 2015 Global Sprint. This year, we had 40 sites around the world all hacking from 9-5 in their time zones.

We saw a massive increase in participation through GitHub activity this year. I think this is directly linked to the resources we made on working openly which we offered to all participating project.

Now that we mobilized the leaders, we wanted to work with them as they mobilized others. We do this through more mentorship.

We selected a few of the people we mentored to become mentors in round 2. We intentionally kept the group of mentors small as we tested this out.

We wanted to test our this type of mentorship around open source in other programs. We asked each program to nominate a few community members for mentorship. We have participants from Open Science, Internet of Things, Internet Policy & Advocacy and more. We paired each mentor with 1-2 participants.

This round of the program started mid-August and is running till the Mozilla Festival (MozFest), Oct 28-30 in London UK. MozFest is the world’s leading event for and by the open Internet movement. All the participants and mentors in the program will be running sessions at MozFest – we’re using this program to help prepare their projects for the festival.

Now we’re going to look at a few stories and lessons we’ve learned going through this experience.

I’m going to go through each lesson from the Open Source Checklist and tell you a story about how that lesson affected someone in the mentorship program.

First up is having a Public Repository and looking at Achintya’s story.

Achintya is a science communicator at CERN and a PhD student in scicomm at UWE Bristol. We’re going to talk about how GitHub usage helped him centralize and organize efforts around his project.

Achintya has an interesting project, Open Cosmics: Cosmis-ray physics for everyone!

For a bit of science background: cosmic rays are high-energy particles that bombard the earth’s atmosphere. This produces showers of particles that we can detect on the earth’s surface. You can even detect these particles with your phone by installing CRAYFIS. You can also get a pocket sized detector from Cosmic Pi.

The problem that Achintya is tackling is that there are all sorts of ways to measure cosmic-rays, but each project stores the data in different formats. Achintya’s project, Open Cosmics, attempts to bring together all these efforts and help with interoperability and data standards.

You may have noticed in the “movement graph” that Achintya brought on three additional projects leads to this project. He was in a unique position where he acted a facilitator between all the projects collecting cosmic-ray data.

At the end of our first round of mentorship, when we asked Achintya was most helpful he said it was learning how to use GitHub for project management. GitHub gave his community a central place to community and the tools he needed to organize and discuss.

Now, Achintya is mentoring two other projects!

So, make sure your code is available! At the Mozilla Foundation we rely a lot of GitHub and have produced some trainings on GitHub for collaboration. But there are many other services you can use for your public repository.

Next, we’re going to look at having an open license and how that helped Rob.

This is Rob! He was fairly new to open source when he joined us.

This is a blurry Rob at our Working Open Workshop. We’re all doing the ‘Open Web Stretch’ here. I believe they’re all “leaning left to avoid the NSA”.

Rob’s project was creating a tool built around PubMed Central, a repository for life science and biomedical research. He created PMC-ref, a tool where you input a paper, then it checks which references in the paper are free to read.

It’s a pretty simple tool that can have a huge impact for a life sciences researcher. Especially if they don’t have access to all the big journals.

I mentioned Rob with this lesson, because going through his GitHub repo, he added an open license days after the Working Open Workshop. Yay MIT license!

If you see the yellow dot linked to him, Rob received his first open source contribution ever during the Global Sprint! The contributor, Deborah, actually wrote a blog post about her experience at the Global Sprint and contributing to this project. The fact that he had an open license made this possible and legal.

Rob is now mentoring Minn. Minn is running an interesting session at MozFest around facial recognition to create art and generate metadata.

choosealicense.com is a great resource for picking an open license for your software. For something easy, Mozilla Science recommends MIT or BSD.

Next we have Kirstie who really embraced writing a great README and having welcoming project communication.

This is Kirstie! She’s a postdoctoral researcher in the Brain Mapping Unit at the University of Cambridge.

We recently announced that Kirstie is one of the new Mozilla Fellows for Science this year! Mozilla Science has a fellowship program for researchers who want to influence the future of open science and data sharing within their communities. Fellows spend 10 months as community catalysts at their institutions and building lasting change in the global open science community.

During the first mentorship round, Kirstie worked on her project STEMM Role Models - inspire future generations by providing the most exciting and diverse speakers for your conference. She built a simple database of great speakers for conference organizers to use when planning an event.

Kirstie took to heart the idea that to make our projects as welcoming as possible, we need to have clear and friendly communication. Even here, on her draft landing page, she makes a real effort to welcome everyone at the top.

Looking back at the mentorship graph, Kirstie did such a great job explaining her project she was able to engage a couple contributors who did significant work building an MVP (minimum viable product). Kirstie has a background in neuroscience (not web development!), so watching her bring technologists and designers together to build something she is passionate about was really inspiring!

Now, as Kirstie begins her fellowship, she’s mentoring two projects including a group from the Detroit Community Technology Project. They’re addressing gentrification through storytelling technology and plan to have a booth at MozFest.

We have a few resources designed to help you write a good README and communicate your project.

First is the Open Project Communication handout.

In the handout, we include the Open Canvas, a tool I find very helpful when starting an open source project. Open Canvas is remixed from Lean Canvas, a popular tool from the startup world that helps you make a one page business plan.

I worked with Jordan Mayes from Top Hat, to remix this for open source projects. We removed some boxes that didn’t apply and added more thinking around community and contributors. You can read more about the process of creating Open Canvas in his blog post.

The Canvas forces you to think through the problems you’re addressing and your proposed solution. We divide the canvas in two main sections, Product and Community, to get people to think about their community, what they’re building, and how others will get involved.

Next in our checklist is writing a roadmap, featuring Bastian.

Here’s Bastian!

When I first email introduced Bastian to his new mentee, his mentee replied with “Thanks for introducing the Mark Zuckerberg of open-source genetics! What a great mentor to have!” and linked to this article. I had no idea this article existed! But I am not surprised considering Bastian’s project.

Bastian is a PhD student in bioinformatics, and was working on openSNP (pronounced open snip). SNP stands for Single Nucleotide Polymorphism, a type of mutation that can occur in your DNA. openSNP let’s you upload your 23andMe (or any other genotyping service) results online. You can learn more about your results, find others with similar genetic variations, and help scientists discover more genetic associations.

When Bastian first uploaded his genetic data on GitHub (before he made openSNP), he received an email from someone who found the data online and analyzed his genetic report. The analysis said he might have an increased risk of prostate cancer. Since this type of mutation is inherited, he told his dad to go to the doctor. They found a tumour growing in his dad’s prostate, but they were able to catch it in early. His dad is alive and well today.

OpenSNP benefited greatly from going through the Roadmapping exercise! I worked with Bastian and Philipp (co-lead on the project) to plan out a few features and fixes that needed to be done. This helped then identify the need for new volunteers and shaped up a few projects they could submit to Google Summer of Code (GSoC).

By making a roadmap, they were able to accomplish a tremendous amount in a few short months. You can read about their GSoC experience on the openSNP blog.

We have a couple exercise you can go through to write a roadmap for your project. Writing down what you plan on working on helps new contributors know where they can get involved.

A roadmap can be a simple as a collection of issues in your issue tracker to a comprehensive wiki outlining the future of your project.

This handout walks you through picking a few milestones and breaking down the tasks needed to get there.

Next up is code of conducts with Richard.

You might notice from the graph that Richard wasn’t part of the first round of mentorship. Richard was actually a 2015 Mozilla Fellow for Science. He did some amazing open source work during his fellowship year, I thought he would be a great mentor.

Notice the moss beard in his avatar.

Sadly, he doesn’t walk around with a moss beard in real life. This is a picture of Richard and his partner Steph at MozFest 2015. MozFest is so awesome that we had capes, buttons, and fox masks. You should come.

I listed Richard under code of conducts since he has an incredibly thoughtful approach when writing documentation for communities.

You can see the code of conduct Richard wrote in the last link, Slidewinder Code of Conduct.

In this particular code of conduct, he has a section called “Open [Source/Culture/Tech] Citizenship” that outlines the goals of having an open culture and encourages others to reward welcoming behaviour. I think this is incredibly important as we’re trying to build welcoming communities.

If you get stuck, Mozilla Science has a CC0 code of conduct you’re free to take, remix, and use however you like!

Next is Contributor guidelines and Tim.

Tim was a physicist at CERN when we started the program. He recently moved to Zurich and is now a tech consultant.

Tim was working on Everware, a project trying to address reproducibility in scientific software. Everware uses Docker to launch an instance of a jupyter notebook directly from a GitHub repository.

Tim cares a lot about reseach reproducibility. I first met him at a hackathon a CERN where he first launched Everware and ruffled some feathers with his insistence that we need to focus on better research reproducibility.

Now, Tim’s mentoring two other groups including one looking at research reproducibility, ReFigure.

Tim and the other Everware developers wrote some great contributing guidelines that helped quite a few people get involved before and during the Global Sprint.

For resources, we have a guide that walks you through creating your contributing guidelines.

The file should be named CONTRIBUTING.md and placed in your root directory.

We break down the different parts of your contributing guidelines in the exercise.

Open with some cheer! You should celebrate someone looking to contribute to your project. Then, introduce the document and explain what these guidelines are for.

The bulk of the document should be some how to guides on contributing, along with expected norms the group follows, like a style guide.

The CONTRIBUTING.md naming convention has become popular since GitHub integrates this in their interface. If there’s a CONTRIBUTING.md file in the root directory of a project, GitHub will display this notice as the top of the page whenever someone opens a new issue or pull request.

The last step is our catch-all for attitude and process, Mentorship. Here, I’m highlighting Madeleine since she’s done a great job including and delegating to others.

Right off the bat, you can see how connected her node is in the graph since she’s been able to bring so many people into her work.

Madeleine is a PhD student at the University of Toronto. Madeleine not only runs an open source project with us, but she also runs a weekly open science meetup at her school, the UofT scientific coders.

Madeleine (on the left) actually spoke about running events at our Working Open Workshop because of her experience with the UofT scientific coders.

Her project is phageParser which uses open data to better understand CRISPR systems. CRISPR is all the rage nowadays because it’s opened the door for faster and cheaper targeted gene editing.

CRISPR stands for Clustered Regularly Interspaced Short Palindromic Repeats. In the diagram the black diamonds are repeating DNA. In between the repeats are spacers. Spacers are pieces of DNA from a virus that attacked the system. The CRISPR system saves the virus DNA so that if it comes across the virus again, it can recognize it and cut it out, hence targeted gene editing.

Madeleine’s group realized that there are many openly published genomes with CRISPR systems. Her project is trying to collect and analyze these systems to try to find patterns and learn more about CRISPR.

Madeleine was able to engage so many people during the Global Sprint that she ran out of tasks for new contributors. I’ve noticed that Madeleine is naturally good at finding tasks and asking others for help, both in her project and with the UofT scientific coders.

At her first UofT scientific coders meeting, she delegated registering a club, managing the GitHub repository, and baking cookies for next week. Most of those people are now the green dots co-leading the group.

For those of us who need some instructions on how to delegate and involve others, we have a few exercises to help you start thinking about mentorship.

Good first bugs can be a great way to give a new contributor a small win when they first start working on your project. Identify a few smaller issues that would be appropriate for someone completely new to the project. Ideally the hardest part of completeing this issue would be setting up their development environment.

This helps you reward new contributors sooner.

Another exercise that helps you think about a contributors progression through a project is the Personas & Pathways exercise. This gets you to create a persona of an ideal contributor. Then, you can outline their pathway from when they first hear about the project, to their first contribution, to becoming a maintainer, to maybe even running the project when you’re ready to hand it off.

To summarize, these resources are helping us mobilize leaders in the open source movement.

Combined with trainings and mentorship, we’re working to fuel the open source movement in science, advocacy, learning, IoT and more.

I mentioned MozFest a few times, you should all come! It’s a lot of fun and you can meet a lot of people and projects I highlighted in this talk.

MozFest really is a place where “you can make things that matter”

Huge thanks to the many people that took part of the mentorship program as participants, mentors, and content creators. There’s a lot of people that made this happen.

You’ve all been awesome!

Thank you!
Slides: acabunoc.github.io/open-source-strangeloop-2016

Note:
I talk about projects from a lot of different fields in this presentation. I’m not an expert in all these fields, so I may have explained something wrong here. Happy to make corrections! Please be kind!