Mozilla Product Strategy Proposal (DRAFT)

This post sets out a proposed product and platform strategy developed over the last few weeks by Mozilla project staff and drivers that aims to enable innovative web experiences for consumers, accelerate the time-to-market for user-facing innovation, and improve the security and stability of our products.

To accomplish these goals we’re proposing a shift in product strategy that would call for:

1. Platform releases every 12 to 15 months and product releases every 6 to 9 months with product releases between platform releases limited to new features and enhancements with minimal back-end impact, e.g. API additions to the platform but no incompatible changes.
2. Adoption of a consumer focused support lifecycle where only the current plus the last major release at any given time would be supported with security and stability updates.  Note: We’ll work with downstream enterprise-oriented distributors and support vendors to provide a program to enable extended support for otherwise legacy releases.
3. Scheduling security and stability updates every 6 to 8 weeks to provide a vehicle to address security and stability issues with critical security vulnerabilities addressed “out of band” unencumbered by other patches.

The following diagram shows the implications of this proposed strategy from a branch and release perspective for both the product and platform:

Comments and thoughts are most welcome as we work to nail down our release plans and roadmaps.

Note that Brendan Eich and Mike Shaver have posted a draft of the platform roadmap for Gecko 1.9 at: http://www.mozilla.org/roadmap/gecko-1.9-roadmap.html

And we've also now begun the detailed product planning process required to produce a specification for the next major version of Firefox.  Details and discussions are being coordinated at:
http://wiki.mozilla.org/Firefox:2.0_Product_Planning

 

Comments

[tr]

One problem I see with this is that bug reporters sometimes will have to wait for 15 months after a fix for "their" bug has been checked into the trunk until they actually see it fixed in a released product.

[Peter van der Woude]

1.does this mean to 1.5->2.0 patches will require approval all the way ?
2.what are people that test supposed to concentrate on, 1.9 trunk or 1.8 branch.. Doing both may be a little too much (especially given the icompatibility between the 2) ?

[Peter Lairo]

Why is Firefox 2 based on the Firefox 1.5 branch and not the trunk?

It seems users will see new features much later than they could if Firefox 2 were based on the trunk.

OT: Is my e-mail address exposed here to spam harvesters? (it seems so in the preview)

[Peter Lairo]

Oh, and a big *thanks* for putting up the time line. It's great to be able to see so clearly where things are going. :-)

[Mossop]

Is the plan to land patches on both 1.8.1 branch and the trunk during the development of firefox 2.0 to avoid the painful merging back into the tree like after firefox 1.0?

[Daniel Cater]

So we won't have a release based on 1.9 until March 2007? Can you confirm that?

[David Naylor]

Does this mean that fixes related to Acid2 won't be out and about 'til early 2007? That would suck, and if so I hope Mozilla.org rethinks it's branch/trunk strategy.

[Peter Lairo]

Why are the Fx2 and Fx3 releases "only" 6 months apart?

If you move Fx3 back (seems likely), that would make the (prolonged) use of the non-trunk-based Fx2 even more unfortunate.

[_FrnchFrgg_]

Apart from my concerns about remaining so long away from the trunk, I personally find the numbering unfortunate.

How would you justify the jump to a new _major_ version, with the way it will just be a refresh of the branch ?

Once upon a time, I read that major version increments should be only used for a major rewrite of the product, and the upcoming gems in the next Gecko would then justify the bump (brand new graphic backend, new reflow code, new display lists, etc...).
Managing to get a Gecko 2.0 along with Firefox 2.0 would also be more friendly to my maniac disease with figures, but I may live without, enduring constant pain as when on a table spoons and knives aren't from the same set... Arghhhh ! ;)

[Daniel Cater]

Agreed. 1.0 to 1.5 sounds like it will be a bigger change than from 1.5 to 2.0, yet that gets a major version change? 1.5 wasn't called 2.0 because it's still using pretty much the same architecture right? So why 2.0 for seemingly UI only changes?

[Gc]

Hmm, there are 5 branches to the graph. Maybe MozCo is thinking in terms of the innovation adoption bell curve:

[0. Developers/Testers: (~0.001%)]
trunk branch, nightlies

1. Innovators (~2.5%):
recent branch betas

2. Early Adopters (~13.5%)
recent branch

3. Early majority (~34%)
previous full release branch

4. Late majority (~34%)
near end-of-life branch

5. Laggards (~16%)
past end-of-life


At least Paul Kim is thinking about adoption curves.
http://www.numenity.org/blog/2005/11/01/frameworks/

Under this thinking, the early majority won't get the FF 1.5 branch until all the new Gecko 1.8 changes and features are polished by the early adopters for a while. After that polishing phase, a bigger marketing campaign with 2.0 version number can target the early majority.

In other words, maybe the idea is to reserve the bigger version number splash for the bigger section of the market. Maybe 1.5 is the early adopter edition of 2.0; 2.0 is the early majority version of 1.5.

[Jed]

Ouch.

One of the more promissing thing from Gecko/Firefox 2.0 was cairo. Something that would atleast be on-par with what MS will have with Vista.

Seeing as now 2.0 is off the 1.5 trunk, this would suck as we would be even farther off, and come after vista.

All in all it's exciting, I just didn't think the trunk (1.9) was really all that far off. Hell, cairo in Windows and Linux is pretty usable!

[Jed]

Ouch.

One of the more promissing thing from Gecko/Firefox 2.0 was cairo. Something that would atleast be on-par with what MS will have with Vista.

Seeing as now 2.0 is off the 1.5 trunk, this would suck as we would be even farther off, and come after vista.

What really sucks about this is XULRunner is even that much further off. Now is the time to get an upper leg on Windows, not release a sub-par platform *after* vista.

All in all this is exciting, however I just didn't think the trunk (1.9) was really all that far off and am bumbed to see it like that. Hell, cairo in Windows and Linux is pretty usable!

[Jeff Schiller]

Just a suggestion: Can you please publish your roadmaps in SVG with a fallback to PNG? Let's start using that technology!

[Attila Nagy]

Maybe I'm too foul, but I'm missing a beloved product of mine from this roadmap: Mozilla Browser . As of the release of Firefox 1.0 I had to notice, that Firefox and Mozilla Browser begun to get more and more further from eachother, and yet I couldn't find any policy about this.
Will you keep releasing new versions of MB also? Will it remain public, or do you plan to slowly degrade it back to a pilot where you could experiment with the new technologies?
I'd like to hear about that strategy.

[Jonas]

Attila Nagy, there has never been a product called Mozilla Browser. What do you mean?

[Robert Accettura]

I'm not liking that Firefox 2.0 comes off the 1.5 branch. IMHO it should be off trunk like 1.5 did. Especially since it's 2 a major verison jump. The interval between Firefox picking up trunk releases is to long. Especially when you consider that Mozilla releases typically ship later than originally planned.

I'd rather ship a 1.6, that contains some UI based improvements (and essential Gecko fixes), and call 3.0 2.0. I think the product marketing is more accurate that way.

2.0 implies major changes. But on the branch, how much change will there really be? Unless the branch is redefined, there's no way the changes that are accepted will qualify as making it a 2.0.

[To atilla]

By Mozilla browser it seems that Attila was talking about either Mozilla suite, or Seamonkey. The answer to the question is that the official Mozilla Suite is only likely to get security fixes and will not get other new stuff. Seamonkey is an unofficial project and will not get the same level of development as Firefox, and for the most part will not include paid developers. The ship has left without you; due to the glory of open source you are likely to continue to get security fixes, but if you want features you'll have to change to firefox.

[toaster83]

There are two aspects to versioning: changes made to the software (technical improvement) and perceived changes made to the software (marketing). The technical improvement for a major version bump is probably not going to be there (unless there are changes to come in that respect as well). However, the marketing opportunity certainly is. It looks like Moz is looking to put out Fx2 around the same time as Vista/IE7. They don't want M-Dollar to launch a marketing blitz for IE7 without some sort of response. Instead of "Fx1.6: incremental update who cares" it will be "Fx2: Major update, don't be fooled by stupid IE7." In short, they are digging the trenches for a battle against IE7 in Q3/Q4 2006 right now.

Given the above, I think Moz is doing the right thing by putting out a 2.0 when they are and then holding off until 3.0. From a technical standpoint, they should have what they call 3.0 actually be 2.0, but when balancing multiple concerns, the technically correct option isn't necessary the overall correct option.