New Roles in Open Source Projects

The Mozilla project has always been a pioneer in bringing new functions and roles into an open source project. In the early days, this was integrating open source DNA with commercial organizations. A number of people are doing this day, and we’re still learning new things ourselves. Another topic in our world today is the additional of people in non-engineering roles. We’ve generally had a small amount of non-engineering personnel — though for many years this meant me. When the Foundation was formed Bart Decrem joined as our second non-technical person. About the time Bart left Chris Beard joined and picked up a range of non-technical topics. Today we have more such people. This includes roles such as:

• product-wide coordination (this role is often known as “product management” but I’m wary of this label because anything with the word “management” in it generates all sorts of reactions),
• communications and outreach (some of which is generally known as “marketing”, some of which is quite new like the Spread Firefox work),
• working with other organizations in the industry who want to build on our work (classic “Business Development” and “Partner Relations”).

This raises many interesting questions. One is that the open source community is not nearly as rich in home grown expertise in non-engineering areas as it is in developers. So filling these roles often means bringing in people who haven’t “come up through the project.” These folks who are new to the Mozilla project need to be accepted by the development community in order to be effective. Status as a Mozilla Corporation employee isn’t enough.

Another issue is that we don’t have an established path to meritocracy for non-technical roles. For potential developers, we know about several paths for getting involved and developing legitimacy — we know about the Quality Assurance path, we know about fixing bugs, we know something about hacking on the code, we know about writing a great extension and so on. We also have clear ways of identifying a person’s known expertise — they may be a peer for code, a “module owner” for code, etc. All of these are reasonably well understood roles within the project that convey a person’s expertise.

We don’t have analogous paths for non-engineering roles. We don’t yet have ways for the non-engineering staff to indicate the scope of expertise of their colleagues. And we are just building a core group of product coordination, community and partner relations (aka product management, product marketing, marketing, business development) contributors whose judgment and commitment to the project are understood by the technical teams to equal their own.

Itegrating non-engineering contributors takes a lot of trust and feeling our way gently. Those people joining us in non-engineering roles must trust that the technical contributors will give them a fair chance to participate, add value, become respected and gain influence and leadership. The engineering community must trust that these people who may be new to the Mozilla community and don’t have deep technical expertise are worth listening to and giving a fair shake.

Periodically I say or write something like “Please give this person the benefit of the doubt. If they seem off on a path that feels really wrong to you, please say so gently. Assume they are unaware of some relevant fact. Assume they are trying to do the right thing. Don’t assume they are evil, or out to change the project or claim control.” It’s generally worked so far, but it reflects the newness of these sorts of positions to our project (and I think, open source projects in general).

Relying on trust is a funny thing. One absolutely needs it. A well-known system for gaining respect and influence doesn’t mean much if participants don’t trust each other. And, who wants to work in a world that’s full of mistrust? But relying on trust alone without any guidelines is difficult in the long run, is intensely personal and leads to people needing to “reinvent the wheel.”

I’m interested to hear what other projects do, and if there is any general learning on this subject. In any case, we’re working through these issues now. No doubt both our successes and our missteps will be apparent 🙂