Firefox's rapid release schedule harms bug-squashing efforts

A former Mozilla volunteer says the project, already squeezed for triage time, needs to handle bug reports more intelligently

Mozilla has garnered unfriendly attention lately after a former volunteer criticized the group's slow responses to bug reports. The timing of the post and the resulting response from observers is notable: It all comes in the wake of Mozilla's "rapid release" initiative, through which the group has pledged to roll out an updated version of its Firefox browser every 16 weeks, possibly sans version number. Mozilla's decision to dramatically speed up its development cycle has met enough resistance to put the group's chair, Mitchell Baker, on the defensive.

Further, the criticism of Mozilla's bug-handling procedures comes at a time when Firefox continues to lose both market share and credibility in the browser space. In terms of the latter, a recent report from NSS Labs (PDF) on browser security found that Firefox 4 caught only 7.6 percent of live socially engineered malware threats, far less than Internet Explorer 9, which snagged 99.2 percent, and behind Chrome, which detected 13.2 percent. Firefox's results were 11.4 percent lower than the 19 percent protection rate observed in the Q3 2010 global test, according to NSS, indicating an overall drop in protection for Firefox.

The author of the now-controversial blog detailing Mozilla's bug-processing shortcomings was Tyler Downer, who stepped down as a Mozilla volunteer out of frustration. In a post dated Aug. 27, he wrote that while he supported the rapid release initiative, he was frustrated by the impact on how it affected the triage group -- that is, the people responsible for processing and confirming end user-submitted bug reports.

His argument (which he clarified in a follow-up post): Triage doesn't have the time or resources to go through all the reported bugs to keep up with Firefox's accelerated release cycle. "With the old model of releasing a new major version once a year, triage had a bit more time to go through a massive pile of bugs, to find regressions and issues, and there was a pretty good chance that most bugs would get caught, just because we had time on our side.... Or so went the theory. Even this process failed us," he wrote.

Tyler did not elaborate on how the process had failed previously, but Firefox did rank No. 5 on Bit9's top 10 list of buggiest software for 2010, behind Safari (No. 2) and Chrome (No. 1).

To illustrate the challenge triage faces with rapid release, Tyler said that Firefox currently has 6,000 unconfirmed reported bugs -- not to be confused with 6,000 real bugs. ""Out of those 6,000 bugs, there are duplicates, bugs that have already been fixed, bugs that are user error, bugs that are caused by third-party software, and so on. I simply wanted to suggest that we need to do a better job of going through the bugs that are submitted. Without going through the list, it is difficult to determine which bugs are real and which are invalid," he wrote.

Tyler provided some recommendations for Mozilla to better handle bug reports, including being more responsive and polite to users who submit them, as well as embracing better coordination within the Mozilla community to investigate bug reports in a timely, efficient, and coordinated manner, perhaps with the implementation of a software tool for better managing the bug reports.

Ultimately, Tyler was not entirely pessimistic about the fate of Mozilla Firefox. "The situation with triage is not hopeless. I have been in talks over the past few days, and I see a good possibility that Mozilla means business in improving triage.... There is a new 'Tell Us More' input tool in the works, which will implement some of my desired changes (such as a separate product for unconfirmed bugs)," he wrote.

This story, "Firefox's rapid release schedule harms bug-squashing efforts," was originally published at Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow on Twitter.

Copyright © 2011 IDG Communications, Inc.

How to choose a low-code development platform