Novell’s Michael Meeks talks LibreOffice 3.3, The Document Foundation & Oracle
LibreOffice 3.3 has arrived to liberate open source offices. We recently caught up with Michael Meeks, a distinguished engineer at Novell and a contributor to the LibreOffice project and discover quite how much of a difference an active community can make to the neglected OpenOffice.org codebase…
How has the OpenOffice.org community responded to the formation of the Document Foundation?
It’s safe to say, many of the people who worked on OpenOffice.org have transitioned to us. The Oracle community council is composed of entirely Oracle employees. It’s a shame, and we regret that. We invited Oracle to join the Document Foundation; unfortunately they didn’t take that option.
Is this a fork?
I think whether it’s a fork or not is up to you. Simon Phipps said it best: if the community keeps it going, and the corporate sponsor goes somewhere else, who forked?
Is Novell doomed because of its dissolution and acquisition by Attachmate and some Microsoft-associated companies?
I’d like to refute the idea there’s some major changes going on in our approaches. We’re continuing very much as is. I think when you look at Novell and SUSE, there are some great projects there that are making revenue. It seems like a valuable thing to buy, and I am looking forward to working for Attachmate. I think it’s easy to over-hype the uncertainty and change. We’re a great business in a great space.
How many of the everyday bugs have been fixed? Word counts never worked, automatic capitalisation has always been a pain, bullet points are ridiculous to use if you want a number at the beginning…
There have been a number of usability fixes. You can now use the spreadsheet to handle formulas, and we got word count to work right. There are volunteers that got annoyed about this, too, and have fixed it. I was more interested in a build and release project. There have not been any unit tests that run in the codebase, for example. One of our thrusts has been adding a good number of compile-time unit tests. That sounds easy to do, but there’s a reason it wasn’t done before. There was code for tests scattered around, and none of them were enabled. This is some licensing snafu. There was some cock-up that broke all the tests that did exist. Luckily, now we have some real unit tests, so as you change objects you can test those objects.
Also, before there was an opt-in approach to memory management: use it if you want. IBM has some neat work for this. OpenOffice.org would save and load a lot; then when we saw the memory graphs, they were not encouraging. We fixed a number of crashes that relied on that behaviour.
What is the best bug fix you’ve seen so far?
There’s a guy called Joe Powers. He got involved in the project with his first patch. It was something really trivial, like a comment fix. He said what do I do next? We said why not go look at BASIC a bit? A patch comes back later for this bug that was filed in 2005. The test case shows the BASIC language is printing out 1,000,000 as 1. He sent in a fix that included a regression test, and it was just a missing < symbol. It’s great that this was something that was left unfixed for so long. My suspicion is the accumulation of lots of this kind of fix adds up to an accumulation in the long run.
How well is the source commented?
The codebase has tons of German comments in it. We have nearly 100 million users, so it’s a shame when they see something they did like and they want to jump in and the codebase seems impenetrable. We have hundreds of thousands of lines of German comments, and we have some Germans cranking through and translating them. Loads of dead code has also been removed. For all our 8 million lines of code, a lot is commented out, or doesn’t work.
There’s been quite a culture of risk aversion. I think just changing that culture should produce code that is beautiful. It doesn’t have to run well, but it should be easy to read.
Norbert Thiebaud removed a library that’s been deprecated for ten years. It was effectively an entire duplicate of another library that was never used. We’re yielding tangible wins from a developer perspective.
It sounds like the codebase was a mess. Was it worse than other projects you’ve been on?
If you look at almost any commercial proprietary product that’s developed in a proprietary company, this is what it looks like. I think our code is even better because it has been open for a while. I don’t think the code is that bad compared to some of the code I’ve read in other proprietary products. There is a lot of opportunity to clean up. It’s easy to get involved, it’s easy to make a difference. There’s a page with easy hacks on the site: things I don’t even need to compile to fix, like German comments. If you’re German, there’s immediate space for you on the project. People want to push on the door and see if it’s open first. People want to submit a small patch and see if it gets in and how quickly it happens.
What’s your next major fix for the project?
Personally, I’m trying to fix our packaging problem. We have a lot of languages, and a great number of translators doing work. There are 55 core translations nearing 100 per cent. The problem has been that we build a 160MB package for each language. The only amount that’s different is a few megabytes’ worth of code. We then upload multiple duplications to a mirror system that tries to mirror this everywhere. This is not a good way to do anything. It takes a long time to build. I have spent a lot of time trying to unify that into a single package. It also adapts in the Brazilian locale to be Brazilian Office. Originally, this was done for trademark reasons. There are some great guys down there and they use LibreOffice, but still called BrOffice.
How many platforms are supported now in LibreOffice?
We’re pretty much there on all platforms. We run on OS/2, we compile for ARM Linux, PPC Linux, x86 Linux and IA64 Linux. We build on Windows; I believe we have 64-bit binaries too. We did a huge amount of work on the 64-bit port back in the day, which was quite a bit of fun; writing tools to check it. I think a side effect of some of the work cleaning it up is hopefully making it smaller and neater. I think one of the joys in this is as the years go by, the devices get so much more powerful anyway. Now, we’re looking at some iPad tablet thing, with some massive CPU in it. I’ve seen us run on small arm handheld devices.
Why is LibreOffice 3.3 the future of open source office software?
LibreOffice 3.3 is the most feature-rich free software office suite there is, and it is nice to be able to load your documents, save them and to be able to interoperate with your friends. Furthermore, LibreOffice is growing, both in terms of code, and community at an incredible rate – its trajectory and the interest in it outpaces any other equivalent free software project that I have seen. While the code is in need of much love and improvement, it is getting that love – and improving rapidly.
What are some of the new features you’d like to see in future versions of LibreOffice?
Wow – well, where to start? The user interface needs substantial improvement to both expose more of our power features and make them easier to use. Performance of import, export and handling of huge spreadsheets needs to substantially improve, with threaded re-computation added to Calc. Then, of course, the code needs much more cleanup, translating and we need to start knocking down the remaining feature-gap to Microsoft Office. We need to shrink the installation and download sizes, while continuing to integrate more useful extensions, and translations. There is a lot to do – and much of this is simple work that we can get new developers involved with: please point people at the Easy Hacks page in our wiki.















What's your opinion?