During a recent Firefox 3.0 status meeting, Mozilla developers noted that over 700 bugs in the Firefox bug tracking system are classified as blockers—issues that have to be resolved before the software can be released.

Mozilla subsequently requested that component maintainers adjust bug priorities to reduce the number of blockers and stated that approximately 80 percent of the bug reports currently characterized as blockers will not be closed before the Firefox 3 release. This statement has been broadly misinterpreted in the press, largely as the result of a New York Times article which conveyed the statistic without framing it in the proper context. The Times claimed that 80 percent of the bugs would not be fixed, when in reality, resolution of those bugs have simply been deferred so that they don't delay the release.

Some have interpreted the large number of blockers as a sign that Firefox 3 is irreparably buggy, but those familiar with the open-source software development process know that the real situation is a bit more complex. The inflated number of blockers doesn't reflect problems with the Firefox development process or the program itself. Rather, it indicates that Firefox community members who actively participate in bug reporting and triaging are having trouble prioritizing the bugs properly. This is a very common problem that often emerges in large open source development projects towards the end of the release cycle.

A look over the actual list of Firefox 3 blockers reveals that the bug reports don't all actually reflect bugs. Many of them relate to feature requests, performance improvement goals, and corner-case rendering issues that only affect specific web pages. Asking maintainers to reevaluate bug priority is a way for Mozilla to refocus development on the most important issues so that the software is as robust and usable as possible by the release date. Reclassifying less-significant blockers is a necessary QA strategy that will actually lead to a better Firefox 3 release. No software will ever be released completely bug-free, and problems that can be fixed in updates after the Firefox 3 release can and should be reclassified at this stage so that they don't hold up more important development efforts.

In a recent blog entry posted in response to the Times article, volunteer Firefox contributor Robert Accettura provides a concise explanation of this phenomenon. "In every release cycle, everyone wants every bug to block a release and therefore everyone is 'blocker-happy,' and later in the cycle, all are changed to non-blocker status except the most critical as perceived by developers, drivers, and testers," writes Accettura. "[E]very bug you fix, feature you add introduces new code, which potentially causes new bugs in other places. Even if you devote 100% effort to fixing bugs, you'll likely never get there... Every project involves deciding what bugs ship, and what holds a release. Every single one. If there's someone who doesn't, it means their QA is likely flawed or inadequate."

In response to overblown concerns that a large number of Firefox's bugs will not be resolved, Firefox community coordinator Asa Dotzler has characterized such claims as "horses***." Dotzler points out that over 11,000 bugs reports and feature requests have already been closed and classified as fixed, a number that dwarfs the remaining 700 blockers.

Mozilla technical strategist Mike Shaver has also responded. "'Bug' in our world—as with 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'," explains Shaver. "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."

I have personally used Firefox 3 alpha nightly builds (codenamed Minefield) on a daily basis as my primary web browser. Although I occasionally get stung by regressions and have to switch back to a stable build for a few days (I had some performance and stability issues last week that seem to have been resolved since then), it is largely very usable. Firefox 3 includes a tremendous number of very useful and impressive features and it is rapidly approaching the point where it is robust enough for general use. There is definitely no justification for concerns about the final product at this point.