In a recent post I wrote about the role of non-engineers in our project. A couple of people responded along the lines of “why can’t we just use our standard techniques, where people come up through bug triage, or our online communities, etc?” I’m glad people asked this because this is a critical point, and at the heart of the topic I want to address.
I whole-heartedly agree with the spirit of this response — people are effective when they are known and respected. This is the basis of shared values, community cohesiveness and continuity. It’s one of the tenants of open source software development that I believe must permeate everything we do. Our challenge is to use this approach in places where engineering “chops” aren’t a sufficient and may not be a particularly necessary criteria.
When we apply this approach of legitimacy-through-reputation to the Mozilla project, it’s clear how engineers “come up through the ranks” and move into broader roles. The combination of “coming up through the ranks” and an organization that is historically mostly engineers means that one “comes up” through an engineering process — bug triage, patches, etc. And we have gotten some great product and project management through our phenomenal collection of lead engineers.
But if one’s skillset is something other than code, then proving oneself through understanding the intricacies of our code is at best inefficient and probably a blocker for many people. So the challenges are to find mechanisms for people in non-code roles to demonstrate they share the values of the Mozilla project and can make contributions that people want to support.
Right now, we’re in the early phases of both building communities focused on product management or marketing and of building those functions into our product development. We’re further along with marketing, since the spread firefox has been active since Fx 1.0 and volunteer marketing began even before that. But even so, a few years isn’t a long time. Open source has been around for decades, and there is a significant group of engineers who participate as volunteers, and a significant group whose work involves open source projects. We know what the set of activities are that lead to acceptance and leadership. That’s no so clearly the case for the set of other activities.
The heritage of open source is primarily about code; only recently about product. And even more recently still about consumer products — I often hear Firefox described as the first genuine open source product for the “mass market.” So it’s not surprising that the Mozilla project is looking at a lot of activities that are new (or new-ish) to the open source world.
We certainly don’t want to exclude people from influencing the project because they aren’t writing or testing code — this would limit the project drastically. At the same time, we maintain our technical excellence through openness, peer review, and the open source process. We need to find ways to continue to build these strengths into all of our activities.