This breathless item at Boing Boing: Mozilla bug-squashing timeline: "This timeline of the discovery of a critical flaw in Mozilla is amazing. It took a scant 31 hours between the moment the bug was first reported to the moment that you could download a patched version of all different Mozilla flavours and derivatives."

So that's nice and all, but this example implies that oh, if we're all open and responsive, it makes the QA burden somehow go away. Which is crazy. I've seen my share of "oh, this fix should be simple, and shouldn't have any impact" fixes that turned out NOT to be simple and that DID have big impact. If some large company named (let's call it Banana Computers) blew out a fix for a critical security problem without doing a full QA cycle, they'd be crucified if it turned out they missed something. Even if they were just as fast at trying to get a patch-patch out.

I'm all about the responsiveness, but let's keep in mind that this bugfix turnaround time is about getting a fix into the daily build, not into a "stable" point release. If you're a sophisticated user who knows what you might getting into, yay for you. I've seen this kind of turnaround internally countless time (in terms of identifying the bug, fixing the bug, and getting the bug past preliminary testing), but crossing the Is and dotting the Ts and making sure you haven't destabilized other things is more than just fixing the bug.

Update: One of my old grad school compatriots turns out to work on Mozilla, and (in the comment attached to this) gives a good summary of what happened in this case, and why this wasn't a particularly risky bug to fix. So I feel like a heel :). I'd like to clarify that I wasn't trying to stomp on Mozilla, which I think is a great & impressive project. What I'm reacting to here is the uncritical notion emanating from Mozilla observers like Boing Boing that Open Source == Zero QA Burden.  9:57:03 AM  (comments [])