Via Rob Sayre:

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

Five years ago, I had just left IBM, and was pretty unsure about what I really wanted to do next.  I didn’t know whether I wanted to switch my goals back to software development, or stay on the IT track I’d picked before the bubble blew.  Firebird 0.6 came out that day, and I found some bugs, so I started poking around Bugzilla.  Things sort of snowballed from there, as I got more involved with QA, and later fixing UI bugs.  I ended up hacking cookies with dwitte, and front end with Ben and Blake, and I found myself more and more involved and enmeshed with Mozilla.

Its pretty fantastic to look back at those five years, from the uncertainty of the Foundation startup, through the huge buzz around Firefox 1.0 and the launch, the growth and maturity of the organization through the challenges of shipping follow-on releases, all the way up until today, where we expect to ship the first release candidate for Firefox 3.  I can say honestly that its the best release we’ve ever done, and I’m excited about getting it to 170 million people as soon as possible.

What’s most interesting to me is that we’ve now grown enough that we’re no longer aiming for It Just Works.  We’ve done that already, so now we’re aiming for the holy grail of Does What I Mean.  Its a much higher bar, but that’s where we need to go next.  We need to do it on mobile, we need to do it on the desktop, and we need to figure out how help people do it everywhere.  And that is my new Five Year Plan.

I hope you’ll all come along for the ride.

(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.

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.

I think its fair to say that many people weren’t 100% happy with the visual refresh on Mac in Firefox 2.  We haven’t forgotten about this, so I took 15 minutes and hacked a few pieces of things into a bit of a PoC.  Results are below.

This is combining Uno (to achieve the unified look) and Kevin and Steven Horlander’s tabs from Pinstripe.  There’s a lot of great work in Pinstripe (notably the tabs, sidebars and findbar) that we’d like to pull into Firefox 3, but I haven’t been able to get a hold of Kevin to find out if he’s cool with this, and what the licensing is like, since the jar lacks any licensing info.

As beltzner noted in last week’s meeting, we’re looking for themers to drive this work, please contact him with recommendations or details if you’re interested and available.

Welcome to Dave Townsend and Jim Mathies, both of whom will be helping in the final big push to get Firefox 3 finished.

Dave, who many in the community will know as Mossop, has  written  a number of extensions and fixed a bunch of bugs (and commented in a lot more).  He’ll be working first on getting more work around Addons wrapped up for Firefox 3.

Jim joins us by way of Verisign (yes, he wrote the EV Cert extension).  He’s primarily a Windows hacker, and will be helping us get better integration on Vista and generally help out with Windows-specific issues as needed.

Please welcome both Dave and Jim!

Part of the behind-the-scenes stuff that people don’t see is the coordination that goes on as part of our trademark approval process.  Red Hat and Novell have been working closely with us for quite some time, but other distros have not been as involved.  I was very fortunate to work with Alexander Sack of Ubuntu and Martynas Venckus of OpenBSD to get their distros in the same loop.  The primary goals are to ensure that all versions of Firefox are of a very high quality and to reduce the overhead involved in shipping distro-specific packages.  There will always be distro-specific links and tweaks, but minimal code differences means that testing is less segmented and more globally useful (and Mozilla maintainers can put their time into core work instead of hacking around upstream issues!).

Here’s a quick rundown on progress in the last few months:

Ubuntu

Ubuntu has been shipping with official branding since Ubuntu 6.10, but it took a lot of painstaking work on Alexander’s part to untangle the monolithic Debian patch and turn it into an organized set of patches.  In the Firefox 3 timeline we hope to either upstream or render obsolete as many of these patches as possible.  The smaller the changeset is, the easier it is to manage, and the more our community testing becomes relevant.

I’m quite excited to be working closer with Ubuntu, we’ve made a lot of progress and will make more on the road to Firefox 3.

OpenBSD

OpenBSD’s patchset has been waiting for quite some time.  Martynas was able, through no small amount of patience, and some fortunate timing while I was at FOSDEM, to get everything wrapped up finally, and OpenBSD is now shipping officially branded and approved builds.  We’re working on getting most of the port code upstream, since they don’t do anything extra for their own hooks they could get to the point where they’re simply shipping stock builds, which would make everyone’s lives easier.

A huge thanks to both Martynas and Alexander for all of their hard work here, it should make things a lot better for everyone.

Additionally, I’ll be posting later today about some related discussions to raise the bar for runtime requirements for *nix, which should help us do better on Linux going forward.

From Saturday’s drive to Toronto:11:13 AM

11:14 AM

11:15 AM

At the recent Firefox Summit, a group of people led by Chris Aillon (Red Hat), Robert O’Callahan (Novell), and myself met to discuss Firefox on the Linux desktop. Historically, there has been a great deal of tension between mozilla.org and the Linux distros, notably over maintenance of branches, divergence between distros, and lack of sustained communication between the groups. All seemed in agreement that closer cooperation and dividing responsibilities appropriately would benefit everyone involved. A number of changes were proposed that have general consensus among the stakeholders.

It is hoped that the proposed changes will drive a stronger and more balanced partnership among Mozilla contributors, and enable the Linux community to work more closely with the Mozilla community. More importantly, we believe this will drive a bigger focus on creating a better Linux user experience for everyone.

Development

• In the Firefox 3 timeline, establish a strong group of maintainers to drive and own Linux-specific development. caillon and roc will likely act as owners here. This is not an exclusionary group, anyone wishing to help in this effort will be able to participate and contribute. This certainly includes other projects that are based on or share code with Firefox (Flock, Iceweasel, etc).
• This group will share responsibility for branch policies for Linux-specific code. In particular, they may choose to land Linux integration features on branches.
• The vast majority of downstream patches will be pushed upstream and into shared CVS, in order to minimize patch sets to distro-specific packaging/build requirements, with minor exceptions from time to time.

Distribution

• Most Firefox Linux users are using builds packaged by their Linux distribution. We will encourage this by having mozilla.com’s download page point to packages from various Linux distributions.
• The Mozilla Corporation will continue to provide nightly builds for testing and development, and will make available reference builds for each release in an unsupported form.
• By minimizing upstream vs. downstream differences, it should be much easier for Linux distributions to comply with Mozilla trademark requirements. The current situation involves a great deal of overhead per distribution due to the large and diverse patch sets. Therefore the Mozilla Corporation will be able to work with more Linux distributions around branding than we have been able to in the past.

Please direct feedback and discussion to the mozilla.dev.planning newsgroup, or dev-planning@lists.mozilla.org

Update: caillon has blogged about the changes from the Linux side

I talked about barriers to entry a couple of times already, and I think that as we start to plan for Firefox 3, we need to make sure that as we try to advance the web, it is critical that we continue to identify and eliminate barriers to entry for users who would otherwise use our products. We need to continue to improve the core features for our existing userbase, and to keep up with the web, but most of the thinking there isn’t solving the barriers question, since by and large we’re innovating in new directions.

Here’s a few that I know are problems already:

• Better integration with systemwide settingsIf a user switches to larger fonts and icons in Windows, we should match those increases in the app. We force users to specify and update proxy data, helper apps and passwords separately within the app, where we could use system settings and APIs instead (the last perhaps on Mac only, but for how long?). A lot of this integration can be done, and should be done.

• Site compatibilityWe’re doing pretty good, marketshare helps, but we need to be better. We need to push Reporter, and put real time into analysis of the top sites showing up there. Sometimes its our fault and we need to prioritize bugfixing, sometimes its Tech Evangelism (and we need to get back to doing that too).

• Firefox lacks feature X from Browser YIt could be a serious shortcoming, or it could be something that should be addressed with extensions. We should make sure we identify these deal-breaking features and ensure that the right solution is in place, and that there are docs in place to point users at the answers they seek.

These are a few, but there are more out there. Please comment here or post to d-a-f with your own!