what makes firefox 3

Couple of articles today reporting that we’re going to ship Firefox 3 with 80% of our current blocker list still remaining to be fixed, which have cause quite the kerfuffle in our little corner of the internet. It appears to be an honest mistake, since a set of meeting notes did include that prediction, along with other elements that mention other approaches to the Firefox end-game, but it’s not our intent to cut Firefox blockers from the fix list against a hard numerical target or fixed deadline. As Matt Asay has noted, we’ve already demonstrated with this product cycle that we don’t roll that way.

At some point, of course, the number of “bugs we’ll ship with” will hit 100%, unless we manage to produce the first piece of bug free software I’ve ever worked with, but even with such numerical truisms aside, the picture here isn’t as simple as it seems. “Bug” in our world — as with every software shop I’ve ever worked, to be honest — includes desired feature improvements, optimizations, basically everything in the gap between “how the software is” and “how someone would like the software to be”. Because of history and some tool limitations, and because we now have a larger set of people triaging blocker nominations than we ever have before, the “blocking” flag doesn’t always strictly mean “we would not ship Firefox 3 if this specific bug isn’t fixed”. It can also mean “we should look at this in more detail before we ship” or “we’d like to focus developers on this set of bugs” or “don’t forget to do something (release note, document workaround, reach out to site authors, etc.) here before we ship”.

Sometimes, of course, it definitely does mean “we really should not ship without this bug fixed”, which is the most common understanding of “blocker bug”. Over time, our impressions of the severity of something can change, up or down, as usage on the web changes, or features get deferred (meaning that “mandatory” platform changes to support the features are no longer mandatory). Some things that we thought were blockers at one point may well be evaluated not to be later on; we reserve the right to change our minds, as must all learning people and organizations, but we’re not going to do that on a strictly numerical basis, and certainly not on the basis of some system dreamed up by a 16th century doctor.

Of course, we want to get Firefox 3 out to users soon, because there are tens of thousands of improvements there: better support for web standards, speed and memory improvements, great new productivity features, safety and security features, straight-up bug fixes, lots of UI polish, and powerful new APIs for extension developers. But we also need — which trumps the “want” of soon, as you would expect — to make sure that we ship a product that’s good enough for a quarter-billion users (on our current growth curve, we could easily see that many people using Firefox during Firefox 3′s lifetime), that’s worthy of the name Firefox, and that we’re all proud to send into the world. Many of us worked on Netscape 6, so we take this pretty seriously.

Mike Schroepfer, our VP engineering, isn’t dogmatic about many things, which is one of the reasons he’s so good at his job. But he’s pretty damned unequivocal that we’re not going to ship until we’re done, as you can read here and elsewhere:

1) We are driven by quality, not time. We want to Firefox 3 to be something that we are all proud of. This means features that delight users and the same or higher quality than previous releases. “Quality” includes performance (Tp/Ts/TDHTML/etc), footprint, web compatibility, regressions, and general fit and finish. Having said that, we want to move the web forward and are in a competitive market. So we should converge on a release as fast as possible.

4) We’ll release betas until we complete our regression work and incorporate feedback from wider-scale testing. Before we release the final beta Performance (specifically Ts, Tp, Tdhtml, Txul, and any other benchmarks we add to the main tinderboxes) will be as good or better than 1.8. We should strive for improved Tp and Tdhtml scores performance v.s. 1.8.

  • When will the last Beta ship?
    • As soon as it is ready (see #4 above)

There’s nothing new or changed here, other than an unfortunate mixup in some meeting notes and that more people than ever before are watching what we do and how we do it. That reporters are tracking our meeting minutes to track the project indicates that what we’re doing is important to a lot of people, and that makes us more motivated to focus on quality than before, and not at all motivated to push out a release to meet some arbitrary deadline. We’re in this for the long game, and years after the release date is nothing more than nerd trivia, people will remember what Firefox 3 did for them, and how well it worked. It’s going to be awesome, even if you have to wait.

Update: Matt Asay has posted a follow-up article. It’s all good.

8 comments to “what makes firefox 3”

  1. entered 16 November 2007 @ 10:21 pm

    [...] Mike posted something very shaverly that talked about the larger issues, how we’re focused on quality more than time, how the list in question contains more than just things that will keep us from shipping Firefox and generally try to educate people about what we might do as a project in the run-up to deliver a product. (Also a link in his post that tried to educate people about the origin of the modern calendar. Bonus!) [...]

  2. entered 17 November 2007 @ 12:22 am

    [...] can read Shaver’s post in What makes Firefox 3. There’s a lot more to be read, so you definitely want to follow that link. Asa Dotzler says [...]

  3. entered 17 November 2007 @ 7:07 am

    Well spoken!

  4. entered 18 November 2007 @ 9:02 am

    [...] Looks like the Mashable story might have been misleading. Thanks to the commenters, we have an update to the story. I’m still disappointed in the current state of Firefox on the Mac, and like Jon says in the [...]

    entered 19 November 2007 @ 8:40 pm


  6. entered 19 November 2007 @ 9:25 pm

    Aclaración sobre Firefox 3 y el 80% de los bugs sin corregir…

    Recientemente se habló de que Firefox 3 saldría con el 80% de los bugs sin corregir. Mike Shaver, de Mozilla, aclara la realidad sobre esta acusación. Entre otras cosas: Demasiados bugs estaban etiquetados como "bloqueadores", pero muchos …

  7. janice
    entered 27 November 2007 @ 1:49 am

    Oh. Your VP Engineering should be cloned. The software world needs more just like him. Working for people who care about quality is awesome. You lucky Mozilla boys and girls, you!

  8. entered 20 December 2007 @ 3:09 am

    [...] version next year. Mike Shaver, Mozilla director of ecosystem development, subsequently penned a blog post that said that 20 percent prediction was a [...]