The Great Mozilla Platform Debate

My previous post stirred up more controversy than I had expected. There seems to be broad consensus that Mozilla is focusing on its platform for the most part only in the service of future Firefox improvements. One commenter goes as far as to link to a posting by Mozilla CTO Brendan Eich, which is so revealing that I will repeat it here:

The XULRunner-based apps (Songbird, Joost) all roll their own, with platform additions. We anticipate versionitis and under-use of any standard XULRunner shipped under Firefox 3. I’m not sure where that plan sits, but to me it looks like a malinvestment. Our platform wins have always been in service of particular apps. Pure platform companies fail (MS has Office as well as Windows, and they’re diversifying). Platforms are great, but not in isolation.

While I agree strongly with Brendan that a platform without a killer app is an unappealing proposition, I still take issue with his position. I don’t think that anyone is suggesting that Mozilla bin (in the “adorable British accent sense”) Firefox and become a “pure platform company”. There are, however, two questions that are certainly worth considering:

• How big a priority should it be for Firefox 3 to ship on top of XULRunner?
• What effort should Mozilla invest into platform features and tools that do not benefit Firefox?

(Note that the authoring tools that Paul Rouget mentioned in his Adobe vs. Mozilla article (English translation), which I agree are the single biggest gap in the Mozilla arsenal at present, aren’t relevant here since they will make it far easier for extension developers to ply their trade and are thus of major benefit to Firefox.)

The answer to these two questions is substantially the same, as I have argued ad nauseum (and when I argue ad nauseum, it’s not just a picturesque turn of phrase so keep a sanitary receptacle handy). Having a near ubiquitous runtime is a huge argument for installing Firefox. Microsoft Office achieved its dominant market position as a direct result of the success of Windows. I bet the Firefox download would be under 1Mb sans runtime, and as some commenters pointed out this could be a great trojan to get Mozilla into corporations that are for some reason Firefox-averse. Pushing out Firefox and the growing number of cool XUL-based apps with separate, incompatible runtimes is thus, in my opinion, to squander a huge opportunity, and one that likely has a limited shelf life. If not Firefox 3 (and thus 2007), then when?

Moreover, none of us has a crystal ball (apparently this is something of a running joke in the Mozilla world right now though as usual I am blissfully ignorant of the origin). The best way to protect against an uncertain future is to prepare for as many contingencies as possible. Yes, we need to consider cost and benefit when deciding whether to include features in the platform. But the single criterion of “does Firefox need it?” is increasingly insufficient as a growing number of Mozilla-based projects has a good shot of contributing significantly to the Foundation’s stated goal to “preserve choice and innovation on the Internet.”

One of my favorite business insights is Andy Grove’s notion of a strategic inflection point. What this boils down to is a willingness to innovate or die, even when existing bread-and-butter products are put at risk. Mozilla did this once when it killed off the Suite to focus on Firefox. I don’t think by any stretch of the imagination that Firefox should be put out to pasture, but I do believe that the relative importance of Firefox and the platform itself is shifting, and that this should be reflected in Mozilla’s allocation of resources.

Bookmark to:

7 Comments »

1. The question for me is not where does MoFoCo put it’s resources in the future, but now?

   Innovation in Firefox seemed to end with version 1. That was when many seemed to disappear to their own startups and / or Google.

   The recent changes seem to be bug fixes and rolling in ideas from Extensions.

   If there isn’t a lot of innovation going into Firefox then what is MoFoCo really doing? Stagnating? Has it put it’s hands up and said “enough’s enough, this is all we can handle”?

   If MoFoCo isn’t finished innovating then XUL (give it a better name, please!) as a platform has to be the most important next step.

   Comment by pd — 4/26/2007 @ 11:27 am

2. Can’t agree with pd, having peeked into MoFo’s kitchen what FF3 is up to, I don’t think no inovation takes place there. To support it, I’d mention a few of them: APNG,,SVG, js. But I must agree with Matt, XULRunner is somehow undervalued. MoFo’s focus should shift from FF to its platform before it’s too late (http://news.com.com/2100-7344_3-6179305.html?part=rss&tag=2547-1_3-0-20&subj=news)
   On the authoring tools topic, the score is even worse. OK, no crystal ball here too, so time will show.

   Comment by funTomas — 4/26/2007 @ 1:30 pm

3. The official (and quite vague ‘managerese’) response?

   http://weblogs.mozillazine.org/mitchell/archives/2007/04/the_open_web_and_firefox_focus.html

   Comment by pd — 4/26/2007 @ 3:08 pm

4. The comment about Joost and Songbird is a self fulfilling prophecy. Projects that build on XUL Runner have to ship their own runtimes because Mozilla does a poor job creating one. Maybe if there was a focus on a good XUL Runner, companies would use that instead of rolling their own.

   Comment by Michael Kaply — 4/26/2007 @ 4:35 pm

5. Kaply and I go way back, so I can say this: he’s enjoying some fine tequila in suggesting that Mozilla is to blame for Joost, e.g., having a patched XULRunner. I’ve been nagging Alex Fritze to get patches landed, and (apart from a non-response asking for something unrelated that we should do anyway to help corporate contributors streamline their CVS access requests), it’s clearly either hard or not a priority (or both) for Alex et al. to unfork and get patches lined up to land.

   Please note that I’m not busting on Alex or other Joosters here.

   I am busting on Mike a bit. Free lunch demands and blame-pinning where we don’t yet have the code to land, are just wrong.

   As for Songbird, we’ve landed big, risky patches (e.g., see bug 176182) at later points in past cycles, just for Songbird. The idea that we (what “we”? we’re an open source project with lots of unbeholding contributors) use some kind of “is it needed by Firefox?” test is false. Last time I heard this (from sicking), a bunch of us landed hard on the notion.

   /be

   Comment by Brendan Eich — 4/26/2007 @ 7:10 pm

6. we’re an open source project with lots of unbeholding contributors

   Er, “unbeholden”. We in mozilla.org staff who worked for Netscape used to call ourselves “beholden mozilla.organs”, and even recuse ourselves when necessary for staff to make judgments independent from Netscape or AOL influence.

   It’s not easy developing the platform we have and building its high-leverage parts, while trying to maintain or remove the less valuable parts. Adding unknown requirements from private startups just won’t do.

   The tendency to fork XULRunner is not a surprise. We’ve seen it with other open source platform code that’s not so well-distributed that its distribution creates an ecosystem, or (suppose Firefox is a big enough distribution) where the new apps need cutting edge platform changs whose patches haven’t even shown up in bugs. Linux is a fine example; arguably Perl in past releases was too.

   I agree with Matthew that smaller XUL app fry with less novel platform demands would cling to the Firefox distribution, remora-like, to good effect for the entire ocean. That would be a fine thing, and it’s not an anti-goal to ship XULRunner under a Firefox 3 or 4 release. It’s just a lot of “last mile” work that trades against innovatively updating the number two browser on the planet.

   /be

   Comment by Brendan Eich — 4/26/2007 @ 7:19 pm

7. Wish I had more time to get on these threads earlier! Oh well, its good to be busy!

   I think thats a good point that is being raised by Brendan, even with the “small fry” stab. An example I like to point out is the cool XUL Explorer app built on XULRunner that Mark Finkle whipped up:
   (http://starkravingfinkle.org/blog/xul-explorer/)
   The Mac app bundle is close to 50 MB while application code is only like 400 KB! How many more cool XULRunner apps could be created if devs didn’t have to worry about:

   - Rolling their own distribution scheme
   - Rolling their own installation scheme
   - Rolling their own updating scheme
   - XULRunner modifications to slim down the runtime to a size that you don’t mind duping for every app you create.

   Comment by enefekt — 4/27/2007 @ 1:43 pm

Trackback URL RSS feed for comments on this post.

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>