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.