6 Mar 2004 uwog   » (Master)

In response to Havoc's blog on GNOME Office @ http://log.ometer.com/2004-03.html#6.

Havoc claims in his blog that GNOME Office was a huge missed opportunity. He's right about that one. The reason of it's failure is that GNOME Office has too long been this meta project, a project (if you can even call it that) with no vision. Recently, this attitude has been starting to change, and we are now discussing on the GNOME Office mailing list how to create the integrated, uniform GNOME office suite we all have been waiting for. We welcome input from everyone, so join the GNOME Office mailing list if you want to be part of the "new" office suite.

Now, Havoc says "Gnumeric and AbiWord are architected differently and use a different approach to portability, but why not suck it up for now and iterate them toward convergence over time".

Not sure if I understand the phrase "to suck it up" correctly as a native dutch speaker, but it seems to imply that we (the AbiWord and Gnumeric teams) are arguing over what would be the best approach instead of trying to work together an actualy produce something coherent. This is certainly not the case, and although I think Abi's approach to being a crossplatform application is the Right Thing(tm) to do, I do not mind at all that Gnumeric chooses another way of achieving it (ie. by using the GTK+ port for win32). No, instead, we *are* trying to integrate the applications better, for example by making copy/paste work between applications: try to make a table in AbiWord, select and copy it, and paste it in Gnumeric. It works. Of course, lots and lots of work needs to be done in this area, and progress is slow. Furthermore, Jodi started to create libgnomeoffice, and library which will allow us more easily to share code between the GNOME Office components.

The reason that progress on the interoperability front is slow is, at least in the AbiWord camp, mainly due to lack of resources. With an active AbiWord hacker team of about 7 people, yes that's seven, and some other more or less occasional helpers, we have to maintain a stable branch, develop new features in the development branch, maintain the webpage, do releases, help users, run through bugzilla, write documentation (which we actually don't have very much time for), etc.

This also explains why we don't make the "hard but worthwhile decision [...] to use the OO.org file formats" yet. Currently, we use the .abw file format as our native format. We are not against the OOo.org file formats per se, but adopting it would cost time, and lots of it. Time we don't have. This is mainly due to the fact that the .abw file format is almost a direct dump of our Piece Table, the mechanism used to hold the document internally. OOo.org's file format does not directly map onto our PieceTable, so importing and exporting it would take time to get 100% right. 99% is not good enough for our users. Another, slightly less important reason, not to immediately adopt OOo.org's file format is that it would make it a lot harder to do new, inovative things that do not map onto the OOo.org file format. We can now just "invent" the things we need for our file format, and get on with it. A process that takes about 10 minutes. We do have some initial work done on an OOo.org importer/exporter plugin, but developement is almost non-existant right now. If any hacker out their is interested into improving it, please join the abiword-dev mailing list, and we'll get you going. Work in this area would be appreciated by a lot of people.

As it is now, Havoc just has to wait a bit to "see the hard decisions and bold roadmap directions" be made. The (realy not so) hard decisions will be made, or have already been made. There are no arguments or flamewars between the different development teams that would hamper the progress we would all like to see.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!