The hard sell

Posted 1 year ago at 15:06. 5 comments

I had the privilege of attending FSOSS last week.

This is a great open source conference put on by the people at Seneca college in Toronto. The conference is now in its second year, and is priced right to actually allow many smaller open source ventures or individuals to attend. I even got the opportunity to talk to a few high school students who were able to attend because the price point didn’t overwhelm their nascent interest. But I digress…

One of the major themes this year was building community and the various problems inherent therein. Even Microsoft sent a speaker, Bryan Kirschner, to discuss how Microsoft is trying to build a community around its own open source efforts. Regardless of whether you trust Microsoft’s initiatives or not, I respect Bryan a lot for coming into what has traditionally been a very hostile environment and trying to rally support without being defensive.

A lot of projects — e.g. Microsoft, OpenKomodo, Miro — are just starting (relatively speaking) to build their communities. They’re dealing with issues that are a little different than ours: how do I attract people to my project vs. project X? Some of these projects have the added benefit of being newer and/or flashier than us (Miro). Some of the projects will be effectively capped by their target audience (OpenKomodo). Microsoft just has to get past 25 years of bad blood.

Mozilla shares the recruitment problem of these other projects, but increasingly our problem is also one of retention: how do we keep the testers we already have (many of the newer projects *are* seductive), and how do we embrace new people who do show up to help and not scare them away?

The best session I saw concerning this was entitled Community Management as Open Source’s Core Competency, as given by David Eaves. I don’t have any formal background in negotiation or debate and yet I am increasing required to interact with a large community of users and testers. I found David’s talk the most eye-opening in terms of how to improve our interactions with the community and to encourage them to come back and help us more.

We (MozQA) are getting a bit better at this. IMO, the biggest step forward we’ve made in this area recently was hiring Tomcat. As someone who came directly from the community, Tomcat is filling those communication gaps that used to exist (e.g. sending notice well in advance of test days and bug days), and he is actively engaging people during QA events.

There are still some pain points though. Many people I talked to cite Bugzilla as a major impediment for joining the project. Bugzilla is often referred to as “opaque,” and it’s apparently still quite common for new people who file new bugs to be dismissed, sometimes harshly. If we can somehow find a way to *not* make Bugzilla the entry gate into the Mozilla community, that in itself would be a huge win.

We already have a few potential solutions in place. Hendrix puts a friendlier face on Bugzilla, and QMO is the new quality-focused community portal. At the end of the day though, this is not a tools issue. There has to be person and a connection happening at the other end of the tool.

And that’s really the crux of our current problem: how can we grow our community with only a small number of community “managers” on our end and still have it feel like a real community to everyone participating? Right now we’re faking it pretty well, especially considering that very few of us have formal training in this, but I fear that if it ever smells fake to our community members, they will pick up their toys and go home. As I mentioned before, they have a lot of other open source projects they could be contributing their time and effort too. If we want them to stick around, we have to engage them and make them feel like a real part of the Mozilla process.

Let’s figure out how to do that better.

Current Tunes: Stereo MC's - Playing With Fire | Filed under Mozilla, Open Web, QA |