Having been the beneficiary of Luis’ excellent GPLv3 analysis, it would be rude of me indeed to not honor his request for feedback to his Firefox / OO.o piece. While I’m many things, I try not count rude among them.
Besides which, the question Luis is asking is both good and one that I’m fielding with some frequency. So while the Q&A format may not have worked that well for my network offering piece last week, let’s see if we can’t answer some of the important questions here.
Q: Before we begin, how about the usual disclaimers?
A: IBM and Sun, both of which have interests in the OO.o project are RedMonk customers. As for the project itself, I’ve been more or less a full-time user of OO.o since I switched to Linux on the desktop in August of ’04.
Q: What’s the basic contention here? What’s the nature of Luis’ criticism?
A: It’s more or less outlined in a piece he wrote two years ago, when he said the following:
In my humble opinion, OOo should to take a page from the mozilla folks- take a release cycle (or more) and focus exclusively on improving performance and usability. No new features. Even remove features if necessary. This is what firefox has done over mozilla, and that’s done wonders for firefox, both in user uptake and hacker uptake. They’ve gone from dozens of paid hackers to something like ten, and despite that, because of the new focus, still increased market share and hacker interest. If open office focused on those problems for a year, licked the startup time problem, and made (say) preferences less grotesque, I think they’d see a radical improvement in uptake and involvement. Frankly, people are excited about switching from IE to firefox, as far as I can see- it offers something fairly light, quick, and new features virtually every user will use and like. No one except people who loathe Microsoft are excited to switch to open office, and they won’t be until the speed and usability issues with open office are addressed. Sadly, I see no evidence that OOo is focused on these problems- if OOo wants to be competitive and relevant, if it wants to excite people, those must be job #1 for the OOo team.
The good news, from Luis’ perspective, is that the OO.o gang did indeed follow in Firefox’s footsteps. The bad news is that they pursued a plugin strategy rather than focusing on performance and usability. While I’m sure the OO.o devs would (strongly) contest the notion that they’re not paying attention to performance and usability – with some justification (2.0’s been far more performant for me) – I think the objection would ultimately be sustained rather than overruled.
Q: So the problem is not that OO.o isn’t learning from Firefox, it’s that they’re not learning the right lessons?
A: Correct. In the first piece linked to above, Luis remarks that even two years later, the above is still true. And he laments the plugin decision, saying:
Plugins do not solve core problems in your product- not when those problems are lack of stability, lack of performance, lack of ease of use, lack of Killer Feature that your competition lacks. That OOo is spending time adding a plugin infrastructure- which addresses none of those problems (except hypothetically the killer feature problem, someday, if you get lucky)- shows that again they still aren’t getting it. They still have not learned the right lessons from firefox.
Q: And you? How do you personally feel about the decision to pursue a plugin strategy?
A: As I told News.com’s Stephen Shankland, I’m mostly positive on the possibility. I’ve been very complimentary of the plugin approach Firefox has pursued, saying:
I tend to believe that the Firefox/extensions model is the best of both worlds, where the base product is simple, but advanced users can extend the functionality to suit their individual needs with plugins and addons without compromising the overall simplicity.
The extensions are, frankly, what’s kept me on Firefox despite some very unfortunate memory management in version 1.5. So there’s no question in my mind that extensions can be a huge benefit to a would-be platform.
But it’s also necessary to temper those expectations with the realization that Firefox and OO.o are different animals altogether. As I told Shankland, the addition of an extension architecture “would not be as significant as it’s been to Firefox, simply because it’s far easier to switch browsers than office suites. But it could make OpenOffice.org a more interesting and compelling platform.” The difference, in my view, is what’s key to understanding the nature of Luis’ complaint.
Q: How do you mean that?
A: Consider the context for the original complaint – poor performance (e.g. startup time), poor reliability (e.g. here), no killer feature (see my comments on where to innovate here). Are these legitimate concerns? Absolutely. As much as OO.o has improved, it’s still got a long way to go before matching its biggest competitor in terms of speed. While some OO.o advocates have pointed out that Microsoft is faster because of how and when it preloads things, or leverages features preloaded by the operating system, I’d respond by pointing out that from a customer perspective that’s irrelevant: Office is faster.
The logical step, at this point, might be to look for precedent in large, bloated applications that went on a diet and came out lean, mean and – most importantly – speedy. Enter Mozilla Firefox. Born of an overlarge and complicated suite, Firefox ruthlessly refactored and junked features getting down to be – if not exactly svelte – far lighter in weight and dramatically more usable.
The moral of that story, to many including Luis, is the same lesson imparted to be by just about every coach I ever had: speed kills. Anything, therefore, that OO.o can do to get faster, is not only a good thing, but a great thing. Potentially a “must have” thing.
And I don’t necessarily disagree with that statement. I just don’t think it’s remotely practical in one or even two or three release cycles – barring an outside donation and intervention.
Q: Why is it not possible? And what do you mean by outside donation / intervention?
A: It’s about the apples to oranges nature of Firefox vs OO.o. I don’t have handy codebase size comparisons between the old Mozilla and the full OO.o suite, but I’d be very surprised if the latter was not more complicated than the former by a significant margin – possible a hundreds of thousands or maybe even millions of lines of code margin. I don’t mean to imply in any way that distilling Firefox from the Mozilla suite was trivial, but distilling out simple, fast applications from the huge, complex and multi-language OO.o codebase is not going to happen in a release, nor even a couple of releases. IMO, anyhow – those with more intimate knowledge of one or both codebases are invited to contradict me if I’m wrong here.
There is a vendor that has done significant refactoring of the codebase, forking it in the process, but at the present time they’re either unwilling or unable, depending on your perspective, to contribute that work back to the parent project. That’s IBM, for those of you who aren’t closely involved with the project’s politics.
And speaking of politics, I’ve fielded complaints from time to time about the development process behind OO.o; complaints that contributed to my call for an independent OO.o foundation. A call which largely went ignored and uncommented on. I’ve been told since that conditions had improved, and that some of the justifications for this initiative had been addressed, but I’ve also received continued complaints.
Anyhow, if you add all of that up, it’s my conclusion that a slimmed down OO.o is simply not in the cards any time soon. I’ll have to speak more with OO.o’s Louis Suarez-Potts – who I’ve met before and is very sharp – about the planned componentization mentioned in the Shankland piece, but I stand by that conclusion either way.
Q: So you’re saying that OO.o would be unwilling to consider the type of action that Luis’ proposes?
A: Let’s use an analogy. If Firefox is like my parents Triumph Bay 190 – a light, agile 19 foot powerboat drafting less than a foot – OO.o is more like the 125 foot tour boats out of Boothbay Harbor. Not terribly manuoeverable, and once a course is set change comes only slowly. So even if OO.o unanimously decided tomorrow that the Firefox course of action was the appropriate one, they’re not getting there next week, next month, or – in all likelihood – next year. When you’ve set youself the goal of feature parity with Microsoft Office, you’ll achieve that – invariably – at the expense of project agility.
Q: In the absence of an ability to make that type of change, then, you view extensions as an attractive second choice?
A: Precisely. In a perfect world, I’m with Luis; I’d love to see OO.o skip a cycle and return Firefox-style. I just don’t see that happening (although if the effort had been started when Luis initially called for it, things might be very different – and I suppose there’s always the possibility of a project run in parallel). In the interim, then, I’m a fan of trying to extend what has otherwise been a very traditional (read: not terribly innovative) platform by allowing developers to scratch their respective itches via plugins.
Q: What is the overall significance of this decision, do you think?
A: It depends, I think, on what ongoing importance you ascribe to the notion of a rich client office suite. In other words, do you think that office suites will remain the hub of productivity going forward, or will they become increasingly niche products catering to just the most complex authoring tasks? My own usage (and my experiences with email) indicates the latter. My research – both professional and personal – supports the former. The truth, as always, is probably somewhere in between.
What course will OO.o pursue (yes, I do believe that it will have to pick one)? Will it continue in its efforts to mirror Microsoft’s suite closely? Or will it break off pursuit in favor of a different end state, one in which it’s more of a complimentary offering to web native office offerings? Probably the former.
In either event, the plugin strategy could help. But Luis’ not wrong; if the goal is out-Officing Office, the aforementioned problems need to be solved, and solved quickly.
