Now that the first OLPC hardware has hit the mean(ish) streets of Cambridge, MA it's time to turn the spotlight onto the software and content. Like us, many of you will be wondering what software treats OLPC has in store for millions of the world's children. The first XO-1 machines out the door were far from polished products.

They contained a number of place holder applications; programmes shoehorned in at the last minute to fill in gaps left by as yet unfinished Sugar modules - or to use OLPC parlance, Sugar "activities". Among these place holders is AbiWord which owes its place on the demo machines due to the unfinished state of Sugar's javascript based eBook activity.

Despite the best hopes of the AbiWord community to leverage its status by studiously modifying the software to suit the needs of OLPC's target audience, the prognosis did not look good yesterday when Ivan Krstic spelled out his vision of AbiWord on OLPC:

let me try to bring everyone to the same page. As I've discussed with several of you before, we'll be shipping a web-based e-book reader and wiki notebook activity on the production machines. The notebook will be the primary "writing" activity, as it will tightly integrate with the rest of the information platform, and support real-time collaboration; we'll be able to do things like desktop-wide annotations and saving snippets directly into it. [...]

Now for production plans: I'd like to ship AbiWord without an editing mode, supporting instead viewing, copy to clipboard, and possibly Save As Crossmark. This would let us retain the ability to view the unfortunately popular closed .doc files, while moving new document creation into the notebook where it logically fits.

These are probably not the sort of things a word processor developer is hoping to hear, what with their software being cut down to become a glorified Microsoft Word viewer.

Fortunately, the closing door did not slam shut. Ivan threw the guys a bone:

That said, the rich editing UI that we're developing for the notebook is Javascript-based, and thus isn't usable by regular GTK apps. This is where you, the AbiWord folks, come in. If you can shrink Abi to an embeddable GTK widget that speaks Crossmark, that would rock a whole lot, because it would let us do rich text everywhere -- file descriptions, e-mails, general annotations, you name it. We could encourage application developers to make almost every textbox where it makes any sense be an Abi textbox.

Seeing as I only have conversational Linux, I'm not fully able to de-geek that paragraph, but Ivan appears to be encouraging the AbiWord developers to change their focus and look at remodelling AbiWord into a much smaller application. This would allow other software developers to embed an "AbiWord lite" editor within their activity - something that they will not be able to do with the notepad/eBook reading activity .

Response from the AbiWord developers was swift; why bother developing a new collaborative editing system when AbiWord are near to completing the exact same feature? As developer Marc 'uwog' Maurer put it in his quick-fire response:

I still think that abicollab [AbiWord's collaborative editing feature] will kick anything else's ass with regards to collaborative editing.. but feel free to reinvent the wheel in javascript

Ivan remains to be convinced that the AbiWord team have cracked the problems inherrant in real time document editing:

I'm very skeptical of things being as simple as you make them sound, because a colleague recently researched most of the published research on collaborative editing techniques, and found many of the problems I list to be generally still unsolved.

Alas, we will have to wait to see whether AbiWord can live up to its collaborative editing claims as the developers are a week or so away from a working test build.

Perhaps in the meantime, the developers have given AbiWord's OLPC ambitions a temporary stave of execution.