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.

Earlier this week, Chris Soghoian posted an interview he did with me about Mozilla and our relationship with Google, as well as some other security topics. I’d had some concerns with a previous article of his, and I was glad that he was willing to take the time to discuss them with me.

In the course of that conversation, though, I misled him about how the upcoming malware list is managed; I had mistaken StopBadware’s role as review and removal channel for them having editorial control over the list in general, which is not the case. Maxim Weinstein of StopBadware contacted me to correct my misunderstanding, for which I’m grateful, and has provided a great explanation on the StopBadware site:

Mozilla, Google, and StopBadware are all expected to play a role in ensuring that the needs of both users and web site owners will be addressed in Firefox 3. Mozilla is working with Google to provide a list of potentially harmful URLs that will be used by Firefox to warn users before they browse to a site that may contain malware. This data comes from Google’s own scanning and research, not from StopBadware, as reported. (Our Clearinghouse allows users to search for a site to see if it is currently on Google’s warning list.)

StopBadware’s role will be (as it is now) to ensure that users and web site owners receive as much information as possible about the warning and to provide a transparent review process to assist site owners in understanding why a site was flagged and/or notifying Google that it has been cleaned.

By working together, we help protect users from potentially dangerous web sites while ensuring that owners of legitimate sites have a way to understand the warnings, clean up their sites, and remove the warnings.

I think this is a really good model that combines the scalability we need to protect more than 130 million users, the breadth of detection necessary to keep up with the modern pace of attacks, and a transparent and neutral process for reviewing and clearing sites that have been fixed. I just wish I’d understood it properly before speaking with Chris!

I ran across this article this morning, about how Microsoft is reaching out to other browsers like Firefox and Safari to encourage adoption of InfoCard technologies. The article is certainly true as written, and I’ve written before about some of my involvement in those discussions, but I would like to caution people against reading into it that we have made or announced concrete plans to support InfoCard as a piece of the Firefox platform.

I think that support for rich and user-empowering identity infrastructure is an important element of the future growth of both the web and Firefox, and I think — perhaps somewhat more controversially — that InfoCard’s principles and protocols are a pretty strong basis for that infrastructure, but there’s a big gap between those beliefs and an item in the committed Firefox roadmap.

For better or for worse, my still-forming opinions about technologies do not Mozilla technology policy make.