Category: Interviews

In many countries in the world, Christmas is celebrated as time of peace. In olden days, in the Northern hemisphere, it was the mid-winter celebration – looking towards the new light to come. Nowadays, sharing presents is a popular activity at Christmas time.
So, let’s look at what presents LibreOffice has left under the tree… Ah, this is clearly the outline of a new major version: 3.5 🙂

I’ll try to unwrap this present a little, looking beneath the shiny paper.
What do I see: hundreds and hundreds of code commits, which talk about ‘clean up’, ‘rework’, ‘remove’, ‘easy hack’. Sounds like tech-talk to me. So how is this a great present to users?
I decided to talk to some developers, in an attempt to get an explanation about what all this work means – to mere mortal office-users like (probably) you and me 😉 Simply: what improvements, in which areas, can we see now or in the long run, as result of all this hard work?

Below you find the result of my search. Some parts are technical, some parts really talk about features for users.
I have stress that I was only able to cover a small part of all people and all the work … Nevertheless I hope you like the (greater) present.

Fast building

An important part of the software development process is ‘building’: converting the source code written by developers into something that we can download and install. But building is also important for developers, to prove that their work is OK, that it works as expected, or fixes the bug, and does not break something.

So developers need to build. Frequently. Quickly. So this is where Norbert Thiebaud has a story to tell:
“Yes, my efforts are aimed at making the build process fast and reliable, to give good reliable ‘tinderboxes’ with fast turn-around and useful feedback, so that in turn other developers can have feedback on their work for platforms they do not have access too, and QA can have builds more regularly and more frequently so they can test early…”

The latest buzz word for that is ‘continuous integration’. Code is reviewed and committed quickly: ideally as soon as possible. So then you also need quick feedback. The ‘tinderboxes’ Norbert tells about are machines that produce builds automatically, on all kind of platforms. Then there is a ‘tinderbox-server’, that reports about the status and builds, on a daily basis.

Norbert again: “This means that I do punctual fixing to try to keep my tinderboxes green :-), i.e. they work properly, so that the server shows a green “OK” sign. We are making great progress with tinderboxes. In this month of December, we are at a rate of 100+ builds a day. Back in April, that was only about 30!”

Lionel Elie Mamane, who will talk later about Base, also contributed in the field of building: “In my early days of getting started building LibreOffice, I stumbled upon a few things that annoyed me in the config/build system, so I fixed them.

“One annoyance was that there was a mysql-connector file that would be downloaded after configure finished, but yet configure failed when the file was not there. A catch-22 🙂 and now that I fixed that, there is a smoother ‘first build’ experience for newcomers.

“Other small things involved stopping the unnecessary creation of many symlinks (so giving a speed improvement here), and enabling colours in the build output for 256 colours, instead of the the old standard 16. This makes development easier, as compilation errors stand out in colour on the screen.”

Proper release building

Builds that are to be released must of course must be good ones. Petr Mladek tell us how this works: “Most of my work is related to producing all official builds, so code wise that means that I fixed build problems. And of course a lot more build related stuff. Since there was one build almost every week, I spent a lot of time with it. Beside that I helped to merge useful scripts from the old build repository. They help package maintainers to provide LO for different Linux distributions. There were many more people helping with this.”

Since builds are also used by QA volunteers for testing, special work was done for that too. “One of the items was fixing Linux packages, so that the different 3.x releases can be installed in parallel. It is useful especially for testers but also for normal users. I also added more precise version information, e.g. beta2, to the the ‘about’ dialog. It should help testers and users to better describe the installed application and provide better bug reports.”

Easy-hacks as a good starter

Now, some words from Olivier Hallot, one of the founding members of The Document Foundation: “LibreOffice code was a challenge for me since the OOo days. I succeeded in compiling it, and the next step was naturally to try one of the easy-hacks suggested by the developers. I found these easy-hacks the best way to get knowledgeable in C++ coding, and I started to fix some UI issues I found in my language. From a simple hobby to a more serious job, now I am involved into the enhancement of LibreOffice. Plenty of fun times!”

Cleaning up: for improving and easy developing

Easy developing .. well, as easy as possible! Tor Lillqvist is one of the developers who worked on that: “I cleaned out many obsolete bits and pieces. This makes it easier to start developing, there is less obsolete or irrelevant stuff to waste time looking at.”

Part of the work Tor does is related to enabling cross-compilation:
“Cross-compilation makes it possible to develop on a fast machine for slower machines, or for machines not running a desktop operating system at all. So now on Linux you can produce an executable for Windows, but not an installer yet. The Lanedo people are working on this.”

Though not directly related to this clean/improvement interview, Tor also wants to add something different: “Yes, for iOS and Android the compilation part is finished too, just a few days ago. But be careful: in no way does that mean there is a version already running on those devices. Just that people interested in working on the UI side now have a solid base to work upon.”

Lionel Elie Mamane also did some general code cleanups:
“I removed unnecessary const casts, unused variables, … This makes the code more maintainable, easier to understand, etc. Const casts are ‘holes’ drilled through a safety feature of C++! So removing them when they serve no purpose helps to catch future programming errors.”

A special cleanup case was the old OpenOffice <-> PostgreSQL driver. “That was ‘bitrotten’ as we say. It only worked up to version 3.2 .. So I reworked it: integrated the native LibreOffice <-> PostgreSQL driver into LibreOffice proper, enhanced it, ported it to the latest LibreOffice version. Lots of advantages for PostgreSQL access obviously.”

Code readability

If you want to make it easy for part-time developers, students, beginners and so forth to work on the code, then good readability of the code is very helpful. There are many examples. Olivier tells about a easy hack that aims to replace the test for strings inside the code: “Previously, to test when a string is empty, you had to get the length of the string. If it is zero, the string was empty. Recently, a new method isEmpty() was written for the same purpose. The job is then to replace getLength() by isEmpty() in all the code: a very laborious task. But the end result of this re-factoring is much better code readability.”

What can users see ?

Working with RTF documents gets better

While others work on general code clean up, the work of Miklos Vanja with regard to cleaning/replacing is strongly focussed in one area. Miklos:
“During the last two summers I have been working on the Writer RTF filters. Both the export and the import filters were old code, with known design issues. So it was time to redo and create new ones. Export was new in 3.3, import will be new in 3.5. Now that makes it possible too to add features in our RTF which have been missing for a long time, such as nested table support, which was introduced by Word 2000 in RTF.”

Miklos always welcomes example documents which are not yet fully handled by the new filters, so that the import can be further improved.

Calc

Improved testing, especially in Calc, is also worth a note. Markus Mohrard is working there: “One of the areas that I have been active in is automated testing work. This really makes the work of developers easier, and reduces the risk of introducing bugs in new and changed functions. Our Calc filters-tests are a particularly nice way to discover bugs quite early. They showed around 15 really nasty Calc bugs, and at least two older bugs in LibreOffice core. From the bug number we see that these are mostly newer bugs that might not yet have been addressed in OOo, and some are our own bugs.”

Markus points out these are new tests, that are fast and reliable, and are run during most developers’ compilation flow – so we can be sure: if it compiled, it will not have these regressions. He stresses that it is not only important, but also really easy, to extend the tests!

“What I did was to download all ods, xls and xlsx files from several bugzilla instances and used this filters-test concept to check if any of these files crash Calc during import, or during the initial calculation of the content. This showed another set of bugs that Kohei, Eike and I fixed before we branched 3.5 off.
“More than 4,000 documents were checked with this approach, which has already significantly improved 3.5.0.”

Another developer: “I removed some unused code and fixed bugs, mainly some that were already introduced in 3.4, and some in master that went unnoticed, or indeed were reported.”. This is from Eike Rathke.

Speeding up

Eike Rathke is one of the long established developers we know from Sun/OpenOffice.org. He starts off by talking about his vacation:
“Summer was so poor in July/August that I started to work on LibreOffice 😉 I joined RedHat in October, the Monday right after the LibreOffice conference. One of the things that I reworked then, was the class ‘Date, Time and DateTime’. In the old code, the system time was obtained every time during construction. This is unnecessary just to declare a variable. Together with related checking and updating, this resulted in many many unnecessary system calls, which are now not happening any more in 130 out of approximately 350 occurrences. “I expect to have gotten rid of a gazillion of calls to localtime with this change 🙂 Sorry, no real numbers on that.

“Of course I also fixed a lot more code, reported and unreported bugs, the work that “Moggi” Markus Mohrhard has talked about. And I merged some fixes from CWSs pending from (A)OO(o) still under LGPL, and applied/pushed patches. I also helped Moggi improve the Calc named ranges/expression handling, especially with sheet-local names and copy & paste behaviour. ”

Base

Moving on to Base, Lionel has a lot to tell:
“Overall, I’d say I focus on making Base (with scripting) usable again, because I want to use it at my daily job, to replace the Microsoft Access-based business-specific programs I developed in the past. And it was quite broken in early 3.4. Further I fixed some user-visible bugs, e.g.: margins in reports; better, more widely supported, syntax for reporting based on a query + sort; fixed several crashes, fixed PDF-export.

“Maybe most important of all is that I re-enabled ADO (ActiveX Data Objects) on Windows; yet another “common API” for access to SQL databases.” He also made enhancements to passwords, metadata, queries, joins:
“With my work in LibreOffice mostly I ‘scratch my itch’, and I take care of bugs and features where I feel uniquely interested and/or competent: database stuff!”

Lionel stresses that the LibreOffice community has been exceptionally welcoming and quick about recognising his efforts.
[Let me (reporter) remark that it looks a nice idea to have a post somewhere with little more details on Lionel’s work.]

Various easy hack-UI improvements

Olivier Hallot was glad to spend time on several easy hacks, resulting in better usability, interface etc.:
“One hack is about improving the extension manager dialog. Now it allows the user to filter the installed extensions, de-cluttering the dialog and easing the search for an installed extension. Another simple one is adding the command ‘Protect Sheet’ to the sheet guides context menu. I also added 8 new symbols to LibreOffice Math, used in game theory equations. The demand came from a college math professor.”

One of the interesting parts of LibreOffice of course is the localisation. Sometimes that results in strings that are so much longer then the English ones, that the texts don’t fit .. Olivier: “Therefore I made several adjustment in the dialog boxes, to accommodate non-English strings, which are a bit longer and were truncated in the UI.” Another example of improved UI readability.

So, what a Christmas present! And this is only a small snapshot from a few of the hackers we managed to drag away from bug-fixing the 3.5.0 betas – there have been many more, more visible improvements – you can see some in the 3.5 wiki page

(by Jorge Rodriguez and Hans de Vries)

Please, tell us something about you and your activities? And how you became involved with Open Source Software and LibreOffice?

I started to get involved with Open Source when I was still a student. I got involved quite a bit with Gentoo (the Linux distribution) in its early days, somewhere around Gentoo 1.2. I even wrote some tools for it, only to scratch my personal itch, but it seems that for example ‘etc-proposals’ is still quite popular. I kept being involved in Open Source, although my first job after graduating from the university was not Open Source related. In 2008 I joined Sun’s OpenOffice Writer team, motivated by the opportunity to work on one of the biggest – and most important – Open Source projects in the world. I learned quite a lot about the codebase and the product there and in turn could bring in some experience from the sometimes chaotic, but always dynamic ways of Open Source projects. As of February 2011 I am employed by Canonical and take care of LibreOffice releases on Ubuntu. Since that date I am contributing code changes directly to LibreOffice. Later I also joined the Engineering Steering Committee of LibreOffice.

How was Hackfest 2011?

It was delighting in its concentration on the essentials. There was: a room, food, a possibility to sleep, a build server (in case you didn’t bring your own hardware to build LibreOffice) and there were lots of cool people to meet.

Hackfest 2011 was an Unconference (see http://en.wikipedia.org/wiki/Unconference) in its best form. It provided exactly what was needed without bureaucratic overhead. Comparing Hackfest 2011 to the then still related to OpenOffice.org Hackfest 2010 in Hamburg, there was a tremendous growth in participants and interest. If this growth continues, some more organization will be needed or the Hackfest might become a victim of its own success. On the other hand, that might be just German over-cautiousness on my part. 😉

There were eleven topics to hack. As I saw the hacks, you were the mentor for Christoph Lutz. Can you tell us something about how you and Christoph came to work together?

Christoph already had his mind clearly set on the topic, which he choose himself. I only became his mentor at the Hackfest. I just noticed what the problem was he was trying to solve at the Hackfest and that I had already meddled quite a bit with related code. So naturally, as these things go on Hackfests and Unconferences, I became his mentor.

In a few words that a newbie can understand, what was the problem that you were working on (‘Non-linear execution time in mail merge’)?

If you had a mail merge document with bookmarks in it, which is quite common in corporate environments or public authorities (like the City of Munich), creating the merged document would get needlessly and unbearably slow with a large number of repititions/recipients.

Did you and Christoph manage to solve that problem?

Yes, the goal to speed up mail merge in this scenario was archived. Actually any scenario with large numbers of bookmarks existing in one document has been made faster.

Did you encounter any difficulties working on that hack?

I didn’t expect any, but there always are some. For example the issue documented at http://nabble.documentfoundation.org/Patch-for-MarkManager-td3308412.html. Fortunately, these issues have been quickly dealt with, so we now can enjoy the fruits of the effort. Quite a bit of work was put into getting Christoph up-and-running with callgrind (http://valgrind.org/docs/manual/cl-manual.html) to safely confirm where exactly the problem was. Once that was done, fixing the issue was the easier part in the end. At least thats how I felt about it. I cant speak for Christoph’s experience here.

I read you are also working on the Gerrit project (aimed at code review). Can you tell us something about that?

We installed a test instance at http://gerrittest.libreoffice.org/ at the time of the Hackfest which is offline again now. It basically worked (kudos also to Norbert Thiebaud, who — among a thousand other Good Things he does for the project also tested Gerrit with me), but in the end we found we needed much more resources for hosting Gerrit than that virtual machine for testing could provide. This is currently being addressed, so that does not invalidate our general assessment that Gerrit would be good for the project and is desperately needed (see http://nabble.documentfoundation.org/Minutes-of-the-tech-steering-call-td3362130.html for all the gory details). More on this topic will be presented in all its epic broadness at the LibreOffice conference in Paris. I invite everyone who is there (and not only developers!) to join that talk as it will also address the general question of “how we communicate” and changes to the source code are the most important means of communication between developers.

Is there a final document or presentation where the all results of all hack topics achieved during the Hackfest are saved? And could anyone interested in these results access it?

http://wiki.documentfoundation.org/Hackfest2011 is still the best with regard to this topic as far as I know. There are no restrictions on access once it is written. However, not every participant might be inclined to spend too much time on documenting progress when he/she rather likes to fix a few more things. So, of course such documentation is valuable, but it is also a trade-off against hacker productivity. More fundamentally: you can’t force volunteers to write documentation when they’d rather write code.

Also I like to note that there were open discussions I had (for example with Andre Schnabel, Christoph Noack, Florian Effenberger and Italo Vignoli) about the general direction of the project that I found extremely valuable. The outcome of those discussions often  can’t be nailed down to some direct result in the product, but they gave me a better perception of the project as a whole.

Finally we had a good chance to exchange quite a bit about the little tricks that everybody uses to make work on LibreOffice easier “on the fly”, just by watching each other work. Even better of course, if this gets documented, which is what Regina did here: http://wiki.documentfoundation.org/User:Regina/DraftParametersForAutogenForWindows for building LibreOffice on Windows.

Finally, in general what do you think of Hackfest 2011?

It was awesome and way more than I expected. In fact, I fear a bit that further growth of the Hackfest might destroy its cozy productivity. Maybe we need more Hackfests?

What made you decide to become a LibreOffice developer?

I was a full time developer on the codebase of LibreOffice at Sun/Oracle a year ago. I had a gut feeling that the Document Foundation had a much better idea of where to take LibreOffice long term and a better understanding on how to handle a open source project as a whole. When I got the opportunity to work on Ubuntu and LibreOffice for Canonical, I didnt miss it.

What did you do to familiarize yourself with the code and development model for LibreOffice?

I knew the code quite a bit from my previous job (and http://opengrok.libreoffice.org/ helps a lot for the areas that I am not fully acquainted with), however I needed to (re-)learn the (actually much simpler) development model. There are three important channels that helped me to learn about the development model in practice:

• IRC
• the developer mailing list
• the wiki

Once you knew how things were done, what was your first contribution? And why did you choose to work on that?

Making LibreOffice 3.3.X the first LibreOffice release on Ubuntu with Natty was the first thing I did — along with a lots of odds and ends towards that. It was the primary task I selected with my new job.

If you look back at that time and what you learned then, what advise would you give new developer’s (not necessarily well-seasoned ones) to make those first steps easier?

a) Start off with an Easy Hack:

http://wiki.documentfoundation.org/Development/Easy_Hacks
http://wiki.documentfoundation.org/Development/Easy_Hacks_by_required_Skill

b) Find help on IRC or the developer mailing list

It might help if you name the Easy Hack you are intending to work on, as seasoned developers are esp. interested in helping new contributors with a clear goal — it also helps finding others who are knowledgable about that area of code.

What are you working on at the moment?

Last week I was mostly setting myself up for the LibreOffice 3.5 release to be shipped with the “Precise Pangolin” LTS release, and identifying what I need and can do for that. The parts relevant to LibreOffice can be mostly be found in these two blueprints:

https://blueprints.launchpad.net/df-libreoffice/+spec/libreoffice-3-5-engineering-steering
https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-libreoffice-packaging
http://status.ubuntu.com/ubuntu-precise/u/bjoern-michaelsen.html

If you had unlimited resources, what improvements or new features would you like to see added to LibreOffice?

With unlimited resources, that question isnt too tricky, is it? However, if I had a limited set of additional resources at my will, I would use it to be even faster with streamlining our existing features and functionality. And if I had — because of the additional resources — more free time at hand, I would try to implement nifty Calc chart visualizations with the OpenGL Shading Language that you can walk/fly around in. But dont tell anyone, as it would only be fun if I do it myself! 😉

Coding LibreOffice to relax a bit from studying tough mathematical problems? Read why and how Markus Mohrhard works on LibreOffice!

LibreOffice can only exist since people are working on it: so please ! tell us a bit about yourself.

I’m a third year math student and have always been interested in computer science(which is even a subsidiary subject for me). I’m always interested in anything new in math, physics and computer science and try to learn as much as possible in these areas.

In what other software projects have you been involved ?

I’ve been working on a university project for about one year now. This project is mainly about model to model transformations.

Where do you live (and study)?

I live at Karlsruhe and study at the Karlsruhe Institute for Technology (formerly know as university Karlsruhe)

What do you do when you’re not working on LibreOffice ?

Mainly studying, but in my free time I do sports or just do something with my friends.

Ah sports means healthy people in the project 🙂 …so, what type of sports?

I’m jogging and playing football. But since university I have no more time for doing this in a club only with friends and in my free time.

When do you usually spend time on the project ?

Mainly in the evening and during nights. Mostly when I have some math problems which drive me crazy and I need to think about something else for some time.

Working on LibreOffice code to relax – could be worse 😉
Do you have a preferred text editor for this relaxing work? And why?

Notepad++, Vim and Gedit. Depending on what I’m doing. Notepad++ is my prefered editor at Windows and sometimes I miss it in Linux. I think for developing in Linux there is only the choice between Emacs and Vim and I just prefer Vim(even if it sometimes drives me crazy). And I like Gedit for its simplicity.

How did you hear about LibreOffice ?

I’m following a tech news site and they report regularly about Libreoffice and the Documentfoundation. I liked the idea of an independant foundation behind LibreOffice that would not force developers to sign a CLA.

Why did you get involved ?

I’ve always wanted to contribute to an open-source project. After I discovered the Easy Hacks page my decision was made and the community made it really easy to get into the development. Especially Kohei helped me a lot to understand the code around calc.

What was your first contribution to LibreOffice ?

It was a one line change to fix a problem showing the right shortcut. Nothing special but I learned a lot about the structure of LibreOffice there. It was about the crasher bug (fdo#37429) and listed and the most annoying bugs. As soon as I found the problem (which took a lot of time) it was just a one line change.

What was your initial experience of contributing to LibreOffice like ?

It was amazing how positive the core developers react to someone new and how much they encourage someone to go on. Even when I started working on my autofilter patch and made some really bad design decisions, they helped me every time with some hints how I can improve my code.

What have you done since then ?

I’ve written some code to support one autofilter per sheet in calc and the corresponding import and export filters(thanks a lot there for Kohei’s help). Since then I’ve fixed several bugs and started working on supporting an unlimited number of sheets in calc together with improving the performance in some situations.

What do you think was your most important contribution to LibreOffice so far ?

For me it is the support for one autofilter per sheet, but for others it might be one of the bugs I fixed.

How will that improve things for users?

This was a long requested feature and improves the compatibility to Excel a bit. There was a workaround for this this but it was extremely uninitive, so I hope that a lot of people can benefit from this feature.

What is your vision for the future and/or what would you most like to see improved ?

It would be amazing if more people would help in the QA and help the developers to find bugs much earlier. I broke some minor things with my patches but they were not detected before RC1 and I think our quality could improve if there were more people testing the nightly builds or beta builds.

Anything else interesting you get up to when not hacking ?

I’m playing chess and doing sports regularly. But I’m always open to new things and try something different. I’d like to travel to other countries more but that will not possible as long as I study.

Thanks a lot for your answers and time!