Sun’s Thorsten Ziehm of the engineering team wrote a post titled: “Does 3.x have a general quality issue?”

Unless my mind is playing tricks on me, and I’m 98.2% sure it isn’t, Thorsten’s post was edited between when I first read it in the morning and when I decided to blog this afternoon. The edits seem to have removed any suggestion that OOo could have a quality issue. Even in the original version of the post Thorsten had concluded that OOo does not have a general quality issue. But in the original version he did discuss some information that could point to a quality issue. For instance, the original showed that the total bugs reports had grown to over 13 thousand, of which about 3 thousand were new feature requests. If memory serves me right, the defects and total numbers were much higher than previous releases. But with more OOo users, this increase did not point to a quality issue by itself.

Thorsten concludes that, while there may not be a general quality issue with OOo:

“We have to work still on stabilizing the existing functionality instead of concentrating on newer functionality only.”

This is a similar conclusion that Andre Schnabel comes to in his reply to Thorsten’s post (not sure if Andre’s reply was to version 1 or version 2 of Thorsten’s post).

“While one may argue (endless) if the product as a quality issue or not, the real point is, that the OOo project’s process of identifying, handling and finally fixing bugs is not really satisfying.”

Andre goes on to conclude that we can make OOo better:

“- joint and better coordinated efforts from QA and development to *fix* bugs
– the common goal of the project to work on bugfixing (instead of the separate statement of the QA project that fixing bugs is not within our responsibility)
– the commitment to fix bugs even in old features (and not only regressions). Each feature once was new. Following our current policy you just need to wait long enough to counter the regression argument.”

OOo is facing a difficult balancing act between fixing bugs and adding new features. Software developed using the traditional software business model often has a larger focus, emphasis on “larger”, not all, on their time on the latter. Who’s going to buy version 5.0 of a product that touts “stuff that you expected to work in version 4.0, now does”. But there is absolutely a focus on reducing the defect backlog. Who’s going to buy version 5.0 of a product when version 4.0 crashed all the time? Wait, hold off the Microsoft jokes :-)

The fact that OOo is facing the same issues, and the project is also spending more of its time on new features, vs. defects, is an interesting response to those that view OSS as a panacea. Both the OSS and traditional software business models can produce high quality software or trash. Producing high quality software starts with a focus on not just track, but systematically reducing defects. It’s good to see more talk about processes focused on reducing defects at OOo.