Skip to main content
dietrich

Building Firefox in the Post-Browser Age

Ok, so maybe we aren't in the post-browser age yet. But we're getting there, and quickly. Most of the "apps" I use on my phone are useless without an always-on data connection, and they communicate with their respective motherships via HTTP. We're staring down a near-future with multiple Web-stack operating systems for both desktop and portable devices. We have server-side application platforms that look startlingly like pieces of a traditional Web client.

All of those places are the Web, so that's where Mozilla has got to be, when and if it's possible to do so. And between desktop Firefox, mobile Firefox, Chromeless, B2G, Pancake, Open Web Apps and the various Firefox features developed by the Labs and the Services groups, we've got a lot of application logic that needs to exist in various forms across those disparate environments.

Up until recently, even including most of the mobile efforts to date, we've had a pretty narrow idea of what constitutes Firefox: Mozilla's browser application with a front-end built in XUL, and rendering content using Gecko, stored entirely in a single source repository.

This narrow view is insufficient given the needs of internet users and the plans we have to serve those needs in the immediate future. This has been starkly illustrated by the recent move to a native UI for mobile Firefox, projects like Pancake, and the expansion of the development of Firefox features by groups outside of the core team.

A few months ago I dumped a couple of thoughts into a thread on the mozilla.dev.planning newsgroup about these things. More than anything, that thread showed me that the broad spectrum of activity in Mozilla today makes our narrow view of Firefox a huge barrier to future success. Some people didn't agree that there was a problem at all. Some people railed against Jetpack or Github, while admitting they'd never used either. Some people agreed that developing Firefox is slow and fragile, and pointed at the relative historical success of that approach. Disturbingly, I got a bunch of private emails thanking me for starting the conversation... what does that mean?! Overall though, there was a lot of agreement on this point: We need more people to be able to work on Firefox faster, and in a more heterogeneous environment.

There's a bunch of work towards that end going on right now, both in Firefox team itself and in Mozilla generally, around lowering the barriers to contribution. Specific to Firefox core development though, one experiment in alternate approaches is the attempt to ship the BrowserID feature as a Jetpack-based add-on that is developed on Github and bundled with Firefox. There are a lot of moving parts, but the exercise is helping us figure out the up- and downsides to building features as add-ons, as well as providing performance data about the Add-on SDK. Maybe it'll work, maybe we'll have to re-route and patch it against the core. Maybe we'll land somewhere in-between.

Regardless of that experiment's outcome, I think we need to be experimenting hard with how we develop Firefox, and asking questions about the longer-term development landscape:

But only some of this is about the technology - other parts are social. As I said above, some people do not agree that developing Firefox is slow and fraught with peril. Is that plain ol' resistance to change, or just the lack of a clear alternative? And maybe we code reviewers should be more forward-looking, demanding larger refactorings instead of non-invasive surgeries. But that's challenging when you're constrained for time, or the regression cost of refactoring is so high that you become risk averse.

I'd love to hear your thoughts on the future of Firefox application development - especially the core Firefox team, and the people working on Firefox features in other groups or via add-ons. Myk Melez has been corralling a group to talk about feature development with the Add-on SDK specifically, but it quickly spreads into these broader issues. He's starting a list for it, but until then there are regular meetings, details available in his dev.planning post.