Pick your own OOo, there must be one for you!

Short URL: http://fsmsh.com/2317


OpenOffice.org is probably the biggest free software project in existence today. It certainly is the biggest single piece of software one can download and compile in one go, with the core package hitting over the 100MB mark (while bzip’d) and the total sources going over 200MB.

It directly competes with Microsoft Office, is a bit more easy to install than KOffice, and is very complete.

But what will you get?

You don’t usually compile OpenOffice.org (OOo for short) yourself. The first reason: it’s HUGE: it needs 9GB of free disk space to compile successfully with default options. Second, it’s LONG—plan at least a day for the initial build if your system isn’t a powerhouse with a dozen gigabytes of RAM. And third, you probably already have a version compiled for your system.

I will explore the highly active OOo 2.x code line here; the older 1.1.x code line may work on older systems and many UNIXes (IRIX, AIX, Linux/Sparc), but it is too limited to remain interesting.


Supported ports

Right now the following operating systems have supported, native, recent versions:

  • Windows NT 5 (2000, XP, Vista)
  • GNU/Linux x86 (starting with kernel 2.2.16, glibc2 2.6 and X11R6)
  • Solaris 8 on SPARC or on x86
  • MacOS X 10.3.5 PowerPC and x86 with Apple’s X11 compatibility layer

The evolution from the original 2.0.0 version to the current 2.2.1rc version is a very good example of free software development at its best. While there was no real breathtaking options and features added, the suite has known an incredible progress stemming essentially from code cleanup and UI refining.

In fact, OOo has a dedicated project for usability, and another project dedicated to performance improvements.

As a matter of fact, the MacOS and x86-64 ports reaped most of the benefits from these cleanups, but the original Windows, GNU/Linux and Solaris ports also saw many refinements added:

  • OOo 2.0 was already much faster to load than 1.1.x; current 2.2.1rc is even faster, opening in only a few seconds, parsing files much faster, and is generally more nimble in most cases.
  • Stability is without common measure: nowadays, even the untested developer builds seldom crash; the highly efficient recovery wizard sees very little use, and works very well in those rare cases where you crash (or voluntary kill) your OOo session.
  • System resources are less taxed: reduced memory leaks, reduced memory footprint, lower CPU use never hurt.
  • Reliance upon a Java VM has steadily decreased; you used to need Sun’s JVM for OOo 2.0 to work correctly, now gcj 4.x (and others) works well enough and several effects that required Java before are now native, making OOo highly usable even without a JVM.

Moreover, so as to provide a better user experience, icon sets, toolbars, controls, print panels and file pickers more and more use the OS’s native elements over OOo’s integrated ones.

Partially working/third-party support/alpha stage ports

The following systems are known to have a working version of a recent OOo revision (2.2 at this time):

  • FreeBSD 5.3,6,7 on x86 and x86-64 (supported by the FreeBSD project) pretty much work
  • OpenBSD, with a few system settings can run the GNU/Linux x86 version as-is
  • GNU/Linux x86-64 is yet unsupported but actively developed by the OOo-build and Porting projects and is highly usable—when you can find a binary
  • MacOS X 10.3.9 PowerPC and x86 without X11 has reached pre-alpha stage; testers are required


OOo is probably most well-known for its numerous translations; listing them here would eat up a bit too much space, but you can read it here: OOo l10n matrix. It may be a bit outdated in how it reports localization completeness; however, it is complete.

Too bad, it seems the Klingon version is now abandoned...

Planned improvements


For a long time now, OOo has supported the execution of very simple Visual Basic for Applications (VBA) macros. This support is getting expanded now at a fast pace, directly supported by Sun, Novell, and the OOo project. It is still far from complete and requires extensive testing with real-world Excel documents (hint: send your macros!), but it is slowly getting there.

Interestingly, it may soon be the only way for Mac users to run VBA macros in OOXML files on their machines, as Microsoft Office 2008 will completely drop VBA in favor of AppleScript.

Another option which will soon reach fruition is the integration and improvement of the OOXML import/export module in “vanilla" OOo. The original Novell implementation was far from efficient, yet this time the OOo community may get it in just right. The difficulty here is, yet again, the scarcity of OOXML-based files on which to perform tests, on top of the completely different specifications for word processor files, spreadsheet files and presentation files—while ODF makes little difference between the three, sharing as much as is possible from one file type to the other.

A long time of suffering is about to end: those of you who like to extensively use graphs and charts will be happy to learn that a completely revamped charts module is finished and integrated in m213. This module fixes a truckload of charts bugs on top of providing better Excel charts imports and more charts options.

And last, a PDF import module is being evaluated. Don’t hold your breath though, PDF is notoriously difficult to import—just ask the guys of KOffice or of Ghostscript what they think about it...


While OOo is very well known for its very strong fonts metrics support and very good style management, the interface is limited: you can’t edit pages side by side or in a mosaics form, which would allow you to optimize screen space. Unfortunately, apart from a little change in default settings, this won’t change before version 3.0 due to some heavy work required on the core of OOo to make it work. Thus, it is planned, but it won’t come any time soon.

Known forks


One of the most notable forks is Novell’s, which extensively modified OOo 2.0.4 to include an OOXML word processor filter, a VBA compatibility module and a DataPilot editor. Those were unfortunately shoved in in a less than elegant fashion, and required long refactoring before OOo’s QA considered them good enough to include in the main line. Still, it is quite interesting to test, as it is available for both Novell’s openSUSE and for Windows.

Right now it is seen more as a testbed than as a real port, though, and most of these improvements have either been published in a release version of OOo, or are planned for the next version.

Planamesa’s NeoOffice

Another port, which is MUCH more controversial, is called NeoOffice. Started a few years ago, it aims at running OOo on MacOS X without the need for an X11 compatibility layer. The two developers decided on two things:

  • use Java as an interface layer between OOo and Aqua (which is a debatable design decision)
  • switch the code from LGPL to GPL, which prevents any backport of NeoOffice code into OOo

The latter decision was voluntary and aimed at preventing Sun from using their code under the SISSL license (at first, OOo was dual licensed; with the OOo 2.0 release, only the LGPL remains—which still allows Sun to redistribute StarOffice as a proprietary product, but which forces direct modification to OOo code LGPL too).

The controversy stems from the fact that not only do Patrick Luby and Edward Peterlin not allow their code to be back-ported to OOo, they seem to defend it rabidly when it can, and are keen to NOT contribute to the native OOo-Aqua port—to the ire of the OOo Mac porting team: don’t EVER mention NeoOffice to them, or they’ll (politely) bite your head off.

Brazil’s BrOffice.org

Originally a branded Portuguese port of OOo specific to Brazil, and government-sponsored.

The original “fork" served as support for a grammar checker, a thesaurus and an automated document generator. All were progressively merged into OOo, making it no different than mainline, apart from the branding.

Various GNU/Linux distributions

Mandriva maintains a rebranded OpenOffice version. It used to include a specific icon set and personalized splash/info graphics. Nowadays, most of the branding is gone. However, Mandriva now maintains a working 64-bit port (using gcj 64-bit for Java support), which is regularly updated, usually based on the most recent release CVS extract with some patches thrown in for good measure, in its “backports" repositories. The equivalent 32-bit version is available for x86-32 (and maybe PPC).

Debian provides various versions (1.1.3, 2.0.4, 2.2.1...) depending on architecture and stability.

For openSUSE, see Novell.

I couldn’t find anything specific in other distributions, which leads me to think that they don’t refactor OOo or don’t provide unsupported ports as much as those.


If you had previously dismissed OpenOffice.org because you found it too slow, too big, too buggy, or because it didn’t work on a Mac, then maybe it is time to reevaluate your opinion. It is a very powerful office productivity suite that you can use seamlessly on pretty much any system in pretty much any language.

It being free doesn’t hurt either, when compared with the competition...


Most ports and plugins can be monitored through the OOo wiki

The latest NeoOffice contribution to OOo-Aqua: Read the whole thread

First BrOffice/OOo meeting



SimonJ's picture
Submitted by SimonJ (not verified) on

Just wondering - how is it easier to install than koffice? I see no difference at all.

(I use both and happily accept that OOo is more complete than KOffice in terms of features, but just a bit puzzled by that comment)

Mitch Meyran's picture

Due to its past as an integrated office (and not a simple office suite) with file picker and all, OOo doesn't have too many packages requirements - making it 'easy' to install on pretty much any system with little external libs required.
On the other hand, Koffice is strongly integrated into KDE. It has heavy requirements, as in it requires all KDE base files and several supplemental packages. Installing Koffice requires pretty much all of KDE to be installed, which is not too difficult (and even quite easy and painless if your distro's dependencies are well maintained) on GNU/Linux, BSD or Solaris, but is a pain on Mac OS X and almost impossible on Windows.
A computer is like air conditioning: it becomes useless when you open windows.

Andrew Min's picture

You should also note that there are KDE bindings for OpenOffice.org. At least for (K)Ubuntu available here

Andrew Min

EpsDel's picture
Submitted by EpsDel (not verified) on

The biggest Open Source project in existence is Linux itself, in all its flavors.
I'm disappointed with OpenOffice. The quality difference between the Linux version versus
the Windows one is big. In win's favor.

Mitch Meyran's picture

Linux, as in the kernel (since the complete GNU/Linux isn't a single project with a single community) is roughly... a fourth of the size of OpenOffice.org.
As to the quality difference between the Windows and the Linux version, well, I've compared the two side by side:
they're absolutely identical. In fact the Linux version has an advantage in speed (much faster to load) and in UI (selects the icon set most appropriate for your environment, uses system's default font for UI, autodetects language settings) on top of being able to use any version of Java you have (I'm happily using gcj with it).
A computer is like air conditioning: it becomes useless when you open windows.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I've been using OOo for 3 years now. I guess you could say I was one of the eary adopters. I keep a running log on my desktop on OpenOffice.org's bugs and it is lengthy:

* OpenOffice.org's spell-checker is simply terrible. It recommends breaking up words. Just yesterday I spelled comma as coma and it accepted the spelling.
* I worked w/ OpenOffice Base for about 300 hrs and find it terrrible. Simple things can not be done. You can't reorder fields in your database. So if you use a field to the far right often you have to tab over each time you need to make an entry waisting time. It doesn't support drag'n drop. The best thing I can say about it is it interfaces to so many databases.
* In Open Office.org Writer
* I get a pulsing screen when I open large documents almost to the verge of crashing the application. I find you have to keep your documents to 35 pages or less to avoid it. Also some of my 100 page documents take forever to load and I have 500MB of RAM and a Duron 900 CPU
* OpenOffice.org's cut and paste from Firefox to an OpenOffice.org document requires time to warm up on some web pages before it can be used. I finally figured out a workaround: Cut with the mouse and paste with Ctrl+V.
* OpenOffice.org's cut and paste feature (while using the KDE Desktop in Ubuntu (not Kubuntu)) captures a few characters before what I want to cut from a web page and paste a few less characters than I intended when I insert it in an OpenOffic.org doc.
*periodically artifacts show up on the screen after doing a cut operation and do not go away unless you close and reopen the doc.
* Up until the last dot release the application crashed a lot although it generally recovered everything.
* It's possible to open two instances of the same document at once if you click too often.
* The scroll bar in the document jumps up a page or two each time an embedded Google ad is passed in a document.

I could go on but I will save you the time.

Why do I continue to use it?
* It has great large document features especially indexing and table of contents and I am writing a book/technical manual.
* PDF creation is a snap and importing has been fine.
* It's free.

To finish-up the OpenOffice.org team should stop and fix the bugs. Once they do they will have a nice product. I think your article was a little too much marketing.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

OpenOffice.org's spell-checker is simply terrible. It recommends breaking up words. Just yesterday I spelled comma as coma and it accepted the spelling.

It is a "spell checker" not a "semantic checker". Coma is a real word meaning to be in a narcoleptic state. Any spell checker will accept coma as correct.

OpenOffice.org's cut and paste from Firefox to an OpenOffice.org document requires time to warm up on some web pages before it can be used.

It works fine both from the X clipboard and the Freedesktop clipboard in Gnome on Ubuntu for me, maybe you have a KDE problem again.

Daniel Escasa's picture

...then put them together using a master document. That's not a work-around, it's smart use of an available feature that you should really use for large docs anyways.

Daniel O. Escasa
IT consultant and writer for hire
contributor, Free Software Magazine (http://www.freesoftwaremagazine.com)
personal blog at http://descasa.i.ph

Mitch Meyran's picture

Thanks for your input. I'm a bit puzzled by your comment though:

  • breaking up words: have you installed the thesaurus? Coma is a valid noun too - there are NO semantic checker in MS Office either, so be careful with homonyms. Any spell checker worth its salt will do the same.
  • Base is a very young component still. However, I should mention that in NO database qualifying for the name will let you reorder the content of a table! You may reorder the output of a selection, but not the content - SELECT * FROM Table ORDER BY (column to sort); - if you want to sort the contents of the actual file, then it's not Base you need, it's Calc.
  • About Writer requiring time to load large documents: I wrote my 450 pages thesis on OOo. Yup, as I said (and as you said) it's slow to load. However it doesn't crash while loading (MS Office choked on the same document, around page 130, and THEN corrupted the file attempting to recover it)
  • your cut and paste troubles and artifacts are strange - I have yet to find anything similar on all the versions and systems I've tried it on. On the other hand, I don't use KDE; the fault may lie in KDE's hand.
  • OOo 2.2.0 is known for having a few bugs - that version was probably the biggest overhaul of the code base with the largest amount of commits at the last moment ever since 2.0.0. 2.2.1 will solve that really soon (rc2 is out).
  • Opening several instances of a document in such a case is normal - don't click too fast. It also is useful when you want to compare a document you're editing to its last known good state without activating modifications monitoring.
  • Google ads contain a lot of code - and OOo knows how to interprete HTML properly, so you may want to paste your text without formatting.

A computer is like air conditioning: it becomes useless when you open windows.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Correct in all regards. Much loved curate's egg containing many hardy perennial bugs and hair-pulling inadequacies that survive upgrade after upgrade. Needs a serious clean-up. If I could code, I'd sort some of them myself.

Mitch Meyran's picture

...to help solve bugs. What you can do is vote for them to be fixed, write complete specifications with screen mockups (for requested improvements), write testing procedures to detect bugs, etc.
If all you do is complain, then stay with your M$ Office: after all, they don't listen to you complaining and don't ask you for input.
A computer is like air conditioning: it becomes useless when you open windows.

Ryan Cartwright's picture

Just yesterday I spelled comma as coma and it accepted the spelling.
Oh dear. At least the British dictionary rejects "liase" - unlike MS did for years. You might like to read this..
There's a useful poem on it to try.

* OpenOffice.org's cut and paste from Firefox to an OpenOffice.org document requires time to warm up on some web pages before it can be used. I finally figured out a workaround: Cut with the mouse and paste with Ctrl+V.

Not sure what you mean by "warm up" but I'm pretty sure it won't be OOo's fault. I've noticed a few times that Firefox doesn't always use Klipper as one would expect. It may be this that is causing the issue.

* OpenOffice.org's cut and paste feature (while using the KDE Desktop in Ubuntu (not Kubuntu)) captures a few characters before what I want to cut from a web page and paste a few less characters than I intended when I insert it in an OpenOffic.org doc.

Never encountered this running KDE (3.5) on Debian. You mention cutting from a web-page (by which I take it you mean "copying") which implies the issue is again related to your Firefox/KDE interaction than anything particularly wrong with OOo (or Firefox or KDE for that matter).

That said if you *do* mean *cut* and paste (e.g. Ctrl-X) then that's your problem. Attempting to cut some text from a web-page (not within a form control) will usually result in nothing being passed to the clipboard.

Yes you can open two copies of the same file but the second one will be read-only.

Finally you don't mention if during your 3 years of use you've fed any of this back to the developers. If not it might be an idea - it's how end-users become a bigger part of the community.


Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

You can always pay the msoffice licence (Or you can have some vacations!)

For me, and I'm a "young" OO user,
it works more than fine for the price.
Obviously that it could have some extra features. I'm sure they will come with time...

Best regards,

Basia's picture
Submitted by Basia (not verified) on

After upgrade from OO 1.x to 2.x together with standard Stable Debian upgrade from Sarge to Etch, regret, the same documents, containing some graphics open much slowler. They almost hang OOWriter. 20 pages document allow me to make tea and start drinking it before starting work. Life...?

Mitch Meyran's picture

Debian Stable contains an earlier version of OOo. Due to the change in default file format in 2.x, file converters and filters had to be shaken around a lot - and usually, performance was forgotten to ensure compatibility; and, indeed, many files opened slower under earlier versions of OOo 2.0.x in all apps.
Several optimizations were made, leading to some eye-popping gains: Excel files that required 1h10min to open previously suddenly opened in less than 40 seconds.
Now, you may have hit another performance snag: you can download a more recent version of OOo (either Debian unstable/Testing versions, or OOo's .deb package), and test your file again: if it's still as slow, I encourage you STRONGLY to report it (and send a version of the file) to the developers: this way, they may just fix the problem for the next release or the release after.
A computer is like air conditioning: it becomes useless when you open windows.

M Petersen's picture
Submitted by M Petersen (not verified) on

Lately the press has been bashing Novell left and right (justified, maybe - maybe not), but to somewhat bash their "fork??" like this is just mis-informing the public. With Sun's version of OOo it has been very difficult to get third-party patches in and has been hard for newer developers to get involved. Becasue of this, Novell took the code and incorporated it into ooo-build @ http://go-oo.org/.

Now, most GNU/Linux Distributions use ooo-build to generate the version of OpenOffice.org into their OS (including Debian, Mandriva, Ubuntu, etc.). To say that all of these features have been incorporated in a less than elegant fashion and because of this Sun has not incorporated the changes into the main branch is just plain wrong. To get the real story on Novell's (actually the community's) version check out an interview with Michael Meeks at http://www.tuxdeluxe.org/node/184

Mitch Meyran's picture

ooo-build was a project started a few years ago because it was, indeed, hard to include 3rd-party patches into Sun's main CVS. However, this has changed: ooo-build is now a test-ground of sorts for the biggest projects out there, but it has reached its goal: it is now MUCH faster to integrate 3rd-party code into mainline - ask those guys working on the AMD64 and the OS X Aqua build.
Now, I think the ooo-build project was Novell's doing is a bit... exaggerated. Moreover, you can't base yourself only on what MM says: he's not alone. You can ask Pavel Janik, Eric Bachard, Sophie Gautier, and some others for more informations.
A problem with QA is that, indeed, they ask for lots of specs - as it should be. Moreover, the build test tools, smoke tests and automated tests have been long outdated, but they have recently been improved, and most 'new' developers now enjoy the CWS system - which has been improved and better defined - as such, QA is getting a bit more responsive, while developer snapshots just work.
As it stands, Novell is working hand in hand with Sun to integrate their improvements with OOo's mainline in a 'proper' fashion - as in, following the OOo project's architecture, code formatting and QA guidelines. It results in a more gradual but much more robust and future-proof integration of Novell's improvements into OOo - otherwise, why would have Novell not kept including their patches in more recent versions of OOo? We're now almost at 2.3 on mainline, and Novell's version is still 2.0.4. Why? Because several of their improvements have been refined and integrated gradually in OOo's structure - while existing OOo subsystems have been modified and made more modular. In essence, this is what MM is saying.
I'm not bashing Novell's build; on the contrary, it was a very nice and well polished first implementation of VBA and OOXML under OOo, but a project the size of OOo requires strict code submission guidelines otherwise you get... Microsoft Office 2000 (required SP3 to be made usable, and 3 years of extra development on a frozen code base to work).
As for the distros using ooo-build, it was true in 2005 - but since then, since ooo-build has been integrated in the main OOo development group of projects (or to be fair, became the standard structure of any and all new OOo development projects), it's not true anymore. For example, I have the latest ooo version (in 64-bit) provided by Mandriva, and it's tagged 2.2.0cvs20070323. Previous was 2.1.7cvs, and from development notes matched against OOo bug reports, it looked a lot like a 'vanilla' 2.1.0 build with some extra CWS integrated. A glorified development snapshot, if you want.
A computer is like air conditioning: it becomes useless when you open windows.

Author information

Mitch Meyran's picture


Have you ever fixed a computer with a hammer, glue and a soldering iron? Why not? It's fun!