Asa Dotzler: ”Anything that is opaque breeds mistrust. People don’t feel they are ‘just doing manual labor’ when they can see how things are coming together.”I went to see Asa Dotzler because I was told that he was the one in charge of worrying about the user community that had grown up around Mozilla’s Firefox browser, which I use. It was a story I wanted to hear in person since I am creating a similar position for NewAssignment.Net.

Different names for it surface all the time. The original was David Weinberger’s: “The network needs a wrangler,” he said. Thus, network wrangler is what we called the job at first. Later: producer. It’s the person in charge of making participation in the site happen, and solving the problems that arise when it does. In the pro-am style NewAssignment.Net intends to practice, the volunteers need their champion (and visionary). Openness must itself have an officer.

Asa Dotzler is that person at Mozilla. So on my last trip to the Bay Area I went to see him at the Mozilla Foundation offices in Mountain View, CA, which is Silicon Valley if any place is. Two things I noticed about the offices: It was impossible to tell what anyone did by looking at what they were doing; and the space itself could be vacated in a few hours without a trace.

We took a conference room. I scribbled notes on a legal pad, he talked. I asked him for his title. “The community guy” at Mozilla, he says. He says “there’s about seven of us” from different software companies or projects who have a similar job. They get together sometimes and compare notes. It’s a very limited universe of people who have done this kind of work, he says. (Later that night over Indian Food my nephew Zack Rosen and I calculated that it’s probably under 25 who have experience at it.)

“Actually, I have several different communities I’m supporting now.” The makers and users of Firefox are one. Thunderbird (a mail client) is another. Mozilla with 70 employees on all its projects has to compete with Microsoft with more than 70,000. Asa lets the numbers sink in. He smiles when he says there is no way to do that without the assistance of volunteers— and good tools that make it possible for volunteers to add value. They’re what make Mozilla competitive, even though it is a tiny fraction of the user base who become active in the communities Asa tends to.

Back in 1998 when he started, open source software “was a very exclusive club.” Only a limited pool of programmers could participate in the allegedly “open” part. Asa is not a programmer himself. His degree is in architecture. (I would call him an artist of the practical.) It’s a point of pride that he set out to broaden the mix to people who were not hackers or coders. The key to it, he says, was ramping down the skills required to contribute and add value.

What’s the next level down from programming? Bug catching. Programmers were already doing that in distributed fashion, but others could do it too. With thousands of users reporting bugs to Mozilla you need volunteers to manage the volunteers. It’s the kind of necessity that leads to invention. “The old open source management structures didn’t work.” The scale of participation was too big when you broadened it beyond the initial participants: hackers. That’s how bugzilla.org came about. (“The bug-tracking tool of choice for many projects, both open source and proprietary…”)

Rules for open source bug catching were “anyone can play.” This is a key principle for Asa. The most basic sense in which a system can be “open” is: anyone can report bugs. But along with that a system of merit: best contributions rise to the top, top contributors get rewards. A group of about 150 “who had been around long enough to know what’s possible and what isn’t…” sort through the reported problems, deciding which have merit. Then a group of about 20 “drivers” take the reports of the 150 and determine what really needs to be in the next version of Firefox. But the 20 are a cross-section— some programmers, some regular users, some employees of Mozilla, some volunteers.

“Distributed project management.” That’s how it scales. He said that as you get closer to the release date you get more and more restrictive about what’s going to make it into the next version of Firefox.

Mozilla couldn’t pull off updates of the Firefox browser without using volunteers and the gift economy they are a part of. Universities contribute the servers necessary to release updates of a product with millions of users all over the world. Volunteers staff the help forums for Firefox; otherwise, it couldn’t afford a help system that good. The “community ecosystem” (Asa’s term) around Firefox includes users who create their own extensions and applications of the browser. Mozilla hosts these, even though they are not Mozilla products per se.

It all makes sense under non-profit conditions, almost no sense in a commercial system. Would you volunteer to staff the help forum for one of Dell’s latops?

Some of the most interesting stories Asa Dotzler told were about volunteers for something new in the making of open source software— marketing by people power. Thus grew the “help spread Firefox” campaign. Again, the key was thinking through the “anyone can…” part. Because once you have that the system is an open one at that point.

One answer: simple button on your blog to help spread Firefox. Mozilla added a little tool that would tell the user (and Mozilla) how many referrals were generated from the button, then listed the top referrers at the Mozilla site, which drove some traffic back to them. They featured not only the top referrers by volume but the fastest climbing ones to give newcomers a little love.

The game: Open source adoption curving. Anyone can play. Object: “Help spread Firefox.” It’s meritocracy with a metric (referrals). You reward the top contributors by pulling them on stage. That’s Asa’s science, as required by his art.

Volunteers came up with the idea of an newspaper ad for Firefox in the New York Times, designed it, wrote it and paid for it with user contributions. They also came up with the idea of making a crop pattern in the shape of the Firefox logo in an actual farm field, and pulled that off too, complete with aerial photographs, which I saw. (Astounding.)

Those projects—the ideas and the execution—came from spontaneous discussions in forums. Asa said it’s hard to know when discussions will take off and become something he has to get behind. “I just do my work in public,” he said; sometimes people react and there are lots of comments. Other times it’s just him… doing his work in public. Follow the forums carefully, he said. You have to “live in the fishbowl” and continue to be transparent in your decision-making, he said. Anything that is opaque breeds mistrust. People don’t feel they are “just doing manual labor” when they can see how things are coming together. Your view of nail and hammer changes when you can see the house and its plan of rooms.

Each of the communities he has built requires “care and feeding,” Asa says. Part of it is matching rewards to level of contributions. If a tester is doing a great job testing a product on a PC but doesn’t have a Mac, he’ll ship him a Mac. He has a budget from which he can spend on various goodies for exceptionally valuable volunteers, but also to support ideas that come up in the forums. When they are good enough for development or meet with Mozilla’s strategic goals, Asa will put assets behind them.

Which is simply to say that there is no volunteer system unless there is also a system for putting a value on what all volunteers do, while identifying the most valuable people in a pool of contributors. You have to know who they are and bring them into your network somehow. Tools that help you do that are critically important.

A lot of what Asa does amounts to cheerleading for people who are doing things that add value, and even though it might seem corny to some it does not feel that way to those who are cheered. He also makes sure all Mozilla employees have the tools and tricks they need to use the open source methods that are key to the Mozilla way of competing. Trying to document what he does: another part of the job. The more who use these methods, the better they will become. For this reason he is interested in my project, NewAssignment.Net. “And I may be a lot more involved than you would think.” He said he would watch carefully how the project unfolds.

He said one of the biggest challenges for NewAssignment.Net is “you can’t architect all this up front,” meaning that it’s impossible to know what tools the community guy will need until you get in there and start dealing with the actual people who show up. “It requires the human touch.” You can try to equip the network wrangler (a term he loved, incidentally, for the accuracy of the image…) but the most valuable tools are those developed to solve problems that arise in the doing of the projects you set out to do. Made sense to me. That’s exactly why NewAssignment.Net is doing projects in open source journalism.

The biggest problem all “community guys” have, he said, is the kooks. But they’re not like trolls at blogs. They’re people who lack a sense of realism, and who want to help but don’t know how or can’t see why their actions are not helping. There are difficulties that come about because some people who are intensely involved want open source projects to be “ideologically pure.” The working ones never are. Sometimes you get major leadership problems, as when a key volunteer who is organizing other volunteers goes missing. Dispute resolution among people with ego invested is a time-consuming headache too.

“The more open you are the more noise there is compared to signal” in the communications you get. One should be prepared for this, he said. He gets 1,000 legitimate (non-spam) emails a day sometimes.

I asked him what the New Assignment site would need to succeed with volunteers. He said:

* Regular flow of new content.
* Tools that let users see what’s happened since last visit.
* An easy way to highlight exceptionally valuable contributions and the people who make them.
* Some automated system to track how much and what kind of work each contributor is doing. He said the failure to build this into his projects was one of his key mistakes because he has to try to follow it all by hand.
* A way to know when key contributors stop contributing. You have to contact them right away and find out why.

Finally, he said the most important factor by far in getting volunteers was to “have a great product.”