tecosystems

What (Should) OO.o Be Learning From Firefox? The Q&A

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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.

5 comments

  1. [Random mutterings of a Civil Procedure-deranged mind, perhaps something more coherent on my blog later this week…]

    I think a big part of the problem is the goal of out-officing office, really. Maybe I should have been more explicit about that when I discussed the need to slim down. Microsoft is always going to build a better Office than OOo is- they have a huge lead, they have the initiative in creating new expectations, and they have the resources. So OOo needs to find the game that MS Office isn’t playing and that is really appealing to users, and fight on that ground, instead of gigantic feature lists. For firefox this was tabs and security, and now it is plugins. For OOo maybe the game MS won’t play is cheap and easy collaboration; maybe it is open formats (though I doubt that is really a killer feature for anyone except governments, sadly), maybe it is something else. However you slice it, just pursuing the laundry list of features MS has already done is never going to be sufficient.

    [I admit that I’m not sure if there is space between Office and Writely, et al. But frankly beating Office is not going to happen; beating Writely might. So they should probably try 🙂 [Plugins, if people enjoy using the base, simple system, of course allow for you to beat Office in particular niches. But that assumes people want to use it in the first place, I think.]

    The size factor between old Moz and OOo, if I remember correctly, was 2-3x- 4-8MLOC v. something like 12-20. Well less than an order of magnitude, but definitely multiple millions of lines of code.

    That said, I don’t think the “we’re too large a ship” argument holds water. I’m not demanding immediate results in the code- obviously that is impossible. I’m not expecting that. All I’m asking is that everyone on the ship row in the same direction- the direction of ‘not sucking’. It is pretty easy to figure out if this is happening. Is some engineer, any engineer, paid by OOo to work on something that is not a massive improvement in the direct user experience? If the answer is ‘yes’, then their priorities are broken, because lets all be honest- no user is excited to use open office. People grudgingly accept openoffice, because the other options are too incompatible, too expensive, not available on their platform, etc. So if they have people who aren’t working directly on that problem, right now (and I’d argue that a plugin system is not solving that problem right now) then they’ve got a direction and vision problem that needs to be fixed.

    Of course 2.0 is better than 1.0, but… yoiks. 🙂

    And to your conclusion, that plugins are an acceptable second-best… hrm. They are certainly better than nothing. But OOo is already second-rate in too many ways. If they are settling for second-best for their users, I’m not sure I see much hope for them. Thankfully, with their great work on ODF, I’ll have a lot of tools to choose from to edit my odf docs in the near future. 🙂

    Oh, and next time you’re in Manhattan, Steven, I’m going to ply you with beers until I hear IBM-OOo stories 😉

  2. How many outside contributors have commit privileges to OO.o’s codebase? Honestly haven’t checked but am curious… I’ve never actually combed through the OO.o codebase, but I’ve heard it’s a mess and I’m well aware it takes quite some time to compile in Gentoo… possibly the only app I’m prone to using the -bin instead of source for.

    It’s a shame as you point out that more community members are not involved with OO.o … and that must make you wonder why… there’s so much potential – what’s keeping the usual suspects at bay???

  3. i tend to agree with luis, especially given that Office 12 is going to fundamentally change the game wrt to office user interface – through the ribbon. it really is a GUI shift of real note.

    On the other hand- plug-ins will at least let us see what kind of functions might be the kind that allowed oo to play between writely and MS office. its about what stephen said on innovation yesterday – if you don’t allow others to innovate to your network, you don’t innovate period. sorry if that overstates your case SOG.

    who, for example, is going to build the OO blog publisher-not the core team certainly, but its a vital component of a modern productivity suite.

  4. Luis: “I think a big part of the problem is the goal of out-officing office, really.”

    i agree, but i think the die is more or less cast at this point. the question – as you note – is what happens now, and where we go from here.

    point taken on the direction question. i do happen to think that the OO.o crew is pulling together more than in the past, but as mentioned above i share your questions on the overall direction.

    on the IBM front, i could tell you, but i’d have to kill you 😉

    AC: great question – don’t know off the top of my head. i’m checking for you right now.

    James: *love* the blog writer idea. here’s hoping someone builds that.

  5. i agree, but i think the die is more or less cast at this point.

    Maybe this is naive, small-startup me, but surely this can still be fixed. All it takes is actual leadership from within Sun. Maybe that is naive… 🙂

    jg: yeah, I didn’t mention the ribbon, but it is clearly example #1 of how MS is continuing to move ahead while OOo tries desperately to catch up to where Office was years ago.

Leave a Reply

Your email address will not be published. Required fields are marked *