June 29, 2009

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.

additional resources
White Paper - How to Improve Delivery of Advanced Web Applications

White Paper

Virtual Workforce: The Key to Expanding The Business While Cutting Costs

Get the independent advice and expertise you need to support a virtual workforce.

Go inside:
The three-step approach to making a virtual workforce a reality.
The four flavors of client virtualization technologies.
The three key initiatives that solve IT challenges.
Download now »
White Paper: Successfully Secure Your Wireless LAN With Wi-Fi firewalls.

White Paper

Addressing Linux Threats Leveraging Fewer Resources

The increase in Linux popularity has increased the frequency and sophistication of malware attacks. Read this 2 page white paper now to learn how you can protect your Linux environment with real-time protection that is certified by all major Linux vendors.

Download now »
White Paper - The 2009 Handbook of Application Delivery

White Paper

The 2009 Handbook of Application Delivery

Ensuring acceptable application delivery will become even more difficult over the next few years. As a result, IT organizations need to ensure that the approach that they take to resolving the current application delivery challenges can scale to support the emerging challenges. This handbook elaborates on the key tasks associated with planning, optimization, management and control and provides decision criteria to help IT organizations choose appropriate solutions.

Download now »
White Paper - Is Your Backup System Outdated?

White Paper

Mid-range Storage Considerations

A common misconception is that mid-range storage requirements are dramatically different than that of a larger enterprise. Mid-range storage users may require less capacity, but they have similar functionality and management requirements. This ESG paper examines mid-range storage needs and reviews a new solution that adjusts size while retaining value, performance and functionality.

Download now »
BigRonG 2-Jul-09 5:04am
This column highlights a question that I have had about the 'open source' community. In my 3 decades of programming/managing, I have noticed that programmers tend to fall into two camps - development and maintenance. By job necessity, almost all have to do maintenance part of the time. However, there seems to be a subset that prefer development (almost to the point of being unemployable). I have wondered if the majority (if not the totality) of 'open source' programmers fall into the development branch. The idea of solving the same problem in a new way or creating a new solution to an existing situation is so attractive that it attracts the entire attention of the community. It is the above trait that characterized the MS programmer base in the early days IMHO and eventually lead to the 'bloat' issue in features. It takes a different mindset to pry open the nasty underbelly of the beast and dig through 'dead' code to fix it. It takes the strength of mind not to 'fix' that code by rewriting it to improve it but simply to correct the non-functioning piece. (Improving code is another way to add bugs that weren't there before.) I hold 'maintenance' programmers in a respectful place in my world. They are just as rare as a truely good development programmer.

Sign up to receive InfoWorld Resource Alerts

Subscribe to the Today's Headlines: First Look Newsletter

Find out what will be news for the day, with our first-thing-in-the-morning briefing.

©1994-2010 Infoworld, Inc.