Excellent article, with one quote in particular that seems to make a well-grounded, broader point:
> I have another theory, too: When software companies get to a certain size, they start taking their users for granted. They start treating their users as pawns in a battle against some other company. Faceless millions. Gotta copy everything the other company does, or risk falling behind. So they end up doing everything the other company does whether the users want it or not, and probably doing a crappy job to boot.
> In our case, we started thinking of everything in terms of the battle against Google Chrome. Oh no, Chrome is doing such-and-such; we'd better do something equivalent or we'll fall behind! We thought we needed a rapid update process like Chrome. We were jealous of their rapid update capability, which let them deploy improvements to users continuously. We had to "catch up" with Chrome's updating capability.
> Credit where it's due: the way Google handled Chrome updates was very, very smart. They recognized that updates are one of the hardest things to get right, so they solved that problem first, before releasing version 1. The first release of Chrome was little more than an empty box of a browser, but it was wrapped around an excellent updating system. This let them gradually transform that empty box into a full-featured browser, without the users ever realizing they were getting updates.
> Firefox did not do such a good job with rapid releases. I've written before about the specific mistakes we made, so I won't go into detail again. To summarize: we did the updates in a very intrusive way, requiring lots of user attention, which made people annoyed because it happened so often. When people restarted after an update to find no visible difference, they wondered what was so important about that update. (Remember the rule that the benefit of the update needs to outweigh the pain? We broke that rule.) Worse yet, we didn't do enough to preserve add-on compatibility, making the updates extremely disruptive to people who depended on certain add-ons; and we kept going with our old version-numbering scheme even though the meaning of the numbers had changed completely, leading to mass confusion.
This reminds me of certain OS races: Microsoft trying to upgrade its 16-bit, cooperative multitasking Windows 3.1, and then ditching it for a new model based on NT, while Apple flounders with the Mac OS's 6 to 9, until it finally got a reasonable architecture with OSX - leading to Microsoft floundering with Vista. But the problem here is the opposite - the difficulty in competing is the same, but the two companies were reluctant to recognise the edge the competitor's system had on theirs until it was costly to fix.
Funny thing, I recently came across my first Chrome update failure - from 19 to 20 on OSX. The instructions to try to resolve the issue involved going into odd directories and deleting entries. This made for a oddly microsoftian feeling fixup process, which, in the end, didn't fix the problem. The only fix was a fresh download of Chrome. Makes one wonder if the Chrome project could be wandering from it's original reliable because it's simple, fast, & self updating to a state more like Firefox.
> I have another theory, too: When software companies get to a certain size, they start taking their users for granted. They start treating their users as pawns in a battle against some other company. Faceless millions. Gotta copy everything the other company does, or risk falling behind. So they end up doing everything the other company does whether the users want it or not, and probably doing a crappy job to boot.
> In our case, we started thinking of everything in terms of the battle against Google Chrome. Oh no, Chrome is doing such-and-such; we'd better do something equivalent or we'll fall behind! We thought we needed a rapid update process like Chrome. We were jealous of their rapid update capability, which let them deploy improvements to users continuously. We had to "catch up" with Chrome's updating capability.
> Credit where it's due: the way Google handled Chrome updates was very, very smart. They recognized that updates are one of the hardest things to get right, so they solved that problem first, before releasing version 1. The first release of Chrome was little more than an empty box of a browser, but it was wrapped around an excellent updating system. This let them gradually transform that empty box into a full-featured browser, without the users ever realizing they were getting updates.
> Firefox did not do such a good job with rapid releases. I've written before about the specific mistakes we made, so I won't go into detail again. To summarize: we did the updates in a very intrusive way, requiring lots of user attention, which made people annoyed because it happened so often. When people restarted after an update to find no visible difference, they wondered what was so important about that update. (Remember the rule that the benefit of the update needs to outweigh the pain? We broke that rule.) Worse yet, we didn't do enough to preserve add-on compatibility, making the updates extremely disruptive to people who depended on certain add-ons; and we kept going with our old version-numbering scheme even though the meaning of the numbers had changed completely, leading to mass confusion.
This reminds me of certain OS races: Microsoft trying to upgrade its 16-bit, cooperative multitasking Windows 3.1, and then ditching it for a new model based on NT, while Apple flounders with the Mac OS's 6 to 9, until it finally got a reasonable architecture with OSX - leading to Microsoft floundering with Vista. But the problem here is the opposite - the difficulty in competing is the same, but the two companies were reluctant to recognise the edge the competitor's system had on theirs until it was costly to fix.