Those marked as “yes” for active in Fx3 are going to be the indivuals in the credits for Firefox 3.  Please take a look and mail me with suggested changes ASAP.  Please don’t comment in the bug, I don’t want anyone put in an awkward position…

As a reminder, the criteria is anyone who made a substantial contribution to shipping Firefox 3, from design and engineering, to critical support people, and marketing/PR.  There isn’t a hard line, or a truly objective set of criteria, everything comes down to my discretion as the product owner.

(No, this isn’t related to DeHydra at all, I make no pretensions to being smart enough to work in that world.)

Shipping software is hard.  Shipping any web browser is probably harder than most software.  Shipping Firefox might be harder still, built on top of the multi-faceted Gecko platform (is it a web rendering engine? is it an app platform for building thick clients? it’s both, and more!)

A Firefox release always results in a new Gecko version, and that make things much harder, because while we are the primary consumer of Gecko, there is a large and diverse ecosystem of software that relies on Gecko aside from Firefox and even web browsing in general.  We’ve spent considerable amounts of effort over the years to build a great app platform that does more than just browse the Web, and beyond obvious Mozilla-built apps like Thunderbird, lots of other apps are out there.  And those are just the ones we know about, but there’s lots of anecdotal evidence that there’s a long tail of small apps floating around.

Because of all of this, Gecko enters into the class of software Fred Brooks called a “system software product” in the Mythical Man-Month.  It is not sufficient that it perform well in a single task or in a single place, it must perform many tasks, in many unexpected ways, in many places, and must do so reliably.  This makes it the hardest class of software to develop (Brooks estimated the cost and complexity of a system software product as nine times that of a purpose-built piece of software).  It’s tempting to cut corners here, but the fallout is often painful and/or catastrophic.

The flipside of this, of course, is that there is considerable pressure to continue to crank out releases, to get better platform capabilities to both web and application developers, and to support continued releases of Firefox.  As a result, we are often placed in a difficult middle ground between shipping Firefox sooner and building/fixing a better app platform for others.  Every tradeoff we make in those cases tends to be unique and needs to be  evaluated on its own merits.  Sometimes it’s a part of the platform that very few apps use or need, and we can fix it in a point release (1.9.0.x), or even a minor platform release (i.e. a theoretical Gecko 1.9.1) depending on when the fix is needed, since many non-browser apps tend to lag behind Gecko releases and build on stable versions.  Other times, we need to not call Gecko done until the platform bustage is resolved, even if it doesn’t affect Firefox, because it will cause severe and ongoing problems for other Gecko consumers.  There will never be a canonical “a Gecko release can/cannot regress other consumers” answer, as a result, but drivers will continue to drive as hard as we can to make Gecko a success story for platform consumers. Ultimately the buck stops at drivers’ door, because we own blocking and prioritization, and it is incumbent upon us to make the hard calls.

It isn’t easy, or fun, to try to ship a pair of symbiotic releases with overlapping priorities, but it’s a critical part of our DNA as an organization, and I’m glad that we continue to make the effort to preserve the ecosystem.

Next time: The Joy of Herding Cats.

Alex seems to have stirred up some debate regarding visual refresh on Linux.  I wanted to talk a little about why its not as big of a priority right now, and longer-term thinking I’ve been doing about Linux.

First off, I think there’s a lot of “Mozilla doesn’t invest anything in Linux” comments which are pretty untrue, both currently and historically.  We’ve actually had more people in the project working on integration with Linux since I’ve been around than on Mac or Windows.  We’ve had really good native appearance  and drawing hooks for GTK2 (Qt doesn’t get much love, but we’ve asked/begged/pleaded for interest, and no one really seems to have it, including the distros that invest time into Firefox).  Where we use native look and feel, we are pretty solidly compatible.  The current trunk  adds native theme form widgets and other goodies, in no small part thanks to the work of Michael Ventnor.  There’s a lot of other work that involved significant time spent on Linux, including pango and cairo integration, and we’ve fixed a lot of things that required just as much effort on Linux as on other platforms, so I don’t think its anywhere close to zero, despite some people’s assertions to the contrary.

Second, we’re not going to share much between platforms other than icons between Linux and Windows.  We use -moz-appearance for most things, and that works really well, as I’ve noted.  There’s some comments suggesting that we’ll look like Vista on Linux, which is really not grounded in fact.  In the absence of separate work on a Linux iconset, we’ll likely share the Windows XP icons, since I think that color palette works better with Linux themes, but we’ll be able to do either/or between the two sets once we have them.

Third, designing a universal icon set specifically for all of the distros using GTK2 is a pretty hard challenge (I’d say nearly impossible), and I don’t think there’s any way we’ll really get it right, and there’s some painful discussions about who to target if we really try to target a specific reference distro.  A lot of the time it feels like the best we can do with the full icon set is broken clock correctness (actually right a small percentage of the time).  We could design a set of icons for one distro’s defaults, but that would look bad on other distros.  Ubuntu has a firefox-themes-ubuntu which adds three themes designed to integrate with their distinctive default look and feel.  We couldn’t use those themes though, and anything we ship is probably not going to look right on their end.

I’ve wanted to use stock icons as the base for the theme, but there’s definitely gaps where we don’t have obvious icons, and that’s something we never quite figured out when we were experimenting with the Fedora guys a couple of years back (that’s when we added the stock icons to the buttons/dialogs).  Its worth looking at again now that we’re raising the bar on Linux library reqs, but there’s still some scary issues about how to fill the gap where stock icons don’t exist for the function you want to expose, without the icon looking totally broken and wrong.

Finally, Stephen Garrity posted about creating a Tango -based theme for Firefox 3 on the newsgroups some months back.  There wasn’t a lot of initial interest/activity there, but if you’re interested in helping improve Firefox 3 on Linux, at least for some subset of distros, please  check out bug 381206.  We’re not saying we don’t want a better icon set on Linux as well, but no one has a clear vision of what the right thing to do is.  Hopefully some people can jump in and start making progress there.

Performance matters more than ever in the browser space, and even as the Web grows up and gets bigger we need to continue to push harder on getting smaller and faster.  New tools and frameworks continue to evolve and provide more fodder for the performance team to chew on, and we’re going to do our part even as we continue to push on innovation in the browser. As a result, the Firefox team is going to put a really big stake in the ground on performance, with the bulk of the focus on cleaning up our own house.

We’re starting with three straightforward goals:

• Cut app overhead on pageload by 50% against Firefox 2.  Measuring “pure” Gecko performance against total Firefox performance is a hard problem, but one well worth solving.  Pageload is the sum of a lot of parts, the more we can fix those parts, the better.
• Improve Txul (new window opening) performance by 20% against Firefox 2.
• Improve Ts (overall app startup time) performance by 10% against Firefox 2.

These goals feel right, and should be within our reach.  There’s a lot of hard work involved between now and these goals, but I believe we have the people and, thanks to the perf team (especially Robert Sayre and his awesome work with dtrace), the tools to start moving faster here.