Jakob Nielsen’s Comments about Open Source and Design

Business Week recently wrote a story about how Mozilla Labs Explores Open Source Design. Overall it was a great article, although it may have slightly misrepresented the role of voting in the design challenge process. It was probably the phrase “submissions are put to a public vote” that triggered Nielsen’s response:

“There are plenty of good ideas, but they don’t work well together with the real world,” says Jakob Nielsen, principal at the Nielsen Norman Group in Fremont, Calif. Open source encourages the addition of new solutions and ideas. In design, says Nielsen, “the brilliant idea can be the one unifying idea that can take away 10 other ideas.”


This quote has been stuck in my head for awhile, not because I specifically disagree but because it so accurately describes the paradox of doing design work in a transparent, collaborative, and open source environment. There is certainly no shortage of great ideas coming from our community, in large part thanks to the success of the Mozilla Labs Design Challenges. But as Nielsen points out, design isn’t just about brainstorming, it’s about unifying things, taking things away, and being able to say no. And this is where I think design in open source is often unfairly misconstrued to be based on voting and consensus building, effectively “design by committee.” People familiar with open source projects know that there is in fact centralized control both in terms of implementation and in terms of design.

What makes open source communities different is that contributors gain influence in a pure meritocracy. For instance, the design of the Firefox icon came out of the community, from a team of people who would later help to guide all of Mozilla’s visual identity. Concepts submitted to the recent Mozilla Design Challenge are impacting both the design of Firefox (a home tab that changes based on the user’s geolocation) and Chrome OS (proposal, submission). Our icons on Linux are created in the Tango style, because the Tango team has earned a tremendous amount of respect. Across both visual and interactive design we see a wide range of very successful contributions.

We also see a lot being turned down, patches failing review, bugs being marked wontfix, and the extremely common phrase “that would make a good extension” (translation: that is not going to make it into the product for mainstream users).

So I agree with Nielsen that “Open source encourages the addition of new solutions and ideas” and that “[designer's create] the one unifying idea that can take away 10 other ideas.” Where I disagree is the implication that open source projects can not successfully do both.

3 comments

  1. Alex, I’m glad you touched on this. The topic of decision-making, of editing down and saying ‘no’ in an Open Source environment is something that stuck with me from your talk at ZURB last month. You’re correct that most people probably misconstrue Open Source as “design by committee.” I know I’ve been guilty of it.

    What I’d be more interested in is transparency into who the decisions makers are, what their mental framework is for making judgments, how they communicate decisions to a community of contributors, and how timing impacts those decisions. A lot of this probably goes back to adhering to a set of core principles, but the people and techniques you use would also be interesting to learn more about.

  2. “What makes open source communities different is that contributors gain influence in a pure meritocracy.”

    Yes, most open source communities are merit based; but so are most commercial firms. Both arenas have counter examples. For example, the planning in the Mozilla project is done by an internal management infrastructure and announced to the open source community. Projects reporting to the internal structure get priority. Since Mozilla defines its community to include itself and exclude others, it can use the meritocracy excuse to validate decisions which do not make sense in a larger context.

  3. So are you saying that Open Source projects benefit from, or even need a benevolent dictator? Where this dictator can be one or a small group of people that takes up the role of saying “no”?