On the road: Mozilla 1.4 alpha.

Mozilla 1.4 alpha is out in the usual locations.

What I find much more interesting, however, is the direction outlined in the revised Mozilla Development Roadmap. Once Mozilla stablizies on the 1.4 release, the move will be towards Phoenix’s model - a smaller, faster, better browser, with stand-alone snap-in modules.

From the roadmap:

1. Phoenix is simply smaller, faster, and better — especially better not because it has every conflicting feature wanted by each segment of the Mozilla community, but because it has a strong “add-on” extension mechanism. We recognize that different users need many different features; such demand is legitimate on its face. Attempting to “hardwire” all these features to the integrated application suite is not legitimate; it’s neither technically nor socially scaleable.

2. What’s good for the browser (Phoenix) is good for the mail application (Minotaur, leading to Thunderbird), too. Mozilla’s integrated mail has many fine features, but it suffers from too many integration points with the other apps, and it remains a complicated front end maintained by too few people, most of whom have different day jobs now.

3. The 1.0 branch is almost a year old. It’s time to move from 1.0 to 1.4 for mozilla.org-blessed stable development and product releases, to get all the stability, performance, and security fixes made on the trunk since 1.0 into the hands of distributors and users. Many distributors have plans to make this migration. This migration frees the trunk to make more aggressive changes during 1.5 and 1.6, but still with the incremental daily build discipline, and the quarterly alpha/beta/final milestone testing feedback loops.

4. Gecko stalwarts are leading an effort to fix those layout architecture bugs and design flaws that cannot be treated by patching symptoms. Those bugs stand in the way of major improvements in maintainability, footprint, performance, and extensibility. Just by reducing source code complexity, Gecko stands to become much easier to maintain, faster, and about as small in dynamic footprint, yet significantly smaller in code footprint.

5. The faux-egalitarian model of CVS access and pan-tree hacking that evolved from the earliest days of Mozilla is coming to an end. Many of the original hackers have moved on, leaving unowned and under-owned modules behind. The combination of over-reach, turnover, and legacy CVS access grants has led mozilla.org to institute code review requirements beyond those required by the relevant module owner (if there is an owner).