Co-written with Larissa Shapiro
At Mozilla we’re always thinking about how to improve our products, how to continue a legacy of innovation and quality while shipping often. That said, we can’t talk about Mozilla’s history, or future without acknowledging the critical role of our global volunteer community in our success, and of it’s importance to our future. Software is made by people, and community is made both by and of people.
This year’s learnings around the challenges of contributor growth and retention, come with a recognition that we have two very different tracks of ‘shipping Mozilla’: How we ship product, and how we grow community are distinct, and there is no doubt that the betterment of both lies in the scaling a human network.
Designing for participation is really about designing for people , it’s about building an ecosystem of empowerment. We’re learning that our most successful pathways reflect diversity of community background, skill-set, available time and motivation.
The aha-moment of open source contribution is when someone feels successful in ‘doing a thing’. Be it connecting to a chat room with an IRC tool, or building a local copy of Webmaker.org, it’s that first success that drives the next. These successes need to happen long before a first pull request, even before taking a ‘mentored bug’. We need to get better at helping people reach their first ‘Mozilla moment’, through deliberate and predictable teaching and learning ‘by doing’ opportunities. We’ve already started doing this in person with Open Hatch events and curriculum, but scaling this means building online opportunities.
We need to provide ongoing, predictable, transparent and inclusive educational opportunities for volunteer community and product teams working with volunteers
Mentoring is core to the success of our community. Staff AND volunteers, go farther when someone is there to encourage their success, to answer their questions and to help strategize for the future. The Mozilla Reps program is a great example of how we can scale participation through thoughtful and ongoing mentorship .
The Mozilla Guides project is proving that by offering a searchable, scale-able, organized resource for brand new Mozillians who need encouragement, coaching, and mentors, to take their first steps and find the projects they want to make an impact on .
Mentoring is done well already in some places at Mozilla. The Reps program has done an incredible job of building a network of mentors, and mentoring is at the core of its success. We need to make mentors and mentoring easily available and usefully structured for all Mozillians at all levels of skill and participation.
Designing Participation Tracks
Designing participation for a college graduate is much different than designing for an experienced C# engineer interested in transitioning strong technical skills to open source ecosystem. Making pathways as simple as possible for the episodic volunteers , is as important as providing long-term opportunities. What other types of participation should we be considering? Is Mozilla contribution accessible for those with disabilities? How do we plug one into the other?
What does it look like to show up as an organized group effort? How do schools and companies interested in lending skills to a project on an single, or ongoing basis get involved?
We suggest that we framing Mozilla contribution as an opportunity for individuals and organized groups. Corporations can lend time and technical talent for skill & team building , while universities across the world can their better help students for the job market through the opportunity that is – contributing to Mozilla. Mozilla in kind, can define on-ramps for organizations (corporations, universities, other open source projects, and more) to be able to easily find opportunities and make an impact – and develop mutual benefit.
A Community Building Community
We’ve been saying that community building is everyone’s job at Mozilla, but what we haven’t explicitly said – is that we’re building a community around ‘community building in Mozilla’. This means, we need to get better at sharing resources across the project. We need improved communication mechanisms to help avoid duplication of efforts. We need to be more deliberate about reaching out with what we’ve learned.
Designing for humans ensures that those who want to go fast (move fast and break things, if you will) – can, and those who want to be more deliberate in their process will get there too. Our collective speed of innovation, development, and impact will increase when we are deliberate about mentorship, teaching and growing a connected community of community designers – as core tenets of participation design, human infrastructure, and volunteer empowerment at Mozilla.
Larissa and I would love your feedback on these thoughts around radical participation at Mozilla.