Last week we took a look at the issue of what OpenOffice.org could learn from the success of Firefox, a post responding to Luis’ assertion that the office suite had absorbed the wrong lessons from the Seamonkey to Firefox transition. Luis’ entry also elicited an interesting response from the OO.o community itself, which to its credit has recently begun blogging – a necessary first step towards greater project transparency. In answering Luis, OO.o’s Mathias Bauer cited some very interesting performance numbers comparing the load times of Firefox, OO.o, Seamonkey, and Thunderbird. The results show that OO.o lags Firefox and Thunderbird – particularly in a so-called “cold start” situation (a start right after a reboot) – but perhaps not by as much as you might think. There have been, as a couple of OO.o folks wrote me, demonstrable improvements in improvement over the last 12 months. That’s the good news. The bad news is that, as Novell/OO.o’s Michael Meeks says, there’s a ways to go:
It’s pretty astounding that OO.o on Win32 takes 13 seconds to cold start, where MSWord takes ~3 seconds; in fact Word can cold-start quicker than we can warm-start, a little depressing.
After having the opportunity to connect with OO.o’s Louis Suarez-Potts earlier this week, I’m convinced that the OO.o is at the very least well aware of the importance of performance improvement and working on it. We may differ as to the appropriate approach to fixing the problem, but I’m at a disadvantage not knowing the codebase as they do. So for now, at least, I’m content to leave the performance issue until I have better data on whether or not the recent focus on speeding up the application will bear fruit.
Instead, I’d like to turn the spotlight on to a different aspect of OO.o’s continued evolution. With the recent highlighting of its extension strategy, it’s clear that the office suite has ambitions of being a platform player. I say highlighting because Louis was careful to note that OO.o has always had a component based architecture; the focus now is on making it easier for developers to leverage. Whether or not it will achieve that goal via an extension approach depends in my opinion on how simple they can make the extension development process itself; Luis’ skeptical and Dana Blankenhorn believes that the lack of response to the OO.o Clipart and Template contest implies an intrinsic weakness in not just OO.o, but open source more generally. I’m not buying the latter, though I understand Luis’ wait and see approach, because that’s actually how I feel.
The question I’m beginning to consider, however, is whether or not the platform approach can be taken to another level. To explain: let’s assume that first order platforms are more or less aggregators; a platform, in other words, that allows for individual applications or extensions to be layered on top of it, as with Firefox. [1] The second order platform, then, might be one that is more granularly composable and malleable, like a Debian. One that can be customized to meet a variety of needs.
When I spoke with Louis on Monday, we discussed the complaint I often hear about OO.o, which is that it’s slow because it needs to load 85% of itself at minimum to open. We talked, as was mentioned in Shankland’s ZDNet piece, about the componentization of the platform – the process of ensuring that individual pieces of OO.o are as independent as possible from one another. The obvious implications of this are performance; a componentized OO.o – which does exist – should theoretically be able to load much more quickly because it would pull in only what it needed. What if you took that further, however, and imagined an OO.o distribution that included only a fraction of the parent projects capabilities? One that was lighter in weight, but didn’t recover ground already trod by OO.o. One that took a different, less Microsoft Office feature-parity led approach.
Personally, I’d find that interesting. It’s not possible yet, from what I understand of the state of the codebase, and frankly it may never be. But if I was OO.o I’d strongly consider taking a page not just from Firefox but Debian as well.
[1] For the record, I am aware that Firefox’s underlying infrastructure is in fact componentized and used in other applications like Songbird, but the high volume of extensions (or Add-ons as they are newly termed in Firefox 2.0) means that Firefox is most often a platform in the sense described above.
