Blake Ross: Creating Easy-to-Use Software

I missed the first couple of comments.

Blake is currently going through a couple of bug reports (they just hit 300,000) as examples of how to think about developing software and the consequences.

Overarching theme for Firefox is to take a lot of features and make it seem really simple. I don't really know anyone who says "hey, let's make really complicated software!".

Open source for mom and dad.

History of Netscape, blah, blah, blah. But he does make a comment about how Mozilla was intended to use a community of developers working for free to build a product that Netscape could use to compete with Microsoft. Mozilla was successful in that it provided an alternative to IE, it just didn't enable Netscape to compete more effectively with Microsoft.

Why was Firefox created? The only reason it was created was because people were asking for it. The problem with Netscape was too many cooks in the kitchen... endless debate and infighting by too many people and they didn't listen to customers.  According to Ross, there was no shared interest between Netscape and Mozilla.

The Firefox solution is to take away the money part of the problem. According to Ross, Firefox does make a lot of money in spite of not focusing on money (corporate partnerships and donations). The Firefox team is small and nimble.

Development rule #1: all patches are not created equal. Second level of review that evaluates not simply whether the code is sound, but is it doing something useful. This is a departure from typical open source projects which gravitate to sound code belonging in the tree.

Rule #2: All users are not created equal. Firefox has a voting mechanism for bugs, but a lot of votes aren't necessarily heavily weighted if the source of the votes is regional or somehow. They also claim to be a meritocracy where peer respect is critical to having a voice in the community.

Rule #3: Make decisions and get a thick skin.

Open source ego. Ross suggests that open source developers talk to humans more often. "the first thing we did in Firefox was throw out half the features, the second thing we did was copy the competition".

Marketing. A lot of open source projects have problems because they don't have a website that humans can understand. The second issue is to have a brand that appeals to demographics outside of 19-25 males. Most of the Firefox promotion is occuring via word of mouth... blogs.

Simplicity everywhere, many Firefox developers use Windows. You don't create a better browser for Windows users by developing it on Linux, would be my interpretation.

How many employees: 15
How are they funded: donations, corporate sponsorships, and a $2m grant from AOL

Firefox vs. Safari: they believe they have more support and are easier to use (I agree).

International use: higher usage levels than U.S.

How is security in spite on increasing vulnerability disclosures? In Mozilla there is a policy regarding vulnerabilities, every vulnerability gets fixed in 24 hours. Outside secuity consultants audit code.

Comments

[Blake Ross]

Jeff,

Plenty of developers intend to create complicated software, particularly open-source developers, who were the focus of my talk. Many of them share a disdain for what we'd consider simple software because they consider it "dumbed down." It might be hard to discern this sentiment unless you've been immersed in the culture, but it's definitely there.

My real point in saying that "Firefox developers are obsessed with simplicity", though, was not so much to suggest that most developers aspire to complexity as that there's a tangible difference between pursuing simplicity and avoiding complexity. For example, a developer who doesn't want a complex Find system can take the easy route and use the standard Windows find dialog. A developer who wants simplicity will go the extra mile and try to devise a better solution, as we have done in Firefox. Similarly, there's a difference between not being slow and being fast. It's a question of what threshold you set for yourself.

--Blake

--Blake

[jeff]

Thanks for commenting Blake.

I've been immersed in a culture that builds complicated software because the problems/processes are complicated themselves (try building software to demand shape a supply chain, coordinate production, and orchestrate all the events required to build something). Having said that, products often get complicated as stuff gets piled on, as you noted in your talk today. Some of it is unavoidable (legacy conditions) and some of it is bad or careless design. Sometimes the best a good developer can hope to do is build a complex application that works well with the least amount of effort (even if it's a lot by definition) to use.

I enjoyed your talk today. Thanks again.