Rapid Release: How to make it work

(apologies for the break in blogging. Taking another stab at ye ole’ blog)

With 103,000,000+ downloads and counting, Firefox 4 has been shipped to the world, hopefully providing a noticeable improvement in their web browsing experience. Speed, interface improvements, and a multitude of fixes and improvements, users should at least notice something different with their browser. They should also notice something different in how their browser is released in the future. Goodbye to major versions with massive changes spanning a year-plus of development. Rapid Release is how Mozilla plans to get fixes and enhancements out to users more quickly and efficiently.  This plan will either succeed mightily, getting rid of the release delays and slow development process of the past, or brilliantly self-destruct and result in little progress and multiple, out of date versions.

I see two things that need to be done to ensure that Rapid Release is at least viable. This is a very very broad over-simplified version, and ignores the nuances and specifics of releasing a new browser. You may also ask “what does this have to do with Triage?”. Well, it has alot to do with triage. Roughly 8000 of the Open bugs in firefox are with versions of Firefox other than Firefox 4 (there is some room for error in this number, due to bugs being submitted with the wrong version number, etc.). This isn’t bad per-say, but Triagers have to approach different versions differently. Someone reporting a bug using Firefox 3.5 will most likely be asked to attempt to reproduce with Firefox 4 for example. So version numbers and development cycles mean alot to a triager.

Under-Promise / Over-Deliver

The worst thing that can start happening to Rapid Release cycles is that developer A comes out, says “Look at my cool widget prototype. It shines and has buttons. It will be released with Firefox 6”. News Outlet B begins to spread the word about this wonderful, new, revolutionary and magical feature. Time to release Firefox 6 comes around, Developer A hasn’t had enough time to finish his widget, the release drivers are forced to either drop the feature, or delay the release. Either way they get burned. Delay the release, have every news outlet on the internet say how Firefox is falling behind, or drop the feature, and hear the same thing.

This whole scenario could have been avoided with a little prior thinking. Problems come up, issues can’t always be foreseen, and development gets slowed down. With Rapid Release, unless a feature is 99% certain to be finished and working on time, nothing should ever be promised for a certain version. I think that so far, the Mozilla team has done a good job of qualifying goals with “If it is ready” and not promising by a certain ship date. It is a better thing to surprise people with more features than none.

Make it Noticable

User Susan starts her computer, opens Firefox, begins her morning surfing. Susan has been using Firefox since the old 2.0 days, when an update comes across, she is used to major changes. She gets a message saying “Firefox 5 is released, update now”. Thinking to herself how quickly this new version has been released, she updates. After restarting, she looks for changes, but there are none. Wondering if the update even worked, she goes and checks her version. Yep, it shows Firefox 5. Puzzled, Susan decides these must be marketing hype and doesn’t update next time Firefox warns her to.

While we can’t let Firefox releases be delayed for a new feature, we also should not let a new Firefox be released with no changes at all. This I think will be one of the biggest pitfalls of rapid release. Each developer has their projects they are working on, but when the time rolls around to release, none of them are ready. sure a few things have slipped in, bug fixes, minor changes and tweaks, but nothing substantial. Too many releases like that and you might as well not release at all, you are wasting user’s bandwidth. On a somewhat serious note, if there are no major changes, what is there for the news media to write about?

Unfortunately, until we make version numbers totally irrelevant, we are going to have to make sure to include major changes in every release of Firefox. I do see in the near future, relegating versions numbers to something only developers care about. With 100% silent updates, pushed through to the user quickly, I think then we can start to relax a little bit in how releases are made. I think Chrome has come pretty close to being able to safely ignore Version numbers. Eventually they will be a thing of the past, only needed for developers to differentiate between releases. But for at least the next few releases, Firefox is still going to be relying on version 5, 6, 7 etc.

So Mozilla, I think that Rapid Release could be a good thing, or a terrible thing. I think the world is ready to be surprised though, the ball is in our court.

Advertisements
    • Robert O’Callahan
    • April 24th, 2011

    I think Chrome has proved that “Make It Noticeable” is not necessary, provided users are automatically updated, which is what we’re going to do.

    • Exactly my point, so long as version numbers don’t matter anymore, and automatic silent updates are enabled by default, Make it noticeable goes away. But for right now, at elast until we get the whole auto update system built and the kinks worked out, we need to make sure we make update noticeable, eg. Firefox 5 and 6.

      • Tiago
      • April 25th, 2011

      Chrome didn’t prove anything. Well, if it did, it proved the contrary of what it tried to prove: that some people don’t like what it does.

      Chrome proved that silent update is not good. Chrome proved that tabs in the titlebar are the work of satan. Chrome proved that the lack of status bar is evil. Chrome proved that people don’t care about speed. Chrome proved that people care that their browser is open source and completely free. Chrome proved that people don’t trust giant corporations that much. Chrome proved that people care about basic usability.

      On the other hand, Chrome has also proved that silent update is good, that tabs in the titlebar is effective, that the status bar is dispensable, that people care about speed and that they don’t care if their browser isn’t free or open source, that people are willing to trust giant corporations and that people don’t care about basic usability.

      See what I did there?

      What I mean, if you’re that thick, is that yes there’s people who like Chrome, but there’s people who find it repulsive, because it is. People who stick or stuck with Firefox because Firefox is not, or was not, like Chrome. “Like Chrome” being debatable, of course. People value different things.

      My point is, you can do anything you like, and you can get away with anything you like. It is all a matter of choice. CHOICE! So don’t pretend that you’re doing feature-less releases because Chrome proved it is possible. Yes, Chrome proved it is possible, but at the same time it also proved it isn’t.

      I also think that the users are completely stupid, and Chrome proved that. It also proved they weren’t. Still, I can’t prove it. Users are stupid, I think, and they don’t care about anything. They just care about what you tell them they should care about. So if you tell them rapid release is better of security (it’s probably detrimental, but whatever), they’ll believe it. It’s like when Apple released iShit with an Apple badge on it. People flocked to the supermarkets because Apple told them it was teh shit. That’s the kind of phenomenon I’m talking about.

    • nikic
    • April 25th, 2011

    Yes, this is something that has bugged me about the rapid release cycle.

    I just downloaded Aurora in order to be sure that really nothing has changed and yes, nothing has changed. At least not from the end user perspective. Sure, CSS Animations are nice, but the normal user won’t care about that. And as far as I understood after branching for Aurora where won’t be any further features included, won’t they? So basically Firefox 5 is just Aurora with some bug fixes.

    I really hope that the release drivers will not ship this as Firefox 5, but just as some minor version like 4.1. Really, I don’t think the rapid release cycle is something bad, but this very first release had just minimal development time (I don’t know exactly, but something like two weeks maybe?). The next version (Firefox 6) and all following may indeed ship using that cycle, because they have much time for developing while the previous version is going through the aurora-beta-final stuff.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: