Someone pointed me to the blog of Luis Villa. He reports some observations and opinions about OpenOffice.org and compares the way how we apparently treated the observed problems with what the Mozilla project did to solve them. I think that his view is somewhat “remote” and I want to add something from my side as an OpenOffice.org developer. Before I will get to the point please let my introduce myself. Knowing where I come from and what I'm doing can help you to judge my statements better.

My name is Mathias Bauer. I'm the project lead of the OpenOffice.org Application Framework and I'm also interested or involved in a lot of the other OOo projects. I work for Sun Microsystems and my job at Sun is to manage the teams for the application framework, Math and Writer.

Here's what I consider to be the basic messages from Luis (I hope I got it right):

• OpenOffice.org suffers from bad (startup) performance

• The OpenOffice.org GUI suffers from usability problems, especially the preferences dialog looks bloated

• OpenOffice.org lacks stability

• Similar problems where present in Mozilla, but Firefox solved them

• Firefox is light and quick and that's the main reason for its big success

• OpenOffice.org ignores these problems and instead only borrowed the “plugin“ concept from Firefox

I believe that we have done a lot to address the reported problems. You can see some proof for that wrt. startup performance below. We also improved the stability of OpenOffice.org a lot since the 2.0 release. I hope that we can talk about this on another day in GullFOSS. We still see these topics as some of our top priorities in development and continue to work on them.

My main concern is the comparison with Mozilla/Firefox. I see this as a classical apples and oranges comparison. I am an early adopter of Firefox since the very first versions of “Phoenix“ (its former name). I like it, but as a developer I have a very individual and technical based opinion about some of its peculiarities and also about the real reasons of its success.

Firefox is perceived as “lighter“ than the “bloated“ Mozilla application and this is seen as the main reason for its success. So the conclusion seems to be that OpenOffice.org should do the same to have the same success. But what exactly is “the same“? And what is “lighter”? I did a very simple test on my notebook (P4 mobile with 2 GHz, 512MB Ram, 30GB disk, Windows XP Pro). I compared the Firefox/Thunderbird combo with the last version the Mozilla Suite and Seamonkey, its successor. I measured startup times in “cold“ start (directly after reboot of the computer) and “warm“ start (average value of 5 restarts). I created a fresh profile, took a blank page for the home page and created an empty news account so that we should have the minimum and equal starting conditions. This is not a scientific treatment and the the results might look slightly different on slower hardware or other platforms. Anyway, it is understandable real life behavior and doesn't rely on fuzzy terms. Here are my results:

As you can see the “ warm“ start numbers aren't too different so we can leave them for now.

The OOo results show that we have achieved considerable startup time improvements in the last year. So it is fair to claim that the OOo development sees startup performance as a high priority issue. Of course there's still room for improvement and we are working on it. But is here something we can learn from Firefox? I don't want to take the numbers too exactly, but even then they don't show a big difference between Firefox and Thunderbird on one hand and Mozilla or Seamonkey on the other wrt. startup performance and memory footprint. I don't think that this is a problem at all, but on the other hand the Firefox success can't be derived from being a “light“ alternative based on startup performance.

But if it isn't startup performance, what else makes Firefox the “lighter“ alternative to Mozilla? And what can we learn from it?

IMHO Firefox just “ feels“ lighter. Finding out why it feels lighter is a long story (just counting e.g. menu items doesn't explain it), but I think the majority of users will agree that the UI design of Firefox is much more pleasing than that of Mozilla/Seamonkey. The most prominent example is the “Options“ dialog (“Preferences“ in Seamonkey) that has been cleaned up a lot in Firefox from its very beginning. Besides that most improvements in Firefox are mainly UI polishing. Most users prefer the new look (so do I), but Firefox does not create a new way to operate a browser (compared to Mozilla).

I agree that OpenOffice.org should take over the idea that making the GUI “feel“ lighter is a worthwhile goal. I warn against applying it too literally, that would be jumping to conclusions. I see two striking differences that both enhance the challenge for the UI designer:

• Simplifying the more complex UI of an office suite needs more than polishing: we have way more functionality, some of it is much more complex than the functions you have in a browser.

• Larger UI changes always bare the risk to make parts of the existing user base angry. We already have gained bad experience with UI simplifications we considered to be marginal changes. As an example, nearly every removal of something in the “Options“ dialog caused a public outcry and sometimes we had to withdraw the changes. The same problem existed for Firefox, they where lucky to solve it by having both versions in parallel for quite some time and now having a part of the developer community that still maintains the old GUI (Mozilla Suite until 1.7.13, now Seamonkey). I don't believe that we (the current OOo developers) can maintain two different UI sets for OpenOffice.org. The development and even more the QA effort would kill us!

We have done UI improvements in selected areas in the past and we will continue to do so, but every change has to be examined very carefully for the named reasons. So UI improvements in OpenOffice.org still will happen step by step and not in one “big bang” release. We are also supporting greater flexibility in the UI by working on modularization of the code base, documenting interfaces and helping developers. We work on all this amongst other things like fixing bugs, improving stability and performance, improving interoperability, looking for important features etc. Expect to read more about this and our progress in the past and future here in GullFOSS!

Finally some words about the “plugins” (we call them “extensions“) concept. We didn't take them from Firefox and it's nothing we just recently started to work on. Since its inception OpenOffice.org was designed to be extendable by UNO components. This goes back to StarOffice in 1998 or so and it was improved and refined over the years. The press roar about the “new“ extensions concept was created by a blog entry from our Native Languages Project lead Charles Schulz who slightly misunderstood something he heard at the OOoCon in Lyon and by some misunderstood comments from our community manager Louis Suarez-Potts. We didn't create a new concept for extensions, it's already there for quite some time. We are now providing better means and tools for creating and deploying them easier as there is a considerable demand for this. We comply with this demand as we want to lower the barrier for new developers. Creating extensions is much easier than working on the core code base and we think that we can attract more developers by making the start easier. The discussions on our developer mailing lists are a good proof for the correctness of this assumption: while only a few people bite the bullet and try core development a lot of people are utilizing our API to create their own solutions. So extensions are not only good for users (I wouldn't like Firefox and Thunderbird as I do now without e.g. adblock and mnenhy!) they also help in increasing our developer community.

It's amazing how much attention our “new“ extensions concept got, obviously we failed to deliver our message in the last years. So what he have learned from this and IMHO also from Firefox is that marketing is very important for success, even if the transported message isn't always technically exact. GullFOSS will be our way to work on the former without losing the latter.