From Fedora Project Wiki
m (rid of level-1 header)
 
Line 1: Line 1:
<!-- page was renamed from Interviews/Abiword
-->
<!-- page was renamed from RahulSundaram/Interviews/Abiword
-->
= AbiWord Team Interview =
AbiWord just had a great 2.6 release and the developers took several hours of their spare time over a few weeks period answering questions and providing information. Thanks to the team and especially MarcMaurer for his time and patience. We present you a detailed interview with the AbiWord team on a broad range of topics.
AbiWord just had a great 2.6 release and the developers took several hours of their spare time over a few weeks period answering questions and providing information. Thanks to the team and especially MarcMaurer for his time and patience. We present you a detailed interview with the AbiWord team on a broad range of topics.



Latest revision as of 20:35, 9 June 2008

AbiWord just had a great 2.6 release and the developers took several hours of their spare time over a few weeks period answering questions and providing information. Thanks to the team and especially MarcMaurer for his time and patience. We present you a detailed interview with the AbiWord team on a broad range of topics.


File:Interviews AbiWord uwog.jpg

Marc Maurer

Location: Enschede, The Netherlands

Age: 27

Profession: Software Engineer

Hobbies: Hackers have to hack

IRC Nick: uwog

Website: http://uwog.net/

Interviewed by: RahulSundaram

File:Interviews AbiWord martin.jpg


Martin Sevior

Location: Melbourne, Australia

Age: 49

Profession: Associate Professor of Physics

Hobbies: AbiWord, Running, Karate, Enjoying life

IRC Nick: msevior

Website: http://msevior.livejournal.com/

Interviewed by: RahulSundaram


Tell us something about the history of AbiWord.

AbiWord was started in 1998 by AbiSource Inc., a company founded by SourceGear corporation. The initial plan was to build a free office suite named AbiSuite, which would encompass things like a word processor, presentation program and a spreadsheet program. The office suite would be cross platform and use the native UI on every operating system it was ported to. Unfortunately they didn't have a usable product yet when the venture capital was all used up. I think this was somewhere in near the end of 1999. Around that time StarOffice was also open-sourced, so new venture capital was hard to come by with such a big direct competitor in the market. In the end, AbiSource Inc. went belly up and volunteers started to take over the project. The only code written so far was for the word processor part of the office suite (AbiWord), so that's what people started hacking on, and continue to hack on till today.


How many people are on the team?

The more regular contributors are Dominic Lachowicz from the USA, Martin Sevior from Australia, Robert Staudinger from Austria, Hubert Figuiere from Canada, Ryan Pavlik from the USA, Tomas Frydrych from the UK, and me (Marc Maurer) from The Netherlands. Then of course we have quite a bit of people sending the occasional patch or translation updates. Then there is Kamran Khan from the USA. He's been very active as our Q/A guy, and he's working regularly on all our importers and exporters

Tell us more about yourself. How did you get started?

I got started somewhere in 1999 when I was 19. I was bored during some classes, and fixed a bug in AbiWord 0.7.14. Since the community was _really_ friendly, I stuck around. That was my first ever contribution to a FOSS project. I started working on the WordPerfect importer, as my father needed that. When we saw our code would be useful for other projects such as OOo as well, we split that off into libwpd.


Within the team, how do you share your work or decide what each person works on? Do members work on specific things?

We have no policies whatsoever. Everyone is free to work on whatever he or she loves working on. In practice we see that everyone has his own niche which he works in. For example: Kamran tends to touch the import and export filters; Martin does the bulk of the document layout code; Ryan maintains our Windows port; Robert often works on the build system and is replacing our old home grown code with glib equivalents; Frydrych did most of the text shaping and rendering work, and I myself mostly work on our collaboration plugin these days and keep myself busy maintaining the stable branch.

It is exciting to see the 2.6 release after a long time. How long has it been in development?

Let me see... we branched off the development branch when we released 2.4.0, which was in oct. 2005. That makes it ~2.5 years. Wow, that's long :-P. Bad us.


Do you want to do more frequent releases going forward?

Yeah, 2.6 was definitely bad in terms of our release process. This was due to 2 things really:

  • 1) abicollab, a new plugin that allows collaborative editing, took way more time to develop than planned and we really wanted to ship it with 2.6.
  • 2) our involvement to get the codebase ready for inclusion on OLPC took away a lot of spare time but both were important enough we felt to delay 2.6 for.

How has the experience of working with OLPC been?

When we started, it was quite annoying at times. This was mainly due to the lack of direction and concrete plans. On the other hand, that is to be expected. The end result was definitely worth it though, as the OLPC enabled us to work full time on getting AbiCollab production ready, for example.

Were you contracted?

I was, yes. I think for about 6 to 9 months but we also spent tons of spare time on it. Martin Sevior and Robert Staudinger also devoted a considerable amount of their time, and so did other abiword hackers.

Could you tell us about the collaboration plugin?

The AbiCollab plugin allows multiple people to work on the same document in real-time. You can select which transport you want to use. For example, we have a basic XMPP (Jabber) transport, a pure TCP one, and we developed one for OLPC, which uses telepathy.

Does that require a server like Gobby, or is it peer to peer?

It's a mix: 1 document is always the "master", which we need for tie-breaking collisions and to make sure the documents stay in a synchronized state. However the protocol is totally lock free (good for high latency connections which we have on OLPC for example). Also there is nothing in the design that prevents us from making another user the master in a session when the current master wants to stop collaborating. We didn't implement this last part yet, but we should have it ready soon. This lack of master-takeover is why the AbiWord 2.6.0 release notes still called AbiCollab "experimental".

How do Abiword sessions on a network discover each other -- do you connect specifically to an IP address?

That depends on the transport used really. For XMPP you add your Jabber account information. For TCP you connect to a specific IP. For OLPC the discovery is built into the platform, which we tightly integrate with. This integrated approach works really neat in practice. For the desktop I've been wanting to make a telepathy backend, but i didn't get to it yet.

We are currently also working on another transport that will use a webservice called http://abicollab.net/ that we are developing. With this backend you just login using your email address and it will automatically fetch all your documents, friends and groups from the webservice.

Martin: Actually our webservice really takes the online experience to a different level. All your on-line documents are accessible from the browser or within AbiWord. In addition we solved one really critical bottleneck in collaborative document production: you don't need to wait for your colleague to check in his changes before you can see what he has done. You grab the most recent document off the site and that is what he is typing in. You can see exactly the latest changes at all times, even when the latest work was not saved yet. By hosting the documents on the site we automatically get around the problem of imperfect file format filters. Users just grab an AbiWord release (a 20 second download) and they see exactly what you've typed. No one else has anything like it and I expect Microsoft will be scrambling to add this feature for their next version of Office. It was worth the long wait for 2.6 to get this right.

Marc: To plug this even more: one cool feature will be the ability to direct link to any revision of a document hosted on http://abicollab.net/ in any format. For example, you can give someone a link to the latest version of your resume in PDF format. As soon as you update your resume (ie. hit CTRL-s in AbiWord), the linked PDF will reflect those changes immediately. Pretty neat if you ask me :)

What are the future plans for Abiword?

For 2.8, we are trying to be conservative. It will not have a ton of new features; It will feature the new Annotations feature though, as well as a proper GTK+ widget that application developers can use in their application as a rich text widget. The fun thing about the widget will be that you will get everything that abiword supports for free, such as support for all the file formats abiword supports and all AbiCollab's features.

What kind of features do you see in demand from users?

Interestingly, not any particular feature stands out anymore. In the AbiWord 1.x era users mostly wanted Table support. For 2.x it went from the lack of floating textbox support, to document revision tracking and better support for international scripts. These days we are pretty much feature complete I'd say, with Annotation support being the single obvious hole in our feature list. On the other hand, Annotation support will be a feature that only a very small percentage of users will actually use, so I guess most people are happy with AbiWord's feature list as it is.

Oh, and don't forget improved OOXML filters. As MS Word 2007 will start being used more and more, the number of .docx documents floating around the net will pick up dramatically. Our users will expect us to be able to handle those.

Do you have many platform specific features, or do you use the same technologies everywhere?

We use the native toolkit on every platform. That means GTK+ on unix-like platforms. Cocoa on OSX (although we don't have any developer working on that platform at the moment, which is really sad) and the Windows API and GDI on Windows platforms. We do try to make as much of our code cross platform though, for example, one really annoying thing we have to deal with is having 3 separate graphics classes (render engines) - we really want to get rid of that.

How are you planning to deal with these things in the future?

On unix, we recently switched to Pango, which is available on OSX and Windows as well. If we then also move to cairo, we can share a single render engine on all our platform. For the toolkit, some people have expressed interest in creating a GTK+ port for Windows and OSX. We don't plan to make that the official port though, but it's certainly interesting to see what the result will be.

Are the ports for different platforms managed by different people?

Yes, but in practice there is a lot of crossover. Also, we don't have a lot of manpower, so if the platform maintainer is gone for a while, one platform can lag behind the others for a while

How has been the collaboration or competition with other FOSS office suites been?

We don't share a lot of work with other office teams. However, we do create code that is shared between OpenOffice.org, KWord and AbiWord, for example, We created the libwpd library, a library for importing Word Perfect documents; that is currently used by OOo, KWord and of course us. We also created enchant (Dominic mostly) - that's a general spell checking framework that is starting to be picked up by the others. We don't compare ourself too much against the rest though. We are a tiny team compared to OpenOffice, with quite a different vision.

Has similar sharing of code not been possible with other filters?

It would have been, but every project already had its own filter for the most common file formats and no one is keenly interested in ditching working code.

So the quality of import/export filters would be different between them?

That's very much so. For example, we'd love to share OOo's word import filters.

Why hasn't that happened then?

That can't be easily split off from OOo. The code is too integrated. The OOo hackers obviously have no time/interest in untangling it of course, which is understandable.

Is Abiword capable of supporting all the Word features, even if the code is shared?

Not to the extent that OOo can, but we would be able to support almost all features users typically use; the one area lacking would be Annotations and Word Art. The first we will fix in AbiWord 2.8. The latter we will probably not implement.

How do you work with distributions?

We try to get as close to the distros as possible. For example I'm the AbiWord maintainer in Fedora. That really helps us to get high quality packages in the distribution. With Ubuntu for example it's a bit harder, as we are too far from the actual packagers. That leads to some issues, such as a lot of Ubuntu users still think after 2.5 years that we don't support the ODF file format which is not true; this comes from the fact that Ubuntu ships that import/export filter as a separate package. Not a lot of users seem to be aware of that; they don't know additional packages exist that's why we are consistently pushing the distros to ship the most useful functionality in 1 package. We hope Ubuntu will fix the long standing bug report about this, as they are a popular distro.

How long have you been the maintainer for Fedora? How has the experience been?

Let me see. My first spec file change was Fri Mar 14 2005. I must say the Fedora experience has been getting better consistently over time. The merging of extras and core was one of the best things that happened over time, making outside contributors a first class citizen. Also the web services (Koji and Bodhi for example) have improved a lot over time. Another good thing is that Fedora is really close to upstream. I often push an Abiword update to Fedora even before it hits abisource.com, which is very nice to be able to do. The lack of bureaucracy is a real blessing. The other area that has seen good improvements is the package review that helped cleaning up my packages a lot recently. Creating a working package is one thing; having consistency across nearly 10,000 packages is very hard to achieve, but Fedora is doing better every day in that respect.

What do you mean by lack of bureaucracy?

Let me give an example about the lack of bureaucracy. AbiWord 2.6.0 was released a few days after the official Fedora feature freeze. I was unaware of this (didn't really pay attention to the schedule, sorry :), so I pushed it in and now my push caused some problems, such as dragging in a lot of new dependencies on the live cd. Instead of forcing me to revert my invasive change, Fedora allowed me to fix it to be able to have the nice new Abiword available in Fedora 9. They could also have chosen to deny my push, as it really was after the feature freeze date.

Is there anything you want to see Fedora improve on to be a better platform for upstream ?

I really would love to offer suggestions wherever, but I can't see how Fedora could improve on this a lot. The process 'Just Works' :-)

How is the concept of GNOME office working out, and what is your integration with Gnumeric like? GNOME is still missing a presentation program.

As much as some people would like to see it differently, GNOME Office really never existed. It started off as this weird 'Meta-Package' concept, just listing every productivity related program on their website. We tried to bring some direction to it by focussing on Gnumeric, GNOME-DB/GDA and AbiWord. However, apart from updating the website, it really went nowhere. As for the integration with Gnumeric, we do ship a 'GNOME Office' plugin, which is based on libgoffice. The plugin allows people to embed (and edit) Gnumeric charts within Abiword, which is pretty nice. It is not based on any component model such as bobobo, but instead the plugin provides the glue between goffice charts and Abiword's general embedding functionality. Also, we made sure you can copy/paste Gnumeric cells from Abiword and visa versa.

As for the presentation program, there was a tiny amount of code in libgoffice for a while that could read PowerPoint files. It was never really used for some reason; I guess no-one is really interested in creating a true GNOME presentation program. The AbiWord developers always used AbiWord in fullscreen mode to do their own presentations; Martin Sevior recently added a new plugin to Abiword that added a 'Presentation' view. This will show your document in full screen, and uses the common keybindings, such as left-mouse click will go to the next page/slide, and the right mouse will go back if anything has changed. He has expressed interest in improving its capabilities, so its usability might rise above the gimmick level in the near future.

Has the Abiword team participated with the ODF spec?

We were asked to join the review committee, but we didn't accept.

Why not?

In contrast to what everyone was saying, we would be far too small to make any real change. ODT is basically run by the big corporations like Sun, Novell and IBM. It would be naive to assume there was anything we could change about the format. Those are my views by the way, I can't speak for the other Abiword developers; I doubt they will disagree.

Martin: In a nutshell neither Dominic nor me wanted to be part of the odt committee because we felt it wasn't a good (or fun) use of our limited time. Both dom and I have full time real jobs as well as families. There is only so much we can do. For my part I'd rather hack on Abiword than have to fight political battles. All that said, if we had been on the committe we might have prevented a couple of silly things being part of the spec.

Such as?

Martin: ODT has page reference positioned images and frames. This means that an importer cannot place the image or frame in the document without laying out the document first. So if you want to translate an ODT file to a webpage you're screwed, because you don't where to place the image.

Marc: Not if you do a 2 pass export :) This obviously sucks complexity and performance wise, but technically it is doable.

Martin: ODF also doesn't define a region over which comments are applied. So in Abiword you can highlight a region and put in a comment like "This phrase makes no sense" or even better, suggest a sentence that should be used instead. Your collaborator on the document can then just click "replace" on our annotations dialog and the text in replaced. Now we can't preserve this feature when exporting to ODT, because comments are only defined at positions in the document not as regions. I have no idea why they did this.

Any comments on ODF as the default format? There was a 2004 discussion, but has anything changed after that?

No. We will not make it our default file format. Our internal model does not map 100% to ODT and visa versa (basically because ODT is nothing more than a dump of OpenOffice.org's internal format). Any data loss that happens because of saving and loading a file again will not be accepted by our users. A user can make ODT the default in their own profile though. Interestingly, we do save to ODT by default on the OLPC XO laptop. We can do that there, because we only have to support a subset of features AbiWord supports, making the roundtrip (almost) flawless.

So you don't advise distributions to set it as default either?

No, I'd strongly advise against making ODT the default format in Abiword for distributions given the previously mentioned lack of 100% feature coverage.

How is the support for OOXML?

We only support OOXML importing at the moment, and it doesn't cover the full spec by far. We got the OOXML import filter as a result of last years Google SoC program. This years SoC program will hopefully futher improve our import capabilities, and maybe bring us an initial OOXML export filter.

Was writing a OOXML importer hard to do? Did you run into any major problems? How did it compare to write a filter for ODF?

I've no idea really, as I never hacked a single line on either of those filters. AbiWord has become big enough that you can't know every line of code anymore I guess :)

What about this year? What are the projects?

This year we will have 6 students working on AbiWord. Two people will work on our OOXML filter (import and export); one person work on improving our LaTeX export filter; Ryan will work on improving our handling of document styles; Robert will port AbiWord's render engine to Cairo and replace gnomeprint with GtkPrint and finally we will have a student working on a multi-page view, allowing you to view several pages side by side.

What do you think about OOXML becoming a ISO standard?

I'm really sad about the ISO verification process, which is a complete farce. As for the format itself, from our point of view it's just another file format we have to support, with all its good and bad parts. In the end, it doesn't matter a single bit if it's ISO approved or not. Millions of people around the world will MS Office and thus create documents that people expect us to support. So even though I'm strongly against how the process was conducted, we will have to support the format.

Was ODF support different in any way?

No, us supporting ODF (even before it was ISO approved) is exactly the same as us supporting OOXML.

How and why did you get involved with Fedora specifically as a maintainer?

For every release, we always uploaded quite a number of rpms to our website (for SuSE, various Red Hat Linux and Fedora Core versions, etc). This gave our users the opportunity to always run the latest version of AbiWord as soon as we made a new release. While this effort was appreciated by lots of users, it also proved to be very time consuming to maintain for us. It also was not the ideal solution we were looking for in terms of ease of use. For example, the AbiWord RPM includes lots of plugins by default, which drags in quite a number of dependencies. The process of manually resolving these dependecies often proved too hard and confusing for our users, even when they were all available in the default repositories.

The only proper solution to solve these issues was getting close to the distribution AbiWord maintainers, or even become one. The latter was not possible in the Red Hat Linux era, but that all changed with the creation of the Fedora Extras reposities. This gave me the perfect opportinity to become the maintainer of AbiWord, and upload new releases directory into the official Fedora repositories. Since then I've maintained AbiWord and a number of its dependencies in Fedora, ensuring that Fedora users always have access to the best AbiWord experience possible.

How much does being far from the actual distribution package maintainers affect you, versus the distribution model in Windows where you are directly reaching end users?

When the distribution does a decent job of packaging AbiWord, it works really well for users. They can get all their software and updates from in one single place: the distribution's software repository.

Things start to fall appart when the distribution starts making the wrong choices: split out the plugins in a seperate package or not, which plugins to package and distribute, that sort of stuff. Splitting out plugins in a seperate package for example only makes sense if having a small download is of absolute importance. From a users point of view, it's almost always the wrong choice. Ubuntu bug 24195 (https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/24195) is a classic example of this, where they decided not to ship the OpenDocument filter in the main AbiWord package. We had a lot of users complaining to us that we didn't support the OpenDocument format. They simply didn't know a seperate plugins package existed (nor should they have to know).

When a distribution didn't package a plugin that a particular user would like use, then the game is basically over. The user would have to resort to compiling the whole of AbiWord and the required plugins himself, which is almost never an option.

This is all very different on Windows, where we can provide the latest version of AbiWord and all its plugins in a simple convenient installer on our download page. In the end, we have far fewer complaints regarding software distribution coming from our Windows users than from the Linux users. If you consider the fact that our Linux userbase by my estimates is a lot smaller than our Windows user base (and more technical generally as well), it shows us that we have a lot of work to do on the software update distribution front.

The AutoPackage we provided on our download page for AbiWord 2.4.x came close to the easy software distribution channel we have for Windows platforms.


Abiword was one of the earlier adopters of AutoPackage. What happened? What has been the experience with it?

Our AutoPackage was an experiment done by Robert. While it seemed to work nicely for a lot of users, a whole bunch of users also had some serious issues with it (I think they were mostly libstdc++ related, but I could be wrong here). Also maintaining an AutoPackage took a non-trivial amount of time, time that Robert was unwilling to spend on it. Being unmaintained, it followed the path of so many other unmaintained bits before it; it was dropped.

If someone steps up to create a new AutoPackage and shows some dedication for maintaining it, I'd be very willing to put it back up on our download page.

Have you looked at PackageKit?

Well, I never touched PackageKit yet, but it does look very promising indeed for plugins, dictionaries, templates and other complimentary add-ons.

Living off Abiword? How many get paid? For specific features? Is any commercial contributor involved?

Noone is living off AbiWord at the moment. In 1999, AbiSource Inc. tried and failed to do just that. Ofcourse, they had the problem of starting from scratch with nothing of value to offer for a while. Eight years later we have a solid product that from time to time generates corporate support requests. Any AbiWord developer that is interested in taking up on the offer is encouraged to do so. Besides doing the specific OLPC adaptations, our mail-merge feature and command line based printing options are both developed under contract for example.

For a long time some of us been toying with the idea to create a legal entity to direct all the corporate support requests to. It didn't really get anywhere up till recently, when we came up with the idea of offering additional services around our real time collaboration technology. We hope to announce our services and plans within the next few months.

Any parting comments?

I'm really happy to see AbiWord 2.6 being as well received as it has. Since it was so long in development and everyone seemed to be too busy to do some development releases, we (or at least I) totally lost track of the quality of it all. Various people all over the internet even declared AbiWord to be dead as a project :) In the end, I just ended up tagging trunk on a rainy weekend and declared that 2.6.0 was done. I won't go as far as some people by claiming (almost) feature parity with OpenOffice.org Writer, I'd say it turned out to be a pretty solid release. Stay tuned for the upcomming 2.7.0 development release. It will feature Annotations and it will finally have proper Smart Quote support!