(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.
