openSUSE Conference 2010: The future of LibreOffice

The OpenOffice.org track at this year's openSUSE conference spontaneously changed to a LibreOffice track after the news of the OpenOffice.org fork. That shouldn't be a surprise: Novell's Michael Meeks was previously responsible for Go-oo, which will be obsoleted by LibreOffice. At the openSUSE conference, developers of the young fork presented the current state of LibreOffice and discussed the direction of development.

Some numbers

The LibreOffice track was opened by Florian Effenberger, a Founding Member of The Document Foundation who resigned from his position as the OpenOffice.org Marketing Project Lead two days after his talk. He emphasized that the 10th anniversary of OpenOffice.org was an important date for The Document Foundation: "We see LibreOffice not as a split but as an evolution and the next logical major step for the next decade." An important part of this is lowering the barrier for new contributors, e.g. by not requiring formal paperwork before contributing code, such as a copyright assignment.

Florian gave some numbers to put the young LibreOffice community in perspective. Currently, it has 15 full-time developers from Novell and Red Hat, and already 65 new code contributors (people that have never contributed a single line before to OpenOffice.org). The announce mailing list has 4,000 subscribers and the discussion lists 1,500. There are 51 world-wide mirrors that are distributing LibreOffice, and in the first week, the LibreOffice beta had already been downloaded more than 80,000 times.

Although most of the LibreOffice supporters seem to be linked to a Linux distribution, Florian was clear about the target platforms: "Most of the OpenOffice.org and LibreOffice downloads are for Windows: these are people migrating from Microsoft Office. So Windows support will not be dropped in LibreOffice." Moreover, he maintained that end users will very soon pick the fruits of the more open development model of LibreOffice: "Because Oracle limits the development of OpenOffice.org with their copyright assignment, we will get more code in and thus become better feature-wise soon." LibreOffice 3.3 will be available this fall, and it will be integrated into openSUSE soon.

Easy hacks

In his talk "LibreOffice Easy Hacks", Cédric Bosdonnat — who is a LibreOffice developer for Novell — gave some hints about how to find interesting parts of the LibreOffice code to hack on, and talked about some tricks and tools to help developers. His main goal was to tell people that coding on LibreOffice isn't impossible; there's a lot of simple stuff out there.

The Document Foundation's wiki even has a page with a list of these easy hacks, and some of them have already been completed. Many of these easy hacks are a form of code cleanup: translating German comments that have been there since the StarDivision days, removing code that is commented out, removing duplicated code, and so on. According to Cédric, the latter is a bad habit among OpenOffice.org developers at Sun/Oracle: many specialists are working on their own module and are not collaborating. As a consequence, OpenOffice.org has, for example, three different line-drawing implementations: one for Writer, one for a Calc cell or table, and one for an Impress table. "When I wanted to add dashed borders, I had to hack three places, so eventually I merged them,", Cédric concluded. The OpenOffice.org code base also has six classes for a string, and according to Cédric it should be reduced to just two (for Unicode vs. 8-bit encoding).

But the easy tasks are not only about code cleanup; Cédric also mentioned some more interesting hacks. For example, one could create an XML file fuzzer: a component that takes an existing, complex ODF document, swaps the contents randomly, and loads the result in LibreOffice to see if it crashes. The goal is to make LibreOffice more robust: prevent it from crashing on arbitrary ODF files. Another interesting hack would be to use the C library libxslt instead of the current Java libraries for XSLT (Extensible Stylesheet Language Transformations). And last but not least, intrepid collaborators could help improving the build system.

Cédric also listed some useful development tools. For quick searches in the LibreOffice git repositories, there's the OpenGrok source browser (for now still on the Go-oo.org domain), and there's also partial source code documentation generated by Doxygen. As for an IDE, Cédric warns about using one of the big ones:

Of course, you can also start coding on LibreOffice when you encounter a crash that prevents you from using it ("scratch your own itch"). Then you have to use GDB, Valgrind, or your other favorite debugger and let the backtrace show the code. Cédric gave a tip for this situation: you don't need to build the complete LibreOffice suite with debug symbols for this. Just rebuild the specific module the crash is in with debug symbols. Another place to start your hacking adventures is the user interface: when you see where you'd want to add a feature, look for a user interface string in the same window, e.g. with OpenGrok. But whatever you do, Cédric emphasized that you should get in touch with the LibreOffice developer community when you start coding. Don't work alone, but communicate on the #libreoffice IRC channel on irc.freenode.net or on the LibreOffice mailing list, and find the right experts to assign any bugs to.

Building LibreOffice

Novell's Jan Holesovsky described in his session how to get the source code of LibreOffice, how to build it, and how to get your patches back to the developers. Most of this information can also be found in the Development section of the Document Foundation's wiki, e.g. the "How to build LibreOffice" page. An especially interesting tip that Jan gave was about distributed building. If you have more than one machine, you can install and configure icecream, a distributed build system created by SUSE developers. And with Kiwi-LTSP you can PXE boot computers to add them easily to your build farm.

Jan also talked briefly about improvements of the LibreOffice build process that are being worked on. In the near future, the build directory will be simplified and the translations (or at least the help texts) will be put into a separate build. In the far future, a split build will be made possible: there will be a separate build of the libraries and applications. For example, at the moment you have to build the whole of LibreOffice completely before you can work on a specific application, e.g. Calc. After that, you can just rebuild Calc each time you change it. But in the future, the initial complete build shouldn't be needed anymore.

Next steps

Novell's Thorsten Behrens brainstormed with his audience about what the next steps for LibreOffice's development should be. According to him, QA should definitely become a priority:

Then he asked for some input from the audience, which resulted in a number of interesting ideas. One of the proposed ideas was to make a LibreOffice viewer, especially for mobile devices such as Android. This could fill a gap, because there don't seem to be that many ODF viewers for mobile devices. If it carried the LibreOffice brand, people would trust that the viewer supports ODF well. Better compatibility with Microsoft Office's file formats and a way to import clip art from Microsoft Office (if the license permits) were other proposals.

Another request was that bug reporting should be made simpler. One commenter complained that it takes approximately half an hour for every bug you file. You have to first search if the bug has already been reported by trying a couple of search strings, and then you have to click a lot of buttons with the risk that you choose the wrong options. Michael Meeks chimed in: he sees some value in a simple bug reporting work flow for users. For conversion errors, this could ask the user to take a screen shot of a file in Microsoft Office and the same file in LibreOffice, so that the developers can try to find out where the conversion went wrong. With such a simple work flow, instead of a daunting bug reporting tool with countless options, users may file many more bugs. A project like Officeshots might also be helpful for bug reporting.

A welcoming community

Although the LibreOffice community has a daunting task, a lot of OpenOffice.org contributors have resigned and decided to spend their time instead on the new fork. To visualize this, Cédric Bosdonnat created a graph showing the contributors by week, using the gitdm tool created by Jonathan Corbet and Greg Kroah-Hartman. He also created a video of the first week of coding on LibreOffice, as visualized by Gource. It surely seems like a successful start for LibreOffice, but it remains to be seen whether the project can keep up that pace. One thing is clear, though, from the talks at the openSUSE conference: the LibreOffice community is very welcoming and does its best to lower the barriers for new contributors.