Ploumterview n°2 : Slowness of is not a fate !

par Ploum le 2006-02-18

I often heard people that complain about : it’s too slow, too buggy, it takes too much memory, it doesn’t care about ergonomy. It’s awful but we need it.

OOO splash screen
OOO splash screen

Altought I’m a long time OOo evangelist[1], I must agree most of the time… Sadly… Yes, is great and useful. But if you want to drop MS Office 2000 in favor of our lovely OOo, you must buy RAM, a lot of RAM. Is a proof of the limitations of OpenSource Development ? Is that true that we cannot compete with proprietary software in some markets ?

Michael Meeks is an developper, famous on pgp for his « bullet list only » blogging style. I’ve interviewed him before the upcoming FOSDEM, the 26th february 2006. I wasn’t prepared to hear so much good news in a single interview…


[1] See my talk at ENS Cachan in 2003 (185Mo)

*Ploum* – Please present yourself.

Michael Meeks
Michael Meeks

Michael Meeks – I’m Michael Meeks, Christian, Hacker, Husband, Irritation – that sort of thing. I enjoy working for Novell who pay me to make great Free Software even better for our customers, currently I’m working on OO.o most of the time


*Ploum* – What, in OOo2, ashamed you the most?

Michael Meeks – Well – the quality I suppose, 2.0.0 was later than expected and far too buggy. The irony is that OO.o has a -very- ‘professional’ development setup – complete with tons of tedious process: eg. a small feature requires a written specification, an iTeam, a dedicated QA person, UI review … and yet the result is demonstrably either not that good, or perhaps worse than it would have been if common-sense & peer-review were applied instead. Part of my mission is to try to remove stifling process that kills productivity & drives away volenteer developers, and encourage a more Free-software-friendly approach.


*Ploum* – Some people were disappointed because OOo 2 is almost as slow and « bloatted » as OOo 1.1. Do you care about such advices? And what do you reply to those people?

Michael Meeks – They’re right – OO.o 2.0 performs quite similarly to OO.o 1.1, and yes I care a lot about that. As it happens this is now a big are of focus: my team and I, some lads from Intel, and some of the Sun hackers are all focusing on improving OO.o performance. Since 1/3 – 1/2 of OO.o (warm) startup time is spent in the linker – I’ve generated a glibc/binutils patch that reduces that by 75% – currently festering un-reviewed by Ulrich Drepper. Of course, we’ve also done a chunk of work reducing cold start & 2nd start time, much of which will be seen in 2.0.2 – we now have a systray quickstarter replacing the rather awful previous quick-starter applets. Of course document load time is also a major issue – we’ve been doing some profiling & optimization there – Radek Doulik eg. has some ~5 fold improvement in impress slide thumbnail rendering he’s showing off.

So – sure, it’s great that people keep pushing us on performance – there is a genuine issue here; My short reply to these people is: don’t assume that because OO.o performance (on Unix) is bad that there is some fundamental problem / nastiness here – there is not. Also – optimizing in my experience is a really rewarding process – and there are plenty of unoptimized code-paths left for people to get involved with. As it happens I have a smallish 6Mb(shared) memory saving sitting on my disk as a patch that needs some polish to get up-stream – volunteers appreciated.

*Ploum* – What is the future of and how do you see your own future in the OpenSource world?

Michael Meeks – Well – so, there is some exciting news about OO.o here that has perhaps not filtered out onto the street. We took nearly 2 years of development to get from 1.1.x to 2.0.0 and during that time, -loads- of problems were fixed and tons of features implemented in eg. the first 6 months that then didn’t get debugged / see the light of day for another 12 months, and this was just really bad for building excitement around OO.o.

The good news is that from 2.0.0, we’re making an excellent move: switching to time-based releases every 3/6 months; including new features ( after they have been suitably QA’d etc. ). This will keep a steady flow of new features & improvements coming that can speed up the user feedback process, get more people involved, and may also improve quality: getting bug fixes to people faster. eg. in 2.0.2 we should have: themable icons, optional cairo rendering for slideshows, improved performance as well as a bunch of other small features I don’t know about.

Michael Hacking at FOSDEM
Michael Hacking at FOSDEM

Photo from Dries Buytaert under CC A-NC-SA Licence, modified by myself

So – the future of OO.o is bright – I’m optimistic about it, the more people we can get involved, the quicker it’ll improve & the lower the barrier to entry will become. Currently we’re really just inching up the beginning of this virtuous circle.

My future in OpenSource – I’ve no idea; the OO.o role is very varied and interesting – not to mention challenging & rewarding. Either way – what I like most is hacking – preferably on a project people use & appreciate in their millions; so I’d like to stick with OO.o for some time to come & grow my team there.


*Ploum* – Thanks you for your answers, for coming to FOSDEM and for your involvement in Free Software.

Michael Meeks – The pleasure is entirely mine; thank you.

Emphases in answers are mine. You can read the whole interview on FOSDEM’s site.

One last word ?
If you’re a developer & can’t make FOSDEM do pop into #go-oo on & get stuck in.

Ingénieur et écrivain, j’explore l’impact des technologies sur l’humain, tant par écrit que dans mes conférences.

Recevez directement par mail mes écrits en français et en anglais. Votre adresse ne sera jamais partagée. Vous pouvez également utiliser mon flux RSS francophone ou le flux RSS complet.

Pour me soutenir, achetez mes livres (si possible chez votre libraire) ! Je viens justement de publier un recueil de nouvelles qui devrait vous faire rire et réfléchir. Je fais également partie du coffret libre et éthique « SF en VF ».