Reporting and Nominating Bugs for Mozilla Firefox 1.0

Thursday April 29th, 2004

Ben Goodger writes: "We're beginning the drive to Firefox 1.0 and we need to make sure that every bug people think is important is filed in Bugzilla and has a blocking0.9? or blocking1.0? request flag set. This will allow the FDT (heh) to develop an action plan for the milestones between now and 1.0, prioritize bugs and so on. It's essential that people start doing this now, rather than later, otherwise bugs might slip through the cracks!" Further details are available in Ben's posting to the Firefox forums.

#8 Alas, yes

by johann_p

Friday April 30th, 2004 12:01 AM

You are replying to this message

I was always convinced and I still am that the idea to make Mozilla->Firefox a "mass market" browser that targets newbies or your grandma was a totally wrong decision without the slightest chance for success: there are already many other browsers that essentially do this out there (IE on Windows, Konqueror on Linux) - what should people motivate to switch? A few geek features? This sector is where it is hardest to compete with IE. I always had the opinion that the better way would have been to be innovative and implement killer features that other browsers do not have so that Mozilla conquers its own segment where it has no and more importantly, no free competition: power users, corporate users, users who need to do serious work etc. In this sector, the integration with the mail app is most important, because a major part of the workload is mail. What *could* have set Mozilla apart from the rest of the crowd is exactly an even tighter functional integration of what 99% of today's advanced users (advanced with regard to their work, not their technical knowledge) need: handling emails, follow-up actions with the browser, managing deadlines, todo-lists, tasks, handling a good calendar etc. Instead the move to FF is a move to provide just another little browser, just another little mail app, just another little calendar app. There is no real pressing reason to choose the Mozilla version of each of these neat little apps. There is no real innovation in that concept from a functional und usability point of view (yes there is lots of technical innovation, but the user and especially the "mass user" you are targeting does not care about that). So I am seeing dozens of missed chances and things not done in the Mozilla project and especially in the decision to go for the "simple little app for everyone" approach which already prevented some innovation in the Seamonkey time. The extensions approach is no solution for this either: it is the easy way out technically, but it makes everything a mess - there is no coordination what to implement how, each extension implementing their own set of overlappign features, each extension contributing in an unknown way to bugs and instability, each extensions being a potential security problem, there is no routine bug tracking or QA at the level of the core code, there is no discussion or coordination how to make the additional features available in a user friendly way with a well though-out gui, there is no way to guarantee that an extension will stay in sync with the developments of the core and many more problems. Instead of just migrating the technical implementation to make the move to seperate processes and the GRE, this switch was also a conceptional one that essentially killed the spirit behind the suite. I think this was not a good idea. It was not a good idea to listen to all those /. geeks who constantly lamented about "bloatware" - an irrelevant minority of users who just have the habit to make a lot of noise. In the timeframe of Mozilla development, with users increasingly using fast hardware, the technical overhead becomes less and less important. What is important is that Mozilla provides something that is unique from a functional point of view. The only way out of this I see is that the Mozilla foundation finally has a vision about innovative features they want in their products and that the actively work to keep the development of these coordinated and centralized. This could mean that what is now scattered among dozens of extensions gets unified into one or two uber-extensions that are developed in the same way as the core: with reviews, qa, coordinated discussion of how to do the UI, and with painstakingly detailled review of potential security issues.