I’ve spent the past week speaking with community members at development and product management meetings, as well as speaking with members of the technical press about the upcoming release of Firefox 3.6, which I truly believe to be the best browser for users. Of course everyone wants to know what’s next for Mozilla, and what the future looks like. Despite doing my best to be as clear as possible, what gets written can be more or less accurate.
The rumours of Firefox 3.7’s demise have been greatly exaggerated. Nobody’s planning on “dumping” features or the hard work of our passionate and tireless community.
The shape of the Internet changes every day. Our mission is to develop the best open source implementations of web technologies and ship them in an excellent browser so that our users and the entire Web can benefit. That means always thinking about how we can deliver technology as efficiently and quickly as possible. Sometimes it means challenging our assumptions.
One assumption we’ve had for a long time is that the only way to ship new technology – such as improvements to downloadable web fonts or support for new standards like CSS, SVG and WebGL – was through a full Firefox version update. Until recently, our infrastructure prevented us from being able to be as agile as we would have needed to be in order to deliver something isolated like the “Lorentz” project (which aims to improve product stability and security by running plugins in their own process) to our users. Now that we have better test automation and the ability to develop on project branches, we can better isolate changes with continuous integration testing, nightly builds and the ability to deliver smaller pieces continuously through the regular maintenance cycle (“minor updates”) of a product. This means that we can, without the user being disrupted or disturbed, improve stability, security, and capability for the 25% of the Internet users who browse using Firefox. One day they’ll start up their web browser and it will be better. Maybe it will crash less, maybe it will be improve typography support on the web.
This is a powerful change, but we must also be careful to keep users in control of their software. Improving the open video engine is something we should feel comfortable doing, as it preserves (but improves!) the existing user functionality. Changing the way the browser looks or interacts with users is something we should avoid doing. I think of it this way: if I take my car in for service and it comes out with better fuel efficiency, that’s great. If my gearshift has changed location, I’d be pretty surprised and upset. We shouldn’t be doing anything in a maintenance release that could leave a user surprised and upset, period.
So instead of thinking of “Firefox 3.7″ and “Firefox 4.0″ and being rigid and proscriptive about what technology improvements will come in which specific months, I’m encouraging us all to think about what we’re trying to improve, and how those improvements can be most efficiently delivered to our users and the Internet. Improvements and support for new technology originally slated for Firefox 3.7 in a draft roadmap long ago may now find their way into users’ hands even earlier. Risky interactive changes that could benefit from multiple iterations and betas can safely do so without worrying about “missing the boat.”
Software development is chaotic, and due to the open nature of our community you (and the press) are getting to see exactly how the sausages are made. It may look like a bloody mess at the start, but once it starts to take shape it’s obvious that you’re making something delicious.