Firefox And The Academy



It’s September, so a lot of students are joining us in various Mozilla forums, hoping to make a contribution to an open source project. This is always a challenging time of year for Mozilla, and I’d like to say a few things about it. If you’re a student hoping to get involved or – even better – an educator who would like to involve their classes in open source projects or contribute specifically to Mozilla, I hope this will give you a sense of some of the challenges and pitfalls you may be facing and how we can work together to overcome them.

If you’re a veteran of Usenet from the days when Trumpet Winsock was a thing and dinosaurs roamed the earth, you recognize the particular flavor of Mozilla’s comms channels at this time of year. People who want to make a difference in the world want be a part of Mozilla and we’re always excited to hear from them, but September is a challenging time; we get a lot of requests for “student projects” and “easy bugs” that can be difficult to address, and the dropout rate from new participants grabbing “easy” [good first bug]s at this time of year is frustratingly high.

Part of these challenges are structural, of course, and some of those structures are out of our control – courses that are designed around software and development as a discrete, compartmentalizable thing, rather than a messy, rapidly evolving and organic process aren’t really compatible with the day to day process of shipping software. Likewise the benchmarks that make up a traditional academic evaluation process don’t really make sense in our context, so more often than not the goals and schedules of students and educators aren’t well-aligned with ours.

We’re grateful for any effort put in, large or small, to making Firefox better and supporting a free and open Web. Having said that: there are a few things that make working with Firefox in an academic context challenging and you should be aware of them.

The biggest one is that we can’t promise to accept a patch within a certain time frame. This can become a problem for both students and professors when getting the patch accepted into the main product is part of the criteria for a good grade in the course.

This has happened in the past: a student has done great work on a harder-than-expected bug, but it didn’t make it through our process – including testing, feedback, revision and more testing – by the time grades were assigned. Despite their effort, the student was undeservedly graded poorly.

This is bad for everyone when it happens – the student and professor both get discouraged, the value of their work (and of the course) gets harder to see, and if the student doesn’t stick with the patch long enough to carry it over the line, despite all that, Firefox doesn’t benefit and Mozilla’s engineers feel like they’ve wasted their time.

If you’re involved in shaping your curriculum, a better approach is to combine fixing the bug or delivering the project with a set of reports or presentations about the process. This presentation – maybe even a blog post, because working in the open is important – can be a discussion of what the student is working on and why it’s important, how the work progressed and what the process of getting a patch in looks like, as well as the challenges they’ve faced and what they’ve learned from it.

Making three or four “this is my experience and what I’ve learned so far” reports over the term a more important part of the grading process than the code itself helps enormously, both in terms of keeping everyone involved motivated and in reflecting the open, community-oriented values of the project. There are other options for instructors who are familiar with our processes – breaking up the grade up so that submitting a patch that builds, responding to the first review and so on all count, even if the patch isn’t ultimately accepted, is one possibility.

The second major challenge is finding bugs that are a good fit for their contributors. We’re getting better at that – good first bugs usually tell you what language they rely on ( [lang=c++] in the Bugzilla whiteboard flags, for example) and often have a pretty good outline of what a successful patch would look like and a mentor associated with them. And while we can’t promise to privilege students ahead of any other contributors, we certainly try to hold up our end of the bargain and answer new contributors’ questions promptly.

One thing that takes the edge off there is that class of bug – “good first bugs”, you can search for [good first bug] in the Bugzilla whiteboard – that are a nice, well-defined way to get involved. The idea behind “good first bugs” is that the major challenge of the bug isn’t the code itself, but learning how to get your development environment spun up, participating in development on IRC and Bugzilla, learning how to navigate our patch review and submission process.

It typically takes a few tries for most new contributors to get their patch through. Reviews for code format and quality, suitable tests, that sort of thing can all take an extra week or two to resolve, especially if you’re working on them around other classes. But most of our good first bugs can be resolved within a few weeks, well within a term.

You’ll have to judge for yourself if this is a good fit for your schedule, your students or your institutional goals. On the one hand, though GFBs are generally well-contained, Firefox uses every feature JS and C++ have to offer, so a certain amount of familiarity and comfort with the language is important. On the other, we’ve got a huge variety of Good First Bugs here, ranging from “correct this documentation” to “fix part of a JIT compiler”, so it’s likely that if you want to contribute, we can find a home for your efforts that will make millions of people’s lives just a little bit better.

More generally, if you’re interested in getting people involved with Mozilla in September, get in touch with us in June. Knowing in advance that people will be looking for new bugs or projects gives us time to talk to our team leads and project managers, to let us all find a place to put our efforts that will be helpful and valuable to everyone.

Which is all to say that small first-time bugs are often as inglorious as they are important; while they don’t seem like much, the small patches and first bugs of today come from the Web’s next generation of leaders.

Thank you,

– Mike Hoye –

Mozilla CBT Build Principles

Sean Bolton


Making implicit information explicit allows us to grow. We are able to recognize and add to something that works well, while focusing less on what doesn’t work well. Being explicit allows us to talk about something we do and/or experience – it allows this information to be shared and understood by others. When we focus on value and impact, we must be explicit in order to understand what is happening.

During my work on the Community Building Team (CBT) at Mozilla, I have been exposed to several themes of how the team works when success happens.  Intrinsically, these are the agreed upon ways by which we do our work. Extrinsically, these are the principles by which we do our work.

I cannot claim to be the single voice for these principles on our team – that would be not Mozilla-like. However, these are things I have been exposed to by working with and reading about the work of all members of the team.

  1. Build Understanding – Demonstrate competence. Seek first to understand. Every engagement is different. We care about people and doing the right thing for them. In order to best help them, we are curious.
  2. Build Connections – Be a catalyst for connection. Our team has a broad reach in the organizations. Sometimes the best way we can build is by connecting what is already there.
  3. Build Clarity – This is important when bringing more people into a project. We seek to navigate through the confusion to create clarity for us, our partners and the community.
  4. Build Trust – This is about having someone’s back. It’s important that the people we work with know that we are in this with them, together.
  5. Build Pilots – Our work is not a one size fits all. We care about the best solution so we test our assumptions to see what works and build from there.
  6. Build Win-Win – Focus on mutual benefit. We engage in win-win partnerships because our success is dependent on others. More people can only sustainably come into a project when it’s mutually beneficial. We want to make our partners look good.

Having these principles allows others people and teams to understand how the CBT works and what things are a valued when doing that work. It allows allow members of the team to have a toolkit to reference when entering into a new engagement and builds a level of consistency about interaction – creating clear expectations for others. All this leads to the sustainable success of the CBT.

I’ve places these into a nice PDF format below.

CBT principles

[Post also appeared on Sean Bolton’s blog.]


Grow Mozilla discussion this Thursday



If you’re interested in helping new people get involved with Mozilla, join us Thursday for an open community building forum.

Exploring Contributor Motivation

Sean Bolton

Why does understanding motivation for open source matter? This allows community builders to design more fulfilling experiences for contributors. It allows a contributor to be recognized in way he or she prefers. It allows community builders to advocate for projects that would be exciting to contributors.

The challenge of studying motivation (and thus recognition) is that our internal biases are strong. I can easily assume that the things I am motivated by are what others are motivated by and the ways I want to be recognized are the ways others want to be recognized. These ideas are deeply engrained – it is our internal motivation mechanism after all.

To find some objectivity in this area, I took from academic writing and did my own user research. The results are were synthesized from Organizing for Open Innovation by Wallin (2010) and countless contributor interviews and interactions I’ve had during my exposure to Mozilla. Some of these interviews were done during Summit 2013 and my Europe trip in early 2014.

Six main areas arose (in no particular order):

  • Intrinsic – This is an internal motivator focused on personal growth and self-actualization. Here people contribute because it is fun for its own sake and because they grow personally from it.
  • Extrinsic – This is an external motivator focused on material recognition such as a badge that a person can point to as a representation  and/or certification of their contribution.
  • Community – This motivator is based on our human need to feel part of a larger group that shares our view of the world – having a sense of belonging. (See Why Do People Join and Stay Part Of a Community for a deeper exploration here.)
  • Preemptive Generosity – This motivator is about giving something before it is asked for. It could be anything and it’s tied to our feelings of reciprocity. In a broad perspective, open source itself often follows this rule by releasing code before others know to ask for it.
  • Social Value – Motivation here is about feeling as if your contributions create a better world. There needs to be a clear and strong sense of impact. As Jimmy Wales once put it, “Usually, when people have an eight-hour binge of editing Wikipedia they think, well, I made the world a little bit better place than it was when I started.”
  • Helpfulness – This motivator is based purely on the desire to help others and give back. This is less about changing the world per se and more about having an impact in a person’s life. Similar but different.

When we can be explicit around these motivators, we can design contributor experiences that support them. That creates a more fulfilling experience for contributors and allows a project to grow while remaining meaningful.

Below is a PDF I put together to explore these motivators as they relate to Mozilla (it’s certainly incomplete). However, these should be relevant in all community driven projects and be non-unique to Mozilla.

contributor motivation

[Post also appeared on Sean Bolton’s blog.]

July 1st about:Mozilla Issue: Protect Net Neutrality, Safe Browsing for Domestic Violence Survivors, and more…


In this issue, you’ll find out how to raise your voice in support of net neutrality, read about exciting new contribution opportunities, and learn about a new way to map your career path.

Thanks for advocating for the free Web!

— The about:Mozilla Team Continue reading …

Nourish your community, nourish yourself.



Food is vitally important to nourish the body you live in.    Recognition is how we help feed our communities and nourish them as they make us strong.  Recognition, like food, is for everyone to partake in, and to share.

Used with Creative Commons Liscense

The tools, processes, and systems we use to identify people making contributions in our project vary widely.  It’s a situation created by valuing freedom of systems over efficiency of systems, and that isn’t something that Mozillians are willing to give up.  It makes it very hard to know who to give access and recognition to.   The Community Building team is working long term on this problem.  I’m here to ask you to nourish your community members, on an ongoing basis, by using vouching as a quick and easy way to give meaningful recognition.

The Community Tools team  implemented as a first step in allowing people to self identify as supporters or contributors to the Mozilla project.   The vouching system is one of the major ways we identify people who make actual contributions to the project. Read more about that here.

Being a vouched Mozillian means something.  It means you can be invited to large events like our Summit .  It means you can get access to internal calls .  It means you are visible to the project, as a Mozillian helping us move forward. It means we trust you.  Let’s make our words reflect that trust.

Since the vouching change was implemented we’ve seen some vouches like:

“ Karl has been around a long time.”

“Cindy makes things.”   

We can do better than that.  That is like skipping breakfast.  You get through it, but nothing nourishing happens.

For example, compare the vouches above, to this:

“Lindsey worked nights and weekends to help the Release Engineering team finish the release on time – it went out on time with much higher quality thanks to her extra effort!”  

Ask yourself:

  • Which one will make Lindsey feel valued?
  • Which one demonstrates the higher level of trust and access that being a vouched Mozillian gives her?

If you want to know more: go to the Vouching page on the wiki to see some additional examples.

We should all see vouching as a form of recognition.  Use it to tell people what they did was meaningful.  Help them understand that the additional access and trust we are giving them comes from the impact of their contribution.  Encourage them to keep contributing by saying thank you.

If that isn’t enough for you, do it because it helps us build the OSS community we need… a community where contribution is valued, regularly, in public.

So here is the request:

1) Create a Mozillians account if you don’t have one.  Talk to three people you know and trust in your regional community– ask them to vouch for your work.  You need to be vouched three times before you can vouch for others.

2) If you have an account and three vouches,  go vouch for others.  Yes, you, even you.  This is a change that our unpaid contributors should drive.  You know your regions, your groups, and your people best.  Take the leadership to recognize them for the impact they are making in their areas.  Take the time to make that mean something in our context.

3) Come back here, and share your story in the comments.

  • How did it feel to vouch?
  • How did it feel to receive a vouch that shared your impact, thanked you, or celebrated your contributions?

And always, keep being awesome!

Mozilla Voices has a new name!

Anthony Duignan-Cabrera

Hey gang, Anthony Duignan-Cabrera here, Editor in Chief of what was originally known as Mozilla Voices.

It was felt that the initiative needed a new name, one that made it clear to the audience that this online news and content platform wasn’t ABOUT Mozilla, but about our mission and support of open systems and a free and healthy Internet.

We opened it up to the community and we received dozens of great ideas, some generating wonderful conversations.

But there was one that just jumped out and caused us to pause and take note: The Open Standard

It completely captured the spirit of what we want to accomplish. Not just as a play on words, but one steeped in both the great journalism traditions and Mozilla’s overall mission.

The name was suggested by Justin Crawford, Product Manager for Developer Relations, and when I asked what inspired him, he sent me the most wonderful explanation:

“I love old newspaper names, the ones that use bold words to try and explain what a newspaper is about. It’s a “Monitor” or a “Camera” or it is the “Times” or an “Inquirer” or it is the “Globe”. Those are aspirational names: They say, “A newspaper is not just school board minutes, it’s not about ads. A newspaper is a camera on the times, monitoring the globe, inquiring after facts.”

My dad (Rocky Mountain News circa 1968-1981) has a belt with the word “Newsman” swooping across it like the word “Superman” in old comic books. Maybe the news business isn’t what it was in the 20th century, but at its best, the news did and does live up to its bold self-image. It holds us all to higher standards than our natures might otherwise cleave to. This is what I also admired about Mozilla when I decided to join: We make standards, and we make products that embody standards, and we do it in the open. We do what we do for the sake of standards.

“The Open Standard” is a cute play on words (“Standard” is an old newspaper name, and “open standards” are … well, you know), and that’s what initially brought it to mind. But this name is more than cute. The Open Standard will be a beacon, a tribune. It will rally and inform. In its finest hour it will live up to its name.”

I couldn’t have said it better. Thank you, Justin.


Grow Mozilla discussion this Thursday


If you’re interested in helping new people get involved with Mozilla, join us Thursday for an open community building forum.

Yammer Inclusion Reserach Findings



[On behalf of Tre Kirkman]

A few weeks ago in my blog I announced the Yammer Inclusion research initiative as part of the Diversity & Inclusion strategy. To begin the research I created a public etherpad to gather feedback from the community around uses and problems with Yammer. Today I’d like to share out some key findings and provide an update on next steps.

On the Yammer Inclusion etherpad, feedback identified Yammer as a place to ask questions when there is no readily apparent alternative. In addition, it seems to be a place for community building, especially for remote staff. Inactive users complained that Yammer is frustrating, time consuming, and overly negative, offering no compelling reason to use over other Mozilla communication channels. These issues were both technical (frustrating interface, etc.) and procedural (discussions too ideological).

Responders preferred the staff Yammer for posts containing sensitive or confidential information, although some felt the split leads to a situation where the community exchange is neglected and unused. Overall, there was a common theme that Yammer primarily functions as an open forum to share ideas, engage a wider community, and locate an unknown point of contact better than other channels of communication.

In the coming weeks I will research the recurring issues raised from the initial feedback to find potential solutions. For more information on the initiative, visit the wiki page Communication Research wiki. Please email me at tkirkman at mozilla dot com if you have feedback or ideas to share.

Firefox 32 New Contributors

Josh Matthews

With the upcoming release of Firefox 32, we are pleased to welcome the 68 developers who contributed their first code change to Firefox in this release, 53 of whom were brand new volunteers! Special thanks to Sezen Günes for compiling these statistics for this release. Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions: