On March 4th TorCHI hosted Mike Beltzner (blog) who is the Director of Development at Mozilla, though he prefers to call himself the “phenomenologist.”  His talk focused on how Mozilla has harnessed the power of the open source community to build Firefox: managing the chaos of open source and have good ideas rise to the top.

I’d like to share some of the notes from his talk, as I have a feeling I’ll be going back to them in a few years when I’m an open source superstar.

Listening to People

When you have an open source project, your developers aren’t your work friends and users aren’t people you can call.  Thus there have to be very well defined and implemented listening channels.  Examples of which are (from lowest fidelity to highest):  crash reports, form-based feedback, bug-trackers, wiki’s, forums, IRC. All are important.

Ideas on voting:  in open source projects, voting (“+1!”) works as a great pacifier. It can be used to measure impact, severity, and interest, but should not steer what is of primary importance (or really used to make any important decisions on things).

Designing by/for People

Despite the fears and chaos, design-by-community has rarely steered Mozilla wrong.  Though it may be chaotic, the community has very strong and hierarchical leadership. Through effective leadership, good design ideas rise to the top.  More on that later.

Design-by-community is very different from, say, what Apple does.  Apple has one persona: Steve Jobs.  That’s great as long as Steve doesn’t miss any ideas (which he will), and if he doesn’t love things that aren’t all that super-great (Cover Flow).  Apple doesn’t have a succession plan for Steve.

Gave great example of the development of the UI features involving closing tabs in Firefox. Ultimately he admitted that Google Chrome got it right, Mozilla got 80% of the way there, as per normal

Organising the Chaos

Expect chaos in open source.  Managing chaos begins with managing the design, rather than the code itself.   In any design decisions, opposite camps form very quickly – especially spurred on by half-finished designs being released as Alpha products.

To manage this chaos, you have to infuse some order.  First point of order is having a public and well defined road-map or a cheat-sheet of where the product is going.  Then build the product in layers, and introduce every major change as an Add-On first.  Educate contributors about “why” things are happening.

Discussions should be supported by research and data (possible cross-over with academia here, especially for people looking for small M.Sc. projects).

Disagreements ultimately end in negotiation, but never forget BATNA .. what’s the worst that will happen (typically “Screw you guys, I’m going to Opera”).  No you won’t.  And if you really disagree with the design change, write an add-on to correct it (yey!).

Leadership and Playtime

You need to identify and elevate in importance people who are “good” contributors – reward them with ownership of small modules in their expertise domain. Form small teams with well defined scopes of responsibility.  The leadership of these teams can be concentrated around these good contributors.

The modules of code are led and owned in a heirarchical manner. Ultimately, someone is the sole owner of the whole thing.  In the case of Mozilla, it’s Mike Connor (youtube) from Toronto, who is kinda hilarious.

Give your contributors complete and absolute freedom to explore the system.  They will reward you with neat things like add-ons to inject random stanzas of poetry into web pages, and localised versions of your product.

Localisation as more than Translation

This came out of the discussion portion, but he spent a great deal of time discussion on the localisation challenges involved with marketing Firefox in China.  He wrote extensively about it on his blog.

The bottom line is that localisation has to be more than translation: it involves studying the interaction of the people with the product, and changing the design of the browser.  Not the technical core of the browser – you should be able to adjust all necessary behaviours and design via add-ons. Discussed how Maxthon benefitted by being included on a very popular pirate build of Windows.

Lesson here is that customisation via add-on’s is ultimately key to solving many design problems.