Rapidity

[This is a re-post of a post that originally appeared on the Future of Firefox blog]

Last week we released a new version of Firefox. We shipped on time, 6 weeks after the last update, making it our first true rapid release milestone. There was cake. Now that we know that we’re capable of this velocity, I’d like to revisit the reasons why it’s important, and the lessons we’ve already learned.

Mission drives Mozilla. People sometimes forget that we’re a non-profit, that our only job is to make the Web a better place. Rapid release advances our mission in important ways. We get features and improvements to users faster. We get new APIs and standards out to web developers faster. We are delivering on the promise of the web at web speed.

Small, frequent releases improve quality, too. Engineers in the Mozilla community regularly say things now like “I don’t like not understanding this piece, let’s back it out and I’ll catch the next train.” We move deliberately. We don’t rush. And, even though it sounds like a contradiction, when we take our time we go faster.

There’s a great deal for us to be proud of, but we also need to be humble. This change was hard for us to make, and it’s been hard for some of our supporters, too. We have been glib or dismissive in the way we’ve communicated about parts of it. We live rapid release daily, and that makes it easier for us to see past the problems. We are also tenacious about the necessity of our new schedule, and tenacity can be mistaken for obstinacy.

We, everyone in the Mozilla community, all of us, need to communicate with clarity and sensitivity. We need to help the people who support our mission to understand why these changes are essential. We need to keep listening, and adjusting as we learn. We need to, and we will.

The push to ship faster isn’t some kind of software machismo. We push ourselves to ship faster because the web is under threat. Amazing and innovative people are doing amazing and innovative things and right now they have a choice: build for the web, or build for the walled gardens. The web can win that fight.

The open web is the most amazing, universal communication and distribution platform ever built. To win, the web needs to be agile and responsive. To help it, we need to be agile and responsive, too. That’s why rapid release matters.

16 comments

  1. Mozilla’s problem is that Firefox’s core users see it as a product and not Mozilla’s tool for changing the web. Users view it this way because that’s how it was originally created. Mozilla’s agendas don’t matter to users anymore than Microsoft’s, Apple’s or Google’s.

    Now, frequent predictable releases aren’t a problem by themselves in fact I believe most users love that. It gives them missing features, bug fixes and optimizations regularly. The problem is when changes are user facing things.

    I know someone who would still be using Firefox 2 today if websites didn’t drop support for it. Instead of being able to stick to what they were used to they were forced to upgrade to a new interface in Firefox 3.

    Now many users are in the same boat with Firefox 3.6. They’re waiting until the web no longer support them before upgrading to a new interface they don’t want to have to learn and get used to.

    Mozilla Suite users didn’t have this issue when Firefox was released. They were allowed to keep using what they were used to. The only thing that changed for them was the name of the browser.

  2. Here’s clarity:

    - rapid release cycles mean there are less releases: previously we had minor releases every 3 or 4 weeks; now we have releases every six weeks – bug fixes arrive slower.

    - there’s less time to develop: previously you spend three or four months on alpha or beta stage adding in features and making sure they work; now there’s only six weeks, stuff has no time to bake and it takes longer to see the light of nightly, let alone final – major features are nowhere to be seen.

    - you don’t know what’s what anymore: previously you had solid landmarks in Firefox and if a user didn’t like 3.5, he’d wait for 3.6 and try it out; now if a user doesn’t like Firefox 6, he’ll never try it again because the differences are so minimum – I tried Chrome 0.4, it sucked, I only gave it another shot at 6, and it sucked, then again at 11 or something, it’s still the same crap.

    For me, it’s pretty simple. I’ll be convinced that rapid release cycles work if, by next spring, Firefox has a home tab, an account manager and fully implemented doorhangers. I’ll even dismiss the profile manager, the fully in-content UI, the tab modal search bar and papercuts. Just those three and I’ll be convinced.

    Of course, it will never happen: one year after Firefox 4 was released (and a late release at that), we still won’t have the features that were planned for it. Why? Because all that time the devs have been focused on doing small fixes, removing the new tab button from Panorama, the close buttons from the tabs and the forward button… And stuff like that. I can do that in a day’s work. Not as cleanly, but still… That’s small stuff, and rapid release cycles is all about small stuff that can be done in six weeks, no more.

  3. @Tiago:

    > “there’s less time to develop: previously you spend three or four months on alpha or beta stage [...] now there’s only six weeks”

    6 weeks on mozilla-central + 6 weeks on aurora + 6 weeks on beta = 18 weeks, aka over 4 months. So the same as your “three or four months on alpha or beta”.

    > “rapid release cycles is all about small stuff that can be done in six weeks, no more”

    If that’s the case, how is it that large changes (for example Type Inference) are successfully going ahead and will be landing soon?

    > “And stuff like that. I can do that in a day’s work.”

    In which case I’m sure they would love to receive your resume:
    http://www.mozilla.org/about/careers.html

  4. Tiago Sá, it’s absolutely not true that the rapid release cycle prevents developers from working on things for longer than six weeks. The JavaScript team is getting ready to land Type Inference, which they’ve been working on for months. The mobile front-end team has been working on our tablet layout for more than six weeks and we still haven’t enabled it by default even in nightly. These big changes happen and will continue happening in project branches, or disabled by default, or even enabled in Nightly/Aurora but disabled in Beta/Release.

  5. A typical user don’t want to change the web, they want to use it and they use it with a tool called browser.

    Forcing users to upgrade their tool is bad.
    They have no choice if they don’t want to use an insecure browser. Some users like frequent updates and many doesn’t like them. It’s the same in the real world, some people relocate several times in their live and some people will never relocate.
    I’m sure that there are enough resources at Mozilla to do a 1 years “LTS” version and the rapid releases.
    and i don’t want to start with the current version number joke from Mozilla that could be fixed with a LTS (major version number change) and rapid releases (minor Version number change)
    I’m sure that our users wouldn’t be angry if they have the choice.

    The rapid release cycle doesn’t affect me at all because I use nightly builds since 7 years but the response from typical users that i receive makes me sad.
    Mozilla seems to get the same negative comments because i can read several blog posts, interviews etc about why the rapid release cycle is good.

  6. Just for the record, and for the naysayers: I ♥ rapid releases – keep them coming! :)

  7. @ Ed M
    > 6 weeks on mozilla-central + 6 weeks on aurora + 6 weeks on beta = 18 weeks, aka over 4 months. So the same as your “three or four months on alpha or beta”.

    Not so. Aurora and beta are feature frozen. Nightly is where stuff happens, only now it’s only given a third of the time for any one release.

    > If that’s the case, how is it that large changes (for example Type Inference) are successfully going ahead and will be landing soon?

    I have no idea what Type Inference is. How is it a large change?

    > In which case I’m sure they would love to receive your resume.

    No they wouldn’t. Anyone can build patches, no need to be an employee of MozCorp.

    @ Matt Brubeck
    My point still stands though. I may be wrong in defend it, for sure, but Firefox 4, the original concept, never was, and will take a long long time to be. Are the reasons I gave wrong? How about the fact that rapid release cycles excuse major releases without major changes also allows the developers not to work on major changes that would justify major releases in the previous model and instead work on smaller changes or changes that wouldn’t?

    I don’t know. Not really. I’m just saying.

    Thanks for arguing though. I just want the stupid cookie popups (the ones from the inbuilt cookie manager) to be doorhangers, and I want to have a decent home page that doesn’t eat up all my RAM. That was supposed to come out with Firefox 4. Where’s it? Where’s it?

  8. Tiago: What you are missing is that big feature development now happens on feature branches, not the nightly branch (mozilla-central). So teams can work on things (like Type Inference – https://wiki.mozilla.org/TypeInference) for months, and only merge them to mozilla-central when they want to get them onto a release train. And, as you say, significant development can’t be done on Aurora or Beta – so it *does* have time to bake. And it can always be switched off if it’s not ready.

    Your other comments seem to be about developer priorities, which is a different thing to the rapid release cycle, and not connected to it. That’s not denying that your issues are valid, just that it’s a different debate, and you shouldn’t let your frustration in those areas overflow into criticism of the rapid release process when it’s not warranted.

  9. Do you know what I want from a browser?

    Speed
    Reliability
    Stability
    Add-ons

    I suspect that 95% of Firefox users want the same.

    I’m sick of having valuable add-ons (that should be part of the official Firefox code anyway) suddenly stop working every time I upgrade Firefox. The add-on catalog is what makes Firefox better than the other browsers.

    The last time I upgraded, I lost 90% of my add-ons. I don’t use tons of them – more like a dozen – but I rely heavily on them. Now I’m going to have to see if I can find the version they worked in, download it, delete the current installation, and re-install the old one. It seems like I have to do that constantly.

    The newest toys in Firefox are not ones that I have any use for, nor do most people I know.

  10. Well put, and understood. But maybe your cadence formula just needs a slight revision… say, a tolerance. 6 weeks +/1 X days, or some such.

    You run the risk of the cadence becoming the goal. As a Firefox user I’d rather the release be the goal. I don’t mind if you add an allowance for contingencies… it’s only practical.

  11. “the web is under threat”….

    Ah. That line deserves more details. Please.
    From my point of view, the web has never been so interoperable. But who am I after all…

    Daniel Glazman
    W3C Working Group, Co-chairman

  12. Daniel, being more interoperable than ever doesn’t mean there’s no threat…

  13. @Randall: correct, but I still don’t understand why there is a threat at all…

  14. Gervase Markham, I see. Thank you for point that out to me, I have heard about the UX-branch, I didn’t know there were more…

    I’ll have to rethink my whole stance on the issue now. Have no idea what to think of it…

  15. Has anyone visited the homepage of https Microsoft.com, because in IE9 it FAILS to provide or show any method to check the SSL certificate as non-secure content is included by Microsoft.

    I bring this up because in Firefox v6, it does show the SSL certificate, but no method is provided to confirm or validate the non-EV certificate.

    In addition, I loaded a SSL website that uses a known Fraudulent SSL Certificate Authority for GTE, same used for Microsoft, in IE9, as a test to see if IE9 would detect the invalid signature… IE9 FAILED, but Firefox v6 PASSED the test.

    The non-EV certificates can be spoofed, Java injection, MITM and worse NOT even Firefox warns the browser end user about SSL certificate mixing, iframe or popup SSL Phishing attacks.

    It’s open season upon the Internet for MITM SSL attacks, especially with DNS redirection. Let’s not forget MD5 collisions is another method of attack, which Google ought to insure all SSL certificates are using SHA512…

    Why isn’t Firefox providing a global certificate repository, so nobody needs to depends upon the Microsoft pre-install, pre-loaded certifciate root authority in Windows?

    Why trust Microsoft who cannot insure Certificate Authorities around the world (thousands of them) who PAID Microsoft to ADD them into Windows?

    Already 50% of the certificate authorities used in Windows 7 SP1 are UNTRUSTED.

    And that’s the discovered bad ones found, what about the unknown and unreported illegitimate certificates floating around?

    Everyone needs a honest system here, not a proprietary Microsoft knows best for NOT being a security company.

    Please do the good thing Google, Firefox and the open source community. Kick out Microsoft, end the security breaches, design a global repository letting everyone update and check instantly who is legitimate.

    A second benefit here would be to allow everyone to participate, no more PAYING Microsoft to distribute their own root certificates only.

    You get the idea…. lets see some results, okay?

  16. [...] Jonathan Nightingale recently published some notes on Firefox and its competitive field. His thoughts were the most encouraging in awhile [...]