Asa Dotzler has been there from the beginning. As Mozilla's director of community development, he's had a hand in birthing some of the web's most successful open-source software projects, most notably the Mozilla and Firefox web browsers.
Asa (pronounced A-suh) first got involved with Mozilla in 1998, when he was still an architecture student at Auburn University. He was interested in free software, but like many, he found the Linux distributions of the day too abstract. But when he heard Netscape had released its browser code under a free software license on March 31, 1998, he felt the urge to get involved. He knew web browsers -- and the problems with them -- so he eagerly offered his services. Dotzler quickly found his niche, becoming a non-technical volunteer within the Mozilla community -- gathering news, distributing executable code to casual users and filing bug reports on behalf of people who didn't know what bug reports were. He could interact with Mozilla's technical staff yet keep his layman's perspective, a skill Dotzler was able to parlay into a real, paying job. He's been with Mozilla since 2000.
Now, with Mozilla getting ready to celebrate its tenth anniversary on Monday and with the June release of Firefox 3 fast approaching, Dotzler agreed to sit down with Wired.com and share how his outsider's eye has helped shape Mozilla's path. He tells us not only why Netscape failed, but why Mozilla's first crack at a browser didn't do much better. He also offers insight into how the Firefox team makes decisions ("We've never been a democracy," he insists) and why he thinks Firefox 3 will improve the health of the web.
Photo: Jim Merithew/Wired
Wired: Talk me through the birth of Firefox, how the browser came to be what it is today.
Asa Dotzler: Within the first year of me being here -- this is around 2000 or early 2001 -- it was obvious to me that Netscape and Mozilla were going to have to part ways. Others saw it, too.
A group of Netscape employees who were also Mozilla contributors were really frustrated with the Netscape's insistence on making the feature set of its browser subservient to the business model of advertising for Netscape.com. Netscape was no longer a technology company -- it was AOL needing page views, and these people were told to build a product to drive page views to AOL.
You started to see things like the default bookmarks being auctioned off. When you downloaded Netscape 6, you had 45 bookmarks already in the bookmarks menu, all of them paid for. We had a drop-down menu attached to the print button on the tool bar with one item in it. You'd click on it and see an option called "Print Plus." When you clicked on that, you'd be taken to HP's website where you could buy printer supplies. HP literally bought a button on the toolbar!
We came to the conclusion that Netscape couldn't ship a good browser as long as the business of Netscape.com was getting in the way of creating a product that people actually wanted to use. However, if Netscape didn't basically whore out the browser for every penny it could get, it would have been put to sleep by AOL. And we needed AOL because they were funding most of Mozilla's core development. So we realized somebody else needed to do it.
Mozilla 1.0 shipped in June of 2002, a little over a year and a half after Netscape 6. We shipped it with everything we felt it needed. We had standards compliance issues, the stability and security stuff, pop-up blocking and tabbed browsing. We thought it was pretty good. And it got about one or two percent of the market. Then we realized Mozilla couldn't do it, either.
Wired: Why do you think that was?
Dotzler: In the early days, Mozilla gave a lot of control over what goes into the product to the community, but they were overly broad about it.
If you were the guy who was working on cookie support, there was nothing to stop you from putting a cookie button on the toolbar. The authority to change the product feature set rested with the owners of all of the code modules down to the lowest level. That sort of thinking created a hodgepodge of a browser that wasn't terribly useful.
We realized Mozilla couldn't build something usable, and we knew Microsoft wasn't going to do it, either. They released IE 6 and saw it gain 98% of the browser market, then made the quite reasonable decision to not even bother improving it.
So we said "Let's try it." We got our own directory on the server so we could experiment. We took whatever version was the current Mozilla browser that moment and stripped it down to nothing. It was a window that literally had nothing but a window for rendering web content and an address field. That's where we started building up a browser that could compete with Internet Explorer and still be something that my friends and family would want to use.
Wired: How did you come to the decision about which features get coded into the browser and which features would be left out or off-loaded onto an extensions framework? For a lot of people, that's still a hot debate topic.
Dotzler: This is something almost nobody knows about. The entire add-ons structure was a compromise we made to avoid losing some of our key contributors. Everyone could see which way the wind was blowing -- this new thing that would become Firefox was gaining tremendous momentum -- but we had people working on Gecko, the web rendering engine, and other key backend stuff that were threatening to leave. They loved working on Mozilla and they told us that if we ditched Mozilla, they would leave.
So we said, "The things we take out, you can just add them back in at your discretion. And, if you love your Mozilla cookie toolbar, here's a really easy API you can use to make that into a Firefox extension."
We used a lot of technology that we didn't invent to make this happen. Mozilla had extensions ever since 2002. Tabbed browsing started as an extension, and that became so popular, we said, "Hey, let's roll this in."
Wired: OK, that's the process that a lot of people are mystified about. Back then, something like tabbed browsing was an obvious choice for inclusion since you had fewer features to choose from. Now, the browser is capable of doing so much and the web has changed so much, people question those decisions more harshly.
Dotzler: For the first two years, we had the same core set of people paying attention to Firefox features -- Blake Ross, Dave Hyatt, Joe Hewitt, Ben Goodger, me and a few others. We would ask ourselves, "Do we think 90% of the people need this feature? Is this something everyone I know really needs?" If not, we would leave it out.
Then in 2004, Mozilla decided to dump the Mozilla suite and support Firefox as its primary browser. At that point, that group of people deciding what those basic "must have" features were grew substantially. That's when we started getting pressured to add things in that we had previously left out.
When it came time for the next release, we asked all of the people who owned each piece of the feature set for the browser if there were any extensions that have proven to be popular enough to roll in.
We found that there are a lot of niche audiences, 5% cases. Extensions make a lot of sense for all of those 5% cases. If you fold all those into the browser, you end up back where you were with the Mozilla application suite. Something that's appealing to the geeks, but so overloaded that regular people can't find the basic stuff.
So, we were and are very cautious about folding in even some of the most amazing add-ons out there. In some cases, we can get away with not worrying too much. Like drag-and-drop reordering of your tabs. It's not exceedingly popular, but it doesn't get in the way of anything so it makes sense to roll it in.
Other things are more extreme. Session Restore is a pretty big hunk of code, but we felt most people would benefit from it. So we rolled it in.
Wired: So how do those decisions actually come about now? Is it still an internal process or is it left up to the development community? Do you take a vote?
Dotzler: Mozilla has from the very beginning had a very simple structure of modules. There's a cookie module, a JavaScript module, a toolbar module and so on. Each module has an owner, and that owner is the steward of that hunk of code. That owner has surrounded himself with a group of people we call peers. These are the people who have direct access to make changes to the code and who can assist the owner in getting the community involved. That's the decision-making group for that module.
We also have modules for things that aren't code, things like policy. Making a policy change at Mozilla requires the decision of the policy module. That's Mitchell (Baker, chairwoman of the Mozilla Foundation) at the top and she's surrounded by a group of about 20 people who have demonstrated the ability to make good decisions about policy. The same goes for features. We have a usability and features module.
Whenever there's a proposed change, those owners and peers go out and solicit comments and feedback from the community -- this is all public, with everything on a wiki that anyone can comment on -- and use that feedback to hone or define their goals. But this is not design by democracy. We've never been a democracy at Mozilla. We're a meritocratic hierarchy. You don't get a voice by being a human, you get a voice by establishing a reputation for doing good deeds over time.
The simpler the problem at hand, the more people think they're experts in it. I think I'm an expert in user interface design and I think I know what should be there. But the truth is, Mike Beltzner, our UI guy, actually has an education in it. He's been working in the area for ten years and he knows a lot more about it than I do. It's not all subjective, there are rules to make things work. It's never "He who gets the most votes wins."
Wired: It's funny you say that, because on our website, we often poll our readers about this stuff. Last week, we asked everyone what add-on they'd most like to see rolled into Firefox to make it a more competitive product. (AdBlock Plus was the clear winner, by the way.)
Dotzler: But voting isn't the only mechanism for collecting that feedback. We can run tests to see what buttons people click on. In our beta testing, we have 1,000 people who have volunteered to give us the logs of how often they click on each button, how long it takes them to find the button they're looking for. If we have hard data about the browser's usability, we might make a change like making the back button twice the size it was in the previous release. So that decision isn't one we're going to take a public vote on because we actually know better. Maybe.
Wired: What do you think is the most significant contribution that Firefox 3 is going to make to the browser ecosystem upon its release? I know that's kind of a big question...
Dotzler: But it's easy. I think the most significant thing we can do is release a browser that respects agreed upon web standards.
If we can empower a new set of standard features on the web by implementing cool things -- that shared set of "new stuff," along with Safari and Opera and Internet Explorer -- I think that would be really exciting. We're working with the WHAT Working Group and the W3C to take features like Canvas, which started off as a single-browser implementation that we now all have (minus Internet Explorer) and make them standards.
For user features, it's safety and security. We're going to make it a lot easier for you to protect yourself online. That's really important, and it also plays into the health of the web.
And of course, for all the people who have had problems with Mozilla's performance and resource usage, the latest releases of Firefox are rocking now. We're the fastest browser on the planet. We're the lightest browser on the planet. And that's something we haven't been able to brag about for a while. But we're beating everyone right now, and with Firefox 3, we're going to ship a browser that's best across the board.
See Also:
