For quite some time I’ve been exploring ways to scale up ownership to meet the scope and pace of our front end work.  One of the key elements of Firefox’s success has been the concept of an “application czar” with overall authority for keeping the app coherent and development moving in a focused way.  The concept of the application czar has been successfully combined with the module owner role since 2002, and we don’t have a better model defined as of yet, so we’re not going to change that now.  However, changes do need to be made to continue to make progress, so I’m implementing a set of changes to how we do things that will push more responsibility to more people, which is great for our forward growth, even if it’s going to feel a little strange at first.

Overall, the intent is to give the sub-module owners more responsibility for driving their area forward in line with our overall goals.  This means identifying pain points (technical and user-facing) and building a plan to solve those problems will be the responsibility of the sub-module owners.  Obviously the technical and product leaders will continue to work with these individuals, but it will be the responsibility of sub-module owners to drive this work forward.  Dietrich Ayala’s ownership of Places over the last two years is a fantastic example of how this should work in practice.  In line with this change, I’ve named new owners for a number of sub-modules.

Another important change I intend to make is to the role of a module-wide peer, since the traditional role is somewhat unclear in a decentralized model.  The closest we have in Mozilla to the idea of cross-module oversight is Brendan, and he doesn’t have any official peers.  Given this, I contemplated doing away with the old concept of peers entirely, and treat the reviewer list as peers in the despot/policy sense.  However, I have concluded that it would be very beneficial to have peers to help with the technical and product oversight role, especially guiding and mentoring people who are learning how to scale up.   To this end, I’ve asked Vlad and Gavin to act as peers under this new model.  This is not just a technical role, but has responsibilities related to product direction and stewardship, which we’ll evolve over time as we get used to this model.

Beyond that, we’re going to add five new (and long overdue) reviewers to various areas (and add/merge some areas).  Ehsan Akhgari, Ryan Flint, Dao Gottwald, Jim Mathies, and Johnathan Nightingale will join the reviewers group with various areas under their care.  They’ve all been playing key roles over the last months and years, and it’s high time we start rewarding them in the traditional Mozilla manner: more work and more responsibility!  Please join me in welcoming everyone to their new roles.

I’ve already updated the official review docs to reflect these changes, so as of now, this is official.  Please let me know of any concerns via email or in the comments.

One of the things I’ve been doing for the last month or two has been working with my colleagues at Mozilla Labs to figure out how best to start incorporating what we learn from Labs experiments into our core products. The technology transfer problem is well known to the tech industry, but it is fairly new to Mozilla, and as our focus is not on profiting from our research, the solution we need will probably be somewhat different.  One key aspect to acknowledge is that most of the Firefox project history has been more direct and iterative, rather than purely exploratory and R&D-like, within the core project.  We have taken some baby steps in terms of prototyping a few features as extensions, and the extension community itself has provided a lot of inspiration and some features and code, but that’s generally been a bit of an outsider’s space.

With the formation of Mozilla Labs, we’ve been better able to try things that we couldn’t really explore as part of our normal ship process.  That’s been great to see, especially as we have explored new and compelling features and interaction models, but now we need to figure out the right way of bringing the best pieces of these projects to all of our users.  Learning how to integrate R&D with the rest of our development process is going to take time and effort, but the goal is to establish a repeatable and transparent process that we can continue to use as we grow Mozilla Labs and the various Mozilla products.

This of course doesn’t mean we’ll take something from every project, or even that every project has to result in a core feature to be successful.  The primary goal of Labs is to explore and innovate and try things.  Sometimes that will be successful, other times it won’t.  Sometimes we will learn things that inspire a different approach entirely, and that is an important success state.  But when we create something compelling, we need to be prepared to learn lessons and adopt the best pieces in ways that make sense.

As our first pass, we have decided to focus on incorporating some aspects of three projects in particular: Prism, Personas, and Ubiquity.  The key defining characteristic of these three projects is that we’ve spent enough time exploring those spaces that we feel confident in identifying and uplifting the most useful pieces.  Users should expect to see these new features in the next Firefox release after 3.1.

Some preliminary work has been done on identifying key elements of all three projects, and we will continue to refine these plans in order to get a good jump on things as Firefox 3.1 finishes.  You can find these first passes here:

Personas
Ubiquity
Prism

We absolutely crave feedback, so please feel free comment here, send mail or comment on the Talk pages on the wiki if you have questions or concerns.  We hope to get to a crisper and more tightly-scoped set of plans over the next month or so, and we’ll continue to point out when there are more changes that we’d like feedback on.

Via Rob Sayre:

The Pencil Project is pretty awesome, and has a ton of potential.  This took me two minutes to build.

Quite some time ago we announced that we would be fully supporting distro Firefox packages, in conjunction with the distributions and their maintainers.  This continues to be the case, even though we’re still shipping official builds of our own to make sure everyone on Linux can experience the goodness that is Firefox 3.  We’re going to be working on web site changes to help users connect back to their distro package where appropriate.

Much has been made of the issues related to fsync, and this is where the distro connection comes in especially handy.  We’ve already received a firm committment from Red Hat/Fedora, Ubuntu, and Novell/OpenSUSE to ship the mitigation patch from the bug, if we do not otherwise need to do an RC2 and thus have a chance to take it in Firefox 3 proper.  We’re going to continue to reach out to the rest of the distros shipping Firefox to roll in the patch.  This means we can ship sooner, while still ensuring the vast majority of Linux users get the patch.  I’d like to thank Alexander Sack, Chris Aillon, and Michael Wolf for being highly responsive to our requests.