Collabora and IceWarp recently announced the development of LibreOffice OnLine (LOOL). The announcement was general, leading to all sorts of speculation, so to learn what was actually happening, I contacted Michael Meeks, the vice-president of productivity at Collabora and a board member of The Document Format, who is also one of the lead developers on the fledgling project. Both the technical approach and the reason for LOOL turn out to be very different from what many are assuming.

As Meeks notes on his blog, the idea of LOOL is almost as old as LibreOffice itself. In fact, at the first LibreOffice conference in Paris in 2011, Meeks demonstrated a prototype in which a virtual desktop runs in the browser.

So why has LOOL taken four years to implement? One answer is that LibreOffice inherited code that had been improved slowly under Sun Microsystems, and everything needed to be done at once.

Another answer, Meek says, is that, unlike projects like Mozilla, The Document Foundation (TDF) has no large regular donors. “Occasionally, someone gives us money, and TDF can invest in the basic infrastructure. At Collabora, we’ve talked to a large number of people who want [LOOL], but no customers who would pay for it. So it’s fantastic when you finally find a customer like IceWarp that has the vision to see that this is really a key piece of the puzzle.”

Still another major part of the problem were the limitations of Meeks’ original prototype. Meeks notes that the prototype worked “surprisingly well,” but required one instance per app per user, and the constant presence of the server, “which is a disaster from any kind of memory consumption. And then of course you get these latency issues – you scroll down the page and the main server has to wake up [and] send more pictures. And this is just not for everyone.”

Such problems meant scaling of LOOL would quickly become a major challenge, both in terms of hardware requirements and general performance. “It would have been possible to extend the GTK Javascript to allow tunnelling bespoke commands through to LibreOffice to allow the wrapping of custom UI,” Meeks writes in his blog, “but, still, the work to provide user interface that is expected on the web would be significant.” Even with funding, the technical approach needed to be refined before LOOL was practical.

Finding a Solution

Over the last year, that refinement has taken place, sometimes with goals other than LOOL directly in mind. For example, Meeks gives some credit for being ready for LOOL to The Document Foundation’s creation of a culture radically different from that which prevailed in OpenOffice.org, LibreOffice’s parent project. “We’ve got some things right in the project,” he says: “structure, licensing, the right people involved, and also encouraging people to change stuff. There was a profound fear of change before, and fear of regression, and fear of the users. We’ve broken that culture fairly comprehensively.”

Meeks also credits LibreOffice’s use of Coverity Scan for reducing the number of bugs by 25 percent, as well as comprehensive testing of each daily build through both 55,000 documents and all supported export filters. Such quality control is desirable in itself, but also helps to set the background for LOOL by maximizing performance.

What was directly helpful, according to Meeks, were the efforts to port to multiple platforms, including the Android viewer for Open Document format, LibreOffice’s default file format.

“Mobile and on-line requirements for basic viewing are really quite similar,” Meek says. “If we improve editing in one place, we can improve editing elsewhere. He mentions, for example, improvements in OpenGL and the transfer of rendering from the CPU to the GPU as much as possible.

In particular, Meeks mentions the development LibreOffice Kit, a development tool that strips LibreOffice to its core functionality and enables the development of new features.

LibreOffice Kit has received relatively little attention, perhaps because few documents about it exist in English. However, for LOOL, the use of LibreOffice Kit means, “throw[ing] away the chrome around LibreOffice and providing a way to expose just the rendering core of LibreOffice, so it can draw pixels, then push them over to the client. So you can read your document fully on the client, and the server has gone away and is serving someone else. If you come back to the document, or someone else wants to read it, we can cache it. The result is that the server requires far less memory, and performance for clients is greatly improved.”

Implementing the Solution

Contrary to some speculations, LOOL will not be a complete rewriting of LibreOffice. Instead, Meek says, “We want to re-use as much of LibreOffice as possible, and provide the best rendering possible,” rewriting only when necessary. Writer, Calc, and Impress will be implemented first, then, “Ultimately, come next year, collaborative editing of those.”

Asked if other LibreOffice applications will be ported, Meeks replies, “I don’t see why not. Math is easier than Base, though. Base brings all sorts of interesting dependencies” – a reference to its reliance on Java – “that we’re trying to get rid of.” He suggests that a project intern might build a new JavaScript framework around Base, but that one way or another, the implementation of Base will probably start with viewing and basic editing, “but not tweaking your pivot tables in some weird and wonderful way.”

However, most code that has to be re-written or added will likely be in C++. Meeks admits that “everyone has their own pet language prejudices,” but adds that, “Pragmatically, LibreOffice has either C or C++. The reality here is that you’re going to want quite a bit of performance here, and that militates to a compiled language. Once you start mixing languages, you start running into other problems – such as a language that is invisible to a debugger, or acts in unanticipated ways.”

Development is in early stages,but Mihai Varga has posted a brief video of LOOL. Other developers – all Collabora employees – are Jan Holesovsky, Tor Lillqvist, and Meeks himself, although he expects community contributions.

Deployment Plans

The announcement of LOOL has caused many online to expect a rival to Google Docs or Office 365. IceWarp has not announced how it plans to use LOOL, but Meeks makes clear that, “TDF is interested in having an instance, but only for members. I don’t think it’s feasible for TDF to host infrastructure for hundreds of millions. It would be a huge distraction, and it’s not our core purpose. So why do it when we can get other people to do it? We’re really just interested in building the base technology, and people can use it wherever they want.”

These intentions are not simply practical, but also an expression of philosophy. Talking about other online services, Meek says, “It’s clear there’s a vested interest in having all the data stored centrally so that it can be indexed and examined, and products can be sold on the basis of it. I think that’s clear from any angle. It’s something to lock people in.”

“Over centralization,” Meeks adds firmly, “is the bane of our existence on the web, isn’t it? There’s a huge advantage in not having a central, monolithic organization doing something. And I think we really ought to have a de-centralized, federated web.”

LOOL may use Open Document Format, a minority file format, but, as it starts to be used, it can demonstrate an alternative to proprietary formats such as those used by MicroSoft Office. “We can provide something that can stop the creation of a monoculture,” Meeks says, “Something that allows document viewing and collaboration, and actually enables users.”