The dirge of NeoOffice

Before we really get into this post on NeoOffice and OpenOffice.org, I need to give a little background, because:

  1. The following email exchange won't make any sense without it.

  2. There's been rumblings about what's been going on in bits of pieces around, but it's more confusing than clarifying for many.

This is something I've been sitting on, primarily because I wanted to see what was going to happen with it over the last week, and I've been trying to get something else out the door, but then I saw enough weird commentary floating around that it's worth getting out there.

I'm going to be working in reverse, which means we'll start out with the heavy stuff for those who are up to speed on what's going on, then break it down -- to the best of my knowledge -- for those who have just seen bits and pieces...

Swinging slings

On October 22nd, I checked my mail at an airport terminal before hopping on a train, on my way away from the talk, and had the following email waiting for me. This was a reply to an email sent to Ed Peterlin of the NeoOffice/J project, telling them:

  • Who has taken over the OOo x11 build, as well as co-leading the porting project.

  • That in order to better promote the OOo 2.0 x11 build, they'd like to relocate mention of NeoOffice/J to a separate "derived projects" page. Currently, when you go to download, you see both the x11 build and the NeoOffice build side-by-side.

  • Who would be taking over ownership of the pages.

I'm not including that original email for a variety of reasons, but here is a somewhat sanitized version of the reply, and who it went out to:

To: Louis Suarez-Potts < x@gmail.com >, "eric.bachard" < x@free.fr > Cc: Patrick Luby < x@planamesa.com >, Eric Hoch < x@gmx.de >, drunkenbatman < x@drunkenbatman.com >, Simon Phipps < x@Sun.COM >, jis xSun.COM, Tim Bray < x@Sun.COM >, David Pogue < x@pogueman.com >

Subject: Re: updating mac os x x11 pages

The original goal we had last year was to devise a combined download page which presents the raw facts of both projects. The objective was to prevent people from "discovering" one or the other of these projects as a Macintosh cure-all (which was frequently the case on the various user and development lists). Unlike other OpenOffice.org supported platforms, a viable fork does exist for Mac OS X which is not directly supported by Sun Microsystems. Different users on the Mac platform may have different needs.

The existing download page provides a side-by-side comparison of the two major ports and is intended to allow users to choose which one better matches their requirements. The OpenOffice.org download page has always been set up to emphasize that the X11 port is more in conjunction with the mainline release on other platforms. For the online forums I host of my own pocket, X11 gets top billing as has been since I first put the server online. I do not see how work on the 2.0 X11 release should change this arrangement.

If you, Eric, CollabNet, and Sun Microsystems have a strong desire to relegate the NeoOffice project to a footnote and exorcise any mention of us from the OpenOffice.org site it is your prerogative as OpenOffice.org is but a corporate-sponsored front. No official entities entered into any legal agreement to provide concurrent mention of our separate products, so any unilateral modification is perfectly sound. I have no intention of using my community OOo commit privileges to instigate a "war" of differing viewpoints.

In the end it will be only end-users who suffer from this withholding of information. The OOo/Sun vaporware Cocoa port announcement has already dried up nearly all donation momentum from the NeoOffice project. This has severely hindered our ability to continue to have a full time volunteer engineer devoted to development. We do not even have funds to enter into arrangements to gain official access to a DTK.

This lack of funds precipitated directly by your actions restricts our ability to achieve compatibility with the Mac-on-Intel platform as well as all thoughts of future OOo 2.0 development. This may very well be the first nail in the coffin of our project.

I wish you and your corporate agenda all the best in your battle against us few from around the world who selflessly donate thousands of hours and thousands of dollars to make software freely available for all. Your cause is a noble one that I'm sure people will remember for years to come.

ed

If one had had a mind, one could backtrack chronologically through the smattering of blog posts out there and line them up with when this email went out, and if you did I wouldn't blame you if you were left with a raised eyebrow and some amusement.

Depressing stuff if you've followed what's been going on, and Ed is having to play a dangerous game to keep his project from getting crushed between interests that sometimes align with his work, yet sometimes threaten to diverge and cut off its oxygen. Now, if you haven't been following what's going on, it's worthing laying out some of the history -- as I know it -- so you're up to speed...

OpenOffice.org

There used to be an office productivity suite known as StarOffice, which was a goofy name but made sense when you realized it was developed by a company named StarDivision.

Sun purchased the product in late 1999, and then open sourced most of the code about a year later in 2000, and dubbed it OpenOffice. Unfortunately, it turned out that someone owned the trademark to "OpenOffice", so its technically referred to as OpenOffice.org or OOo, but most people ignore that and just call it OpenOffice.

Now, StarOffice didn't go away. People contribute code to the OpenOffice project (including Sun employees), and once its reached a certain level, Sun branches off the code and adds in some special proprietary seasonings to create the next version of StarOffice: fonts, templates, a database, various filters for importing other formats, a different spell-check system, etc. StarOffice then gets sold under more than one name, on more than one platform, sometimes via subscription model in tandem with their other offerings.

The whole deal is highly reminiscent of how AOL creates their Netscape suite, and gives Sun traction in areas they otherwise wouldn't if they weren't able to provide a credible answer to Microsoft's Office because, you know, people actually do need to do Office stuff. It's really hard to get a company to buy into say, Sun's linux distro or thin-client stuff if they can't open spreadsheets. Because it's OSS, all the other linux distros (or Windows, or FreeBSD, etc.) can include OOo (which isn't their only option), but the fact that OOo isn't an exclusive benefit Sun can offer is offset by:

  • They're able to shift some of the development costs off their neck.

  • Anyone not using Microsoft Office is a win for Sun, on any platform.

On the whole it works out well for Sun, or at least they think it does, and we need to be clear about the works out well for Sun part, because while there is nothing wrong with that, it's one of the primary reasons we're headed for a clusterfuck when it comes to the Mac.

Any color you want...

The OpenOffice project has a lot going for it. It's free, which is always a big deal when it comes to adoption, and it's feature-rich. You can generally do anything you'd need to with it, and did I mention it's free?

It's not perfect -- it's got a lot of crud and such built up over time, and it's not going to win any usability awards, but it's still a big deal. I.E., I knew a couple in South America who was setting up a community computer lab, so people who couldn't afford computers in their home could go there and email relatives, do homework, receive training, etc. You're looking at the cost of the hardware and the operating system, and then the third-party software. In this case, unless they were able to find major discounts, a copy of Microsoft Office would cost the same or more than what they were paying for each computer.

There would have been other options if they'd been looking at a full-Linux solution (whatup, KOffice and Gnome Office), but for a variety of reasons (not the least of which was some donated educational software for kids and training issues) being able to throw OOo on the computers saved them a ton of cash and let them have six computers instead of two. OSS productivity suites are a big deal.

Unless, of course, you're using a Mac.

...So long as its black

Something Mac users often don't take into account is that if buying a Mac is even on your radar, you're probably either doing alright in terms of disposable income or, if you aren't doing alright, have priorities way out of whack with those sharing your bracket.

It's a premium commodity -- a luxury premium item -- and you buy it because you can afford to buy it instead of a Dell for half the cost. Also, outside of some content creation areas -- especially film -- it's become heavily focused around the consumer, specifically consumers who place a high value on aesthetics. There's nothing wrong with it, but there are always tradeoffs, and it's always been really, really hard to make the case for a concerted effort for OOo on the Mac that they'd actually accept, yet the Mac base doesn't align well with Sun's traditional goals.

Windows was a no-brainer -- you want to be a player and present yourself as a viable option, you have to be on Windows. Linux and FreeBSD and such worked out fairly well too, via the x11 version. Sun is selling their own Linux solutions, as well as Solaris on some desktop-thingies, and due to the way Linux desktops work, with some tweaking a viable x11 version plugs into all of them well enough, and normally enough.

This isn't the case with Mac OS X, which doesn't build on x11 and instead uses its own graphical subsystem -- Quartz -- which you plugin into via Apple's APIs. This is a major stumbling block (and the Cocoa APIs in general, GNUStep notwithstanding) when getting Unix apps with a GUI onto the Mac, and vice versa. They do have an X11 environment ported to OS X, which Apple has tied to Quartz for a degree of acceleration, but it's native only in the sense of not being emulated.

An x11 app sticks out in a major way on OS X, although if you are coming to the Mac from looking to use unix scientific apps, it's doable and generally works well enough, but you really have to know what you want to be using and be willing to work within its limitations. This, unfortunately, excludes most consumers, who aren't even aware of the x11 environment, excepting a few here and there who downloaded a Gimp package, fired it up, and then forgot about it. They might get x11 OOo up and running, and be happy they can do some things, and then they might end up in font hell, among other things.

The need for native

Productivity suites -- pound for pound -- are in the running for the most complex code bases on any platform. Microsoft's Mac Business Unit certainly doesn't get enough credit for getting their stuff over to OS X on day one, let alone when x86 Macs ship, and you have to keep in mind:

  • While you may not need to make use of a lot of their features, a productivity suite does a hell of a lot of things, which comes from a hell of a lot of code. In OOo's case, we're talking a word processor, a spreadsheet app, a presentation app, a drawing app, a database app, an equation editor, and more depending on your platform.

  • The need for productivity software (word processing, spreadsheets, databases, presentations) has been around forever, and you don't build a productivity suite overnight. These code bases go back a long, long way.

StarOffice was originally cross-platform through a proprietary C++ library, and it does a hell of a lot of things internally rather than using platform-specific APIs. Strategies for how to handle cross-platform development always seem to snap back between different poles over time, but at the time it was created, the idea was to do as much as you possibly could within the app itself so you weren't bogged down by a bunch of platform-specific junk. As times goes on, this can be problematic, because what you're competing against may be doing everything it can to leverage platform-specific features.

I.E., you may have a built-in spellchecker that works on all the platforms, but Mac users want it to use the system-wide spellchecker so it picks up the words they've already added. They knocked over a lot of pins with the x11 version, but that still left Windows and Mac OS X. Whatever Sun did, it had to have a native version for Windows that wasn't all weird and whacked out, and they did put a ton of effort into making that happen. It's not perfect, and you're not going to sing along while using it, but it's native and it works.

And then there's the Mac.

Devil you know

Sun actually looked at porting StarOffice to the Mac, which meant OOo on the Mac, and met with some fairly disastrous results. For all intents and purposes this was a horror show.

At the time, Sun was really trying to get some traction for StarOffice, and was getting none. Anywhere. When they announced they were all hot on OS X, I don't think they were able to get one major PC maker to jump on board and bundle it. They really liked the idea of Apple bundling a native-ish version (using Java) with their machines.

Imagine if you would, getting Office X to OS X without the Carbon APIs, and you can have an idea. The OOo code base expected a hell of a lot of things to work a certain way, and included a hell of a lot of things, and matching those up to how OS X expected things to work was a scenario leading to a rubber room. This isn't an accurate analogy, but it gets you mentally close to what they were having to deal with.

It died, and it died hard.

The x11 port stayed around, but even that was a struggle because no matter what some Unix guys say at first glance, OS X likes to do some things differently. Take a handful of guys and throw them several hundred megabytes of code on a System where you can't change a few makefiles and recompile, and you are going to feel the burn. It also didn't get much love, as you had the distinct impression Sun wasn't interested in throwing many resources towards its development, and was hoping Apple would be interested enough to pony up some cash to help it happen -- and this all was excacerbated by the fact that they needed people who could deal (read -- make sense of) with OOo's code base as knowing the ins-and-outs of OS X.

Those people don't grow on trees, and throughout it all, Sun burned about as much karma as you can get by, you know, saying things were coming and being worked on, and then several years later having it come out that they hadn't been touching it much at all.

NeoOffice

Two guys associated with the OS X port of StarOffice and OpenOffice, Edward Peterlin and Patrick Luby, took what they'd learned and decided to roll their own, and dubbed it Neolithic Office. Back when a native port was in the works, there were two strategies for getting it up and running:

  • NeoOffice/J
    The idea here was to internally map what OOo was doing to what OS X expected via Java. This was "supposed" to be sort of a stop-gap while the real port took place.

  • NeoOffice/C
    The idea here was to do what NeoOffice/J was doing, but using Cocoa. It'd be faster, more efficient, and feel native.

The Cocoa version of NeoOffice/C was DOA, and couldn't be run for more than a few minutes before crashing, and that was if they were able to get it launched at all. Ed and Patrick decided to focus their efforts on the Java version (which, just to be clear, only used Java for a very small amount of the code) and ended up getting NeoOffice/J out the door.

This is the only working and viable native port of OOo for the Mac, and it was -- for all intents and purposes -- done by two guys over several thousand hours. It's not perfect, and is a continual work in progress. Just launching it will show you this is an app with a non-Mac pedigree -- it's obvious where it comes from and what is is. However, it uses native OS X printing, the System's fonts, and it has a menu bar.

While it's not perfect, and arguably at a stage where only a mother could love it, it is still a remarkable effort. Adjectives can get thrown around to make things interesting to read, but remarkable is really warranted here, and it's why I first came into contact with Patrick. These guys have dropped huge amounts of time into a project that may not be acceptable by Mac standards, but is remarkable for existing at all -- and it's in serious, serious trouble.

Into the rough

NeoOffice/J exists outside of OpenOffice.org -- it isn't counted among their projects, but it is entirely dependent upon it, sharing 98-99% of its code base with the Mac OS X x11 port of OpenOffice. Because of this, it was always going to lag behind the x11 port a bit, and all the others on other platforms.

To make matters more complicated, licensing issues presented themselves. Originally, Sun muddied the waters in a big way by having two licenses for the projects: Sun Industry Standards Source License (SISSL), and the LGPL. Around a month ago, Sun decided to retire the SISSL for OOo and make it entirely LGPL, but to put it bluntly they'd made enough weird decisions and sidesteps that they were wigging people out, and strange things started squeezing out in the sides.

A directly applicable example is that NeoOffice is GPL, yet dependent upon OOo, which is LGPL. Search the site for LGPL for a better explanation, but suffice to say the OOo guys can't just go and use NeoOffice code in their project even though they're directly related. This in many ways has complicated the relationship between the teams, but it's understandable -- you have a few guys who felt abandoned, then put their blood and sweat into pulling off a hat trick, and don't want a company swooping in once much of the heavy lifting has been done and profiting.

The above licensing situation hasn't always made the relationship between the two projects hunky-dory, but we'll get into why the above is a problem in a moment, as there are other things chafing NeoOffice in a big way and they all interrelate:

  • We're really talking about two guys here, with ancillary help along the way, putting in thousands upon thousands of hours of work to get NeoOffice to the state it's in. They're also about the only two guys who have a clue as to what's going on.

    While it's OSS, due to the size and scope of the project, it might as well not be. This isn't the type of project where you can notice a problem, drop into the source (several hundred megs I believe) and submit a patch -- you are looking at devoting a hell of a lot of time to even figure out what's going on before you're doing anything worthwhile. The type of programmers they need don't grow on trees, and the ones who could help simply can't devote the time to get up to speed.

  • NeoOffice was originally going to be a test-bed, a sort of proof-of-concept to figure out what did and didn't work before something real got started. Unfortunately, for all the talk, nothing real ever got started and NeoOffice/J ended up being the only viable offering. Sun had stated they weren't going to be doing it, the OOo group wasn't going to be doing it, so that left NeoOffice/J to do it, and they set about trying to do it.

  • Two guys working in their spare time can only get so much done, and they were actually starting to build some interest with their last releases, which meant getting donations to hopefully devote more time to the project as well as trying to get a DTK (developer transition kit) from Apple in order to get the thing working in x86 land, which costs $1,000.

Lots of things come up in a project like this, like having to move to the newer 1.4 Java Virtual Machine in OS X and such before the switch, or adding SpotLight support via NeoLight, instead of further work on improving its integration.

They're already strapped, but they were building some momentum. And then in a presentation at OOoCon, OOo announced that they were going to be dumping x11 and doing their own native, Cocoa-fied version of OpenOffice for the Mac, and NeoOffice was back to square one.

The most dangerous game


Overnight, that comment went all over the place, and NeoOffice's momentum was on life support if not dead, which brings us back to the email I referenced. It's worth noting:

  1. Who was CC'd, as a few addresses stick out.

  2. That I know Ed and Patrick from awhile back when they made my radar, because they're the kind of people I think need more light on them. I was looking at doing one of my chewable interviews with them, and the above is just what I picked up researching, not from their mouths.

Now, if you do the math on who sticks out in the list of recipients -- using the only real stick they have to not have it relegated to a far-off page on the site (fyi, the page was updated with more info, but the NeoOffice part wasn't removed) -- you can get an idea of just how hard they're fighting to try to keep the project alive and just how much trouble it it's in. They're starting to play a very dangerous game, and smart people don't do that unless they are out of options.

I'm not going to go so far as to say it's obvious Sun isn't down with having NeoOffice gain traction anymore, but I will say NeoOffice was worthwhile to Sun only as providing as an excercise in mindshare. Since it's GPL and not LGPL, Sun can't producticize it as they can OpenOffice.org, and there is a reason why most of those within OOo are on Sun's payroll in some way. Not all, as there is a community and people do contribute some code (the original OS X port was volunteer-led, with some resources provided by Sun), and some other corporations like Novell and RedHat do cycle in some dedicated developer time.

However, when Sun starts talking tens upon tens of thousands of people involved in OpenOffice.org, it can be a little misleading, as while there are volunteers for the most part they aren't contributing much to core development of the project -- that is funded by Sun.

Spooky girlfriend

Either way, NeoOffice is in a real pickle:

  • Their project is heavily based on the X11 OS X port, and with that shutting down in favor of another Cocoa-fied port, NeoOffice is going to have that much more work as new versions come out.

  • When it comes to funding, it's awfully hard to get people to sign on and contribute funds to a project when the Big OOo Hope™ is just around the corner yet again. They've done a lot of work gearing up to get it to x86 Macs, but effort doesn't put a Developer Translation Kit in their laps to actually test it.

  • When it comes to getting people interested in learning the code in the hopes of bringing on other contributors, this again becomes a non-starter because no one wants to latch their horse to NeoOffice when the big brother might be coming next year and relegating it to a sideshow.

  • When it comes to picking up user interest, which is often intertwined with the preceeding two issues, it's awfully hard when as far as the public is concerned, the real native OpenOffice version is on its way, and there is just some weird experimental project floating about.

To be fair, NeoOffice isn't entitled to exist, despite the amazing efforts of its founders, and if OpenOffice.org wants to shut down their X11 port and create a Cocoa-fied port that's all fine and good. A Windows-quality port would certainly be sweet. The problem is that a lot of this doesn't make a whole lot of sense:

  • There are serious technical limitations inherent to the OpenOffice code base, and Cocoa, that make them extremely unsuited for each other, which the original porters hit hard. No one has said why this time would be different, as nothing has changed in the code base that would change things, and nothing has changed much on the OS X side of things that would change the equation.

  • Even assuming there was a will and a way, there can't be that much will and there can't be that much way. At best, we're looking at a year until we're seeing anything real, and at worst, several. This is non-trivial stuff, and when I asked around about who would be doing this Cocoa-fied version of OOo, I wasn't put at ease. We're again talking a very small handful of people at best, who are solid contributors but not necessarily who you'd flag for a crack Cocoa-porting team.

However, the real problem is that Sun -- and OpenOffice.org -- burned through their karma long ago when it comes to a native OS X port, having several 'announcements' bandied about that turned out to be vaporware, and haven't come close to saying why this time would be different.

Considering they're doing a bang-up job of asphyxiating a project which actually works now with their announcements, I think it's perfectly fair to ask why we should think this time will be different, and if we aren't given that, whether these types of announcements -- while within their right -- are actually right.

yummy alcohol posted button Posted by drunkenbatman
    October 31, 2005, at 11:37 AM


Comments (55)




Post a comment



Anonymous comments are allowed, but please enter something for a name.

And do endeavor to appear sane.









Remember personal info?