Why Mozilla’s Firefox Rapid Release Cycle Works and Why it Doesn’t.


From the ‘Half Empty/Half Full’ files:

There has been a lot of discussion this week about Mozilla’s Rapid Release cycle. Much of that discussion was fueled by a blog post from Mozilla Chief, Mitchell Baker.

Baker’s post is a defence of the new cycle, which has caused lots of concern in the Mozilla community and elsewhere. Baker’s view is that the browser needs to be more like the Internet.

“If we want the browser to be the interface for the Internet, we need to make it more like the Internet,” Baker wrote. “That means delivering capabilities when they are ready.  That means a rapid release process.”

At a high-level, I completely agree with Baker. Innovation doesn’t come once or twice a year, it comes throughout the year. And why not have a browser that attempts to match that speed of innovation.

It’s a model that has worked superbly well for the Linux kernel too – Linus Torvalds pushes out new kernels every three months which has given Linux a significant advantage over Windows in multiple markets (notably the server). It also makes sense for Firefox to keep pace or outpace Google’s Chrome.

Why should Chrome get new features first, especially when some of those features were the result of efforts first begun by Mozilla?

The other side of the coin however is that too much change actually breaks the web. The Internet does change, but not nearly as rapidly as rapid release cycle. The reason for that is that most browser on the Internet today aren’t likely to be the latest/greatest versions.

It’s a problem that we all went through back in 1998 when IE and Netscape went back and forth over version numbers relatively quickly. As a web developer, I remember well pitching my clients on the need to use the newer standards but the issue always came down to what users were actually using. As a web developer, for better or for worse, I always had to develop to the lowest common denominator in order not to break a site. The same is true today.

While it’s great to have new features, if they’re not supported by all (or the majority) of the users of a given site, then the value of building on those innovations isn’t as great as it should be. This is not a new problem and no I’m not saying that browser should not innovate. For all those years before Firefox when the web was stagnant, the web was a static and boring place. Firefox changed that and accelerated the pace of development for everyone.

Reality is that users cannot consume the changes as fast as the developers put them into Firefox. Reality is that web developers are already over-taxed and aren’t likely to consume all those changes either. The other problem for Firefox is that unlike Chrome, there isn’t a default silent updater either, which means users might get left multiple versions behind.

This is a chicken and egg problem, a paradox and problem without an easy solution.

Personally I was a fan of the Mozilla ‘Lorentz’ plan last year where incremental new feature were set to be added to the 3.6 branch and then major changes would go into major release versions. It’s a plan that made the most sense to me on multiple levels even though Mozilla ultimately abandoned the plan.

Yes, I will continue to update Firefox for each and every new release. Yes, as a developer, I’ll try and consume and build to the new standards, features when possible too. I just wish I had a little more time to breathe…

News Around the Web