Firefox 3.0 may ship with a slew of serious bugs intact
Whatever happened to open-source projects being released according to development readiness, rather than an arbitrary release schedule?
Mozilla seems to have forgotten this, with The New York Times reporting that the upcoming Firefox 3.0 set to ship with only 20 percent of its remaining 700 "blocker" (serious enough to justify postponing a release) bugs resolved before it ships.
Of course, Mozilla has already fixed over 11,000 bugs, according to Mozilla developer Asa Dotzler. Even so, that doesn't answer the apparent fact that the Firefox development community is planning to ship a product before a wide range of known blocker bugs are resolved. (Firefox 3 meeting notes can be perused here.)
For now, the mountain to climb appears quite high, as The New York Times notes:
As Mozilla pushes to post Beta 1 of Firefox 3.0, it has asked developers to prioritize already-identified bugs so that the most important can be fixed. But according to notes of yesterday's Firefox 3.0 status meeting, that will leave about eight in 10 bugs untouched.
"We have 700 bugs currently marked as blockers," the notes read. "That's too many. We're asking [requiring] component owners to set priorities on blockers, as a first pass of what bugs should be Beta 2 blockers. You want it to be about 10 percent of blockers, or what you can get done in four weeks."
On the positive side (and I mean that sincerely), Firefox 3.0 continues to miss its stated deadlines. I think this is good. It means that, in fact, Mozilla is prepared to put quality of code before an arbitrary release schedule. My life will go on if I continue using Firefox 2.0. In fact, Firefox 2.0 works exceptionally well.
What I don't want is to transition to a presumably "ready" Firefox 3.0 only to have it routinely die on me. Fix the bugs first, Mozilla. There's just no need to hurry the release.
Update: Mozilla sets the record straight.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
What kind of development process leads to this failure rate? Does a programmer just submit code for build without unit testing? Truly nuts.
I think they have decided to join the rest of world and just fix enough to get it to build and then fix the rest in Beta.
Truly sad.
In my QA world, it appears that most developers just toss code over the fence, then put testers thru the ringer for reporting defects. Not to mention project managers getting all spun up because there's a risk of schedule slipping when many critical issues are exposed. Slipped schedule = no bonus for them.
Nothing surprises me any more when it comes to quality, or the lack thereof.
Disclaimer: I'm not saying all developers do this -- just the majority of the ones I've dealt with over the past decade.
That's good news for Microsoft Office and Microsoft Internet Explorer.
As it is, I have Firefox 2.x installed on my computer, but prefer Internet Explorer 7.
I've worked as a software quality engineer for years and I have seen companies hide huge issues with their products. I made a lot of enemies at my past places of work because I could not believe what people were willing to release to the public. I fought hard for high quality standards. I won some, but lost most of the arguments. Consequently, two of the companies I worked for are now defunct - CompuServe and MCI. Talk about lessons learned!
These numbers don't bother me at all - I know someone is looking at the code, they know the issues, and it will eventually get addressed. If I wanted, I could join in the bug hunt and crush a few myself. I could even make suggestions at the code level. I have no idea what Microsoft is trying to slip into my computer and I know for a fact that they will not be open to disclosing all their issues. Obviously, that would hurt sales.
The question on everyone's mind is: What's the Rush?? FF 2.0 works exceptionally, and the Mozilla Team should take its time to bring about this new or enhanced browser to its full potential. I rather bring a browser to good working conditions than submit to possible angst by the Mozilla Community and FF lovers the world over.
In conclusion, the so-called "browser wars" in a no brainer, FF continues to amaze and enthrall people and that is the essence of what the Mozilla Organization should focus on. So bring it forth Mozilla, intact and ready to use.
stealing their ideas.
They've been shipping software with tons of known bugs since Day 1.
Once an application starts making cash, you really need to start using release schedule to make sure the cash keeps rolling in. A new release = press = more cash.
Unlike firefox, most open source projects are labors of love, not commercial cash cows. So most open source apps can afford to wait.
If you'd bothered to look at the history of past Firefox releases, you'll have seen (yes, after the Google tie-up too!) that they have regularly missed their originally announced "deadlines" because of the need to fix bugs. Because Firefox 2 is still one of the best browsers out there, Mozilla have no real need to rush-release Firefox 3 before its most serious bugs are fixed.
I think Mozilla are right to prioritise bug fixed to fix the worst ones first (anything that causes crashes or dataloss must be fixed prior to release) and I bet that even then the schedule will slip a few weeks to sort those out, which is fair enough.
Also, how do you come to the conclusion that Firefox isn't a "labour of love". If it wasn't, the developers would have given up long ago and let the frankly awful Internet Explorer dominate with a 95%+ market share. You'd also have had to wait a lot longer to see IE7 (which is better than IE6, but that's saying very little really) and any innovation on the browser front (and hence on Web sites) would have screeched to a halt.
Alpha: Many things are changing, new features are being added, code tends to be very unstable.
Beta (aka: Code Freeze): No further features can be added, code is becoming more stable, bugs are being fixed.
Release Candidate (aka: Controlled Release): All known bugs are fixed, it is now being tested by a larger group of people to see if previously undiscovered bugs appear.
Shipping (aka: General Availability): All known bugs are fixed, the product is now *shipping* to customers.
Of course Beta 1 will be released with many known bugs...that's how it's supposed to work. Beta 2 will have many less bugs, Beta 3 even less. Eventually they'll get to the Release Candidate 1 phase, then there will be an RC2 as more bugs have been found and fixed, and maybe an RC3 and RC4. The last Release Candidate will eventually become the *shipping* software, and the product will go into General Availability.
If Firefox still has a slew of known bugs when it hits GA, you should write this article again. In the meantime, it's a BETA. Normal people should not use Beta software, because *it's full of bugs!*
- Re: Much Ado Over Nothing
- by quirK November 18, 2007 10:38 PM PST
- I can't say much about people who prefer to use inferior releases over superior ones, like Firefox 2 to Firefox 3, or worse, Firefox 1.5 to Firefox 2.
- Like this Reply to this comment
-
(12 Comments)