Upload
pascal-finette
View
105
Download
1
Embed Size (px)
DESCRIPTION
Slides from my talk at the MIT Open Innovation Workshop on May 24th, 2010 in Mountain View, CA.
Citation preview
Lessons from Mozilla:How we are learning tofoster and grow participation
Pascal [email protected]
MIT Innovation Lab MeetingMay 24-25, 2010
Warning! Your Milage May Vary
about:Mozilla
First, some context
about:Mozilla
1. a global, open source project
2. a community of thousands of creators
3. a mission-oriented organization
4. a public benefit company and subs
5. the maker of Firefox & Thunderbird
Alternatively…
about:Mozilla
Mozilla’s Mission:
To promote choice andinnovation on the Internet
The Web is too important…
seriously.
that’s it.
about:Mozilla
• Mozilla project started in 1998 within Netscape
• Mozilla Foundation started in 2003
• approximately 250 paid staff in 20 countries
• 40% of code contributed by volunteers
• testing community of 20,000+
• current reach is more than 360 million users
• global browser market share >25%
http://upload.wikimedia.org/wikipedia/en/d/d2/
Internet_map_1024.jpg
The Strongest Open Systems are Chaords
1. distributed decision-making2. nodal authority3. ways to route around
1. exhibit characteristics of both chaos & order
2. regularly yield surprising innovation
3. highly robust & scalable systems
Examples: the Internet, Visa, Wikipedia
Characteristics of Chaords (coined by Dee Hock)
Mozilla is a Chaord
1. high agreement on core values
2. decision-making rests with module owners
3. groups have distinct ways of working
4. many decision-makers outside the “official” org
5. communication is central
We are a community of creators
about:Labs
“Laboratories are where science and creativity meet to develop, research, and explore new ideas.
Mozilla Labs embraces this great tradition - a virtual lab where people come together to create, experiment, and play with new Web innovations and technologies.”
Structure
Projects Platforms Programs
Mozilla Labs so far
• 17 major projects (and many more explorations)
• 1,000+ participants
• 3,000+ submissions, ideas & concepts
• 40+ schools & universities world-wide participate
Crowd Sourcing: Concept Series
Crowd Sourcing: Design Challenge
Lessons from Mozilla
Challenge #1
Increase participationfrom non-developers
Challenge #1:Increase participation from non-developers
Situation
• The Mozilla project traditionally has strong participation from developers (and related areas) but lacks participants in fields such as UI/UX/HCI designers
Hypothesis
• Targeted outreach (e.g. universities and UX user groups) and programs geared specifically to the target group introduce participants to Mozilla, get them involved and turn some of them into long-term contributors
Challenge #1:Increase participation from non-developers
Experiment
• Targeted outreach to 50+ universities with UX/HCI programs around the world as well as IxDA (large UX user group)
• Setup of initial Design Challenge around “Chromeless Browsing” w/ video sessions, lessons, multiple phases
Results & Findings
• 15+ participating universities (on different levels) / 40+ participants / 18 submitted prototypes
• Scalability issues around program
• Prototype requirement was a mismatch to skill set (designers vs developers)
Challenge #1:Increase participation from non-developers
Refinement
• 6 additional Design Challenges
• Increased outreach to both universities & user groups
• Average participation: 100+ submissions (video/mockup)
• Parallelization of challenges problematic
• Still struggling with scalability issues
Challenge #2
Create the rightincentives & motivations
Challenge #2:Create the right incentives & motivations
Situation
• Participants in Open Source projects are primarily motivated by the desire to “scratch an itch”, social recognition, as well as learning new and expanding existing skills
Hypothesis
• Participating designers are more motivated by (formal) recognition (e.g. for CV building)
• Further: Sharing and open collaboration is much less common among designers than developers (where code sharing is common practice)
• Designers enjoy challenges which they can directly relate to
Challenge #2:Create the right incentives & motivations
Experiment
• Design Challenges have an element of formal recognition by showcasing all submissions and bestowing “Best in Class” honors (without monetary prizes)
• Design Challenges explore different topics - ranging from major Firefox features to very specific and “niche” problems
Results & Findings
• Participants react extremely positive to recognition mechanism, lack of monetary prizes doesn’t seem to make a difference
• Specialized Design Challenges result in low participation
Challenge #2:Create the right incentives & motivations
Refinement
• Careful topic selection and “dressing up”
• Expansion of public recognition element (hi-fi showcases)
• For “niche” topics: Pre-selection of relevant target groups, higher touch outreach
• Problem: Fatigue amongst participating designers
Challenge #3
Ideas don’t (automatically)
result in collaboration
Challenge #3:Ideas don’t (automatically) result in collaboration
Situation
• Participants in the Concept Series often simply submit ideas directed to the Firefox team (similar to Dell’s IdeaStorm) and don’t develop them further
Hypothesis
• Participants often lack specific skills to develop an idea further
• Collaboration across strangers is hard
• Main challenge: Lack of incentives to drive an idea forward
Challenge #3:Ideas don’t (automatically) result in collaboration
Experiment
• High-touch support of participants and their ideas within the Concept Series by Mozilla staff
• Teams of students (with complimentary skills) from participating universities, working together on single idea
Results & Findings
• Ideas overcome initial inertia after receiving input & support by Mozilla but fizzle out after support stopped
• Excellent results from student teams - though project development stops after students turn their focus onto something else
Challenge #3:Ideas don’t (automatically) result in collaboration
Refinement
• Highlighting relevant projects/ideas to turn the community focus onto them (with specific tasks)
• Potential to empower community members to take up mentorship roles (train the trainer)
• High-touch outreach has strong scalability issues
Challenge #4
Tooling
Challenge #4:Tooling
Situation
• Few existing tools which don’t fully fit the specific workflow of our initiatives and are usually designed for closed communities
Hypothesis
• A good tool can lower the barrier for collaboration significantly and make collaboration much easier
• Good tools create incentives for participation & collaboration (e.g. personal profiles)
Challenge #4:Tooling
Experiment
• Tested a couple of available tools (with different focus - e.g. StackExchange, IdeaScale, Elgg)
• Tried to build own tool
Results & Findings
• Existing tools mainly don’t work for Mozilla - openness and specific UI/UX workflow prove to be main issues
• Building your own tool is hard - especially if you don’t exactly know what you need to build
Challenge #4:Tooling
Refinement
• Currently looking into Intuit Brainstorm (which seems to fit the bill quite nicely)
• Lots of discussions with tool vendors to share learnings and evangelize the open nature of these tools
Challenge #5
Filter & voting mechanisms
Challenge #5:Filter & voting mechanisms
Situation
• Simple voting and filter mechanisms (e.g. Digg-style thumbs up/down) have known limitations and can easily be gamed
Hypothesis
• A robust voting mechanism needs to limit gaming and allow creation of a robust average from participants with different backgrounds
Challenge #5:Filter & voting mechanisms
Experiment
• Test with simple voting mechanism (all participants could vote on all submissions and leave a vote up)
• Second test with mechanism based on innovation tournaments (participants can only vote on 5 randomly selected submissions, vote on different criteria from 1 to 5)
Results & Findings
• Initial test was immediately gamed and produced meaningless results
• Innovation tournament voting very robust, yet hard to implement on an ongoing basis (voter fatigue)
Challenge #5:Filter & voting mechanisms
Refinement
• All Design Challenges will be run with an innovation tournament style voting
• Still looking for easy to implement and use mechanism for robust filtering/bubbling up of good ideas
Postscript
Some thoughts about the future
Some thoughts about the future
More experimentation
• We’re currently staffing for a role around the Concept Series & Design Challenges
• Continued experimentation w/ university collaboration
• Still on the quest to find the (mostly) right tool
• Starting to act more like a catalyst -- which fits nicely with our overall model of openess
Questions & Discussion
[email protected]@pfinette
All content CC-Attribution
Thanks & apologies & materials borrowed from:John Lilly, Chris Beard and the Mozilla Community