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.
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.
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:
There is no full-fledged integrated development environment that can handle that much code. This includes Eclipse, NetBeans, and KDevelop. Instead, I prefer using Emacs or Vim with a C/C++ configuration, supplemented with an index and search tool like ctags. For such a big code base, searching with grep isn't useful, and therefore we have also set up a make tags make target.
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.
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.
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:
Historically the code base had not much unit tests, so if you changed something you needed to test it manually. Moreover, the only unit tests that are present are for base libraries. It's really important to have more unit tests, to feel sure that if you change something you don't break things.
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.
to post comments)