Firefox's Version Controversy isn't Just About Marketing. It's About the Strategic Direction of the Company.

14 July 2011 by Matthew Gertner - Category: Rants and Ruminations

For those who tuned in late, Mozilla announced after the release of Firefox 4 in March that they would be instituting a rapid release schedule like that of Google Chrome, involving a new browser release every six weeks. Resistance to the plan has been widespread. To some degree this reaction was psychological: Firefox 4 was over a year in the making and was launched with great fanfare. This was hard to reconcile with the fact that, a few short weeks later, the version had already been supplanted by a new major release, which was itself on the road to obsolescence the day it hit the market. But if you agree that there is a compelling reason to make this version number change, then there is some truth to the assertion (in the comments of Gerv Markham’s blog post) by Asa Dotzler, Firefox’s Product Manager, that “negative publicity has already happened. It’s in the past.” In other words, people always hate change, so let’s just take the PR hit and wait for people to forget about us and get outraged by something new and dastardly that Facebook did to their newsfeed.

Mike Kaply makes a more serious point: that the support policy for older versions that accompanies the new versioning scheme make Firefox less attractive to corporate customers. To this, Asa Dotzler (remember him?) replied in the comments: “Enterprise has never been (and I’ll argue, shouldn’t be) a focus of ours. Until we run out of people who don’t have sysadmins and enterprise deployment teams looking out for them, I can’t imagine why we’d focus at all on the kinds of environments you care so much about.” Much eye-rolling ensued.

But by far the most important implication of the rapid release schedule is on Firefox’s strategic direction. When Firefox hit the scene in 2004, it was touted as a way to counter Microsoft’s neglect of Internet Explorer, which had become the transmission vehicle of choice for all manner of malware. With the Chrome’s rapid ascent, there is now another viable “not Microsoft”. Meanwhile, Microsoft has been shaken out of its complacency and is improving IE regularly, if not exactly rapidly. Firefox needs a new way to differentiate itself. The most obvious is to build on the strengths that it already has. And the greatest strength of all is the richness and breadth of its add-on community.

Firefox is better at enabling the development of sophisticated add-ons that make deep and innovative changes to the browser. So much better, in fact, that it is hard to imagine Chrome or Internet Explorer ever catching up. A big part of this is the ability to create binary components that tap into the very core of the browser, an ability that Daniel Glazman points out is gravely threatened by the new release policy. The impact is the same for our own WebRunner, which relies heavily on binary components. Instead, extension developers are being pushed towards the Add-on SDK, whose capabilities are much closer to those of the Chrome extension APIs.

This is another step down the path that Mozilla set out on when then CEO Mitchell Baker announced the new platform strategy in 2007. In essence, Mozilla wants to focus on creating the best browser possible. The distractions inherent in maintaining a platform for third-party developers (then XULRunner, now sophisticated extensions) undeniably detract from this goal. But what if being the best browser, in the sense of being truly differentiated from the competition, actually means that Firefox must be a great platform? In tackling the Chrome insurgent by seeking parity with its rapid release schedule, simple extension API, sparser user interface, process-isolated tabs and so forth, Firefox may be losing its strongest reason for existing.

Update: I changed the title of this post since I didn’t want potentially provocative terminology to detract from the point I am trying to make.

« Should Apple Discontinue Safari or Double Down? - Packaging WebRunner Applications… For Dummies! »

COMMENTS

http://home.kairo.at/blog/ Robert Kaiser

There is no actual debacle unless people visibly market it as one. Thanks for doing just that and therefore harming the community.
http://www.salsitasoft.com/ Matthew Gertner

Robert: That’s nonsense. It’s a debacle when one long-standing member of the community after another (including myself) writes a blog post about their dismay with the new policy. Whether someone decides to label it as such is not what determines this. An honest and open discussion of these issues will make the community stronger, not harm it.
http://www.salsitasoft.com/ Matthew Gertner

Nonetheless, I changed the title. This is an important discussion and I don’t want to distract people from the substance of my post.
http://mike.kaply.com Michael Kaply

I think you need to take the last line of your post and set it apart and bold it.

“In tackling the Chrome insurgent by seeking parity with its rapid release schedule, simple extension API, sparser user interface, process-isolated tabs and so forth, Firefox may be losing its strongest reason for existing.”

I’ve always believed that add-ons are Firefox’s strongest competitive advantage.

But I think for a while now add-ons have been relegated to just a problem that Firefox has to deal with every time they want to release a new version.

I wrote this post – http://mike.kaply.com/2010/01/11/extensions-personas-and-jetpack-oh-my/ – a year and a half ago when I felt like Firefox was really started to look down on add-on developers, and it still summarizes my feelings pretty well.

Back then I was complaining about six month release cycles.

That will teach me.
http://Website Henry

Nice going trying to guilt people out of dissent there, Robert. What an unpleasant way to behave.
http://Website deftmetal

From reading tea leaves and blogs over the years, I think in future you’re going to see a bare handful of complex extensions tolerated (Firebug certainly, AdBlockPlus and NoScript if they shout loud enough). Otherwise extensibility seems likely to be downgraded to a Chrome-parity feature.

Looks like (one of?) the new key differentiator(s) is going to be the user’s portable relationship with “my Firefox”. Client-side data-mining and auto-personalisation, de-creepified by the fact that it’s presented by a not-Clippy-like, but Clippy-like fox character who is your friend (see bug 661075). Or by the fact it’s done locally and by Mozilla, if the user understands what that means

Despite opening and closing the bookmarks sidebar every five minutes to search, I’m not a fan of the AwesomeBar. However, I have always admired its underlying exemplarily Mozillian principle of putting repeated/redundant search back into the hands of the users and, grumbles aside, improving the user experience to boot. I assume that predictive UI/behaviour which builds on what places.db knows about your habits and is available from your phone/tablet/PC is where Firefox could stand out.

What I’ve highly-speculatively suggested above would seem to be more of a retention strategy than one to win new users though. New users would observe very little benefit at first from such an approach, during the “getting to know you” phase. Furthermore, other browsers can easily “follow” in this direction. Opera’s already got Speed Dial, for example and there’s nothing to prevent a privacy-eating, cross-referenced, server-side, but very charming “Google Google Gander”.
http://Website Havvy

You managed to summarize the (obvious) debate that has been going on for the last two weeks. Thank you.

The question though is, “Where do we go from here?”.
http://Website Pikadude No. 1

“A big part of this is the ability to create binary components that…”

I disagree. A big part of this is that so much power is available to extensions that don’t use any binary components whatsoever. Binary components were always a hassle even before the rapid release thing started; most developers don’t want to recompile to test every little change.
http://kev.deadsquid.com/ kev

I’m curious if JS Ctypes meets the needs of the binary components you use. I’m trying to capture as much info around this as possible, as I’m very interested in figuring out how we can ease the pain around this more.

Ctypes is designed to mitigate some of the pain around keeping binary components compatible from release to release, and where it doesn’t meet needs I’d like to understand more. The comment I hear most around not adopting it centers around the inability to do calls back into the browser, and I’m wondering if this is an issue for you and what you think can be done to better mitigate the issues that recompilation every six weeks brings.
http://www.cornerstonenw.com Peter Rust

Wow. You’re right. FF has been trying too hard to compete with Chrome by *matching features* instead of by *capitalizing on FF’s competitive advantage*.

Yes, FF has been working on much-needed (IMO) ways to improve the lives of extension developers, but they have done so at the expense of backwards-compatibility. It’s taken me a while to realize it, but backwards compatibility is the most critical feature of a platform/API. Joel Spoelsky’s classic article “How Microsoft Lost the API War” http://www.joelonsoftware.com/articles/APIWar.html explains it nicely and John Resig’s reiterated it recently in his post “jQuery 1.6 and .attr()” (http://ejohn.org/blog/jquery-16-and-attr/): “If we’ve learned anything after doing 31 releases of jQuery it’s that people like having stability in their API and will cherish that over everything else.”
http://www.salsitasoft.com/ Matthew Gertner

Kev,

I’ll tell you what. I’m going to try to get rid of the binary XPCOM components in WebRunner so I will report back with any problems I encounter.

In retrospect I agree with Pikadude above that binary components aren’t the biggest consideration. It is rather that so much of the innards of the browser is exposed via XPCOM. In theory all of this should be accessible from JS and that would be very desirable since writing C++ code is much more tedious (especially when you have to check return codes after ever method call) even when you leave aside the issue of ABI compatibility.

I’d be perfectly happy with a world where there are no more C++ XPCOM components as long as we’ve done the heavy lifting to make sure that JS is ready to take up the slack (e.g. Giorgio Maone’s concerns about multithreading). But I think it would be a mistake to replace XPCOM with Chrome-style interfaces such as the Add-on SDK (although this is a great complement to the lower-level XPCOM stuff).

The goal of the Add-on SDK seems to be to anticipate what they will do and make it possible, but the best thing about the FF extension infrastructure is that developers can do new and unexpected things.
http://Website jerryC

I have an in-house application that is to a degree similar to WebRunner. It’s a much older app dating back to the early MFCEmbed days. It’s been very successful and even though it has been a headache for me to update for each new version of Gecko, the end-user web code has always run just fine except for a cosmetic glitch or two.

I’m concerned about the future of the app on the Mozilla platform. There are alternatives, but I’d really like to stick with Firefox. I’ve already ported a subset to the mobile world but that’s all WebKit based. That’s not Mozilla’s fault; there is currently no choice.

My biggest challenge in moving away from C++/XPCOM is my “enc:” Protocol Handler/StreamConverter (It provides encrypted chrome/local content, without which the app couldn’t exist) and the binary for the XML-based scripting that handles navigation. I don’t know if JS will give me the kind of access I need to make things work. I guess we’ll see.
http://tomercohen.com Tomer Cohen

Rapid releases has some negative reactions, and it might not be the best idea to switch to 6 week major releases plan for few reasons:

Newspaper are not reporting on every minor release. In other words, they reported on 3.6 release and 4.0 release, but not intended to report on every other release such as 3.6.4. When we release a major version every month and half, they find it stupid to report on minor releases marked as major, and we will get LESS mentions on the press than we used to get before.
Users are afraid of major releases, and there are users still using 4.0 and asking if it should be safe upgrade. I afraid we lose some amount of users by every major release that find their current version good to them and because they refuse to upgrade when the message appears, they keep using outdated version until their nearby computer technician/geek will step by and upgrade their browser.
Addon authors are not updating their addons every month or so, and some addons are still not bumped to support Firefox 5. The most recent question I saw on our local community forum is a question about compatibility of Google Toolbar; if the big brands won’t update their add-ons periodically, users will refuse to update or switch to other browsers which doesn’t have this limitation.
http://glazman.org/weblog Daniel Glazman

What bugs me even more than that strategy I now understand but cannot accept because it will harm my own business is the absence of serious response from Mozilla’s head. I heard about an offsite this week but still. Apart from Mitchell’s message that I hardly decode, that silence is rather eloquent.
pd

The “ooops, let’s get on with it” approach is that of a rank amateur mentality. Learn from the mistake, do not just brush it aside as “a PR hit”. The issue is not guaranteed to go away. It will simmer for a few weeks in b/w releases but thanks to the meaningless-release decision, it is just as likely to keep spiking every 6 weeks. You’ve built a rod for you’re own backs.