Is Mozilla Making the Same Mistakes as Microsoft?

Feature bloat, among other concerns, is causing the open source browser to lose some of its charm.
(Page 1 of 2)

There was a time when I had high hopes for Firefox. The idea of having a small, lightweight, swift, secure, low memory/CPU-footprint browser appealed to me a lot. I’ve always been a default Internet Explorer user but I can’t say that I’ve ever really been thrilled by it (or even mildly jazzed) and if something better, faster, more secure and less hassle came along, I’d make the leap. For a long while I thought that it would be Firefox that I’d be making the leap to, but I’m now doubtful that Firefox will ever be more than a curiosity to me. I’ll experiment with it, but I don’t really get to the point where I really use it any more.

My browser needs are pretty simple. I need something fast and secure that I can use to view web pages, and something that makes it easy to store and organize bookmarks. It would also be cool if the browser could be loaded onto a USB flash drive and used when on the move, and it would be really cool if there was a simple way to sync bookmarks between different systems, but these are dream features. Ultimately, what I want it speed and security.

The Firefox project is interesting because it is an example of what goes wrong with anything designed by committee. There’s an old saying that a camel is a horse that was designed by committee, well, Firefox is a web browser designed by committee. The early goals of the Mozilla team were to come up with an “open-source web browser, designed for standards compliance, performance and portability” (this quote dates back to Nov. 1999, via the Internet Archive Wayback Machine). Add security to that and you got me hooked! That sounds just like the kind of browser I want to be running. But there’s a problem with developing a browser that’s standards compliant, fast and portable – it’s just not sexy.

So the Mozilla development team came up with a way to make Firefox sexy without adding too much bulk to the code – add-ons. This enabled users to add additional functionality to the browser but kept the overall download small and the base browser relatively simple to use. The problem with add-ons, in particular browser extensions, is that they become addictive. You start off by tentatively installing one and pretty soon you have a dozen installed. This does nothing to improve performance, and if you’re like me it’s also real pain making sure that several different Firefox installs all have the same extensions fitted.

Another downside of extensions is that the more you have installed, the more you have to keep them updated. It’s not a major pain to update add-ons because it’s done automatically and you only have to click a couple of buttons, but it does interfere with the workflow. The times when Firefox extensions have caused me a lot of grief is when upgrading to a new major build of Firefox. For security reasons I update Firefox with a new version as soon as it’s out but every time I’ve done this I’ve had problems, ranging from losing add-ons which had become a vital part of my workflow to add-ons behaving badly after an update. It’s important to bear in mind that add-ons are transient and a Firefox update can spell the end of the line for them, especially if the developer has lost interest in the project. Realizing that they’re possibly short-lived makes me wary of integrating them into any workflow process. That’s a real deal-breaker as far as I’m concerned.

Page 1 of 2

1 2
Next Page

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.