From time to time I read mails in OOo mailing lists or comments on blog entries ( as for my last one) that the Quality of OpenOffice.org is not good or it is not good enough. There should be many very critical issues still open, many users cannot work with that version since OOo 2.0 was released or the users do not want to be Beta tester for an incomplete version. I am sad about such feedback.

I work in the Quality Assurance team for StarOffice and OpenOffice.org since more than 11 years. I am convinced that the last versions of OpenOffice.org are the best version we every had. I know this huge project has still a mass of open issues, we still have not a medicine against regressions from one version to the next and some of the known bugs hinder some users to work with this product like working with other office suites from competitors. But in general the quality increase dramatically in the last years.

Why could I say this?
Many activities were initiated since OOo 2.0. One of the biggest wins was the integration of the crash reporter tooling in OpenOffice.org and StarOffice. With this tooling many critical crashes were identified quickly. The most critical and most reported crashes could be fixed in the next release/update ( some data I brought up in one blog ). Another hard work was to eliminate all compiler warnings from the code. All these warnings are hints for potential crashes or other critical issues. Until now the code isn't warning free in all cases, but with OOo 2.3 the developers will nearly finalize that project. ' Valgrind '-warning free code is another project. A run with Valgrind identifies additional errors in coding which could lead to buffer overflows or other critical issues. Some of the generated issues are fixed now, but this project is still in progress. Last but not least continuous code reviews are made by Sun developers. All other teams which contributed to OOo could find our accepted coding guidelines for C++ on OOo wiki.
These are activities to stabilize the product. In my daily work I notice this extremely. I didn't crash at working with released versions or developer snapshots in the past months.

Another point of quality is the usability of features and general functionality. The QA team and other teams brought in a wide front of tools and processes which should guarantee this high quality. First of all the Sun QA team run all automated tests with VCL TestTool on the Master builds for each supported platform by Sun (also the porting teams on OOo run these tests as well) and a set of test scripts run also on each CWS. Currently it is planned to integrate subsets of tests in a likely Tinderbox environment for each CWS ( here you can find more). Another powerful tool which is used is ConvWatch. It makes a bitmap comparison between saved/exported documents between different versions and identify formatting or file format errors quickly. Also performance tests for load and save run automatically. These are defined processes for Quality Assurance and these tools identify regressions more effectively before a QA member make a Quality Control and check all issues at a CWS or at last the feature integration in the Master build.

All these activities and many others more show me the correct way to increase the quality of the product or hold it stable on a high level. This can be seen also in the following graphs, where the incoming issues (filed in IssueTracker since OOo 2.0 was released) are listed. The reported issues, especially reported by community members, decrease over the time. Yes, you can say that there are not many new features integrated over the last months. But that isn't correct. There were integrated many new smaller features in the last minor releases. Also many general restructuring of code redesign were done, especially in the last release

Since August 2005 ~19.000 issues are reported in IssueTracker on OOo. Overall round about 80% of these issues are reported by the community outside Sun team. The number can be reduced a little bit, because not all of them are related to the product OpenOffice.org. Ca. 9% of these issues are submitted in components related to L10N teams, marketing, www, OOo environment etc.

The graph show that the numbers of incoming issues per month goes down by ~600 issues (highest period Oct.05-Jan.06 with ~1300 issues and latest period Jan.07-Apr.07 with ~700 issue). On the other side the download numbers (and hopefully the users) increase dramatically over the past years and also the reporter of issues are more and more. So the numbers say to me, that there aren't so many new issues in the product and that the quality from user perspective increased.

At this graph you can see, that most of the issues are closed. Overall ~30% of all issues are fixed/integrated in the last releases. 30% of all issues are not really bugs or they are duplicates (most are closed). 40% of the 19.000 issues are still open. But that's aren't all bugs. 15% of these issues are wishes for enhancements or features. When you also remind, that 9% of these issues aren't for OpenOffice.org as product, a number of less than 5.000 defects/bugs are open.

You are right, there are in sum round about 10.000 defects still open (current issue number in IssueTracker is near 78.000). They are not only the 5.000 from the past 2 years. If 5.000 or 10.000 is a high number, I do not want to decide. The number alone is high, but when you are working with OpenOffice.org 2.2 you will see, that it is for general work a product with a very high quality. Therefore in my opinion the number of 10.000 defects is not a high number.

I also know, that in these open issue (not only defects) are issues, which hinder somebody to work like he works with competitor products. Also there isn't every environment supported very well, so some business solutions aren't so smoothly to integrate as expected. As the last graphs show more and more older issues were and will be fixed. One point here is, that currently some restructuring and re-coding were and will be done (e.g. my favorite tables in Writer – one of my first bugs I found in StarOffice is fixed now after 11 years!).

All teams work very hard to make Quality Assurance for StarOffice and OpenOffice.org. OpenOffice.org isn't such feature reach as other product, but the quality in general is on a very high level. This is a good base for the next minor and major releases. If you do not know, OOo 3.0 will not start on a complete new code line. NO! OOo 2.x will the code line and the quality of this code line will be reflected in OOo 3.0.

So recommend StarOffice and/or OpenOffice.org and let make it more popular as it is. Perhaps then more teams will invest in this open source project and bring more resources on bug fixing and QA-ing.