zarro boogs found

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