I fancy myself an equal opportunity offender, policing all technology companies and individuals that would try to co-opt Open Source for their own nefarious means. And although I’d like to pick on someone else for a change, Sun gives me way too much good material — they just keep it coming.
By the time you read this, OpenOffice.org 2.0 (and Sun’s commercial version, StarOffice 8) will have been released and made its way into any number of Linux distributions. 2.0 is a major milestone for the project, as it includes a vast number of new features that really prove that the software is ready for prime time as a business-worthy office productivity suite. The project developers and Sun deserve immense praise for their hard work and commitment to producing such a highly polished product. Because of them, we’re a lot closer to being freed from the vicious biannual Microsoft Office upgrade cycle. My wallet and my heavily worn credit cards thank them for it. Mazel Tov!
So what’s not to like? Well, at the time of this writing, a number of industry observers and Open Source leaders have taken issue with the fact that a lot of 2.0’s new features require a Java Virtual Machine (JVM). Now, this is nothing new, as there already was some Java integration in OpenOffice.org 1.x, although it only affected a very small percentage of the feature set, and the software could be compiled without any Java dependencies at all. Apparently, even under 2.0, you still can build the software without Java, but you won’t be able to use the new database application, the integrated media player, mail merges, or document wizards.
Java, as we know, is not released under an Open Source license, and while any end-user can currently download the latest Sun JVM and use it without any restrictions, Linux distributions must actually license a JVM to package it with their products. However, very few distros actually bother to do this, and the ones that do are usually the more expensive “Server” versions, where the licensing costs on passed on to you.
To minimize this exposure, both Novell and Red Hat have formed strategic relationships with IBM to get better pricing and access to the IBM J2SE JVM.
And for its community distro, Fedora, Red Hat chose to use an Open Source implementation of Java, GCJ, which is part of the GCC compiler suite. Unfortunately, both IBM’s and GCC’s Java virtual machines are not fully compliant with Sun’s latest Java 5.0 J2SE implementation — and guess which Java works the best with OpenOffice? Yup, you guessed it: Sun’s.
So, what should be done to keep the world safe from more and more Sun Java VM? Well, the OpenOffice project could fork itself and continue development in a Java-free version, but I find forking to be divisive and destructive. Forking forces political alignment that can stunt progress and adoption. (However, in certain instances, forking has been effective or even necessary, such as with Xfree86 and X.org, so perhaps that’s not out of the question.) Another option would be for a major vendor, such as Novell or IBM, to put major development resources into an Open Source Java VM, such as GCJ, Kaffee, or Blackdown, but then constant feature creep and Java VM certification against the Sun gold standard will always be an issue. And we certainly can’t ask Sun to GPL or LGPL Java, because we know exactly where Sun stands on that.
I think that the best way we can keep the OpenOffice.org project and their Java-dependencies in check is to make sure there are good alternatives to OpenOffice.org, so that all our hopes aren’t in one basket.
The KDE office suite, KOffice, is making some nice progress, and now that both the Windows and Macintosh versions of Qt have been released under the GPL, we could see KOffice challenge OpenOffice as the predominant Open Source office suite on all the major platforms, especially should a major player such as Red Hat, Novell, IBM, or Oracle come in to give it major mentoring and support. I think we can agree that it’s really not in Red Hat or Novell’s (and even IBM’s) interest to make themselves dependent on technology that is (for the most part) engineered within Sun, even as good as OpenOffice is. And certainly, AbiWord and Gnumeric are nothing to scoff at, although those projects have lagged behind OpenOffice in features and updates considerably in recent years.
But what I’d really like to see is IBM, Novell, and Red Hat, along with a consortium of other vendors such as Corel (which became totally irrelevant since Xandros was spun off) to assume leadership and produce their own standardized Open Source office suite, perhaps leveraging stuff that’s already out there but underutilized or discarded, such as all that Lotus SmartSuite code that IBM has lying around collecting dust (Yeah, I know there’s a fairly new release of it out, but who’s buying it?) Couldn’t a good portion of that be opened up to the community, even if the code isn’t currently usable? Can’t IBM just do the same thing Sun does with StarOffice and Openoffice? One version with paid technical support and commercially licensed doo-dads, and another version for the community? Heck, given that Microsoft Office runs as well as it does under Codeweavers’ Crossover Office, couldn’t we start out by tweaking the Win32 version of the Lotus SmartSuite code to run well under WINE, paving the way for an eventual, full-blown Qt or GTK port down the road?
Choice is good.
If you want to recommend a company or individual for Jason Perlow to pick on next, send him email at
class="emailaddress">firstname.lastname@example.org. Jason Perlow is an equal opportunity offender.