Phoenix has a new name… Mozilla!

Just after the fifth birthday of the code release, draws a new roadmap that charts a bold course for the future. Partially a response to the failures and experience of the past development years, it is also a natural progression and recognition of projects already leading the way.

Key points:

  • All future apps will leverage the Gecko Runtime Environment (GRE).
  • The browser component will utilize the work on Phoenix.
  • Similarly, the standalone Minotaur/Thunderbird project will become the basis for the mail application.
  • The full everything-in-one-process Mozilla suite of apps will be replaced using a more modular approach.
  • Bless the 1.4 release as the new stable release and discourage the use of 1.0 for future work.
  • Fix architectural bugs in the Gecko layout engine to enhance performance, extensibility, and maintenance.
  • Give more power and responsibility to module owners and have fewer people with blanket check-in rights.
  • Relax super-review requirements for those people, such as the module owners, that demonstrate good judgment and ability.

It remains to be seen how this will play out, but I like the essence of the plan. The Phoenix browser is worlds better than Mozilla in some areas and even Mozilla 1.3 is fabulously better than 1.0. Having a more modular architecture should benefit not only Mozilla apps, but applications and products built by other organizations. Having better defined module ownership and the ability and desire to say no to poor quality code should also improve the project.

Still, I have concerns, primarily about user interface. The roadmap has this to say about UI:

It is almost always better to have a competent owner who rules decisively, than to have no owner and live in a state of indecision (N.B.: a committee of more than one or two is not an effective owner). This point is especially true for top-down application design and policy setting, particularly for user-interface design. For coherent UI within an application, there is no substitute for leadership by an “application czar”. For cross-application consistency where it is needed, we expect such czars to communicate, cooperate, and consolidate things such as common default keybindings.

That’s true, as far as it goes… where Mozilla, and open source projects in general have broken down is in actually having the application czar. (Or more to the point, in having good ones that understand user behavior and can design well—most open source projects effectively have an application czar that is the lead programmer.) Having UI involvement and management just at the module level isn’t enough. UI decisions frequently affect overall architecture, from the network on up to the browser chrome and everything in between. Add to the mix that for good or bad, the best designers are rarely top-notch coders. So how does the application czar get elected and respected in the community?

A related challenge is in determining target audience for the application. I’ve seen many end-user complaints that the mozilla developers just don’t work on the things that are most annoying and need to be fixed. Unsurprisingly to me, Phoenix is a better browser than Mozilla because it set out to be a browser for real people. Will the ficticious “Mozilla isn’t for users” mindset continue? Or will the Phoenix practice win? With many more companies deploying and shipping Mozilla (see RedHat and HP for examples) and with this roadmap it’s time to admit that Mozilla is for users.

But who is the user, specifically? I’ve often thought that using a Persona approach such as described by Alan Cooper and others could provide an answer for open source developers. It’d be worth a try. Until then, design for mpt’s mother.

Back to the big picture, the idea of providing an extension mechanism is quite appealing to geeks, but the average person wouldn’t even know to look for extensions. There’s also the shared-computer / internet café to contend with. How will the question of the default set of capabilities be answered? Whatever was in IE? Whatever the module owner likes?

Regardless of these concerns, I believe this is a step in the right direction. Even if done for reasons other than concern for the user, it will benefit them. I just hope can take the additional steps to create processes and products that will result in joyous and satisfied users.