Participation Lab Notes: Volunteer vrs Contributor

Emma Irwin



As part of the Participation Lab’s efforts we recently began conducting  experiments on the Get Involved Page seeking to better understand how people navigate and connect (or fail to connect) to contribution opportunities. In preparation for this experiment we looked at some of the research that the team had conducted in recent years, and a number of their  key learnings led us to a deeper conversation about the language and labels we use to invite contribution to Mozilla. Some of the those learnings were:

  • People need to understand what, and why before they’ll be interested in understanding how they can contribute to Mozilla.
  • We must make it immediately apparent that the Get Involved  page is seeking volunteers and not employees.
  • We need to set clear expectation of investment/journey needed to get involved or become a Mozillian.

This matched some other feedback,  and as a result we decided to conduct a series of interviews to discover more ideas and prejudices that exist around the terms volunteer and contributor. Eighteen interviews covering diverse perspectives were conducted, these included core contributors, project leaders, alumni, community project leads, those working in open science, advocacy and randomly selected people in my life who had never contributed to Mozilla.  We discovered four interesting insights shared below.

Project preference is ‘Contributor’


Overall, people working in, or already volunteering with Mozilla were more comfortable with ‘contributor’, but agreed that unless your background was working in a field like software engineering, or science where the term is already part of the language ecosystem, it might be challenging to grasp.  I also noticed  a trend in feedback that acknowledged  once you’re regularly involved  in a project you might no longer be objective, and that we may, in fact, be skewing even the most common understanding of these terms. One example given was the use of  ‘paid contributor’ and ‘volunteer contributor’, which made no sense for most people outside of Mozilla.

The term ‘Volunteering’ is more universally  associated with lending time and skills but…


While people seemed to generally understand that volunteering was about lending time and skills, I encountered sensitivities that the word ‘volunteer’ which invoked feelings of being ‘charitable’ vs the more empowered feeling of being a ‘contributor’ .  I heard that ‘contribution’ lends to a feeling we’re part ‘part of something ’ while ‘volunteering felt more detached.  One core contributor felt very, very strongly, that volunteering was not the term for what they do at Mozilla.

‘Contribution’ feels more like giving a gift or donation


Feedback from non-technical contributors ,and those I spoke with outside the Mozilla community indicated that  the term “contribution” was easy to misinterpret as being about donating funds or something of greater significance than some people felt they could offer.  When asked, a couple of people cited political campaigns, and fundraisers as the most common association they with the word ‘contribution’.

What’s in a Name?


It was also suggested that at Mozilla we should stop labouring over generalized terms like volunteer and contributor,  and instead focus  energies on clarifying ways people can help – One person felt that such opportunity  exists in more explicit ‘role titles’  i.e. Android Community Ambassador’.   The hypothesis is, that by providing role titles we can help people connect to opportunities that are resume-worthy with recognition that contribution is an opportunity.  Of course, there are already examples of success with role names demonstrated by the Mozilla Reps program and most recently Club Captains and Regional Leads in Webmaker Clubs.


We had an interesting suggestion that  we make up our own name!  Create a Mozilla-fied name for volunteers that makes volunteering at Mozilla a unique version of both terms.  An inspiring example was the London Olympics which called volunteers ‘Games Makers’, what a Mozilli-fied version would be remained unclear :)  but I’m sure we could come up with something.  What do you think?

Additional lure of a Mozilla-fied name is a chance to help people recognize the amazingness of the community they would be joining which MDN reported to be a factor in repeat contribution in their area  – and similar to how an Olympic volunteerism resonated with a name describing their impact.

So where from here?


There is the opportunity for continued experimentation and testing using the Get Involved Page, and  we would love to hear from you – contributor volunteer, Mozillia-fied name?

What experiment  do you think the Participation Lab should design  next with these new insights?



Image: “Mozilla Summit Day 2” by Roland Tanglaois licensed under CC BY 2.0

Meet an MDN contributor: klez

Janet Swisher


Photo of Frederico klez Culloca

Federico klez Culloca made his first few edits to MDN in 2013, but started contributing in earnest in 2014, as a localizer for Mozilla Italia. After a couple of months, he started attending the bi-weekly MDN Community meeting, and later the Learning Area meetings. After that, he concentrated his efforts on the Learning Area of MDN, especially the Glossary.

He says that working on MDN gives him a good idea of how an organization as big as Mozilla actually works, bringing together paid staff and volunteers.

His advice for MDN newcomers?

Don’t be afraid to make mistakes in good faith. Someone is always able and willing to correct them and help you learn from your errors. It’s a wiki, after all :-)

Thanks, klez, for all your contributions to MDN!

Participation Lab Notes: The Power of Swag

Lucy Harris


It doesn’t take long, once you’ve entered the Mozilla community before you notice that swag is a big part of Mozilla. Stickers, t-shirts, lanyards are everywhere and for many Mozillians these things have become a kind of currency with emotional and physical value.

Photo by: Doug Belshaw on Flickr

Photo by DougBelshaw/CC BY 2.0

In 2014, Mozilla spent over $150,000 on swag to engage contributors across four major initiatives: Maker Party, MozFest, Mozilla Reps, and Firefox Student Ambassadors (FSAs).

However we rarely stop to examine what we are learning about the results, benefits and challenges of this investment.

In order to surface and capture these insights the Participation Team interviewed four groups at Mozilla, for whom swag is a core part of their activities, and identified the most interesting insights and challenges faced by each group.

As a result, we discovered that many of the groups face similar challenges but have found distinct solutions and strategies for managing them. The two major insights were that by encouraging local production of swag, and creating swag that is tailored specifically to the needs of the community, costs can be minimized and value to the community increased.

Maker Party

Although in the past year, swag has become a much smaller part of Maker Party as the campaign has become shorter (17 days vs. the previous 2 months) and more contained. In 2014 thousands of people spent the summer throwing events, and swag was an integral part of growing and motivating the Maker Party community.

Insight : Swag Legitimizes Hosts & Events

Much more than a form of recognition for event hosts, in many communities swag is perceived as a vote of confidence from Mozilla that legitimizes both the host and the event. Many communities feel that if we are willing to support an event host and their event through physical things, and it marks them as “officially sanctioned” by Mozilla and this alignment with the brand dramatically increases the influence and reputation of the contributor and the event.

For example, in South America, a Maker Party host created Mozilla branded mouse pads to legitimize their events in the eyes of local internet cafe owners who let them use the space for free in exchange for Mozilla branded mouse pads.

Challenge: Cost of Shipping

For Maker Party, shipping swag across the world, often to extremely remote areas, was very expensive and problematic. Certain countries charge enormous taxes on clothing and have been known to detain parcels with t-shirts – to the detriment of volunteers who often cannot pay the high customs fees.


While MozFest, as a short-term festival is a bit different from the other examples,  it identifies another way in which we use swag to build and support community.

Insight: Swag is Key to Partnerships

Every year MozFest partners with other like-minded organizations to put on the event. As part of this relationship, partners are offered the opportunity to distribute swag and some promotional material to attendees. As a result Mozilla can produce a small amount of swag like a tote bag and water bottle, and have partners add their swag to create fun gifts for participants that also act as promotional pieces for partners and Mozilla.

Challenges: The Right Swag

Finding swag that is re-usable and has value outside of the event is challenging, but water bottles and tote bags have proven popular and effective, and have the added benefit of reducing the event’s environmental footprint.

Mozilla Reps

Unlike Maker Party or MozFest, Mozilla Reps is a community where individuals participate in multiple ways over a sustained period of time. For this group, it is often the variety rather than quantity of swag that drives excitement.

Insight: Creating A Collectors Culture

Within Reps, swag is a great way to acknowledge contributors and support events. However, in some circumstances, swag can come to be seen as a symbol that represents value and status in the community. Therefore as more of a swag item is produced the value of each item diminishes, and collectors culture has developed. While rare swag is a very powerful tool for driving engagement and recognizing achievement in the Reps community, it is important to be aware of the number and variety of an item that is produced, and to carefully manage expectations to prevent swag becoming an end in and of itself.

Challenge: Mitigating Expectations

As swag is a large part of the Reps culture, it is important to be careful about the expectations that are set around the value of swag. Limiting the kinds of official swag that is produced to t-shirts, stickers, and posters and having clear value attached to each, may be one way to keep expectations low and guard against increasing expectations.


The Firefox Student Association has many parallels in it’s structure and its relationship to swag as the Mozilla Reps program. However by carefully controlling the value of swag, and encouraging local production, many of the challenges faced by other groups have been avoided.

Insight: Careful Curation & Local Production

The FSA’s have solved problems related to shipping swag, and reduced the “freebee” quality by having FSA’s create their own swag locally and then be reimbursed for the cost. Like the Reps program they also have a collectors culture but set formal expectations on the “value” of different kinds of swag ie. t-shirts are something you have to earn, stickers are freebees you can give away at your event, and posters are something you have to produce yourself.

Challenge: Tracking Designs

Because unique designs are a large part of what gives t-shirt swag it’s value, there is a struggle to find and keep track of the many ways t-shirts and designs are being used across Mozilla. In order to coordinate the FSA program suggested creating a central repository of t-shirt designs and what/when they should be distributed so that the use of swag can be better aligned across all of Mozilla.

Overall, across Mozilla there is a great deal being learned and experimented with around swag as well as many areas for growth and improvement. Our hope is that by surfacing these lessons and insights, we’ll spark new conversations and gain more insights into the swag processes and how it can be improved. If you have experience or thoughts around swag at Mozilla please share them in the comments here, or on the Participation Team Discourse page.

MDN Fellows: What They Did & What’s Next

Diane Tate

It’s hard to believe our MDN Fellowship Pilot is winding down! Announced in May and oriented in June, our five Fellows and mentors have been heads’ down ever since.  Here’s a short summary of their accomplishments in the program and a taste of what’s next.

Curriculum (Steve Kinney, Fellow; Chris Mills, Mentor)

For the curriculum Fellowship we selected to write a full course on “Advanced beginning JavaScript.”  Steve and Chris considered this to be important because, while there are loads of resources looking at beginner-level stuff like variables and basic function usage + a load of discussion of really advanced techniques, there is very little to help a budding developer who has already mastered the basics and wants to level-up their skills.

Steve and Chris are still working on the course, and will be for weeks to come — see the repo, and read the index file for an idea of the content we’ll include.

If you want to dig in right away, you can already start working through some of the tutorials and demos.

Service Workers (Flaki Szmozsanszky, Fellow; Brittany Storoz + Anne Van Kesteren, Mentors)

With more widespread browser support for service workers fast approaching, we were aiming for creating a “baseline” service worker content kit. It was to cover the general, high-level “what are service workers and why should I care?” questions as well as being able to provide resources for interested parties. Take a test drive of the content kit here.

Beyond just collecting and completing the above baseline content kit, during the Fellowship Flaki had the chance to work closely not just with his service worker mentors Brittany Storoz and Anne van Kesteren but also with the content & platform teams at Mozilla who work hard on implementing service workers and related features in Firefox & Firefox OS.

We also devised a proof-of-concept transparent image format polyfill that uses service workers, which, besides being a novel approach in using service workers, helped a lot in uncovering some lurking bugs in Firefox’s preliminary implementation. We especially want to thank Ben Kelly of the platform team who was invaluable in tracking down, reporting and fixing those issues.

See this blog post for more details on the content kit and the proof-of-concept polyfill.

Test The Web Forward (Ben Boyle, Fellow; James Graham and Josh Matthews, Mentors)

As Test the Web Forward already has great documentation on getting involved, we had two goals: (1) address the quality of the contributions, and (2) build confidence in new contributors.

We’ve focused on understanding web specifications in order to write accurate tests both in terms of coverage (understanding the detail in a simple specification) and in challenging assumptions so that tests are based on what the spec says (and not what we think it means).

We’ve set up a codepen to use the testing framework. This can be forked to write new tests to check behaviour and is useful for exploring a problem, or for accompanying bug reports. It’s a nice quick way to get started, before installing the Test the Web Forward repo to contribute directly.

We are also working on a couple of case studies (more to come) showing the experience after finding an interoperability issue including researching the specs and analysing the behaviour seen in browsers. Each journey is different, and a wonderful chance to learn more about the web.

Web App Performance (Vignesh Shanmugam, Fellow; Harald Kirschner, Mentor)

With the increase in average website size, we need to better access the web from varying levels of computing power devices and experiments to show the impact on revenue with the increased load times – particularly during development.

The content kit that we are building helps web developers and others understand basic techniques for their websites to load faster. The focus is heavily on the network side of the performance since 70% of the time is spent on the network. Our Content Kit also has various beginner and advanced tutorials, slides and demos.

The kit is not complete yet. We are also planning to include lots of deep dive tutorials on understanding packet level information on TCP stack, how to leverage modern capabilities in browser etc. Please feel free to pour in your ideas.

It was an amazing experience to work with the fellows and mentors who are all part of the MDN fellowship program. Thanks to Mozilla for making this happen :)


WebGL (Greg Tatum, Mentor; NIck Desaulniers, Mentor)

It has been really exciting being part of the first Mozilla Fellowship group. One of the big reasons for my involvement with the web and open source communities is the feedback from my peers and the quick sharing and collaboration on ideas. The fellowship has quick-started my involvement with MDN and their enthusiastic team of staff and contributors. One of the most valuable experiences was being able to write an article for MDN and get immediate in-person feedback from one of the staff writers. It was really empowering to know that the docs I use every day are so easily improved.

I had a blast diving into explanations of some of the fundamentals of how you go from abstract data to 3D-rendered images in the browser. It was really helpful for my own understanding to build out content kits and articles that step through matrix math fundamentals, the 3d projection process, and finally getting to taking that data and lighting it.

I’m very passionate about creative coding and the technologies surrounding it. It still feels like a niche genre with a community that is growing, especially with people moving from desktop applications to web projects. I only want this community to get larger and produce more and more interesting works that inspires me. I hope my time spent with the Mozilla Fellowship and other open source contributions can help to continue to grow people’s knowledge and interest in technologies like WebGL.

Content kits

Shared utility library for WebGL explanations:

MDN Articles based off of the content kits:

…with Lighting Models coming soon

What’s Next?

We’ll be evaluating the role that this type of program might make towards the goals of both MDN and Mozilla overall. You also might see more contributions on MDN from our Fellows. And rumor has it you may be seeing some of this great work – and even contributing to it – at our November MozFest event in London.
Can’t get to London? Nothing’s stopping you from diving into those repos.

Firefox 41 new contributors

Josh Matthews


With the release of Firefox 41, we are pleased to welcome the 62 developers who contributed their first code change to Firefox in this release, 51 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Participation Lab Notes: Short Simple Tasks Increase Engagement

Lucy Harris

The Mozilla Participation Lab is an initiative that focuses on experimenting and surfacing new approaches to Participation. Read more about the Lab on our wiki page.

Every year, about 7 million people come to the contribute page on looking for information about how to get involved with Mozilla. These visitors represent an exciting opportunity to increase the number of long-term relationships Mozilla has with people who are passionate about the open web.

Right now, however, only about 0.76% of those people ever register to contribute. Even once they’re registered, how we connect them to their contribution area of interest is far from optimized.

In partnership with the team, the Participation Team has set out on a medium-term project to try and maximize the potential of this page. Our aim is to make it a better tool for potential contributors, Mozilla, and the mission.

This first experiment set out to figure out how to increase engagement with tasks presented to a visitor after they said they were interested in contributing. We designed and ran an A/B test over a few weeks, presenting visitors with different types of tasks.


  • we were able to increase the engagement rate to 60% (from 15%) in selecting tasks
  • visitors preferred simple tasks to challenging tasks, and shorter tasks to long tasks
  • presenting more options (6) versus fewer options (2) increased the number of people who chose to pursue a task

Keep reading to learn more about the results and the future iterations and experiments we have planned.


In this A/B test we created four new versions of the contribute sign-up page. Each page presented viewers with a number of tasks categorized either as simple/challenging (variation a) or as taking a little time/more time (variation b). For each of these variations we displayed either 2 or 6 tasks per page.

Variation B : Simple vs. Challenging

Variation B : Simple vs. Challenging

Variation A : Little Time vs. More Time

Variation A : Little Time vs. More Time

For the purpose of this first test we did not track engagement past choosing the specific task, and we did not track engagement with individual tasks, measuring only the category of the tasks selected (eg. simple/challenging or little/more time).


The major findings from this first round of testing were that visitors to the contribute page preferred simple tasks to challenging tasks, and shorter tasks to long tasks. We also found that presenting more options (6) increased the number of people who chose to pursue a task instead of selecting the “not ready” button. Finally across all of the page variations we found the percentage of people who engaged with the pages (either by choosing a task or selecting not-ready) was 60%, much higher than the 15% engagement rate of the original page.

Based on all of the results we can infer that majority of visitors to the contribute page prefer easier, low-barrier tasks, and prefer a handful of choices to just 2.

However there were still a minority of individuals who expressed a preference for more challenging tasks — they may represent skilled contributors who are ready to become deeply engaged in complex projects. In coming iterations of this experiment we will be exploring the level of readiness and skill of these contributors, and whether individuals from this group are more likely to become core contributors than those who selected simpler tasks.

Overall, the enormous engagement rate by both groups further supports the amazing opportunity latent in this page.

Next Steps

Over the coming months we will undertake several rapid iterations on this test. There is a great deal still to be learned, however we believe that through experimenting with participation in venues like this we can unlock huge potential to help people engage with Mozilla in high impact ways.

Over the next few weeks the Participation team will be working to design a second experiment and we will focus on:

  • Enhancing our understanding of the specific kinds of tasks contributors are most interested in
  • How the task completion rate varies among types of tasks and levels of difficulty and what this tells us about the contributors we are able to attract through this page
  • How wording and framing of tasks effects task selection and completion

Other topics we will seek to explore in the longer-term include:

  • Understanding best practices for how to setup second and third tasks to engage contributors in a more long-term way
  • How presenting localized tasks affects completion rate How to identify and present tasks with the maximum appeal to contribute page contributors
  • How to provide “off-shoots” for the non-typical contribute page contributors (such as those who want to contribute code)
  • How to increase the conversion rate from the homepage to the contribute sign-up page If, when and how to collect email sign-ups and what the process is for engaging contributors by email

This project is currently owned by Lucy from the Participation Team in conjunction with the Team. If you have any questions, ideas for future tests, or if you just want to chat about the future of this page please do not hesitate to get in touch!

Firefox 40 new contributors

Josh Matthews


With the release of Firefox 40, we are pleased to welcome the 55 developers who contributed their first code change to Firefox in this release, 49 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

  • ijdt.editor: 1139429
  • kevin.m.wern: 1148694
  • wrahman0: 1132208, 1150514, 1153877
  • Aaron Graham: 892229
  • Aime Galmi: 1084911, 1132213
  • Ali Movahedi: 1154773
  • Anirudh S: 1134494
  • Anthony Tseng: 1158425
  • Anton Myagkov: 1132558
  • Antonio Ladeia: 1123372
  • Atif Iqbal Ahangar: 1150197
  • Bryan Quigley: 1155943
  • Daniel Miller: 699860
  • Darren Lyons: 1147233
  • David Cooper: 667471
  • Denis Volk: 1095098
  • Dipti Nirmale: 1148095
  • Dmitry: 1154676
  • Dmitry Sagalovskiy: 977586
  • Elbart: 1069979
  • Ethan Wu: 1148268
  • Fabian Furger: 1107941
  • Florian Merz: 1063946
  • Giorgos Logiotatidis: 1155579
  • Gordon Klaus: 1155140, 1155648
  • Ilya: 1125816
  • James Lai: 1150800, 1155956
  • Jose Rios: 1161640, 1161666
  • Julian Descottes: 999568
  • Kai Bittner: 1148167
  • Kartik Somani: 1147398
  • Keita Mimura: 1137234, 1149198
  • Kevin Chen: 1097479
  • Kit Cambridge: 1150683
  • Krishnashish Gogoi: 982852
  • Lee Salzman: 1156536, 1158154
  • Martin Tomes: 1084296, 1160487, 1160489
  • Matt King: 952290, 1140592, 1147027, 1150621
  • Michael[tm] Smith: 1096172
  • Morgan Phillips: 1151834
  • Nazim Can Altinova: 1127234, 1144399
  • Németh László: 318040
  • Patryk:Res: 733679
  • Paul17041993: 979705
  • Ross: 1152454
  • Ryan Hamley: 1150484
  • Ryan Nath: 1158547
  • Shane Tomlinson: 1146904
  • Sheefeni Hauwanga: 1142192
  • Shyam Venkatesh: 1157728
  • Taylor Brown: 1018932
  • TheOneisNEO: 1149872
  • Thibaud Backenstrass : 1157661, 1158122
  • Tomas Flek: 1127139
  • bogas04: 1139026
  • cedric raudin: 1079697, 1115365
  • Q3 Objectives for the Participation Team

    Lucy Harris

    After weeks of meetings and planning the Participation Team has decided on six objectives to focus on this quarter.

    Each of these objectives was chosen for it’s ability to bring us closer to our 2015 goal: Demonstrate that participation brings strategic advantage to Mozilla’s key product and functional goals.

    Here are our six objectives for Q3 and the key results for each:

    1. Firefox OS Ignite Initiative has a great, validated community program design

    View on GitHub

    • KR1 – Long-term FirefoxOS community program design
    • KR2 – 50 weekly users of updated Foxfooding tools
    • KR3 – 100 weekly contributors on ‘beta’ community collaboration platform
    • KR4 – 5 “test” events for in-person contribution and community building

    2. Mozilla and Firefox brand building efforts in Germany  boosted by larger and stronger community

    View on GitHub

    • KR1 – Specific areas of contribution and participation measures defined jointly by participation and engagement teams
    • KR2 – 10 new community leaders/organizers recruited and on-boarded
    • KR3 – Events with a total of 1,000 attendees for the purpose of growing community and building issue support

    3. Our Indian community is successfully contributing to Fennec with “local” strategy in mind

    View on GitHub

    • KR1- 25 contributors active and committed on Fennec projects
    • KR2 – Articulation of strategic opportunities/options for bringing local advantage to Fennec

    4. Systematize support for ReMo and communities of focus

    View on GitHub

    • KR1 – ReMo + region/country of focus + partnership performance profile, dashboard and review process is developed and implemented
    • KR2 – Medium-term planning process in 3 communities is developed and tested
    • KR3 – Coaching methods and process for community leaders is systematized

    5. Launch the basics of a refreshed leadership development program

    View on GitHub

    • KR1 – Basic first iteration of “Foundations of Mozilla” curriculum is developed and tested
    • KR2 – Volunteer selection for MozFest, Leadership Summit and Orlando Work Week is strategic and builds trust with volunteer communities, by designing, executing and systematizing a process
    • KR3 – Outline and plan for a Leadership Summit to be held in late 2015 or early 2016

    6. Cross-Mozilla Participation Technology Group is formed and aligned on goals and key questions

    View on GitHub

    • KR1 – Participation Technology Group is formed and trust is built through delivering a first draft of user stories and technology options
    • KR2 – 7 of 9 Mozillians next and Reps abstraction projects delivered

    We work in three week sprints called “heartbeats” and you can follow along with each of these projects on GitHub to see what we will be working on for the next three weeks.

    Can’t find what you’re looking for? Team members also have individual projects and objectives that aren’t directly related to these team objectives. You can read about the other projects we’re working on here.

    Want to get involved? Search for tasks with the “Volunteer Task” label here.

    Meet an MDN Contributor: Heather Bloomer

    Janet Swisher


    Headshot photo of Heather Bloomer

    Heather Bloomer started contributing to Mozilla in November 2014, initially on SUMO. There, she saw a link to MDN, and realized she could contribute there as well. So, she is a “crossover” who contributes to helping both end-users and developers. She has been heavily involved in the Learning Area project, writing and editing Glossary entries and tutorials. She describes her contributions as “a continuing journey of enlightenment and an overall awesome experience.”

    Here’s more from Heather:

    I feel what I do on MDN has personally enhanced my writing skills and expanded my technical knowledge. I also feel I am making a positive impact in the MDN community and for developers that refer to MDN from beginners to advanced. That is an amazing feeling to be part of something bigger than yourself and grow and nurture not only ones self, but others as well.

    My advice for new contributors is to just reach out and connect with the MDN community. Join the team and just dig in. If you need help on getting started, we are more than happy to point you in the right direction. We are friendly, supportive, encouraging and a team driven bunch of folks!

    Thanks, Heather!

    Ten years of evolution of MDN

    Janet Swisher


    Logo for MDN 10 year anniversaryThis week marks the tenth anniversary of Mozilla Developer Network (MDN) as a wiki. This post offers a deep dive into where MDN came from, how it has evolved in various ways, and where it may be going.

    (This post is based in large part on a round table discussion about MDN that was held during the “Hack on MDN” weekend in Berlin in April 2015, and on Florian Scholz’s history of MDN’s JavaScript documentation.)

    What is MDN today?

    For many web developers, MDN is the reference manual for the Web, the place they go to look up or learn about open web technologies. MDN offers much more than that. It is a resource for learning about the Web, and a place for developers to share their skills and knowledge. MDN’s strength lies in its openness, where anybody can help make the resources incrementally better, or substantially better. MDN can also encourage the growth of web technologies into new spaces from where they’ve been in the past.

    MDN is a community of programmers, writers, and localizers. A few of these are paid staff of Mozilla, but they are a subset of the larger community of people who make small or large contributions.

    One of the coolest things for those who contribute to MDN is that every time we talk to developers, they tell us how much they love MDN. It’s not, “Oh MDN is kind of cool,” or “It’s great.” The response is: “I love MDN. It’s the best resource out there.” It’s tremendously gratifying to feel that you are part of something that people really love.

    Who is MDN for?

    MDN serves a variety of audiences:

    • Web developers, first and foremost
    • People who want to teach themselves about web development
    • Teachers of web development skills and concepts
    • Developers in the ecosystem of Mozilla products, such as Firefox add-ons, and Firefox OS apps
    • Developers working on the Mozilla codebase

    Beginnings of MDN

    The site that became MDN, or “Devmo,” started as a redirect to a developer-oriented page on the main site. Later that content was moved over to Devmo; it contained primarily information for developers contributing to the Mozilla codebase.

    Just as the Mozilla project emerged from the remains of Netscape, also MDN as we know it began with documentation originally written at Netscape. The site known as “Netscape DevEdge” documented web technologies, such as JavaScript, and other things that were implemented in Netscape products. After Netscape was acquired by AOL, the DevEdge site eventually was shut down, and that information disappeared from the Web.

    Mitchell Baker (Chair of Mozilla) and others from Mozilla worked out an arrangement with AOL to release the DevEdge content, which she announced in February 2005. At the same time, Deb Richardson was hired to migrate and curate the DevEdge content into Devmo.

    Mitchell and Deb made the decision to put the content into a wiki, to enable open contributions to maintain and update the content. Previously, the DevEdge content was in a CVS source control system, and published as a static site. Using a wiki for documentation was a novel concept at the time, and it took a while for some core developers within the Mozilla project to warm to this way of working. However, others quickly embraced the idea, and the many of the earliest contributors to the Devmo wiki were developers who were active elsewhere in the Mozilla project.

    Deb and some volunteers spent a few months mining and migrating the still-useful content from DevEdge, working on a test server. This effort was still in progress when the content was migrated to the Devmo site, now titled “Mozilla Developer Center” or “MDC” in July 2005. We mark this as the starting point of what we now call Mozilla Developer Network.

    Platform evolution

    MDN has lived on three different wiki platforms in the course of its history: first MediaWiki, then MindTouch DekiWiki, and now Kuma, a Mozilla-developed platform. Looking at the technical infrastructure is interesting not just from a technical point of view, but also because technology influences social structures like community.


    The wiki platform used for the first iteration of MDC was MediaWiki, the open source software that underlies Wikipedia. It was the most robust and widely-used wiki at the time. The Devmo project began to discover that software designed for writing a general-purpose encyclopedia was not necessarily ideal for writing developer-oriented technical documentation. For example, it did not handle code examples well, reformatting them to be unreadable. Mozilla tried to fix such issues by creating its own fork of MediaWiki, which then ended up being quite difficult to maintain.

    On the level of contributions, using MediaWiki was initially an advantage, because many technical people were already familiar with how to use it. However, the project eventually reached a plateau, where it became difficult to keep contributors coming back. This, combined with the technical quirks, led to a search for a more user-friendly platform.


    After an evaluation process that looked at all the wiki products available on the market (not just open source ones), the choice was made of DekiWiki by MindTouch. One advantage of DekiWiki was that the source format for articles was HTML, rather than wiki markup. It seemed a logical choice for a site targeting web developers, to have the source format be a standard web language. This required migrating all of the content from MediaWiki markup format to HTML, which was a major migration project. The choice of DekiWiki was announced in November 2007, and the site switched to it in August 2008.

    While DekiWiki was a quality product, one way that the selection process was flawed was that it did not include a major group of stakeholders: volunteers who contributed to the site. The rate of contribution nose-dived, because the platform was not embraced by the contributor community. In particular, localization communities, who translated the content into various languages other than English, were severely disrupted. They had built tools and processes around working with MediaWiki, and these tools didn’t work with DekiWiki. After a few months, many of these groups simply disbanded and decided not to contribute any more, with the result that translated documentation started to become stale, and became more and more out of date over time.

    DekiWiki was also written in C#, and designed to run in a Microsoft .NET environment. This was a mismatch with Mozilla’s technical infrastructure, which is Linux-based. Trying to run DekiWiki on Mono led to a great deal of instability, with the site being down for days and weeks at times.

    These issues, after a couple of years, led to looking for another solution. The best candidates on the market were still MediaWiki and DekiWiki. Now that the content was all written in HTML, migrating back to MediaWiki markup syntax was not feasible. No product seemed suited to the specific needs of an open developer documentation site, so Mozilla decided to create its own.


    The current platform for MDN, known as Kuma, is written in Python with Django. It started as a fork of Kitsune, the platform for the Mozilla support site, and was adapted to the needs of a wiki site for developers rather than end users. (Also, “kitsune” means “fox” in Japanese, and “kuma” means “bear”. Because users : foxes :: developers : bears, right?)

    Like DekiWiki, Kuma uses HTML as the source format for the content. The migration effort in this case was converting the scripts and macros used on the site. DekiWiki used “DekiScript,” based on Lua, while Kuma introduced KumaScript, which is based on JavaScript, using Node.js. KumaScript is the brainchild of developer Les Orchard. As with creating content in HTML, KumaScript means that MDN is implemented using the same technologies that it documents, and that its contributors are familiar with. It was possible to migrate about 70% of the existing macros automatically, but the rest had to be manually converted.

    The goal when launching the Kuma platform was to achieve feature parity with the DekiWiki implementation of MDN. The content was migrated to the new system, and changes from the production server were periodically updated on the Kuma staging server. Thus, the Kuma instance was kept in sync with the production DekiWiki server. While the months leading up to the launch of Kuma were involved a great deal of migration work, the actual launch was very smooth. A routing switch was flipped, and traffic shifted to the new site seamlessly, without even disrupting login sessions.

    Community evolution

    From the beginning, the community for the DevMo site grew organically, starting with contributors who were already active in other parts of the Mozilla project. Like other areas of Mozilla, communication happens through a mailing list and IRC chat channel. By mid-2007, contributions were typically 250 per month. As mentioned before, the migration to Dekiwiki led to a dramatic drop-off in localization contribution, and total contribution declined as well.

    Doc contributors sitting around a table, in Paris, in October 2010

    MDN doc sprint, Paris 2010

    As part of an effort to engage the community more actively, I (Janet Swisher) was hired as a staff technical writer in mid-2010. I brought experience with open source developer documentation, and in particular, experience with the “book sprints” methodology used by the FLOSS Manuals project to produce manuals for free software in five days or less. The first MDN “doc sprint” took place in October 2010, in the Mozilla Paris office. Doc sprints bring together a number of MDN contributors, either physically or virtually, for focussed, collaborative work, typically over a weekend. These were held about once a quarter for about three years. More recently, they have evolved into less frequent but broader “Hack on MDN” events, whose scope includes hacking on the platform or tools, as well as on content, to make them more attractive to developers.
    Idea pitches at HackOnMDN weekend, Berlin 2015

    Idea pitches at HackOnMDN weekend, Berlin 2015

    In addition, the MDN community holds a number of regular online meetings, both for general information, and for tracking specific projects. These community activities, as well as the migration to Kuma in 2012, have led to a significant increase in contributions, now around 1000 per month.

    Branding evolution

    In the beginning, the DevMo site was known as “Mozilla Developer Center.” At first, it simply sported that title, with a simple skin on MediaWiki. With the move to DekiWiki, the word “Mozilla” became the Mozilla wordmark, followed by “<developer center/>”, to convey slightly more webbiness.

    Wordmark for Mozilla Developer Center

    Wordmark for Mozilla Developer Center

    In September 2010, the name of the site was changed from “Mozilla Developer Center” to “Mozilla Developer Network” or MDN. This change was met with some skepticism from the developer audience at the time, though by now they simply accept MDN as MDN. The visual design of the site changed at the same time, to a darker theme, and MDN acquired a logo, the “robot dino,” which it had never had before.

    MDN robot dino logo

    MDN robot dino logo

    Along with these visual changes, features were added to the site to broaden its scope beyond just documentation. One successful feature is known as “Demo Studio”, an area where developers can upload code demos, share them, and show them off.

    When MDN migrated from DekiWiki to Kuma, the visual appearance was preserved, so there was very little visual difference between the pre- and post-migration sites. After six to eight months of bug-fixing on Kuma, a project was started to change not only the visual design, but also the content structure. These changes were rolled out using feature flags, to users who chose to be beta testers. Thus, while most users continued to see the old design, while beta testers saw and tested the new visuals and structure. “Launch day” for the redesign consisted of simply flipping a switch in the database to make the new features visible to everybody.

    The redesign brought not only a new logo, the dino-head-map that we see today, but also structural features like the navigation sidebar, which varies depending on which content area an article is in. In localized pages, items in the sidebar that are not yet translated link to their English versions, and show an invitation to translate them.

    Content evolution

    We mark the start of MDN “as we know it” from the acquisition and republication of the Netscape DevEdge content in 2005. But in the early days, the content was very slanted toward Mozilla products and technology. Not only was there documentation of XUL and internal Mozilla APIs (which are still there), but documentation of web technologies tended to be focused on Mozilla and Firefox, for example, with big banners like “works in Firefox 2.0” or explanations of Gecko’s support of a feature in the middle of an otherwise neutral article.

    As Mozilla began engaging more actively with the MDN community in 2010, community members began to express a vision of MDN as a vendor-neutral resource for web developers, whatever browsers they are targeting. Adopting this as a strategy required a lot of clean-up effort to remove Firefox-specific content from articles about web standards, and to create the compatibility tables that exist now, with information about all major browsers. Not coincidentally, as the content on MDN became more browser-agnostic, MDN started seeing contributions from other organizations.

    MDN today and tomorrow

    Two current projects on MDN are having a major impact on the shape of MDN in the near to medium term: the Learning area, and the compatibility data project.

    MDN’s information about web technologies has long been a resource for experienced web developers. But it has poorly supported beginners to web development. The aim of the Learning area is to change that by offering tutorials and other resources to people who want to teach themselves about web development. This effort is happening in response to surveys we’ve done of our audience, who reported basic learning material as a significant gap. The Learning area project has been underway for about a year, and in that time has created a large Glossary about web technology concepts, and a number of new tutorials, corresponding to the Web Literacy Map developed by the Mozilla Foundation. The Learning area is a great opportunity to get started in contributing to MDN, since learners and teachers are as needed as technical experts.

    Currently, data on MDN about browsers’ compatibility with web technology features is maintained in tables on the relevant pages. The data is pretty good, thanks to many, many crowd-sourced contributions. But this approach is not very sustainable or maintainable; for example, every table must be replicated on all localized versions of the page. The compatibility data project aims to improve the quality of the data, make data contribution easier, make access to the data easier, and allow reuse of the data, through a centralized data store. This project is action-driven rather than time-bound; contributions and involvement are welcome.

    MDN in 10 years?

    MDN as it exists today is quite different from its beginnings ten years ago. The Web has evolved, Mozilla has evolved, and MDN has evolved. We can expect even greater changes in the next ten years. Perhaps the vision of a direct brain interface to virtual reality “cyberspace” will finally come to pass. We know for sure there will be many more web developers, many more types of devices, and many standards that are not yet written.

    Some things won’t change: Mozilla’s mission will continue to be to work towards an Internet that is a global public resource, open and accessible for all. MDN will continue to be a means towards that mission, by providing resources to enable anyone to become a creator of the Web, and to develop on the Web as a primary platform. MDN’s content, no matter how it’s delivered, will continue to be contributed by a global community of people who are passionate about learning and sharing knowledge about the Web.