User Tools

Site Tools


Mozilla’s latest debacle – and why it hurts open source projects

This article was originally published on February 6, 2014.


After Microsoft switched to Chromium as its code base for Edge, I left Firefox in the dust. The organization turned unnecessarily political and ideological, and as various security and privacy concerns were raised, I decided it was no longer worth my time.

To date, Firefox continues to store passwords in an insecure fashion: if someone has access to your logged-in session (like someone using your computer at work or school), they can easily access your passwords.

All Chromium-based browsers, including Edge, make use of the operating system's secure password storage - this is called Credential Manager in Windows and the Keychain in MacOS. Revealing passwords requires the logged-in user's password.

I strongly advise against continuing to use Firefox in any capacity. It isn't secure and will not keep your online account passwords secure.

Quite a few years ago now, a large open-source project called Pidgin fell prey to one of the bigger pitfalls of OSS – developer-user relations. With commercial software development, a company has resources available to do things like usability testing, analysis of interface design, and most importantly – interact with customers through company representatives whose primary role is to address customer concerns and issues. Software developers are famously stubborn and, for lack of a better word, assholes about their work. Customer liaisons protect users from the rough-around-edges aspects of the developers’ personalities and tendencies, and the end result is that the customers are happy, the software satisfies the customers’ needs, and the developers don’t end up in really sticky situations.

Open source software isn’t so fortunate, even with large projects. Back in 2008, a popular multi-protocol chat client called Pidgin (known as GAIM in the late 90s and early 2000s) released a major update that overhauled the user interface. Many advanced settings and features were removed, but one of the most contentious was the removal of a manually-sized input area in chat windows. Instead, the text area expanded automatically and, when empty, was only a couple lines high. A bug report was quickly filed.1) Functionality that had been present since the inception of the project had been arbitrarily removed, and legions of users wanted to know why it happened and when it would be fixed. The primary developer who handled customer comments on the ticket, Sean Egan, repeatedly harassed the many users who complained about the change and requested that it be fixed. Rather than listening to what the users requested and understanding that options (particularly in open-source software that had previously been designed to serve power users as well as regular folk) are better than none, the developer opted to insist that the change was good and would not be changed.

Particularly troubling was the response of another developer, deryni, who had this to say in one of his comments:

The key here is that you don’t manage us, a fact you are keenly aware of and even reference farther down. Another fact is that we have no requirements for any of this beyond what we feel like creating, which is a freedom your managed developers do not have. Both of these factors are central to our claim that it is more work than we care to put in and why we ask for people who do want it to write it (at which point we will happily accept it).

Unfortunately for the folks at the Pidgin project, when your open-source software creates a large enough user base, your requirements must extend past what you “feel like creating”. Your project has evolved past a tiny for-fun application that you hope people will consider using into something much larger, and an inability to accept that is one of the biggest reasons why businesses still reject OSS as an option. The end result of the Pidgin fiasco was twofold – a fork was created to put back the feature (the developers claimed it was “too much work to fix”, even though the feature had previously been there and was deliberately removed), and Pidgin lost quite a longtime users, including myself. While the dent in the user base wasn’t big enough for the developers to fix the bug, the fact remains that this attitude is what prevents OSS from gaining legitimacy in the larger world of technology and end-user applications.

We are now seeing the same attitude from the developers of Firefox, one of the biggest web browsers in the world. A bug was filed in 20082) due to what appeared to be an accidental or arbitrary change in Firefox’s functionality. In OS X, Firefox had consistently prompted the user with an “Are you sure?” dialog when the user attempted to close the application using the system-wide Command+Q keyboard shortcut. This was very useful for Mac users, since the Command+W shortcut to close a tab was easily mistyped on a standard QWERTY keyboard. The Firefox development team saw fit to remove this behavior. Bug reports were quickly filed, since the functionality had previously been there and was very much expected behavior – in fact, other browsers for OS X, including Safari, Opera, and Chrome, prompted on quit.

Rather than listening to the users, the developers took the bug report as an opportunity to launch a moralistic crusade against changing anything they didn’t feel like changing. Six years later, this bug report has been reopened by users who simply do not understand why the developers would (a) remove consistent, expected functionality and (b) stubbornly refuse to consider reverting the change. My inbox has been blowing up the last few days because of how heated this discussion has become. The developers have simply refused to fix this, with reasoning varying from “the people complaining here don’t represent anyone else in the user base, so it doesn’t matter” to “we want it to behave like this regardless of what you say”. There is no objective, logical reasoning behind why the functionality was removed. It just was, and now that enough people are up in arms about the change, the development team is unwilling to swallow their pride in their product (which is a very good product, to say the least!) and fix something that users have been complaining about for six years.

Meanwhile, let’s look at what happened with two products recently released by Microsoft – the Surface and Windows 8. The Surface RT was met with great ridicule at its launch, in part because its hardware specifications were somewhat lackluster for its initial price point of $500. Microsoft responded by keenly observing media and user criticism and, a year later, released the much-improved Surface 2. The biggest complaints – the screen resolution, the slower USB 2.0 port, the placement of the MicroSD reader, and the single-position kickstand – were addressed. Rather than saying “if you don’t like our product, you’re wrong!” Microsoft did what any business needs to do to keep its customers – they listened to feedback and did something about it. The result? The Surface 2 sold out and was impossible to find in most regions until after the holidays. Even now the updated Surface Pro 2 can be hard to get your hands on.

Windows 8.1 had the same impact. Customers had a hard time adjusting to Windows 8’s replacement of the start menu with a full-screen Start interface, so Microsoft added an option to boot directly to the desktop3). Customers wanted more customization options for the Start screen, so Microsoft listened and added more options for changing the color scheme, menu background, and tile size. The search interface was unnecessarily complex and required extra clicks to find files or settings, so it was streamlined into a single results list, with the option to view expanded search results if needed.

It’s great to be proud of what you’ve accomplished when you create something. However, software development is not like modern art – you can’t create and respond to criticism with “you don’t understand the meaning of art”. Instead, it is paramount that developers learn how to handle criticism and customer pushback gracefully. Until that happens, even the largest open source projects will have a hard time finding acceptance in the business world, and those that do – like Linux – will continue to require real businesses behind them, like Suse and Red Hat.

Will I stop using Firefox? Of course not. I don’t find Chrome to be an adequate replacement for my needs, and I rarely use OS X. When I’m on a Mac, I found an addon to replace functionality that never should have been removed in the first place4). However, retaining users should not be seen by the developers as a message that what they’re doing is working. It should instead be viewed as an unfortunate fact that their users don’t have a good alternative and are at the mercy of the developers’ stubbornness and arrogance.