Josh Matthews is a platform developer at Mozilla. He's a programmer who writes Rust code and is active in the development of Firefox. His development experience has led him to enjoy mentoring new contributors in open source projects.
Josh is going to be speaking at OSCON 2016 on the topic of Optimizing your project for contribution and graciously agreed to an interview.
What's your background? What got you excited about open source?
My earliest experiences with programming occurred in environments where it was possible to look under the hood and see how everything was put together. Similarly, one of the first mailing lists I joined was full of people who liked to share code and help each other learn collaboratively. When I realized that I could not only learn from open source software, but also modify it and share my changes with others, I was hooked. For me, the prospect of collaborating with others has always been far more attractive than the simple act of creation.
What was it about the Mozilla community that invited your participation?
In my case, it was a blog post from a Mozilla developer describing a low-priority, high-impact, exceedingly daunting project that could benefit from additional bodies. This was the inaugural work on splitting Firefox into multiple processes back in 2009! The combination of something specific and concrete that I could contribute to—combined with the promise of help getting started—made me want to give it a try.
How do you ensure that your open source project is not overlooked? How important is social media in getting the word out?
My short answer to the first question is "marketing." A social media presence can be a useful tool for publicizing information that is time-sensitive or audience-specific, or enabling low-touch communication and technical support centered around the project. To avoid being overlooked, projects need to find where their target audience is, figure out why they should care about the project, and broadcast that message (tastefully). Additionally, projects need to usefully communicate how they are changing over time, such that both existing users and potential new users can see at a glance if the current state and future goals are aligned with their needs.
What are some of the barriers—real or perceived—that keep people from contributing to open source projects?
I'm not convinced that there's a difference between "real" or "perceived" barriers, since they both end up stopping potential contributors from doing so. A perceived barrier is often a result of mismatched or unclear expectations from both parties—if a project doesn't have great documentation, its issue tracker is uncurated and/or full of jargon, and maintainers only respond when addressed directly, these can all be taken as signs by a struggling newcomer that they don't belong there, even if that was not an intended outcome.
That being said, some of the biggest barriers stem from opportunities for contributors to make mistakes. Every time there is a part of the process that is ambiguous and there is no clear way to receive help, it becomes that much easier for a contributor to give up and walk away when they encounter a problem. I often hear that people feel intimidated and vulnerable while attempting their first contribution to a project. We should be crafting our documentation and tools with them in mind, since everyone will benefit from the results.
What advice would you give to someone who is trying to develop community and participation in an open source project?
Identify what kinds of people would want to participate in your project, and why. Make it as easy as possible for them to do so:
- Identify appropriate ways of participating (e.g., regularly curated lists of available work).
- Invest in automation that eliminates paint points (e.g., style checkers and development environment setup).
- Use communication media that allow the most flexibility. Limiting a project to only IRC can exclude significant populations due to timezones and social constraints.
- Recognize participation loudly, enthusiastically, and often.
Only at this point does it really make sense to begin actively encouraging participation from wider audiences. These are the foundations for a successful first contribution, which is a prerequisite to repeat contributors.
How does a person get started contributing to Mozilla?
One easy way to find an area of interest is to visit WhatCanIDoForMozilla.org, which highlights teams and subprojects based on the skills they require. From there, you will be linked to specific instructions for contributing to each project that interests you. We provide curated lists of tasks to work on in our bug tracker, where each one is associated with a mentor. There are also specially marked tasks intended for newcomers that are straightforward and self-contained. Finally, we have an IRC channel called #introduction that is full of people from all over the world who enjoy answering questions, whether from first-time open source contributors or seasoned veterans.
How is participation in the Rust community? How do you encourage participation? What are Mozilla's most pressing needs at this time?
The excitement and energy in the Rust community has blown me away! There are new libraries being released every day, and there's a vibrant and positive culture that takes pride in answering questions quickly in a respectful, positive manner. The response really warms my heart every time I end up asking a question in public!
As for encouraging participation, the team has put a significant amount of thought and effort into creating tools that make it easy to write Rust code and share it with other people. Additionally, the language development process has been completely open since before the 0.1 release, but the public RFC process for evolving it was a great demonstration of the principles of encouraging contribution—it took an ad-hoc process that many people cared about, defined the rules for participating in it and the format by which to do so, and has been consistently applied ever since. As a result, there have been over 1,500 RFCs filed in just under 2 years!
When it comes to Mozilla's most pressing needs, they're surprisingly straightforward. We need more web developers testing sites against pre-release versions of Firefox and reporting bugs they encounter, as that helps us catch significant regressions in backwards compatibility as we continue to evolve the web platform. Additionally, we need help triaging the bugs that are already being submitted—people who can take the time to try to reproduce the issue, tease out the conditions under which it occurs, and help create a reduced testcase are a huge boon to the project.
Comments are closed.