OpenOffice.org priority on adding new features vs. fixing bugs

OpenOffice.org developers agree that a renewed focus on fixing bugs is required

Sun's Thorsten Ziehm of the OpenOffice.org engineering team wrote a post titled "Does OpenOffice.org 3.x have a general quality issue?"

Unless my mind is playing tricks on me, and I'm 98.2 percent 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 OpenOffice.org could have a quality issue. Even in the original version of the post Thorsten had concluded that OpenOffice.org does not have a general quality issue.

[ Keep up with the latest open source news with InfoWorld's open source newsletter and topic center. ]

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,000, of which about 3,000 were new feature requests. If memory serves me right, the defects and total numbers were much higher than previous releases. But with more OpenOffice.org users, this increase did not point to a quality issue by itself.

Thorsten concludes that there may not be a general quality issue with OpenOffice.org, but other goals remain:

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 OpenOffice.org 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.

OpenOffice.org 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. 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 OpenOffice.org is facing the same issues and the project is spending more of its time on new features versus defects is an interesting response to those that view open source software as a panacea. Both the open source software 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 OpenOffice.org.

Follow me on Twitter at: SavioRodrigues

p.s.: I should state: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions."

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies