32C3 Report – Chaos Time Zone

Written by Valentin Schmitt.

Entering the CCH (Congress Center Hamburg) between Christmas and new year brings you somewhere else than Hamburg on Central European Time.

Most people you’ll meet will say they are from Internet (or the Internets, if they are funny), and for a few days you’ll live in -what a friend of mine called- Chaos Time Zone: a blurry mix of everyone’s time difference. Days are pretty shorts anyway and you’ll probably spend a lot of time under artificial light, so it won’t help your internal clock keeping on track. The organizers will gently remind you the 6,2,1 rule: 6 hours of sleep, 2 meals and 1 shower per day, that should keep you safe. You’ll probably meet a lot of great people, and will often have a hard time to decide which talk or workshop to go to.
This is the 32nd Chaos Communication Congress. Welcome, and have fun!

32C3 Chaos Communication Congress

32C3 Chaos Communication Congress – Photo: Mario Behling

FxOS is not dead.

I looked for a screen printer, or anything to do myself a t-shirt with the message “Firefox OS is not dead!” on it, but very surprisingly regarding the variety of machines there, I couldn’t find any on site. I really wanted to do that, because most of the people I talked to about
Firefox OS answered me “But isn’t Firefox OS dead?”. I bet it won’t come as a surprise for you, as there was a lot of feedback from the community regarding what some might call “a PR disaster”. It just made it very clear to me that we (still) have to communicate a lot on this topic, and very loudly, because the tech news websites will be less likely to spread the word this time.

Once this detail (*cough*) was clarified, almost everybody I had the chance to talk to showed a lot of interested for the project, the only ones who didn’t were the hardcore Free Software enthusiasts, whom have been disappointed by Mozilla recent policy choices (like the tiles with
advertisement, or the DRM support in Firefox desktop), or the people who care less about software freedom and prefer an iPhone to a free (as in freedom) mobile OS.

Mozilla and Firefox at 32C3 with friends

Mozilla and Firefox at 32C3 with friends – Photo: Mario Behling

“Well, it’s Mozilla.”

Mozilla has a pretty good image in the Free Software community, and the main reason why people never tried a Firefox OS device is only because they never had the chance to do so (not many devices marketed in Europe or the US, not many ports on mainstream phones). Fortunately enough, I had some foxfooding devices to hand out. The foxfooding program had a very positive reception, most people were happy to have the chance to try the OS, participate in sending data to Mozilla, file bugs, some were eager to develop apps, and try port the OS on their favorite phone or device (the RasPi got a bunch of them very excited).

More importantly, they really asked me how to flash a device, where to find the documentation to get started, how to file a bug. The people I handed a device to planned to show it to their colleagues, friends and fellow hacktivists, and were very excited to have phone with a hardware good enough to provide a responsive experience.


“Is there a Signal app or any secure messaging app?”
“Can I use Tor?”
“Can I keep OSM maps in cache?”
“Is there an app for WhatsApp?”
These were the questions I was asked the most. It’s pretty expected that the hackers community is looking for reliable privacy tools, but I was a bit surprised by the last question that still came up several times. 🙂

Mozillians, assemble!

An assembly is the name the Chaos Communication Congress gives to the physical place (typically a bunch of tables with a power outlet) within the CCH where people can gather to hack, share ideas and have self organized-sessions on a particular topic, or around a particular project, there were 277 registered this year.

Assembling Under The Lights

Assembling Under The Lights – Photo: Hong Phuc FOSSASIA

With the Mozilla Assembly, we had several sessions (directly at the Assembly or in dedicated rooms) over these 4 days:

  • Several Nightly Firefox OS workshops, combining more than 50 participants;
  • The Mozilla community meetup that gathered 20 participants;
  • a Thunderbird session with 42 participants;
  • an IoT and Firefox OS workshop, in a dedicated room that was packed with 90 participants;

On average, there were around 15 Mozillians at the Assembly and a continuous flow of people from different community.

Other projects where Mozilla is involved were represented, like Let’s Encrypt, with a talk so successful that the conference room was full, and New Palmyra, for which Mozillians organized a session for 25 participants.

The hackers and makers communities have a real ethical and practical interest in a mobile or embedded OS that’s trustworthy and hackable, we bear similar values and Firefox OS is a great opportunity to strengthen the ties between us.

Mozilla’s Strategic Narrative for 2016 and Beyond

All around the world, passionate Mozillians are working to move Mozilla’s mission forward. But if you asked five different Mozillians what the mission is, you might get seven different answers.

At the end of last year, Mozilla’s CEO, Chris Beard presented a clear articulation of Mozilla’s mission, vision, role and how our products will help us get there in the next five years. The goal of this Strategic Narrative is to create for all of Mozilla, a concise, shared understanding of our goals that we can use to be more empowered as individuals to make decisions, and identify opportunities to move Mozilla forward.

In order for Mozilla to achieve it’s mission we cannot work alone. We need all of the thousands of Mozillians around the world aligned behind this, so that we can do incredible things at a pace and with a voice that is louder than ever before.

That is why one of the Participation Team’s six strategic initiatives for the first half of this year is to spread this narrative to as many Mozillians as possible so that in 2016 we can have our largest impact yet. We will also be creating a follow-up post that will do a deep dive specifically on the Participation Team strategy for 2016.

Screen Shot 2015-12-18 at 2.02.07 PMUnderstanding this strategy will be crucial for anyone looking to make an impact at Mozilla this year, as it will determine what we advocate for, how we focus our resources, and which projects we focus on for 2016.

As the year kicks off we will dive more deeply into this strategy and share more details of how the various teams and projects around Mozilla are working to further these goals.

The immediate call to action is to think about this in the context of your work and about how you will contribute to Mozilla next year this helps shape your innovations, your ambitions and your impact for 2016.

We hope you will join the conversation and share your questions, comments, and plans for what you will do to drive the strategic narrative forward in 2016 on discourse here or share your thoughts on Twitter with the hashtag #Mozilla2016Strategy.

Mission, Vision & Strategy

Our Mission

To ensure the Internet is a global public resource open and accessible to all.

Our Vision

An Internet that truly puts people first. An Internet where individuals can shape their own experience. An Internet where people are empowered, safe and independent.

Our Role

Mozilla is a true advocate for you in your online life. We advocate for you both within your online experience & on your behalf for the health of the Internet.

Our Work

Our Pillars

  1. Products: We build people-centered products & educational experiences that help people unlock the full potential of their online life.
  2. Technology: We develop robust technical solutions that bring the Internet to life across multiple platforms.
  3. People: We develop community leaders and contributors who will invent, shape and   defend the Internet.

How we lock-in positive change for the long-term.

The “how” matters just as much as the “what”. Our health and lasting impact depends upon how much our products and activities:

  1. Promote Interoperability, Open Source & Open Standards
  2. Grow & Nurture Communities
  3. Champion Policy & Legal Protections
  4. Educate and activate digital citizens

Participation Lab Notes: Participation Champions

This year, during the 2016 planning process, an exciting opportunity arose to impact goals around participation across the organization. Chris Beard announced “invite participation” as one of the five top-line guiding principles for 2016 and each team was asked to show a clear connection from one of the top-line principles to their team’s goals for the year.

In order to capitalize on this momentum, the Participation Team formed a group called the Participation Champions to help improve the quality and maximize the impact of teams’ “invite participation” initiatives as they were being built.

Invite Participation Top-Line Guidance:    

  • Empowering people and building community to invent, shape and defend the Internet is core to who we are, and critical to the success of our mission.
  • Participation is key to our ability to have impact at scale. It is both an end and a means. We need it in our work and on the Internet more broadly to achieve and sustain positive change.
  • We must design participation into our products, innovation activities, and efforts to promote our cause.

The key asks for initiatives tied to “invite participation” were: 

  1. Ensure that we are designing for participation.
  2. Find and rally allies, leaders and supporters to our cause, and support their work.
  3. Identify and invest in opportunities to pilot radical and modern participation

The Process

As each team began drafting their 2016 plans and identifying initiatives for the first half of the year, the Participation Team formed a group of 21 staff members from across 11 different teams all who work directly and regularly with contributors. This group of Participation Champions met regularly with the purpose of reviewing the 2016 plans with a focus on “invite participation” to help identify opportunities and adjustments to plans that would increase their capacity to empower people and build community around Mozilla’s mission.

Our process was, first, to collectively review each “invite participation” initiative, specifically considering how it could be strengthened and identifying concerns or missed opportunities. After the collective review, each functional and supporting team was delegated to a different Participation Champion who looked deeply at that team’s goals, and made specific suggestions for strengthening participation in that area. These suggestions were based on both the feedback from the collective review and a more in-depth look at the overarching goals.

We decided that each Participation Champion would communicate those suggestions and feedback directly to the team owner and/or the planning point person. At the end of the quarter we came together assess the impact of our approach, to share what we learned and identify suggestions for future reviews.

The Outcome

Based on the final discussion we concluded that while we didn’t have an immediate and dramatic effect on the plans themselves, this exercise helped drive more conversations about participation, and added accountability to many team’s who hadn’t realized that people would be reading or reviewing their “invite participation” plans.

At the end of this process we had three pairs of findings and suggestions that we will attempt to implement and incorporate into the next strategic planning process:

  • Finding: Teams were willing to talk about increasing participation in their work but reluctant to change the label of initiative to “invite participation”.
  • Suggestion: Change the way the drop-down menus are structured in the planning spreadsheets so that it’s easier for teams to choose multiple top-line guidances. Find ways to emphasize the importance of hitting on multiple top-line guidances instead of just one.
  • Finding: Some parts of the process were uncomfortable because team’s weren’t expecting or ready to have a conversation about their initiatives.
  • Suggestion: Re-think the one-on-one conversation approach for the next planning process and have this kind of review surfaced formally at the start of the planning process so teams are more open/expecting it.
  • Finding: It was difficult to convey a crisp incentive for why teams should care about participation or incorporate it into their plans.
  • Suggestions: Model the potential of participation through “bright light” projects and help individual teams identify their needs that could be met by participation. Additionally, work with managers find ways to tie a team’s success in participation to points, deliverables, or other rewards.

We believe that these planning processes are an excellent opportunity to strengthen participation at Mozilla. Therefore in 6 months we’ll be reconvening the Participation Champions, and based on our experience this round, we’ll spend some time thinking about how we can help move participation forward in the next round of planning! If you’re interested in joining please let me know at lucy@mozilla.com.

Firefox OS Participation in 2015


Though a great deal was achieved and accomplished through the Participation Team’s collaboration with Firefox OS, a major realization was that participation can only be as successful as a team’s readiness to incorporate participation into their workflow.

Problem Statement

Firefox OS was not as open a project as many others at Mozilla, and in terms of engineering was not structured well enough to scale participation. Firefox OS was identified as an area where Participation could make a major impact and a small group from the Participation Team was directed to work closely with them to achieve their goals. After the Firefox OS focus shift in 2015 from being partner driven development to user and developer driven, participation was identified as key to success.

The Approach

The Participation Team did an audit of the current state of participation. We interviewed cross-functional team members and did research into current contributions. Without any reliable data, our best guess was that there were less than 200 contributors, with technical contributions being much less than that. Launch teams around the world had contributed in non-technical capacities since 2013, and a new community was growing in Africa around the launch of the Klif device.

Based on a number of contribution areas (coding, ports, foxfooding, …), we created a matrix where we applied different weighted criteria. Criteria such as impact on organizational goals, for example, were given a greater weighting. Our intent was to create a “participation sweet spot” where we could narrow in on the areas of participation that could provide the most value to volunteers and the organization.

Participation Criteria

Participation Criteria

The result was to focus on five areas for technical contributions to Firefox OS:

  • Foxfooding
  • Porting
  • Gaia Development
  • Add-ons
  • B2GDroid

In parallel, we built out the Firefox OS Participation team, a cross-functional team from engineering, project management, marketing, research and more areas. We had a cadence of weekly meetings, and communicated also on IRC and on an email list. A crucial meeting was a planning meeting in Paris in September, 2015, where we finalized details of the plan to start executing on.

Team Meeting

Team Meeting

The Firefox OS Participation Hub

As planning progressed, it became clear that a focal point for all activities would be the Firefox OS Participation Hub, a website for technical contributors to gather. The purpose was two-fold:

  1. To showcase and track technical contributions to Firefox OS. We would list ways to get involved, in multiple areas, but focusing on the “sweet spot” areas we had identified. The idea was not to duplicate existing content, but to gather it all in one place.
  2. To facilitate foxfooding, a place where users could go to get builds for their device and register their device. The more people using and testing Firefox OS, the better the product could become.
Firefox OS Participation Hub

Firefox OS Participation Hub

The Hub came to life in early November.


There were a number of challenges that we faced along the way.

  • Participation requires a large cultural shift, and cannot happen overnight. Mozilla is an open and open source organization, but because of market pressures and other factors Firefox OS was not a participatory project.
  • One learning was that we should have embedded the program deeper in the Firefox OS organization earlier, doing more awareness building. This would have mitigated an issue where beyond the core Firefox OS Participation team, it was hard getting the attention of other Firefox OS team members.
  • Timing is always hard to get right, because there will always be individual and team priorities and deliverables not directly related that will take precedence. During the program rollout, we were made acutely aware of this coming up the release of Firefox OS 2.5.

For participation to really take hold and succeed, broader organizational and structural changes are needed. Making participation part of deliverables will go some way to achieving this.


Despite the challenges mentioned above, the Firefox OS Participation team managed to accomplish a great deal in less than six months:

  • we brought all key participation stakeholders on the Firefox OS team together and drafted a unified vision and strategy for participation
  • we launched the Firefox OS Participation Hub, the first of its kind to learn about contribution opportunities and download latest Firefox OS builds
  • we formed a “Porting Working Group” focused on porting Firefox OS to key devices identified, and enabling volunteers to port to more devices
  • we distributed more than 500 foxfooding devices in more than 40 countries
  • the “Mika Project” explored a new to engage with, recognize and retain foxfooders through gamification – The “Save Mika!” challenge will be rolling out 2016Q1

Moving Forward

Indeed, participation will be a major focus for Connected Devices in 2016. Participation can and will have a big impact on helping teams solve problems, do work in areas they need help with and achieve new levels of success. To be sure, before a major participation initiative can be successful, the team needs to be set-up for success 4 major components:

  1. Managerial buy-in. “It’s important to have permission to have participation in your work”. Going one step further, it needs to be part of day-to-day deliverables.
  2. Are there tools open? Do you have a process for bug triaging and mentorship? Is there good and easily discoverable documentation?
  3. Do they have an onboarding system in place for new team members (staff and volunteers)?
  4. Measurement. How can we systematically and reliably measure contributions, over time, to detect trends to act upon to maintain a healthy project? Some measurements are in place, but we need more.

We put Participation on the map for Firefox OS and as announced at Mozlando, the Connected Devices team will be doubling down its efforts to design for participation and work in the open.

We are excited about the challenges and opportunities ahead of us, and we can’t wait to provide regular updates on our progress with everyone. So as we enter the new year, please make sure to follow us on Discourse, Twitter, and Facebook for latest news and updates.

2016, here we come!

Brian, on behalf of the Participation Team.

(Originally posted on Brian King’s blog)

Saying goodbye to Demo Studio

When the Demo Studio area of MDN launched in 2011, it was a great new place for developers to show off the then-cutting-edge technologies of HTML5 and CSS3. In the years since then, more than 1,100 demos have been uploaded, making it one of the largest demo sites focused on cross-browser web technology demos. Demo Studio also served as the basis for the long-running Dev Derby contest, which offered prizes for the best demos using a different technology each month.

In the last few years, quite a number of code-sharing sites have become very popular, as they are solely focused on code-sharing functionality, for example, Github Pages, CodePen, and JSFiddle.

Given the variety of alternative sites, and the technical and logistical costs of maintaining Demo Studio, we at MDN have made the decision to remove the Demo Studio after January 15, 2016. After that date, demos will no longer be available from MDN via Demo Studio.

We encourage demo authors to move your demo to an alternate site, such as your own website, if you have one, or one of the popular code-sharing sites. In case you no longer have a copy of your demo code, you will be able to download your demo code from Demo Studio until 23:59, Pacific Standard Time, on January 15, 2016. If you’re looking for a place to share your demo, check out our guide to Using Github pages.

After January 15, 2016, you will be able to request a copy of your demo code by submitting a bug in Bugzilla. Please be sure to include the name of your demo(s) and an email address at which you can receive the source code. Demos will be available via this process until April 8, 2016.

Key Dates

Demo Studio will be removed; deadline to download your code.
Deadline to request a copy of your demo code manually, if you didn’t download it.

You are welcome to link to the new location of your demo from your MDN profile page. No automatic redirects will be provided.

Thanks again to all the demo authors who have contributed to Demo Studio!

Leadership Summit Planning

With a successful Mozlando for the Participation Cohort still in our rear-view mirror, we are excited to begin the launch process for the Leadership Summit, happening next month in Singapore.


What is the Leadership Summit?


As part of the Participation Team’s Global Gatherings application process for this event,  we asked people to commit to developing and being accountable to recruit and organize contributors in order grow the size and impact of their community in 2016.  We ran also ran a second application process this month, to identify new and emerging leaders – bringing our invited total to 136.

Participation at Mozlando

The Leadership Summit will bring together this group for two days of sessions and experiences that will:

Help Participation Leaders will feel prepared (skills, mindsets, network) and understand their role as leaders/mobilizers who can unleash a wave of growth in our communities, in impact and in numbers.

Help Participation Leaders leave with action plans and commitments, specific to growing/evolving their communities and having impact on Connected Devices and a Global Campus Campaign.

Help everyone leave feeling that “we’re doing this together.” Everyone attending (volunteer and staff Mozillians) will feel like a community that is aligned with Mozilla’s overall direction, and who now trust one another and have each others back.

“You mentioned Connected Devices and a Global Campus Campaign?  Say more…”

Sure! In setting goals for 2016, we realized that focusing on one or two truly impactful initiatives, will bring us closer to unleashing the Participation Mozilla needs, while providing opportunity for individuals to connect their ideas, energy and skills in the way that feels valued and rewarding.

To that end, we are currently developing a list of sessions and experiences for the Leadership Summit that will set us up for success in 2016 as community leaders, and on each of our three focus areas:

  • Connected Devices
  • Campus Campaign
  • Regional / Local / Grassroots

We will say more about each as we get closer to the Summit, as well as including the opportunity to connect personal goals through 1:1 coaching for all attending.

“What about Reps and other functional areas?”

Fear not!  Sessions and experiences will include:

Alignment for Reps around changes in the program, what’s expected of them, and what they can expect from Council and staff in 2016

Opportunity for volunteers in specific functional areas to build relationships with staff in those areas


This event will complete the process of merging participants from three events into one activated cohort – this is our beginning, and I am excited, I hope you are too!


Feature Image by ‘Singapore’ CC by 2.0 David Russo

Firefox 43 new contributors

With the release of Firefox 43, we are pleased to welcome the 46 developers who contributed their first code change to Firefox in this release, 35 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, yes and, community

The "Foxy" mascot is held aloft by attendees of the Mozilla 2013 Summit in Brussels

Photo by Marcia Knous

I’ve noticed that the terms “participation” and “community” have become more or less interchangeable in the context of Mozilla. I’ve even had a conversation with a Mozilla executive who said “I thought they were the same.”

It seems that the term “community” has been somewhat deprecated within Mozilla because it is ambiguous, in that it can mean different things to different people, which can lead to miscommunication. For example, some people use “community” as a shorthand for “volunteers” while others very intentionally use it to mean all Mozillians, paid and non-paid.

I see “participation” and “community” as related but distinct concepts, both of which are essential to Mozilla. Let’s start with definitions (sorry, I’m a word nerd). The Participation Team’s wiki page says:

Participation is when people can freely contribute their energies, time and ideas to support Mozilla’s mission.

So far, so good.

Here’s my generic definition of “community”:

A community is a group of people who interact and develop a network of relationships around a common factor.

The “common factor” is the wild card that leads to a wide variety of types of communities. If the common factor is physical location, the community can be a traditional geographic community. Some other types of communities include:

So, what kind of community is Mozilla? I consider Mozilla to be a community of action united by the Mozilla mission, which is the shared goal. Members of the Mozilla community take action (that is, participate) in order to realize that mission. However, Mozilla is really a constellation of overlapping sub-communities based on geography, interest, or practice. The nature of the sub-community determines the type of action that its members typically do. For example, a localization community shares a particular language, such as French, and its members take action by localizing software, websites, or documentation. A community for a functional area, such as QA, has some characteristics of a community of practice, but members focus on the practice of their skills on behalf of Mozilla.

Other key concepts in my definition of “community” are interaction and relationships. People who share a common factor, but don’t interact about it or have relationships with one another as a result, are not, for the purposes of this discussion, a community. (I know this excludes another widespread use of the word. That’s why I gave my definition.)

So, to bring the concepts together:

Participation is the “what” of the Mozilla community; community is the “how” of Mozilla participation.

Or rather, community, in my opinion, should be the “how” of participation. If people simply participate, but don’t interact and build relationships with others (that is, become part of a community), they are unlikely to sustain interest in participating over a more than, say, a few months. Therefore, when creating opportunities for participation, one needs to build-in opportunities for interaction, in order for the set of participants to develop into a community. When participants have relationships with one another, they are more likely to keep coming back to participate, making the group sustainable, that is, retaining more people than it loses.

Participation and community don’t necessarily go hand in hand; ensuring that they do requires careful design of participation opportunities.

The canonical example of participation in open source software is contributing a code patch. A programmer finds something that needs fixing, gets a copy of the codebase, fixes the bug, submits a patch for review, and ideally has the patch accepted into the main codebase. At the very least, this programmer has to interact with a reviewer. Ideally, she interacts with other members of the project earlier and more extensively than just at review time, through mentorship and discussion of the bug. She might also subscribe and post to a relevant mailing list, and read and comment on other bugs. Through these interactions, repeated over time, she becomes part of the community for the open source project.

However, not all participation opportunities have interaction built-in. For example, Mozilla Developer Network (MDN) is a wiki of developer documentation. Because it uses a pure wiki model, no review is needed for a change to go live on the site. It’s quite possible for someone to create an account and make many edits to the site without ever interacting with another human being. Such contributors are participating, but are not engaged with the MDN community. As community manager for MDN, one of my challenges is to draw contributors like that into communication channels such as mailing lists or IRC, and encourage them to interact with other members of the MDN community.

As your Mozilla team sets goals for 2016, with an eye towards inviting participation, I encourage you to also look for ways to invite and encourage interaction among participants, especially if open participation is new for your team. This could be as simple as creating a category on the Mozilla Community Discourse site, and encouraging participants to post there via welcome emails. Of course, make sure that existing team members initiate and respond to discussions there as well; they are part of the community, too. Communities don’t happen overnight, and they require (repeated, sustained) help in order to grow. The payoff is in sustained participation, as well as in the intangible benefits of relationships with fantastic Mozilla contributors.

Firefox 42 new contributors

With the release of Firefox 42, we are pleased to welcome the 41 developers who contributed their first code change to Firefox in this release, 26 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: Volunteer vrs Contributor


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 Mozilla.org 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