AbiWord team interview (Red Hat Magazine) [LWN.net]

AbiWord team interview (Red Hat Magazine)

Posted May 11, 2008 22:32 UTC (Sun) by proski (subscriber, #104) [Link]

I disagree. People who like to code on their free time would not want to go to the committee, take days from the vacation, pay for the tickets, all that just to sit there and have virtually no influence over the process.

That's different from somebody representing a large company, who is paid by the employer to go there and who has a much stronger backing.

AbiWord team interview (Red Hat Magazine)

Posted May 12, 2008 5:55 UTC (Mon) by gravious (subscriber, #7662) [Link]

I disagree proski :) If you turn down an invite you can hardly complain if things didn't go
your way. How can they have known beforehand that they would have little or no influence? The
areas of deficiencies they site I'm sure would have been tweaked had they been involved, if
not then yell about it during the wrangling process and maybe then you'll have my sympathy.
Time should not be an issue as collaborating on open standards is an inevitable part of a
project like Abiword I'd imagine. I  think the finance thing is a red herring.

AbiWord team interview (Red Hat Magazine)

Posted May 12, 2008 21:27 UTC (Mon) by Tet (subscriber, #5433) [Link]

How can they have known beforehand that they would have little or no influence?

Thus speaks the voice of someone that has never tried participating in a standards process where big corporate interests are involved. I'm not saying they wouldn't have benefited from having someone representing their interests on the committee. But given limited resources, it is almost certain that their time was better spent on hacking Abiword than on getting bogged down in standardization politics.

AbiWord team interview (Red Hat Magazine)

Posted May 12, 2008 8:53 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

As I've detailed before, what you actually commit to with any of these "open" formats is
recreating the internals of the program that "set the standard", in this case OpenOffice.org.
If their borders get 4 pixels bigger when the font is over 20 points then it doesn't matter
that the "standard" is silent about border thickness, that's what you've got to implement to
load their documents.

In the event that you allow other people to come forward and add things to the "standard" as
well you end up with a standard that no-one implements. That worked out really well for HTML 4
and CSS right ? Just a decade later we've got three half-working implementations which overlap
on maybe 90% of features and it's finally starting to be usable... except the 800lb gorilla
doesn't implement them properly so you still can't use most of it. HTML 4 and CSS is a /walk
in the park/ compared to a usefully complete word processor or spreadsheet document format.

To be compelling, ODF needed to take large, real world documents, and create several programs
which, without code-sharing displayed those documents the same way, and got the same results
from arbitrary changes to those documents.  That was never even /attempted/ let alone
successfully tried.

AbiWord team interview (Red Hat Magazine)

Posted May 12, 2008 10:54 UTC (Mon) by renox (guest, #23785) [Link]

[[As I've detailed before, what you actually commit to with any of these "open" formats is
recreating the internals of the program that "set the standard"]]

Apparently KOffice developers disagree with you, I (barely) remember an interview but they
said that when they find that OOo doesn't respect the ODF standard they simply file a bug
against OOo..
We're not talking working with Microsoft here!

AbiWord team interview (Red Hat Magazine)

Posted May 12, 2008 14:08 UTC (Mon) by msevior (guest, #52030) [Link]

Hi everyone,
As one of the interviewee's I felt I should add a few comments.

ODT is a comparatively easy format to implement, compared to say RTF and especially *.doc. The
implementation we've made for AbiWord-2.6 is pretty good. It's good enough that I don't feel
bad about inflicting it on millions of kids via OLPC, where it is the default.

Nevertheless it is still a dump of the internal document model of Openwriter and as such has
some limitations. The two I mentioned in the interview are the two I'm having most trouble
implementing. Well the annotation bug is just stupid actually as it limits the usefulness of
the program. The page referenced images are an obvious limitation of OpenWriter. Just stick a
few page referenced positioned images in a document and export it to HTML and you'll see it
immediately. All the images just get shoved onto the beginning of the page, even if they
overlap. For all it's complexity RTF does not make either of these mistakes.

Now my own project, AbiWord, is far from perfect and people are quite open about pointing out
our flaws to us so I'm not being holier than thou, just pointing out issues.

Fair enough that we cop some flak for not participating in the process of defining ODF. It
basically isn't fun for us to do that kind of work. Maybe we should have roped in some people
who like to argue in committees to represent us? I didn't think of that...

OK here is a job opening at AbiWord. Person to represent our views at ODF committee meetings.

Renumeration: exactly the same as the highest paid AbiWord Hacker :-)

People should not be surprised that version 1.0 of a format has issues and not be so defensive
about it. By talking about bugs openly I hope the next version of the format will be better.
If someone takes up the offer above you'll have a chance to influence things to avoid similar
bugs in the future.

Martin Sevior

AbiWord team interview (Red Hat Magazine)

Posted May 14, 2008 9:13 UTC (Wed) by Janne (guest, #40891) [Link]

I can'¨t help but think that, instead of speneding time implementing online-collaboration
inside AbiWord, wouldn't it be more worthwhile developing a system-wide method for
online-collaboration. So you can work with your colleagues in Abiword now. Great. How does
that feature help Gnumeric-users, Koffice-user, Lyx-users etc. etc.?

A while ago I wrote about a virtual desktop or something similar, that would be shared across
the network. That desktop would be accessible to other users on the network, and they could
launch different apps on it and work together with those apps. The individuyal apps wouldn't
really need to individually support such collaboration, since it would be supported at the
desktop-level.

Of course my suggestion was more or less shot down, and we now have individual apps that work
towards such collaboration...