September Never Changes

This is work-related; I’ll get back to the usual nonsense soon enough.

September Is Coming

It happens every year, a wave of students joining us in various fora 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 make a contribution to Mozilla part of your curriculum, I hope this will be useful to you, and give you a sense of how we can best work together.

If you’re a veteran of Usenet from the ‘Net of old (long may it slumber, and someday rise again) when the alt.* hierarchies were still controversial and dinosaurs roamed the earth, you’ll recognize the particular flavor of Mozilla’s comms channels around mid-September.

We’re kind of a big deal in the open source community, an awful lot of people use our stuff and contributors are a big part of how we got here. People who want to make a difference want to work with us – and we’re always excited to hear from them! – but even so September is a challenge. We get a lot of requests for “student projects” (usually from professors) and “easy bugs” (usually from their students) and that can be difficult to address. We have great starter bugs – search Bugzilla for “good first bug” sometime – but the dropout and abandonment rate from new participants grabbing those bugs at this time of year is frustratingly high.

Root Causes

Part of these challenges are structural, of course, and some of those structures – those most relevant to the students, predictably – are out of our control. Courses that are designed around software and development as an atomic, compartmentalizable thing aren’t really compatible with the messy, organic and rapidly-evolving process we find out here in the wild. 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, schedules and incentives native to the academy aren’t well-aligned with ours.

This is not to say that we’re not glad to have you – we’re grateful any effort put in, large or small, to making Firefox better and supporting a free and open Web. Only this: there are a couple of things that make working with Firefox in an academic context challenging and you should be aware of them.

Impedance Mismatches

The biggest one is that we can’t – and will not – guarantee that we’ll accept a patch within a certain time frame. This can turn into 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, and far too often: a student has done great work on a harder-than-expected bug that didn’t make it through our process – testing, feedback, revision and more testing – by the time grades were assigned. Despite their effort, despite hard, high-quality work that didn’t quite make it to production by the end of the term, the student is graded poorly for no more reason than the classroom’s definition of success and Mozilla’s don’t quite line up.

This is bad for everyone involved.

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.

Again, nobody involved in this failure has done anything but good work in good faith; this is a consequence of two organizations with mismatched schedules and incentives. These are structural problems; to some extent they’ve been exacerbated by Mozilla’s move to a rapid release model, but they’ve always existed.

A Problem We Can Solve

There are a few ways out from under this, but everyone involved needs to know this problem exists before the first week of class.

If you’re involved in shaping your curriculum or deciding how students are graded, please consider downplaying “fixing the bug” in favor of a set of reports or presentations about the process. A presentation – maybe a blog post, because working in the open is important! – that says, “This is what I was working on and why it’s important. This is how the work progressed, this is what the process of getting a patch in looks like. These are the difficulties I’ve faced, this is what I’ve learned, and this is where we are now.”

Making two to three “this is my experience and what I’ve learned so far” reports to share over the course of 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.

The second major challenge – one of the biggest problems in open source – is finding bugs that are a good fit for their prospective owners. We’re getting better at that – good first bugs usually tell you what language they rely on ( [lang=c++] whiteboard flags, for example),  have a pretty good outline of what a successful patch looks 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 community, our patch review process and our coding standards.

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. Most of our good first bugs can be resolved within a few weeks, well within a term, but

You’ll have to judge for yourself if this is a good fit for your schedule, or for your students, course, or institutional goals. On the one hand, though [GFB]s 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; this is On the other, we’ve got a huge variety of Good First Bugs here, ranging from “correct this documentation” to “fix this coner of the JIT compiler”, so it’s likely that if you want to contribute, we can find a home for your effort that will make millions of people’s lives a tiny bit better.

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

Which is all to say, good luck, and thank you. This work is often as inglorious as it is 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.

I’d be happy to talk to you more about this, and help how I can.