January 2005 Archives

The Firefox community responds.

Sounds like Blake's getting set up for more Firefox hacking.

I'm not as organized as I should be. I got a reminder of that today and I'll be working on getting my todo list into better shape and keeping a closer eye on it. In the mean time, if I owe you something -- an email reply, some Bugzilla action, or anything else, please don't hesitate to ping me and multiple times if needed. A reminder email or a poke on IRC (I'm almost always on as Asa or Asa_) are always welcome.

Mozillazine, (adot's notblog's gracious host) has a post up pointing to Blake Ross's latest firefox commentary. I pointed to his previous firefox post titled Neverland in earlier comments. Both are worth a read if you enjoy reading the inside views on Firefox.

We're coming up fast on the 1.8 Beta freeze -- February 9. When we ship Beta, we'll be locking down the trunk until we branch for Gecko 1.8. See the roadmap diagram for more detailed schedule information.

Beta is the last chance to get L10N impact changes landed for all of our applications. It's also the last chance to get any high-risk or potentially destabilizing changes landed. With the Firefox and Thunderbird 1.1 "Gecko update" releases scheduled to come from that branch, we can't afford to regress stability over the 1.7 and Aviary 1.0 branches.

Ben has posted some information on the 1.1 release at his weblog and I hope to have an updated Aviary roadmap graphic soon.

This week flew by pretty quickly. I had two doctors visits and spent all of Wednesday out of the office so it felt like a very short week but I still managed to get a few things done.

Under the heading of "regular activities", I attended the mozilla.org staff meeting where we discussed topics from the stated of various releases to new tools like hendrix and reporter tool landing. I also had a drivers@mozilla.org and aviary team meeting where we talked about a 1.0.x Firefox update and the schedule for Firefox 1.1. Not to let a week go by without at least three meetings ;-) I also met with the update.mozilla.org team to discuss bringing the service up to a higher level of quality, security, and scalability. Oh, and I had a great meeting/discussion with Aaron leventhal, MoFo QA, and accessibility contributors to discuss our a11y goals and plans for Firefox.

Also under the heading of regular tasks, I did a few bits of Bugzilla administrative work, adding keywords, updating default assignees, etc. and I mediated in a couple of Bugzilla disputes.

My overall focus this week, other than meetings and general administration, was on planning for automation. I worked with several contributors in defining a set of requirements for some preliminary functional test automation, investigating some 3rd party tools, and working with twalker and jst on a testing tool I hope to talk more about next week.

In addition to the regular tasks and the automation work, I also spent some time investigating Firefox 1.1 blockers and spent some time here on this blog and at SFX posting updates around the Firefox download milestones -- oh, and I worked up and posted the Ask Asa responses.

Also, I've created and posted a new roadmap diagram for inclusion in the Roadmap. I think I'll whip up a "zoomed in" roadmap that shows the Firefox schedule on the Gecko 1.8 branch.

There were lots of other little bits and tasks but I'm not even sure if anyone's interestd in this kind of stuff so I won't go into much more detail until I hear if you care about this kind of status info.

Let me know what you think, and if you're a regular contributor to any of the Mozilla projects, I'm keenly interested in what you've been working on recently.

Pamela Jones' GROKLAW has a great post titled Firefox FUD is Born where the Michael Gertenberg article urging business to think twice about deploying Firefox because Firefox doesn't support ActiveX gets taken down a notch.

It's a good read and some solid talking points should you run across this FUD and need help crafting a response. Thanks,

Mitchell Baker, our Chief Lizard Wrangler and President of the Mozilla Foundation, has another great blog post on "First Days at the Mozilla Foundation."

Yes, I did score a nice window seat in the last desk shuffle. Had I known that Mitchell was interested in this space, I'd have gladly taken myself and my machines to the broom closet instead :)

I left my camera at home today. I'll post some photos next week.

update: I think I've found a space I like even more than the window. Marcia, Chris Beard and I will be doing a big office plan and maybe I'll move myself and free that up for Mitchell when we do the reorg.

Blake Ross, Firefox engineer, child phenom, Stanford student, playgirl coverboy, and aspiring childrens' story author, has a great blog post up at his Firefox Blog.

If you ever wondered how we stay sane working on these projects (or maybe how we haven't stayed sane :-) then you'll want to give this one a read. Good stuff, Blake.

I've finally made a minute (140 of them, actually :-) to put down some answers to the latest installment of Ask Asa. I'm not necessarily the best person to answer all of these questions and I don't have time to consult all of the authorities but where I could, I asked around for some input from others. Maybe in the not too distant future we can revive the Developer Chats that Chris Nelson launched on #mozillazine way back when. Until then, I'll do my best.

OK, on to the Q & A:

backpack asked, "I was wondering what sort of additions were planned for gecko. For example, is there any timeframe for getting SVG 1.0 'finished' and into the default firefox builds? Also, are there plans to implement CSS 3 whenever the spec is final? That sort of thing."

Well, backpack, you've asked just the kind of question that covers an area I'm clearly not an expert. From my role on drivers@mozilla.org I've been involved in some of the planning and scheduling discussions around SVG and it sounds to me like a plan has emerged for what of SVG will happen and the beginnings of a plan for when. SVG depends on quite a bit of rendering (GFX) work too, so it's not just the simple question of "when will we have SVG"? Robert O'Callahan has posted a roadmap to the Mozilla wiki that outlines a plan for updating our GFX layer with Cairo, which would provide a substrate for the cross-platform Mozilla SVG implementation. As to when it will happen, I believe that the Cairo work that will give us a snazzy new graphics layer, including all of those cool zooming and blending features, is on the Mozilla (the platform) 2.0 list so I'd hope to see much of this work happening in the 1.9 timeframe. With CSS3, we've been implementing pieces of CSS 3 for ages. As you mentioned in your question, the spec is still a long way from complete. Given its incomplete state, dbaron offered me the estimation of 40%, we have been implementing it piecemeal and with a focus on areas where our app needs the feature. There are a few exceptions and we do have some CSS 3 support that Web developers today can use like some of the pseudo-class selectors, opacity, and columns.

A`ja asked, "Anything you can tell us about plans for addition of X+V 1.2 and CSS3 speech capabilities to Moz browsers, ala Opera 8 beta?"

A`ja, as far as I know, there aren't any plans to add speech capabilities to the Mozilla apps.

XeroCool said, "How will the future of FF look like?"

Well, that's a huge question. Let me try to focus it down to something more near-term. We've got a Firefox 1.1 coming up this spring/summer and the goals for that release are to move to a contemporary Gecko core (the rendering engine that shipped in Firefox 1.0 is now approximately 7 months old and will be nearly a year old when 1.1 ships.) This update to the 1.8 Gecko will provide new layout features, improved website compatibility, better performance, and hopefully stability. In addition to the Gecko improvements, we'll probably see some big improvements to the Options/Preferences window, both backend and frontend, as well as a heap of Macintosh bugfixes that should bring it much closer to the Windows and Linux builds in terms of usability and overall quality. After 1.1, we'll be looking toward the 1.5 release which is just now being planned. Look for major innovations around our new unified storage code and updated graphics capabilities. The future of FF looks good :-)

dolphining had a couple of questions. The first was "You mentioned Web Forms 2.0 in the other post. What are the plans for it, e.g. how soon (after it's finished) can we expect it, is anyone working on it already? And if you know offhand (though I should probably ask Hixie...), how soon will Opera and Safari support it?

Another question where I don't have great answers. Web Forms 2.0 is still in the defining and planning stages, I think. It's on the Mozilla (the platform) 1.0 list so I'd expect work to happen on it this year. I don't believe you'll have to wait for it to be finished before you can play with it -- unless someone has plans to change the Mozilla incremental development process. I don't have any information about Opera and Safari's plans on anything.

dolphining's second question was, "What bug currently, for whatever reason, irks you the most?"

Talk about a difficult question :-) I've been reading bugs since 1998 and for a number of years, I read almost every bug that came into the system. I'm irked by literally hundreds of bugs and couldn't possibly nail it down to one. I'd be lame for using that excuse not to answer your question so I'll mention a few that aren't necessarily the worst, but that popped into my head immediately. I really hate that we don't have a mechanism for setting default browser on Mac. I'd love to be able to delete attachments from mail messages. I'd like to see the network error dialogs replaced with an error page. Hrm. Wait. Those are actually feature requests ;-) There really aren't any bugs in Firefox or Thunderbird that really irk me. I do have a couple of bugs in Bugzilla that irk me but I'll bet no one's interested in those. If you are, feel free to look up the bugs I've reported or am cc'd on in that Product.

Ludovic Hirlimann says, "You recently said Mac builds tooks hours to complete, could you give use the specs of the machine doing those builds ?"

Well, I was probably exaggerating a tad. We do have some flashy new dual G5 Macs that QA and development inside the MoFo office are using and those are considerably faster. The older ones can be quite slow. Imola, for example, makes a Firefox branch and trunk builds completes in about an hour. It's a quicksilver 867 MHz G4 with 2 MB cache and 512 MB RAM. But completing the build isn't the only problem. We also have to upload the build and the talkback symbols and that can take up to an hour so if we're sitting around waiting on the next build to come out with the latest checkins, it can take two or more hours for Mac.

My lovely wife, Deanna asked, "What...is your name? What...is your quest? What...is your favorite color? What...is the capital of Assyria? What...is the airspeed velocity of an unladen swallow?"

Hrm. What do you mean, an African or a European swallow? ;-)

minghong asked, "When will Mozilla support ruby characters? :-P"

That would probably be bug 33339. I don't think anyone has an answer to that. Perhaps someone who cares enough will come along and make it happen.

Martijn had quite a few questions. Let's start with the first and work our way through :-) "I'm seeing a lot of work done on SVG and XForms. Who are those guys working on that (they are specifically working only on that)? And why are they doing it (now)?"

The guys working on SVG (and it's dependencies) include Tim Rowley, Robert O'Callahan, Jonathan Watt, and probably a few others (certainly they're getting some help from our core layout folks like dbaron, bz, and others.) I haven't been following this closely so anyone that has, feel free to chime in with more info. Bryan Ryner and Darin Fisher were the two I know of working on XForms. More recently, Doron Rosenberg has been helping too. I'm guessing that since Darin's gone to Google, that will just be bryner and doron now :| though I'm not sure of that. Some of these contributors are paid to work on it, others aren't. I don't think any of them have SVG as their exclusive contribution to Mozilla.

"Can I help in those areas, with testcases and stuff? (if I find the time)"

I'm sure you could. They have a project page at http://www.mozilla.org/projects/svg/ and lots of bugs in Bugzilla. You can probably connect up with those folks through one of those avenues. For XForms, you should probably email bryner or doron and see if there's anything they need.

"Where can I download those builds with SVG/XTF/XForms enable? (Did I forget something?)"

You can occasionally find builds with SVG posted at Mozilla's FTP site. I think the links are available at the SVG Builds page. I don't believe there are any XForms builds available yet. Doron says that XPIs are coming soon though.

"I've submitted a few simple patches for Firefox code, but I've noticed that reviews are rather slow. Is that normal?"

Yes. That's normal. There are currently about 1,100 patches in Bugzilla awaiting review or super-review.

"Also, the people who do reviews for Firefox is not listed somewhere, like for Mozilla. So, it's not really obvious for me who should do reviews/who is doing reviews. Wouldn't such a review list be handy?"

They certainly are listed. You can find reviewers at the Module Owners page. An owner or Peer is able to do reviews. For Firefox, those modules would be Toolkit and Browser.

Ivan Icin says, "You publish stats frequently. I was wandering, are those percents applied to total number of Internet users, or to number of page hits?"

Actually, Ivan, it depends on which stats I'm publishing. The download stats are just that, completed Firefox and Thunderbird downloads. The stats from other organizations like WebSideStory and OneStat are usually based on website tracking.

Jos� Jeria asks, "What happend to devedge.netscape.com? They shut it down, and then it was back up again? And now gone again? I think many web developers would be very happy to see it back again.

Jos�, AOL, who owned all that content pulled it down. As soon as that happened, the Mozilla Foundation looked into it and Mitchell Baker started work to try to secure that documentation. I think she's got a post coming up on this but things are looking really good.

jens.b asked a couple of questions in his comment. The first was, "On some developer day slides, it was mentioned that Mozilla would move to a graphics engine library called cairo, and that a new canvas implementation was started as part of that work (i.e. not based on previous work for bug 102285). However, I miss some information about this - progress, who's working on it, target gecko milestone etc. Do you have any info on that? I wonder why, unlike other stuff planned for Mozilla-the-platform 2.0, this new canvas implementation doesn't seem to have any up-to-date details in the mozilla wiki, the corresponding bug, newsgroups..."

I believe that this implementation would wait on Cairo support in Mozilla and would hope that the experts, Stuart and Vlad, would pick that work up when the substrate is primed. I don't have much more to offer here, sorry.

The second question was "I often wonder how users, interested developers or soon-to-become-developers are supposed to know whether a bug is intended to be fixed (imagine a "yes, we want this, feel free to work on it" tag). For example, many bugs in Firefox are just assigned to Ben Goodger, but with no indication he or his peers did ever look at it. I mean, we have ASSIGNED and RESOLVED WONTFIX, but these bugs are in between those, in a state that could be described as "UNNOTICED" or "UNDECIDED". Given that bugmail is not always read, how can one bring them out of this state?"

This is a good question. We don't have a great system for making this clear in Bugzilla. The first thing I'd suggest is to make contact with other active developers in that area and find out where they're looking for help. We've always had more bug reports coming in to Bugzilla than our developers can possibly stay on top of if they're going to get any work done. For this reason, we try to harness the community to clean up and triage bug reports, to nominate major problems, and certainly to contribute patches for problems they can fix. Utilizing the community of people who care about particular issues is critical to our successes. But, yes, you're right. It's not often easy to tell whether or not the issue is one that we (those responsible for the product decisions) want the changes. If you're unsure and you can't get info from the module owner or peers, then I'd move on to a bug that's clearly in need of fixing. We have enough of those that no one who wants to fix bugs should feel like there isn't a good place to start. Avoiding "features" and devisive changes is probably a good idea since those are most likely to cost you a lot of time without a lot of benefit.

Jos� Jeria says "How should bug reports that are filed with 1.0 be treated? For example typical "firefox crashes on this website" kind of bug. If it works on the trunk with the same system, should it be marked as WFM right away? Chances are that the bug was fixed long time ago."

We're not going to be releasing any 1.0.x releases with fixes that would break Gecko compatibility with 1.0 or Mozilla 1.7.5 -- if at all possible. If the bug is working on the trunk and it's not security related, then go ahead and resolve it as Worksforme, unless you can locate the actual bug where the fixed happened, in which case you might resolve it as a Duplicate of that.

Gids says, "Similar to Jos�'s question: I'm looking to help out more with Bugzilla, when I check the 'bugs already reported today' I often see bugs like 'foo.com doesn't look right in Firefox' filed for example under Firefox General. Most of the time these pages are far away from any W3C spec, so can't be expected to render as in IE. What should happen to these bugs should they, for example, be marked INVALID or moved off to Tech Evangelism?"

Gids, this is a bit more complicated that it would at first seem. To correctly process them I'd suggest a few steps. First, the easy one. Check to see if it's a dupe of an existing layout or evangelism report. My latest calculations show that more than a third of bugs reported these days turn out to be duplicates. If you don't find a dupe, then the next step is to come up with a simplified testcase and look for any layout or evangelism bugs that share the same problem. Once that work is done, comes the hard part, determining if the issue is something we should try to fix or not. For that you often have to consult one of the experts. If you've got the simplified testcase, though, it's usually not too difficult to find a layout person to look at it. I wouldn't mark them invalid, though. They're either a layout issue or an evangelism issue and until we get the "report a broken website" tool hooked up (any day now) we're still accepting evangelism bugs. Our process for accepting layout and evangelism bugs will probably change, though, once we have our new tool

David Naylor asks "When and why was the idea of including a couple of extensions with the FF download abandoned?"

It wasn't. We ship the DOM Inspector as an included extension and we may include others if we find ones of sufficient value and quality.

Neil Paris wonders, "Any chance of getting the graph from December (http://weblogs.mozillazine.org/asa/archives/007184.html) updated (or a similar one for January, maybe?) I think it would be interesting to see."

Yeah, I'm too late at responding to the Ask Asa questions. I've already posted some updated graphs. You can find them here and here.

perko says "Was there a conscious decision to not add a download address bar in the download manager? Is one in the works for Firefox 1.1?"

Yes, all of the UI decisions about Firefox 1.1 were conscious :) I don't believe that this is planned for 1.1.

pipe asked "How many of the Secunia vunerabilities would you expect to be fixed for Firefox 1.1?"

We've already fixed one or two of them already (at least the window injection one) and we'll fix the ones that really matter and fix them in time for 1.1. There are a couple that really aren't that important, though, and I'm not sure about those.

larfnarf asked "could you please explain the way that the Mozilla FTP/Firefox distribution works? I was under the impression that the org went through a lot of work to get mirrors for firefox... Also, I was under the impression that in the early days of the release that offical counts of downloads took some tabulating.. Is there now a new system that makes counting downloads easier?"

The wonderful folks at OSU's OSL have been working on a tool called Bouncer which is, to put it real simply, a mirror management tool. We serve our releases through a fairly large network of mirrors (somewhat above 50) and this Bouncer tool has some great features including the ability to easily add and remove or disable mirrors, automatic scaling and routing to the most appropriate mirrors, hash checking to insure file integrity, etc. I has mad counting downloads considerably easier and taken some of the guesswork and estimation out of it but the tool is really more about managing traffic and load than providing Asa with lots of good stats. When it's a little bit further along, I'll ask for more in terms of reporting.

squegole says "I was wondering if you could elaborate on an recent post of yours regarding the need for rich text editing and other textarea field enhancements. Have you shared this idea with others in MoFo circles? What would it take to get such features incorporated into Firefox? For example, is it realistic to hope some features of this type might be integrated before, say, version 2? Whilst on the topic of future technologies and Firefox, is integration of XForms or Web Forms 2 confirmed?"

Yes, squegole, I'm sure that the need for better rich text editing and other text area enhancements is already well known to others at MoFo. It's been an area of discussion for years. My post was really trying to approach the issue from a "what would make blogging better" standpoint but the idea of better text editing is not new. I think that it's possible we could see something like Contente Editable in Firefox 2.0. Some of the other suggestions, I'm not sure. That's one reason I was soliciting input here at the blog. I'd like to find out how much interest there is and if anyone's interested in helping to make some of those features happen. In response to your second question, yes, integration (in some form) of XForms and Web Forms 2.0 are planned. Whether they'll be in upcoming Firefox releases, I don't think that's been decided yet.

OK, that's it for this round of Ask Asa. Hope you all found it interesting. I'll field follow-ups for this issue in the comments and hopefully post another Ask Asa sometime in February.

Mozillazine is reporting on a couple of new Firfox books coming out. I've had an opportunity to review some of the Don't Click On The Blue E book and I think it's going to be a great addition to the growing Mozilla-related bookshelf. If you've got friends or family that need that extra nudge or who just like having a good instruction book for making a significant change like from IE to Firefox, this book should help a lot.

If you're a Mozilla (Seamonkey, Firefox, Thunderbird, Core, whatever) developer, you should head over to brendan's blog and have a look at his latest post.

If you're a praying person, our good friend Gerv could use your help.

Wow. Exciting times. Darin Fisher, our networking Module Owner, is also headed to Google. As he notes at his blog, he'll still continue to be very much involved with Mozilla.

Before going to Google, Darin was employed by IBM to work on Mozilla, and before that, by Netscape/AOL.

What an interesting development ecosystem we have, where you can have three successive employers each interested in funding your work on Mozilla.

It's up.

According to this article, "A fifth of the UK's 35 million business and home internet users are predicted to switch from Microsoft's Internet Explorer (IE) browser to Mozilla's open source Firefox product before the end of the year, according to a new report."

Them's some large numbers :-) The figures come from consulting firm BDO Stoy Hayward. Dr Peter Chadha, technology expert at BDO Stoy Hayward was quoted as saying, "Firefox isn't totally secure as no browser can be, especially if it runs on Windows, which is the world's top digital target. But, in short, Firefox has better security and privacy, and we are actively working with clients to reduce their IT costs by incorporating Firefox into their environments."

I like it :-)

I just read this press release

SEATTLE, Jan. 25 /PRNewswire/ -- Speakeasy, (www.speakeasy.net), the nation's largest independent broadband services provider, today announced it is the first provider to offer an official customized version of Mozilla Firefox 1.0, the award-winning web browser from the Mozilla Foundation. Mozilla Firefox: Speakeasy Edition will empower users to browse faster, safer and more efficiently, and will be distributed as part of Speakeasy's self-install broadband service kits to its residential customers starting this month. It will also be available as a free download to anyone from www.speakeasy.net/firefox.

"We're thrilled to be the first broadband service provider to adopt Firefox, taking our customers' browsing experience to the next level. This special edition is just the first step in making browsing the web better for our customers. We plan to continually enhance the browser with features that will benefit Speakeasy's home, business and gaming subscribers," said Mike Apgar, chairman and founder of Speakeasy.

In an effort to curb some of the comment spam, I've asked my gracious hosts (kerz) to install the MtCloseComments plugin for the Mozillazine-hosted weblogs. It was recommended by shaver this evening on IRC.

Kerz rocks, so we now have what I hope will be a solid tool for fighting spam in the mz blogs.

Most of my comment spam comes into posts that are older than about a week and haven't had any recent activity. This plugin allows me to specify and age and days without activity number and it will automatically close posts to comments.

I've started out with age>10 inactive>4 so posts are going to get closed pretty quickly if they aren't active.

If you're trying to comment to a closed post, I recommend either posting in your blog and trackbacking me or sending me an email.

My goal here is to spend less time cleaning out spam and more time writing informative blog posts. I'm more than happy to adjust the settings to give more time if people think that's a good idea. Let's see how it goes.

Google Labs has opened up a beta of Google Video Search. Looks like a good start to me.

Blake Ross, one of the gang behind Firefox, is ramping back up at his blog. Go give it a read, grab the feed and check back regularly.

My old Linksys wireless router and print server finally had a meltdown last week and with no other router in the house, Deanna and I have been trading off the ethernet cable for days. Today my new kit arrived, a D-Link Xtreme G DI-624 Wireless Router. Also, Comcast is boosting our cable bandwidth from 3Mbits to 4Mbits per second. Happy days.

As I'm sure most of you have read elsewhere, Ben Goodger is now collecting a paycheck from Google rather than the Mozilla Foundation.

If you're wondering what this means then go read Ben's post. If that doesn't give you all that you want or need, head over to Mitchell Baker's blog for more.

According to the latest from heise.de, Firefox and Gecko have made huge strides in the last year.

                               Jan '05   Jan '04
Mozilla & Co (Gecko-Engine)    44,1 %    28,0 %
Microsoft                      36,3 %    54,8 %

That's pretty amazing and it's pretty much all Firefox gains. In one year, Gecko and Microsoft have nearly swiched places in terms of marketshare. It's nice to see such a major site with non-IE users in the majority.

In seventy six days, more than sixty three thousand of you have joined the effort to deliver Firefox 1.0 to more than twenty million thankful users!

You all are simply amazing!!

You've engaged your friends and family, your co-workers, colleagues, and fellow students in a novel and exciting effort to take back the Web. You've helped twenty million people to get beyond the daily chaos of adware, spyware, and constant virus infections. You've created the first and the largest open source marketing effort in history. And you all are educating the world that they do have a choice and that they can take control of their Internet experience.

You all have demonstrated that open source community can be powerful, committed, and capable of accomplishing once-unimaginable feats.

Today, we celebrate twenty million Firefox 1.0 downloads. But more than that, we celebrate the community that you all have built and we celebrate each and every one you!

(cross posted to spreadfirefox.com.)

This graph shows the total number of downloads each day since the release on November 9. These 76 days worth of downloads add up to the 20 million total you see in the graph below.

As you can see, we had an amazing first couple of days with about 2 million downloads. The first week after that averaged over 300,000 downloads per day. Since then, we've been moving between 210K and 270K daily averages.

Without better labels, it's not obvious which days are which but I can tell you from my larger version that the dips are happening around Friday and Saturday (weekends) and the peaks are happening mid-week. You can see the double-peaked section in the middle that sticks out some. That's the New York Times ad pulling the downloads up out of the slump they were in for the 10 days before.

Hope you all enjoy the data dump. One final note. These are taken from our total download numbers which includes all of our mirrors and includes all of the locales hosted by Mozilla and our mirror network. Right now I don't have good data on language breakdowns but I'll try to get a post up soon with some of my estimates.

One of the most frequent requests I get from people here and over at SpreadFirefox.com are for more detailed download information. The cumulative download graph is the most often requested and fairly easy to put together.

This graph shows the total number of downloads since the day of the release. As you can see, the line is pretty darned straight. That's highly encouraging to me as we've never before seen this kind of linear growth over this length of time with any prior Mozilla product releases.

In this graph, it's not real easy to see, but things had started to dip a bit right before the New York Times ad ran on December 14. The slope turned upward a bit for the following two weeks. Then it fell back a bit over the Christmas and newyear holidays but came back with a nice kick as people returned to school and work in 2005. That uptick is visible starting around January 4th.

The line runs up through early this morning when we hit 20,000,000 downloads. That's shy of 11 weeks since the 1.0 release.

I've got a daily totals graph that I'll be posting next so stay tuned.

Ben Goodger has posted some screenshots of the new Firefox Options/Preferences window. Mozillazine has the low-down and discussion.

I'm hoping to get around to answering some or all of the latest batch of Ask Asa questions sometime tomorrow or Monday. (So you've still got time to add questions.)

Until then, there may not be a lot of activity here so if you're looking for something else cool to read, I invite you to check out the latest over at The SpaceWriter's Ramblings. As is always the case, Carolyn Collins Petersen has posted some great observations, photos, and pointers to the latest in astronomy and cosmology.

Even if you're not really into astronomy, she's worth a look. You might just find that her beautiful photos and clear, mostly jargon-free descriptions of the cosmos will hook you like they have me.

We're finally diving headfirst into planning for the Firefox 1.1 release. As many of you know, this release is a minor update without significant feature additions. The goals for this release are primarily to get the Firefox 1.0 code integrated with the latest and greatest Gecko code from the Mozilla development trunk.

If all goes as planned, we'll be syncing all of this up at the 1.8 branchpoint and delivering a Firefox and Thunderbird 1.1 release based on Gecko 1.8. Right now that branch is scheduled to happen in late February or early March with a release from the branch sometime after that.

In order for us to make sure this release is of the highest quality, we're looking for your help in identifying any significant 1.0 problems that need to be fixed for 1.1 and any regressions we've had in the nightly builds since 1.0 shipped.

If you've got cycles to spare, please grab the latest nightly builds of Firefox, use them for your day to day browsing, and report any regressions you find. Also, if you know of bugs that meet either of the two categories above, please nominate them for fixing in the 1.1 cycle by setting the blocking-aviary1.1? flag. The project team will evaluate all of those requests as we start to build the 1.1 buglist.

Just a reminder, this is not a feature release, it's a Gecko update that should provide performance, stability, and website comaptibility improvements for Firefox. We will try to squeeze in a few critical features like Safari migration and default browser settings for Mac that missed the 1.0 boat, but we're not looking for additional feature nominations.

Thanks for your help and I look forward to wading through all of your 1.1 bug nominations :-)

update: See also Ben's post over at Inside Firefox.

Mitchell's post about the Firefox 1.0 release day is posted at slashdot.org. If you've got slashdot moderation points, head over and help keep things topical and useful :)

For those of you who haven't gotten the Wired February edition and are interested in a better look at the cover, click on the thumbnail to see a photo I snapped this morning.

The lighting isn't quite ideal here in my livingroom so the levels aren't perfect but it's a bit better than the tiny shot I found at Wired's website.

The photo on the left is the one from the interior of the magazine that includes both Ben and Blake.

There are also a few nice charts and graphs in the magazine and a fairly decent article :-)

If it doesn't show up online sometime soon, I might take a minute to transcribe some of it and post here.

Today, as I was browsing through all of the latest Opportunity and Spirit MER raw images I came across this great photo and had to wonder if that donut we can see in Opportunity's tracks was piloted or auto-nav. Is Opportunity having some fun on the Meridiani Plains when no one's watching ;-)

This is a cropped and slightly resized version of the original Navcam photo.

While I'm on the topic of off-world photography, check out the amazing Huygens photos of Titan and read about how scientists have unlocked the secrets of the Saturnian moon's landscape. This story is just amazing.

Oh, and the team over at MSSS have posted another pair of beautiful MGS MOC (1) composite images (2) of the Martian globe. I did a little bit of enhancing and posted brighter versions of the images at my flicker (1) account (2).

I guess after spending several hundred billion dollars invading another country, there wasn't any money left over to keep supporting one of the most amazing science tools ever created. I doubt that any other instrument has inspired as much interest in astromy as the Hubble Space Telescope.

What a crying shame.

I highly encourage all of you to go read Mitchell's post, linked to in my previous post, and when you're done with that, head over to Red Hat and read the interview with Chris Blizzard. Chris is one of our long-time unix hackers, an employee of Red Hat, one of drivers@mozilla.org (with me and a dozen others) and on the Mozilla Foundation board of directors.

Here's an excerpt (but you really want to go read the whole thing):

RHM: So Firefox is largely from the same code base?

CB: Parts of Firefox are largely the same, yes. The core rendering engine for webpages is the same, as well as the underlying technologies that deal with networking and most web features. Where there is divergence is how certain features of the web (like popups or webpages being able to resize windows) are handled. Also, the UI has been rebuilt from the ground up with a focus on ease of use.

RHM: Is that why the browser project was renamed to Firefox?

CB: I think there was a lot of pressure to make sure that people understood that there was a pretty clear difference between what Mozilla was and what Firefox had become. It's not just a fresh name on an old face, but a new proposition to our users that states what we believe in and how good we feel the web can be with the right technology.

RHM: What was Mozilla then, in your eyes, and why was this "new proposition" necessary?

CB: In reality, Mozilla was a reincarnation of the old Netscape 4.x suite. It hadn't changed much in a few years, and many people considered it a mess from a user interface perspective. The Firefox project (originally named the Phoenix project) started as an effort to get rid of all of the things in the user interface that were probably not needed by 99% of end users.

It was also seen as ground to experiment with technology and try to innovate in the browser space, something that hasn't really happened in a long time. In the end, I think that the Firefox project was needed to prove that we could still make positive changes on the web.

RHM: Give us an example of where Firefox has served as that "ground to experiment."

CB: Firefox's popup blocking was derived from previous code found in the Mozilla project, but only in Firefox was it possible to make the changes required to turn it on by default and refine it to the point where it works as well as it does today.

It's also important to note that Firefox as a browser is also a platform for a huge list of "extensions." These extensions have two purposes. One, power users can still add all the functionality they want without requiring everyone to have the same feature set. Two, it means that developer's experiments can be tried out. From time to time an extension will be pulled back into the project and made part of the product.

The extensions system in Firefox is largely based on the one that was available in Mozilla, but it's easier to use and has tools to manipulate those extensions. What made it possible to install or not install the Mail component of the old Mozilla browser is largely the same technology that is used to install extensions in Firefox today. It's just much better refined.

RHM: What are Red Hat's plans for integration of the Firefox browser?

CB: We know that Firefox is one of the most successful open source projects to date, and we also know that the Firefox people take the user experience seriously. We will continue to bundle Firefox for our users because we understand that a great user experience is crucial to our own success as well.

If you're as interested in Mozilla as I am, then you'll want to head over to Mitchell Baker's blog and read her amazing post about the day we released Firefox. I mentioned in an earlier post that I thought blogs would become a more important tool in Mozilla communications, offering a new level of insight and transparency, and I think Mitchell's post is a great example.

Chris Hofmann, our engineering director (and much more) spoke this week at the Amazon DevCon and I just found some notes. I'll try to get a report from him when he's back and if there's anything valuable to add, I'll post it here. Check out the Amazon Web Services Blog for the lowdown.

Looks like Firefox made the cover of Wired magazine -- in Blake's hands, nonetheless.

I really think that the media is way too focused on personalities in all of this coverage (over the last three or four months) that features Ben and Blake.

I guess it makes their story easier if they can focus on a person rather than a project. To get the cover right, Wired would have had to find a way to include the hundreds of other developers, the thousands of active testers, and the tens of thousands of people spreading the word, and the teams of people that have been organizing this effort over the years.

I know that's just too much to expect. At a minimum, I think that Ben should have been on there with Blake (they did come out here and take about a million pictures of the two of them) and it's a pretty uncool slight to have left Ben off. Well, that's the media for you.

I did hear that the article inside is, on the whole, quite good and that there are photos inside that do include both Ben and Blake.

For your viewing pleasure, here's a photo I took of Blake getting his lipstick applied for the wired photoshoot.

Also, Blake Ross and Ben Goodger were together nominated in the 6th Annual WIRED Rave Awards in the category TOP RAVE - WIRED Renegade of the Year. They're in with some good company so check it out.

I'm really enjoying all the gains that Firefox is making and I certainly don't begrudge anyone their moments in the spotlight. I just wish that the press would work a little harder because I think there's a great story to tell here -- and that story isn't about any one person.

(cross posted to spreadfirefox.com with minor edits.)

update: I found a few more photos I took of the photoshoot. I've added the one over to the left so you all can get a feel for what it's been like in our office with all this crazy press. The photo shows Ben and Blake standing in front of the first screen. It was taken from underneath the sodacan bridge with the real photographer to the right (out of view).

This was taken before (I think) they got all wardrobed up with their $2,000 leather jacket (seriously) and $300 belts and whatnot. I wish they would have shot them in their street clothes. Well, again, it's all about image and Wired's got a certain image they're after. Oh, and that globe and hands was Photoshopped in.

As reported at TechWeb (and other outlets,) WebSideStory is reporting that "Microsoft's Internet Explorer's share of the U.S. browser market is in danger of dipping below 90 pecent," and "the Mozilla-made open-source browser had captured 5 percent of the U.S. market by Jan. 14, 2005, an increase of almost a full percentage point since early December."

I believe that's a 1 point gain in November and then again in December. Our Firefox 1.0 downloads trendline is pretty darned linear (I'll post some graphs for you all early next week) so I'll bet we can gain another percentage point in January. That might be the magic point that pushes IE under 90%. Exciting times. Very exciting times.

Firefox 1.0

Five years ago, Microsoft supposedly ended the browser war against Netscape when the dominant Internet Explorer emerged victorious. But while fat'n'happy Microsoft toasted itself and coasted, users became increasingly fed up with the constant surge of security updates and living in a state of perpetual panic that IE would give hackers free reign over their PCs.

Is it any wonder we're all fleeing to Firefox?

Firefox is a bare-bones version of the open-source Mozilla browser, and it's the only Softy winner nominated by every single editor on the staff -- for the second year in a row! Much like last year's beta version Firefox 1.0 eschews the typical "everything and the kitchen sink" approach that cripples many applications. Instead, Firefox provides the bare essentials for browsing -- fast speed and good compatibility -- with vital advanced features like tabbed browsing and an integrated RSS reader. The secret sauce is its extensible architecture, which lets independent developers add whatever functionality they want via small, cross-platform extensions. Last time we counted, there were more than 150 extensions available, and more are being added every day.

If you need another reason to love Firefox, check out it's security chops. It doesn't support the ActiveX applets that many spyware vendors use to breach your computer's perimeter, so Firefox is effectively immune to many vectors of infection for your PC.

It's about time IE got 86'd. Get Firefox now. (Dig it: it's free, www.mozilla.org)

Jeff pointed out this great article in comments. Thanks Jeff. Everyone else go check out BBspot's Browser Showdown. It's great fun.

I've been poking my head into feedhouse since I got a comment (or email, can't remember) and it appears that the emailer was right and my prolific posting is sort of overwhelming that page.

I'd rather not change my posting habits so I've asked Kerz to remove me from the feedhouse aggregator. If you read me there and you'd like to continue reading me, I suggest you grab my feed (over there on the left) or bookmark this page because it's gonna be gone from feedhouse shortly.

Firefox gets a nice plug and a couple of good quotes in the Spyware: IT's public enemy No. 1 artile over at ZDNet.

What remains to be seen is whether these efforts can keep users from migrating to Mozilla's Firefox. Part of the attraction of the open-source browser is its reputation as being significantly more spyware-proof than Internet Explorer. Corporations have been slower than individuals to change browsers, citing compatibility concerns, but many IT departments are taking a close look at Firefox.

"We have been evaluating Firefox as a more secure browser to help prevent all malware infections," said Higgins of Saturn Electronics. "Currently, it runs about 90 percent of our intranet applications."

"Internet Explorer is an inherently vulnerable browser, partly because it has such a high user base and also due to poor coding by Microsoft," said Hughes. "Here at Marist [College in Poughkeepsie, NY], we recommend that users use (it) only for Internet Explorer-specific tasks, such as Windows Update, and use Mozilla Firefox for all other browsing."

I realize I'm late to the game on this one (and kerz has even set this up for the MozillaZine-hosted weblogs, including me) but I'm catching up quickly. For any one else that's just getting up to speed on this, Phil Ringnalda has a great post up at his blog, phil ringnalda dot com - a digital magpie.

:P

It sounds like we're getting very close to a cure (or at least a decent prophylactic) for comment and trackback spam. It's good to see the search guys working on this from both ends. Now, we just need all of the major blog tools to add this feature as an option.

Weekend Pundit has a nice post up about Firefox adoption in the enterprise called Some Companies Making The Move From IE.

I think we're going to see some serious bottom up pressure in the enterprise space because people want to use a Web browser and not be used by it. They want to get their work done without interruptions from adware and spyware. They want a cleaner and faster Web experience. They want a more capable tool; it's that simple.

When enough people demand it, I think a lot of small and mid-sized business will make that move away from IE. We'll even get some of the big boys in the Fortune 500, though their IT cycles are often a bit longer and managed with a heavier hand.

It's going to be a great year for Firefox, and it won't be limited to the home user.

The Mars Exploration Rover Opportunty has found a meteorite on Mars. This is the first meteorite ever discovered on another planet. Wild.

The science team suggested about a week ago that this rock might be a meteorite because of the pitted appearnce and the mini-TES spectrum. They finally drove up close enough to use the APXS and M�ssbauer which confirmed it.

You can read the full press release here. Other than this ;-), not much to report since my last MER update.

update:I found a nice Pancam image and a couple of decent Microscopic Imager pictures in the raw archives. Pancam, MI 1, and MI 2

Mitchell Baker, our fearless leader, has just blogged her new year's resolutions. Trampoline sounds like great fun and if I get into a little better shape, I might just give that a shot myself. Blogging, I've started to get the hang of that ;-)

Like Mitchell, I also decided recently that I'd like to post more regularly about what I do at the Mozilla Foundation. I tried to get that going with the many updates on the status of the 1.8 Alpha 6 release and then the big post with answers to your questions about the Mozilla release processes. That one came out about 5,000 words so it kinda took the steam out of my work-related posts but I'll be back at it again in the next couple of days.

Also, I'm going to try to ramp up the semi-regular Ask Asa installments but hopefully get them a bit more focused on specific areas where I think my answers might actually be interesting to you all :-) -- sort of like the release questions, but hopefully not quite so many.

Anyway, I think that blogs will become a more valuable Mozilla tool as more of us use them to talk about what we're up to. We're a very large community and more communication can only be a good thing.

What an amazing accomplishment you all have made. In just a little over 10 weeks, you've helped to spread the word to over 19 million people. 19,000,000! When numbers get this big, I personally have a difficult time wrapping my brain around them so I turn to some volumes I can actually imagine. Nineteen million people would fill the NFL's largest football stadium -- 200 times over. Think of that, the largest professional sports venue in the US, stacked on top of itself 200 times! It's about the total population of Australia or New York! Not that it actually helps me visualize anything but my estimate is that these downloads add up to about 90 terabytes.

Firefox and accessibility just got a bit better. Check out this story.

Dave Miller (a.k.a justdave, and new Mozilla Foundation employee) has a nice blog post up on the arduous process of getting Bugzilla 2.18 released. Check it out.

These guys don't get nearly enough credit. They're building the worlds greatest open source bug tracker and giving the Mozilla folks the best possible tools. Without Bugzilla, we couldn't possibly have scaled our projects up to this size. All roads lead to Bugzilla and justdave, myk, gerv, vlad, timeless, and everyone else working on Bugzilla deserve a huge thanks from all in the Mozilla community (and plenty of other open source communities too.)

Thanks, guys. We really appreciate all of your hard work.

Of late, I've been doing a lot of blogging and webmail and have come to realize that HTML forms are some of the least friendly UI in our App. What can we do to make it better.

Some suggestions that come immediately to mind would be a save/submit prompt when closing a tab or window that has user form data, an inline spellchecker, a text area resizer (allowing users to resize text areas by dragging a resize widget in the corner of the text area, akin to window resizing,) search and replace within text areas and maybe a wrap/nowrap view.

This might be a bit over the top for most users. What do you all think? How can we make text areas better for bloggers and webmail users without going overboard with clunky UI or unnecessary features?

via slashdot:

"I've been doing some ActiveX coding on the side for a couple days, stuff I'm not familiar with, and I'm just flat out _appalled_ at how bad that entire API and design is. I can make an OCX that basically formats your hard drive, stick it on a Web page with a tag, and if your security settings are set low enough, you'll start formatting your hard drive the minute you visit my Web page."

Note that he didn't say "if you agree to execute, install, or even download my program". That's just scary. What scares me the most are the literally hundreds of millions of users on pre-Windows XP systems without the proper patches. These folks are the least likely to upgrade, they're the most likely to leave the system as they found it, without regular security upgrades, and they're the most likely to be victims of malware.

If you are one of these people, please upgrade to a newer version of Windows and get Firefox. If you can't afford to purchase a new operating system (I think an upgrade for XP Pro is $189.99 and the full OS is $299.) then please get Firefox and Thunderbird and stop using IE for anything but Windows Update. If you start IE, make sure your start page is set to a safe page and don't go anywhere except to Windows Update. It's just not safe.

Even if you have or do upgrade to XP (and definitely get SP2) you still shouldn't use IE. You can set XP to automatically fetch updates so you have no good reason to launch IE at all. It's just not worth the risks.

My mom just called me up to read the Maximum PC "Softy" award over the phone. (My parents subscribe to Maximum PC) It sounds like we're the only application to be nominated by all of the Maximum PC editors and we're the first listed in the annual awards.

Firefox is kicking butt! Thanks for the heads-up, Mom!

Alvin Woon, over at alvinwoon.com, Daily Misery, has a difficult time with people who simply can't believe that a product as good as Firefox could actually be free or that a free product could actually be as good as Firefox.

I've got a suggestion, Alvin, send them to the Firefox Store where they can pay $15 (and not only get Firefox, but a nicely packaged CD and Guidebook -- just like all that other expensive software you buy at a computer store.) That would make them feel better about using Firefox and it would contribute money towards the Mozilla Foundation so we can affort to continue making great products. It's a win-win situation!

John Haller has done an amazing job with Portable Firefox 1.0. There is no better affirmation of that than downloads; more than 100,000 people can't be wrong. If you haven't tried portable Firefox yet, you really should. These USB flash devices are getting dirt cheap and they're just so convenient.

And don't forget Portable Thunderbird and Portable Nvu. With most new USB flash devices you should have room for them all. I'm wondering when we'll hear about the first people using Firefox from an iPod Shuffle :-) update: hehe, just as I posted this, I found this weblog post :-)

(this image was just a quick photoshop hack, sorry if that confused folks.)

OK, I didn't find the time to flesh out the update much more but for those of you not following things closely, this should bring you up to speed from where we were before the holidays.

As Spirit slips and slides, traveling up "Husband Hill," the rover encountered the first of a new type of rock, (they named it "Wishbone,") one that looks nothing like those from lower in the hills and down on the plains. These rocks are rich in phosphorus and dappled with plagioclase. After lots of observation with pretty much all of the science payload onboard, and after dislodging the potato-sized hitchhiker that was riding along inside Spirit's wheel, the rover celebrated one year on Mars with more remote sensing.

A few days later, the engineering team was able to confim the existence of a short in the power bus on the return side of the rover arm that's been suspected since about October. This doesn't currently impact the rover activities but could prove problematic if there was another short on the chasis.

Spirit's main challenge right now is driving up this fairly steep and sandy hill. The rover was experiencing major slippage and digging in over the last month but it sounds like the engineers have devised a new system of driving to counter much of this problem and the drives of the last few days have been much more productive.

Opportunity approaches its one year anniversary on Mars, in a way, back where it started, next to the heat shield that protected Opportunity as it flamed into the Martian atmosphere. After several days of examining the heat shield and debris field, weathering a dust storm that limited battery charging, racking up more than 1.3 miles on the Odometer, experiencing another flash problem (this time from a bad command) and discovering a very interesting rock dubbed "Heat Shield Rock," Opportunity is a healthy rover.

There's not much more one could ask for than that :-)

It looks like the MozillaZine crew has returned from the holidays. After a quiet period of almost two weeks, they've got ten new items up today alone, so go check out the news.

After my recent response to all of the great questions about the Mozilla release process, it feels like a good time to open the floor to another installment of Ask Asa. So, here it is. If you've got questions that you think I've got answers to, please comment here and I'll try to post a reply later in the week.

Yes, I still owe you all a Mars update and I'll try to get that posted later today when I'm finished with some work I'm doing on at book review.

As many of you know, Bugzilla is the open source bug tracker. It was born at Netscape and Mozilla and continues to be a very prosperous Mozilla project. Yesterday, they Bugzilla team released Bugzilla 2.18, their latest stable release of Bugzilla. This version has been about 2 1/2 years in the making and includes some major improvements over the previous stable release.

We at the Mozilla project are lucky enough ;-) to be Bugzilla's largest installation and regular guinnea pig so most of the new features have come into our Bugzilla incrementally but if you're on some other Bugzilla installation, this new featureset is huge and very exciting. You won't know how you ever got by without them.

You can find the release announcement and more information at Bugzilla.org.

Great work guys!!

via slashdot, I just found the new Phoenix Mars Lander site. This mission, set to launch in 2007 and arrive at the Mars pole in May of 2008, will be an extremely exciting one. It won't be a rover like the MER duo, but will carry a pretty hefty science payload including an amazing robotic arm developed by the great folks over at the JPL. The arm will be used to dig and scoop samples for analysis by the lander's extensive set of cameras, an awesome high-temp furnace and spectrometer, and a sweet little wet chem lab and microscopes also provided by the JPL. You can find the science tools rundown over at the Phoenix Technology page.

It's still a ways off but I can remeber thinking the same thing about the MER missions and that seems like just the other day. I can't wait.

update: Hrm. I'm a bit confused by the first paragraph on the MARDI page. Didn't Mike Malin provide the Mars Descent Imager for the MER missions? Is this just outdated text?

update2: After further reading, I think much of this documentation is just old. I'm sure they'll clean things up in the coming months.

Firefox's success proves that the open-source process can reach beyond geekdom to serve�and even delight�Just Plain Users. And that when the Empire has no clothes, people will go out and find some new threads on their own.

I promised I'd get to all of your questions from my making releases happen post and I've finally got a few minutes free to take a stab at it.

Some of the questions overlap and some would take a lot more time to answer than I've got for this post but I've done my best to put together replies to each of the questions. I'm put my responses together in the format of direct replies to each of the people who had questions. Maybe later I can distill this into a more condensed post about the release processes at Mozilla.

This took a good bit longer than I expected :-) (hours, not minutes) so I haven't done any serious proof reading; please excuse grammar or spelling issues. Also, this is just one man's opinion and if I've got something wrong here or misrepresented anything, pin that on me and not on drivers@mozilla.org or other members of the community.

Peter van der Woulde was the first to post questions, so he gets the first set of answers.

1. How do you decide what to plus and what to minus ?

   This is probably one of the most frequently asked questions and our process isn't based on a set in stone list of rules. As I'm sure you know, there are two types of flags we evaluate and set. The first is the "blocking" bug flag and the second is the "approval" patch flag. The blocking flag is for bugs which should stop the shipping of that particular release and the approval flag is for patches which should land during the freeze for that release.

   It's probably also important to realize that there are about a dozen of us on drivers@mozilla.org and we all come with different expertise. I am particularly focused on quality and how our testing and user communities will respond to each of the product releases. Others have a focus on things like Web standards, security, freezing and maintaining APIs, or the Mozilla application platform. We all approach the plussing and minusing of bugs and patches with a somewhat different set of criteria.

   There are a lot of factors that come in to play, but I think over the years all of drivers have come to settle on some basic tenants.

   First, our criteria for alpha, beta, and final cycle changes are all different. We're going to have a different approach to determining whether or not a bug should block an alpha release than we would for a final release. We're also going to be a bit more relaxed about the kinds of patches we approve to land during an alpha freeze than we would for a final release freeze.

   Alpha cycles can absorb more risk than beta and final cycles so we're likely to try to use drivers@mozilla.org's influence to get high risk patches (including features, major code rewrites or reorganizations) landed in the alpha cycles. I'd certainly rather hold an alpha release for a day or two in order to get the added testing on a major new feature before beta and I'd be willing to approve the landing of that change during the alpha freeze when I might push out lower-impact changes to the beta. It is sometimes a bit odd that we approve higher risk changes and deny lower risk changes, but there's some sanity behind it :-)

   In a beta cycle, we are working to get our features in and all of our localizable resources frozen so we chase down any last feature changes, especially those with localizable strings. Our blocking and approval flag setting during beta are heavily influenced by our desire to get those changes all settled so that our testing and localization communities have a clear idea of what we plan to ship by final and we can get good testing coverage and as many complete localizations as possible.

   During the final cycle, usually on the branch, we're all about minimizing risk and preventing changes that would break localizations. In addition to those criteria, we are looking for spit and polish changes, stability improvements (any low-risk topcrash fixes) and those routine changes to our application identifiers like user agent strings.

   During the alpha cycles, drivers operate more as individuals and we often make blocking and approval flags without consulting all of the other drivers on the team. During beta, we usually get more focused and try to ensure that we've got more than one person making the decision. In a final cycle, we often seek a "triple handshake" where we have at least three drivers agree to a change, to make sure that we've looked at the bug or the patch from various different perspectives before plussing or minusing it.

   Lots of other factors come into play when you start talking about specific bugs and much of this is handled on a bug by bug basis. It is not at all uncommon that we make decisions outside of the criteria listed above.
   

2. Is that mostly bases on what is fixable with the "limited" resources you* have or based on what you feel must/should be fixed ?

   It's extremely difficult for me to generalize here. In some cases it's about the available resources. In other cases, it's about the value of the change. There have been many driver decisions to not take a fix that was ready to go or to even remove a feature that was already implemented. There have been other cases where we've influenced developers, paid or unpaid, to stop work on other things and tackle something that was really important. If drivers feel it really must be fixed, we'll do what we can to make that happen. Sometimes that is a specific bug that can be tackled during a single cycle or even freeze period. Other times, with large features or architecture, it's a much longer-term effort.
   

3. Why are bugs that are plussed for e.g. FF1.0, but didn't make it, automatically plussed for the next release (create the new version flag before the current release is out)? This way testers don't get the idea (impression/fear) that bugs are forgotten.

   Maybe I misread your question, but I assume you meant "why aren't plussed bugs that fail to make it into a release automatically plussed for the next release?" Again, this is hard to answer in the general because bugs get plussed for a lot of different reasons. Many bugs which were plussed for a release but, for whatever reason, didn't make it into the release are plussed for the next release. Some bugs which were thought to be a priority are no longer as high on the list when compared with new issues in the new release. Other times we were "abusing" the plus flag as a "we really want to get this" or "let's be sure to look at this closely before we ship" but it's not technically something we'd block the release for. It's often the case that when one of us uses a flag in this way, we comment something to that affect in the bug. The flags by themselves simply can't convey all of the purposes we've used them for so it's also important to read a bug and any comments from drivers, developers and testers in that bug.
   

jens.b asked quite a few questions and so I've tried to get to each one, but somewhat more briefly.

1. Which is the general rule (or: the blocking=+ chances) for blocking=? bugs that... a) have a patch that is not yet reviewed, or have a review=- and need a fixed patch? b) don't have a patch, but the assignee promises to make one and let it review in time? c) have no patch, and no active developer? e.g. "we never set blocking=+ on such bugs", "only if we think we really need it", "that depends (on...)"...

   In general, jens, we really try to reserve the blocking+ flag for bugs which we would actually block the release on. If a bug has a patch, then the request should be for approval rather than blocking -- unless the problem really should block the release. Occasionally, there's a patch that we're very interested in and just to make sure it doesn't get overlooked, drivers will set a blocking flag, but the normal case is that we will often give approvals to patches on bugs that aren't necessarily release blockers so the patch flag should be used rather than the bug flag.

   I certainly believe that we'd be more likely to set the blocking+ flag on a bug that had a chance of being fixed than one that didn't but the blocking flag is mostly about whether or not we think that level of problem should block the release, not whether or not we've already got a developer commitment to fix it. We often plus bugs as blockers with no developer commitment and then we go looking for help. Other times, if the bug isn't terribly important to that particular release, we'll minus it as a blocker even if there's a patch in the bug (in those cases, I'll usually say something like "not going to block for this but we'd consider an approval request for a fully reviewed and tested patch." or something like that).
   

2. Do the "blocking-flag guidelines" differ for alpha, beta and final releases - if so, how?

   Yes, they do vary some. I covered a piece of this in one of the responses above, but to try to explain it more clearly and with hypotheticals, there are lots of issues for which I'd say "if this doesn't make alpha or beta, it's not going to ship in the final" and for those bugs they might get labeled alpha or beta blockers but if they didn't make it, they wouldn't be final blockers. There are other bugs which seem bad to hand to end users, but that I believe our testing community can work around. Those might be final blockers but not alpha or beta blockers. As I mentioned above, we don't have hard and fast rules, but our general guidelines do provide the latitude we need to get alphas out with minimal developer interruption (tree closure) while maximizing new code testing, and to produce final releases of much higher quality.
   

3. Would drivers try to find someone (from module owners/peers/MoFo staff/mozilla.org) to work on a bug that's been approved as a blocker, but that has no (or no longer has an) assignee? Or are bugs that are not yet being worked on a near-automatic blocking=- ?

   I think that depends on why the bug became a blocker. There are no automatic or "near-automatic" minuses given for bugs that drivers have determined to be real blocking issues. The only semi-automatic minusing that happens usually happens when the bug flag is still in the request state, not in the already plussed state. I, for example, semi-automatically minus ancient feature requests as blockers because in most cases, an age old feature request hasn't blocked us up until now and probably shouldn't block us going forward -- that is, unless something has changed that equation.

   To make a long answer somewhat shorter, yes, we do regularly go seeking help from all of our developers from module owners to paid Mozilla Foundation staff, for critical blockers.
   

4. During the code freeze, are there usually approved checkins that are not because of regressions and not for blockers? E.g. features that were finished last-minute and should be in alpha/beta to be mass-tested, or even go into the release because they're considered so important... If so, can you think of (current or older) examples?

   Yes, during freezes, we often approve patches to land from bugs which were not labeled as blockers. If we determine that the risk to the release is minimal and that there is significant value to the change, we regularly approve patches to land that we would never label as blockers -- or that we had even evaluated and explicitly minused as blockers. You could probably construct a fairly simple Bugzilla query that would give you all of the cases where a patch was approved to land for a bug which was either not plussed as a blocker or even minused as a blocker. It all depends on the risk versus the reward tradeoff for the patch.
   

5. Do you sometimes need to discuss a bug with other drivers/module owners in order to decide whether it's a blocker? If so, does it take the form of "need your advice", or is it even a consensus thing?

   I mentioned a little bit above about this. Some folks might get the mistake impression that I'm the one making all of these decisions. Given that I'm the guy that does most of the marking in Bugzilla and that I often talk about releases as though I'm solely responsible for everything ;-) this isn't the case at all. There are about a dozen of us that drive releases and we all play a role in the decisions. Some decisions are easy for one person to make, others require more than one person, or even most of the full group.

   The decision whether or not to block a final release for an unimplemented feature request from three years ago is pretty easy for me to make alone. The decision to turn on SVG in the default builds is one where we'd want a lot of driver (and other interested parties) participation. I very often turn to the experts in particular code areas -- whether they be drivers or not, before making the decision about a blocking or approval request. Sometimes that's me asking Brendan about a JavaScript engine change or David Baron about a style system bugfix. Other times it's me asking Darin about the impact of a networking change or asking Sarah to test a Mac fix before a decision is made.
   

6. Not being a developer, do you find it sometimes difficult to estimate the risk a bug introduces?

   Definitely! That's why I'm so quick to request that information from the developers who requested the approval. I'll also consult with other developers, other drivers, and get actual testing from QA. Evaluating risk was much harder for me several years ago. It's gotten a lot easier though as I get to know which areas of the code are more or less stable, which developers have reputations for breaking or never breaking things, etc. There's no doubt, however, that I'm not as capable as almost everyone else on drivers and most of our developers at judging code change impact so I am very quick to ask for that information. As a rule of thumb, if you're requesting approval for a change to land, you'll get a lot faster response from drivers (and especially me) if you include a risk assessment and any information about the testing you performed on the code you'd like to land.
   

z had only one question.

1. Why is Mozilla release schedule as muddy and delayed as Microsoft. And what are you guys doing to improve the on-time success rate? [these days, almost NO ONE believes that Firefox 1.1 is due by march end or so.] I know it is tough to predict in software etc, but, i would be glad to know, if something is done to see that we don't lapse like we often happen to do :(

   I'm not sure I'd agree with your characterization but maybe I can shed some light here. Yes, we are often delayed in our releases from what we publish in the developer roadmaps. First thing, though, is that the developer roadmaps, aren't necessarily commitments to consumers. They're developer roadmaps and they are designed to try to coordinate the contributions from a massive team of contributors from all across the globe. As we grow and our consumers, especially our distributors, and other large-scale customers, become more dependent on our releases, we're working to communicate our release plans better. In the end, though, we care a lot more about quality than we do about a few days or even weeks slip in our development schedule and I'm not ready to switch those priorities around. As for individual consumers waiting to download the next release, if you're looking to the developer roadmap for specific release dates, that's probably not a good idea. That page was designed as a resource for our developers and for other projects and organizations who were developing or deploying Mozilla-based applications, not as a public release date commitment.
   

Bernd asks a great couple of questions that I've done my best to answer honestly.

1. Some bugs require more than one day work, do drivers also encourage long term fixing well in advance of a release, if so how are these bugs selected. Could you show some examples where that steering did work nicely. When does the release preparation begin relative to the closure of the three.

   Usually when a release comes very close there is some hardcore reminder of bugs that don't get fixed even if they are marked as blocking and linked from tinderbox, how do you deal with them, does MoFo throw its internal resources on this?

   Yes, we try, but this is an area where we really need to do better. First, we need to surface these problems sooner, then we need to start rounding up resources to make their solutions happen sooner.

   All of drivers have other workloads and contribute time driving as only a fraction of their Mozilla workload but we do need to put more time in during the release cycle and not just in the last few days.

   We're not completely falling down here, though :-) There have been quite a few large-scale changes that had driver involvement from very early in a release cycle which helped to get the issues sorted out in time for a release. Much of this used to be tracked in our branch/patch landing tool. Now that we have a better Bugzilla feature set, a lot of that has moved to bugs. A few quick examples would be things like getting the Firefox 1.0 and Seamonkey 1.7.5 Geckos synced up, getting the new Plugin scripting API landed, coordinating the code and other components for getting simultaneous localizations for Firefox 1.0 shipping in a couple dozen languages from Mozilla build machines, finding resources to fix the "mangler" crash problems, coordinating the enabling of xtf, SVG, plugin finder service, and more. I'm sure I could read back through my drivers mail and find lots more examples.

   Still, we definitely need to be more proactive early in the development cycles and I'll be putting in more of my time to try to make this happen. If you've got suggestions of specific ways to improve this, please send mail to drivers@mozilla.org. I'm always looking for help :-)
   

Jilles had a number of questions. I've tried to answer them but if anyone would like clarification or follow-up, please comment here and I'll try to add more in the comments.

1. I have great respect for the innovative style the Mozilla project has been managed, which IMHO is the main reason for the success several of its products is currently enjoying. A problem area however is roadmaps.

   Mozilla releases appear to be mostly time driven (release every x weeks) with the exception of major releases which follow a less predictable scheme (and are often delivered later than planned: e.g. Mozilla 1.0, Firefox 1.0 took the best part of a year to pin down after being announced in a roadmap. Do you agree?

   I don't agree that we're mostly date driven. We certainly do publish milestones and shoot for hitting certain date targets. Without that, we'd have no way to coordinate the contributions from so many people and organizations. There were about 1,000 people who contributed code last year. That's a lot to coordinate and it comes from people all across the world, working on a very large codebase. Without target dates, we'd never release anything.

   We've also learned over the last half decade that there are limits to how much we can change without getting the more widespread testing that we get from our alpha and beta releases. We have hundreds, sometimes thousands of people downloading and testing our nightly builds each day, but until we reach tens of thousands or hundreds of thousands of testers that we get with our milestone releases, some problems might go unseen. If we didn't have these milestone releases regularly and on roughly the cycle lengths we've been using, our code wouldn't get the depth and breadth of testing it gets in time to make any regression fixing easier to do and we wouldn't be able to make necessary improvements to new features without the widespread feedback we get from those milestone downloaders.

   So, yes, we do care about getting our alpha and beta releases out on some kind of a regular schedule, but we're not doing it because we must hit certain dates. We're doing it because we've learned that we benefit from that regular testing, and talkback data.
   

2. However roadmaps are about features and technology and there seems to be a fairly consistent inability to predict/steer the delivery of features in a particular roadmap. Many people are no doubt interested in Mozilla 2.0 and its relation to the various Mozilla projects. Could you comment on the current plans for moz 2.0 (both time and features)?

   I think I disagree with your characterization of our roadmap. It is about more than just features and technology. It's about coordinating a massive project of distributed resources. Yes, it's about planning for our projects and products which necessarily includes feature and technology planning, but it wouldn't serve us well to just have a roadmap that described a linear series of code additions.

   I think I understand what you're getting at, though, that drivers haven't been responsible for describing all of the coming changes and how and when, precisely, they would land and be available in product releases. I can't argue with that. I do think that it overlooks a lot though. First, if you go back and look at the push to Mozilla 1.0, you will see that there was a lot of work put in to build the requirements list from a technology standpoint, from a product feature set and usability standpoint, and from a quality standpoint. I know because I put in a lot of hours on that effort and I think it was quite successful. We've been ramping up to get the 2.0 requirements and plan in place now. You can follow that in the newsgroups, in the various roadmaps, and at the developer wiki.

   I think it's worth pointing out, though, that the Mozilla projects aren't as hierarchical and top-down as I think a lot of people expect. There are lots of feature and technology decision that are done at the Module Owner level and even some that happen at the individual developer level. A lot can and does happen without drivers@mozilla.org leading or getting in the way. Drivers can and should do more to surface major changes so that they'll be visible to the broader Mozilla developer community.
   

3. Is there going to be a realistic, long term technology roadmap or are you planning to stick to the proven release every x weeks and we'll see what will happen (which is perfectly fine with me).

   We've had several major roadmaps that I think were mostly all realistic and long-term technology plans. The first one described the major changes around the movement to the new layout engine, the new networking libraries, the new xp frontend, a new build system, etc. I think we met all of those goals at the same time as "releasing every x weeks".

   The second major roadmap update outlined our push through the Netscape 6 release to a new milestone schedule, a new review system, and a new project management group (drivers@mozilla.org). For those people who weren't paying a lot or close attention back then, this was a critical time as Mozilla began to differentiate itself from Netscape and started to develop an independent technology and product plan with a focus on performance, stability and correctness rather than new features. I consider our weathering the Netscape 6 release and setting the stage for a Mozilla 1.0 release to be a great success.

   The Mozilla 1.0 Manifesto was the next update and I think was one of the most specific and realistic technology roadmaps we've had. After 1.0, the next roadmap was introduced along with a new milestone plan that moved away from the release every 5 weeks to an alpha/beta/final plan. This plan had a focus on how to handle our first long-lived branch and a major push for embeddability on the trunk with a focus on footprint, memory usage, and performance. We made awesome gains in those areas during the 1.1-1.4 cycles. I'm not sure how that can be characterized as anything but a great success. It was during this time that I also made a big push to get community nominations going, which I think has been one of the most important improvements we've made in our project management process.

   The next roadmap introduced the plan to move our focus to the stand alone applications, Firefox and Thunderbird. We were ambitious about the goals and the time frame. I think we delivered on these goals with our most successful product releases ever. We didn't make it on the time frame we'd hoped, but I'm hoping you'll cut us some slack given the amount of time and resources that were required to set up an entirely new organization, find the funding, find and hire the people, achieve non-profit status, and all while continuing to deliver several major updates to the legacy Mozilla suite.

   It's time for a new roadmap (well, maybe a little bit past time) and Brendan, drivers, and our development leads have been working out the details since last year's Developer day where Brendan outlined the big picture (slides available online). Discussion continues on the Wiki, in drivers meetings, in meetings with module owners and even representatives from other browser makers and major Internet technology builders. This document doesn't exist yet, but much of the work that will be reflected in it has been going on for quite a while. You can see lots of great work going on in areas like XULRunner, WebForms 2.0, SVG, APNG, Canvas, NPRuntime, Cairo integration, an entirely new storage system, etc. When Brendan gets free from other commitments, he'll post the new roadmap document to the web site, but all of this work (and more) isn't happening without coordination and direction -- just because we don't have that page updated yet.

   I hope this didn't come across as too defensive, and I hope that it answers some of your questions. I'm happy to try to elaborate more or answer more specific questions if you have them.
   

4. Could you comment on the relation (or lack thereof) between Bugzilla and the various roadmaps

   We've done quite a bit to track our roadmap plans and progress in Bugzilla. In the early roadmaps, we used dependency trees to track our blockers and I think that was quite successful. It was painful, but successful. Next I added the Bugzilla keywords for tracking nominations and approvals and with that we saw more people getting involved in the process. We also integrated the branch/patch landing tool as a half-way point between the roadmap and Bugzilla. It was extremely valuable for tracking specific steps for getting bugs or bugsets finished off to meet the goals of a milestone plan. With the advent of Bugzilla flags, I think we've taken a great leap forward in to opening up and expanding the participation of developing the roadmap and product plans to a much wider group of participants. Literally thousands of people have played a role in nominating bugs. (somewhat off-topic, but I did some queries about a month ago which suggested that nearly half of all the bugs that have ever been nominated as a release blocker by our community have been resolved as fixed.) We haven't done the best job in using the Target Milestone field (with the exception of the Thunderbird team who used it quite well in their push to 1.0) but I'm hopeful that this can be improved. Do you have suggestions for improving the relationship between Bugzilla and our other tools?
   

Darin Grimm asked two questions.

1. What role do "support/issues from users" plan in determining what issues are considered blockers for the next release. The Mozillazine forums seem to be at least the most public way of gauging issues that users are having with a product like Firefox. What role do those experiences play in shaping the "critical" issues that need addressed and in the 1.1 release and beyond in order to improve the end-user experience?

   I think that these support groups play a couple of roles. First, there are a number of people from the groups that file, identify, or nominate bugs which impact large numbers of users. We could use more of this. If you have suggestions about how to improve this system, I'd love to hear them. The second is that I try to read as much feedback as possible in the forums, the newsgroups and blogs as so that as I'm evaluating bugs with drivers@mozilla.org, I can help to represent those users and to gauge the user impact (as opposed to code or technology impact that is the focus of some of the other drivers).
   

2. This issue may not be completely appropriate here, but it has come up a lot in recent discussions of Firefox development with those of us on the outside looking in and it would be nice to get some comments from someone directly involved in the process. When the aviary branch landed on the trunk, there were a fair number of significant regressions and issues that appeared on the trunk builds, making them less usable for daily testing. Many of these have been there for weeks now with no apparent move towards fixing them, why is that?

   Yeah, I hear you :-) A couple of things happened here. The landing was mostly successful but it was interrupted by the holidays when many at the Mozilla Foundation (including me and Tracy and Marcia and Sarah who all do regularly daily smoketesting) were taking vacations and recovering from the Firefox and Thunderbird releases. When we got back, it was time to jump right in to the 1.8a6 release work and that meant that Firefox trunk builds had to take a backseat for a couple of weeks. I hope to be able to get back focused on the state of the Firefox and Thunderbird trunk builds soon.
   

3. Thank you Asa, your willingness to field questions from those simply trying to learn more about this process is appreciated!

   Thanks. I hope to be doing more of this in the future. It's somewhat time consuming and with all of my other responsibilities, it's easy to let this kind of thing slip, but I believe that it's critical for our success that we remain as transparent and engaged with our community as is possible. It's very easy to crawl into a shell and put your nose to the grindstone when pressure is high, especially around things like major releases, but in retrospect I always realize that was the time when being open and engaged with a much larger group would have been most beneficial.
   

Going in order of the questions, there were a couple more form jens.b.

1. Beyond the "continue to maintain and release security updates for the last stable branch of the suite, 1.7.x" statement, will there be further releases of Mozilla that incorporate the latest Gecko improvements - e.g. 1.8, 1.9, 1.10(?)... What are the prerequisites for that?

   I believe that there will continue to be trunk based releases of the Mozilla application suite because there are members of the community who want it to continue and will contribute the resources to make that happen.
   

2. When you posted a draft roadmap graphic, you spoke of the "Gecko 1.8" release - is this just an alias for the Seamonkey 1.8 release? What form will a "Gecko release" have - e.g. a Seamonkey build, a XULRunner version, a Gecko SDK...

   Gecko is the core component shared by all of our applications and as we have more and varied products all shipping from the Mozilla codebase, we'd like to see them all ship with compatible Gecko versions. Rather than tracking all of our products releases based on "Seamonkey" branches, we're going to start looking at this as "Gecko" branches. If everything goes as it's planned today, we'll be shipping a Mozilla (Seamonkey) 1.8, a Firefox 1.1, and a Thunderbird 1.1 from the Gecko 1.8 branch.
   

Doug's question is about the Aviary branch landing.

1. There are currently 104 bugs (Fx+Tb) that are marked fixed-aviary, but aren't fixed on trunk. Is it safe to assume that these are all 1.1 blockers?

   We'll have to evaluate all of them. There are probably some of those which are fixed on the trunk or which never existed on the trunk and they just need to be closed. Overall, my goal would be that 1.1 doesn't regress functionality over 1.0 so if it's genuinely a bug on the trunk that was fixed for Firefox 1.0, we should get that fixed for Firefox 1.1.
   

The final set of questions was from Wally. I'm not sure what kinds of answers you're looking for here. It sounds to me more like a checklist from a textbook than a genuine inquiry into how we make releases happen. If I'm wrong and there is more specific information you're interested in, please let me know in the comments.

1. Is there a release process? (Evidence for a process could be a document or a web-page describing it).

   Yes, see the Mozilla Release Checklist.
   

2. Is the process under control? (Evidence for this could be a date or version issue control system, and approval and review system etc.)

   Yes, see the Roadmap and Bugzilla.
   

3. Are there release criteria? (Which would be listed in the process).

   Yes, see the Roadmap, the Mozilla Release Checklist, and Bugzilla.
   

4. Are these criteria based on objective measurements of the software under review, or are they arbitrary? (e.g. date driven, or decided by an individual in an ad-hoc manner).

   Our criteria are based on lots of things and are rarely arbitrarily date driven or decided by an individual.
   

5. Are there metrics for the process?

   Yes. See Bugzilla.
   

6. Is there a process owner? (Someone who has responsibility for monitoring the process and initiating improvements).

   Yes.
   

7. Is the process effective? (Is the released software meeting the criteria).

   Yes. We can always improve.
   

8. Is the process efficient? (Does it take too much time and effort to operate).

   Yes. We can always improve.
   

9. Are there methods for improving the process?

   Yes.
   

10. Are the stakeholders (all those affected) in the process involved in the definition/implementation/measurement/review of the process?

    As much as they're willing to be.
    

Well, this was fun :-) Let's do it again sometime. Maybe I can get it done in less than 5,000 words next time. But, seriously, I hope this was a valuable read for you all, especially the folks that put time into asking some great questions. If I didn't answer your question to your satisfaction, or misunderstood what you were asking, feel free to follow up in the comments here and I'll do my best to respond.

The Daily Kos, a top political weblog, has a discussion up about technology that has a lot of Firefox comments.

Eighteen million is a huge number. I'm amazed watching these numbers. I mean, I knew that we'd see numbers like this but actually watching the numbers grow by millions and millions is pretty wild.

This doesn't happen without thousands of people getting the word out, telling friends and family, pushing Firefox into the enterprise, installing it at schools and libraries, helping neighbors get set up, etc. You all have made Firefox 1.0 a huge success.

We're going to hit 20 million downloads before the end of the month. It's a wild ride and shows no sign of slowing down. Keep spreading the word. You all are the ones taking back the Web.

crossposted at spreadfirefox.com

Susan Kitchens' 2020 Hindsight is the place to be today for coverage of the Huygens news. Give her some eyeballs!

update: and check out the esa picture page

Head over to the Yahoo! Search blog and check out the buzz on Firefox!

Things are looking good for the Huygens probe. Susan Kitchens' 2020 Hindsight has some great coverage.

More coverage at SpaceFlight Now and the ESA Huygens site.

update: Susan's got photos up!! Go check it out!

I read the Festa article late last night (or was it early this morning?) and the Slashdot headline doesn't really tell the story. Go read the profile. Mitch is an interesting guy and makes some great points (and yes, Mitchell Baker is a godsend and Mozilla and all of open source owe her a lot.)

I'm a bit confused about the latest stats from WebSideStory. A big part of the reason I'm confused is that their report, apparently issued today, isn't available.

I go to their front page and see this nifty Firefox logo and headline "Firefox�s Adoption Rate Soars - Adoption rate of upstart browser triples over the last month. Read more." but the link for "read more" doesn't point to any real story.

Then there was the comment (now changed) in the business week article saying that Firefox gained 4.6%.

So, if we ignore the second hand reporting and just look at what WebSideStory says today, we tripled the Firefox adoption rate in December (assuming that means as compared to November) and the Novemeber growth was 34% over the previous month (from here.) so that would suggest that the rate of adoption was 100% in December (tree times 34%)? If so, that would suggest about a 4 point gain in December which would put Firefox at roughly 8%.

That doesn't seem to make a lot of sense either, given that the WebSideStory guy was quoted as saying "It's an emotional number. When Microsoft drops to 90%, it's big news,". If Firefox really was up to slightly more than 8% then Microsoft would have to have dropped below 90%, not just to 90% (because safari plus netscape and mozilla was just over 4% last month.) Now, I guess it's possible that Firefox took two percent from mozilla+netscape (and maybe even a bit more from safari+opera) and so IE at 90% could work out.

Well, I guess we have to wait and see the actual WebSideStory story. I wonder where the BusinessWeek guy saw it. I've sent them email about the bogus link. We'll see.

update One other way to guess at the report is to look at the WSS IE metrics from December, 91.80%. The BW article quotes WSS January 12 results as saying MS now has 90.6%. At a bare minimum, it sounds like Firefox grabbed another 1.2 percentage points from IE. Add that to Firefox's 4.06 number from the December report and Firefox should be up to 5.66%. As I mentioned above, it's also possible that Firefox took some more market away from the "other" browsers, Mozilla+Nescape+Opera+Safari.

This morning, my quick tests of the 1.8a6 candidate for Linux (the gtk2+xft build here) didn't turn up anything horrible so I've give the OK for Chase to start the repackaging.

Repackaging is to fix up the stub instllers (also called net installers) to point to the releases directory for their XPIs rather than the nightly directory. We also clean up the filenames and make a source tarball.

Once that is done, and I check in the final bits of release documentation, we're done.

update: and we're done :-)

Slashdot has a post up titled Planning for Mozilla 2.0 where they as their readers to chime in on their 2.0 wishlist items and how Firefox has affected things.

Overall, I'm surprised at how little interesting there is in this Mozilla thread. I think that out of the 250 or so comments that I read there, there were about three interesting ones. There wasn't even a good Mozilla vs. Firefox flamewar :-)

Maybe some of you all could head over to slashdot and elevate the discussion some.

I pretty much never use caps in my blog titles, but this one seems to call for it.

According to Business Week's quoting of WebSideStory, Firefox has gained 4.6% in the two months since its release!

It's Godzilla vs. Mozilla, and Mozilla is a midget. Yet the pipsqueak is pulling off a feat that would have seemed preposterous a year ago. It's taking chunks of share from Microsoft in the Internet browsing market. According to a survey released Jan. 12 by research firm WebSideStory, Mozilla's free Firefox browser has grabbed a 4.6% share in the two months since it was released and seems well on the way to its stated goal of 10%.

Microsoft's Internet Explorer has slipped 4.9 percentage points over the past six months, to 90.6%, the lowest in three years. "It's an emotional number. When Microsoft drops to 90%, it's big news," says Jeffrey W. Lunsford, WebSideStory's chairman.

That's amazing. Go read the rest of the article. It's good.

It might also give us some rough estimation metrics for comparing downloads to marketshare. If we got 16 million downloads during the two months WSS noted a 4.6% gain for Firefox, then that translates to about 1 percentage point for every additional 3.5 million downloads. It'll take more data to really nail this down, and there's always a mess around upgrades versus new users, but it seems like this should be a somewhat useful estimation tool.

Then again, as Blake pointed out to me, it's possible that this is confused reporting and that Firefox total is at 4.6% (from the beginning of time, not since the release) which would be up about half a point from the WSS stats from a month ago.

Either way, this means that OneStat and WebSideStory are mostly in agreement that Microsoft is down around 90%, off from significantly higher highs.

edited after blake quelled my initial excitement

The Mozilla development trunk is open for 1.8 Beta development. As soon as we get builds tested and release documentation up, we'll have ourselves a 1.8 Alpha6 release. Stay tuned. (Or, if you're a developer that's been grinding at the bit, land away.)

update: I've just committed the initial checkin for the release docs under releases/mozilla1.8a6. They're still not finished (especially the README) but the rough changelog is there and most of the other notes. Next I've got to get the releases/index.html page updated, the VARIABLES file (which updates the version number string for the various download links) and a news.html item. I'll hold those locally until we push the final bits to FTP. As soon as that's all checked in, I'll put together the newsgroup announcement and submissions for "the press" (mozillazine, newsforge, slashdot, etc.) It's my hope that we can get this all up tonight but if we run into any problems, it's late enough in the day that I suspect we won't finish up until tomorrow sometime.

update2: Windows builds finish faster than Mac and Linux so we've already got that build and the quick smoketest passed so things look good. The GTK1 Linux build is looking good too, but it's the GTK2+XFT build that will be the default so we're still waiting on that. And, of course, Mac, which should be done compiling in about a year ;-).

update3: We had some problems with the Linux build and it had to be restarted. Mac and Windows test out OK but it's getting pretty late and we still have to test linux, and repackage the builds for FTP, so Chase and I decided to pick things up first thing in the morning for the release.

This is interesting. Firefox is actually number two among desktop client apps for RSS! That's pretty sweet.

Check out Gerv's latest bit of coding over at the Hendrix test installation. You can read all about Hendrix -- our general feedback gateway, it at Gerv's blog post.

This tool will give our users a more appropriate (than Bugzilla) mechanism for submitting general feedback and is a great first step in returning some sanity to Bugzilla. One of the next steps will be the launch of the "report a broken website" tool. Between the two of these, I'm hopeful that we can pull a bunch of the noise out of Bugzilla.

We've still got the challenge of better handling what comes in to Bugzilla, but preventing much of the general feedback and untestcased web page complaints from landing in Bugzilla is an important prerequisite to improving things.

It turns out that one of the fixes that we had ready to land last night wasn't quite ready to land. Hopefully we'll get that fix in this morning, get a new round of builds to test, test those, open the tree to 1.8 Beta development, and ship this alpha release today.

update: Johnny's got a fix for the one remaining critical bug and that should be landing shortly. We'll kick off a round of respins and as soon as this final fix tests out, we'll open the tree to Beta devlopment. Then we've got a little bit of work to do in repackaging the builds for FTP, making source tarball, and getting the release documentation up. When that's wrapped up, we'll have ourselves a release.

update2: Ugh. We regressed XPI when we took the fix for theme install. Working on a fix now. We've been locked down for too long already so I think we'll take this fix, tag the tree and open for 1.8 beta. Then we'll test the builds when they finish later this afternoon and if we find any additional problems, we'll create a small branch from that tag to address those problems.

update3: Releasing is hard. Sicking found a problem in Johnny's patch. Johnny's working on a fix for that.

final update: (I hope ;-) We're not going to have theme install for 1.8a6. Tree is being tagged as we speak and should open for beta development soon. Any further 1.8a6 news will happen in a new post :) Time for me to get the release notes together.

Today we broke the 17 million downloads mark. The total as of this posting stands at 17,071,315 downloads since the launch just over two months ago.

Carolyn Collins Petersen, over at The SpaceWriter's Ramblings, has a great new year's post and a beautiful photo of NGC 6946. Do go have a look, and if you're ever looking for some inspiration, there's a link over to the left there under the archive and feeds, that'll take you back to her great blog.

If you enjoy her posts as much as I do, head over to Amazon and buy her latest book. You'll be glad you did.

Today we made some really good progress on the release, with patches submitted for all of our remaining blockers. By the time I left the office (about 7:30 PM) we had reviewed and approved patches for all of the blockers except one.

If all of these patches make it into tomorrow morning's builds, and our testing doesn't show any new regressions, I think we'll call it done.

There's significant pressure from developers to get the tree open for Beta development and the one remaining blocker may be moved out and landed early in the Beta cycle.

If in the morning, we don't have all of the approved patches landed, I'll do what I can to chase down the remaining ones (which would also give a window of opportunity for the one outstanding fix to land,) get a new round of builds from Chase, and as soon as those test out, we'll open the tree to new development.

Alphas aren't supposed to take a long time; we schedule a few days of freeze to get them stabilized and we try not to interrupt the development efforts too much so I hope we can wrap this up and let our coders get back to landing code tomorrow.

Susan Kitchens has a great post up about this week's (this year's, maybe) most exciting event in planetary exploration. The Huygens probe, which was carried on the Cassini space craft will be landing. Head over to 2020 Hindsight and read her great post which gives some great information including the critical timeline.

Thanks, Susan!

This week, a number of things should happen.

• Firefox will pass 17 million downloads. check!
• Mozilla 1.8a6 will be released and tens of thousands of testers will download it. check!
• The Mozilla development trunk will open for 1.8 Beta changes. check!
• I'll find some time to respond to the releasing software questions.check!
• Firefox will pass 18 million downloads. check!
• I'll finally post the Mars rover update that I've been working on for a few days.check!

Congratulations to Scott, David, and all of you who helped to make Thunderbird 1.0 such an amazing success.

In the first month after it's release, Thunderbird 1.0 has been downloaded 2 million times! That's two million people that won't be getting the next round of Outlook viruses. That's 2 million people who will be able to push the spam aside with Thunderbird's innovative junk-mail filters and get back to using e-mail again rather than being abused by it. That's two million people who will have access to the new and exciting world of RSS. Simply put, that's 2 million people who will enjoy using e-mail again :-)

Thunderbird, like Firefox, is built upon the well-tested and extremely stable Mozilla platform. All of the people that worked hard building the Mozilla technologies that underly this great new e-mail application deserve a huge thanks and congratulations, too.

We're just getting going, folks. 2005 is going to be a great year.

This chart shows the last two weeks of downloads. Each blue bar represents one day of Firefox 1.0 downloads. The first week is fairly representative of what we've seen for Firefox downloads over the last month or so. The second week, which shows a spike of about 20-25%, covers January second through yesterday.

Several possible explanations have been posted to the blog comments from my earlier post. I suspect that it's some of all of those (with the possible exception of attributing hundreds of thousands of extra downloads to Will Chatham's wearing his Firefox t-shirt ;-) We certainly did see some good press in early January, and it certainly seems reasonable that people got some good advice from family members around the holiday visits and now they're returning to work and school to follow up on that advice.

We had some problems on Friday with a Mac checkin for bug 187508. I approved the checkin because it looked like a fairly safe patch that was going to solve one of our most frequently reported Mac issues. Unfortunately, until we got a null check landed, this caused the Mac builds from Friday morning to crash. The fix went in but the next Mac build failed to complete (some build machine issue, I believe.) Mac builds take forever and by the time Chase had the problem sorted out and the next tinderbox cycle completed it was already pretty late in the evening.

We still have a few bugs left on the blocking1.8a6+ list. We've got patches in review for all but one or two of those so we're looking pretty good on the blocker list.

Other than that Mac problem and the remaining blockers, the builds we've been testing (Tracy, Sarah, Marcia, and myself) are feeling good enough to ship as an alpha. As long as we don't find anything new and major or don't see any serious regressions from the remaining blocker bug fixes.

Oh, and I'm still going through the blocker nominations. A quick scan of the summaries and keywords doesn't lead me to believe that we've got a significant number of alpha blockers there. We'll see after I get into reading the full reports (hopefully today and tomorrow).

We are also having some difficulty with talkback and our build systems. Chase and Jay are working on that and will hopefully have it sorted out by Monday.

If you know of any bugs that should block this alpha release, please nominate them. I'm mostly looking for recent regressions -- things that were working in 1.7.x and aren't working on the current trunk builds, as well as any new code that is so broken it would discourage our testing community from pulling down the A6 release and testing it out.

If all goes well, I think we can have this release out early in the week and let our developers move on to Beta work.

We're in the middle of a release wrap-up and I'm pretty busy with that but it also feels like an ideal time to bring up this topic.

With literally hundreds of thousands of lines of code changing every cycle, it's clear that there's a lot of engineering and testing work that goes into every Mozilla release. You can see this by looking over one of the "rough changelogs" that I create for each release (Mozilla 1.7, for example.)

What a lot of people don't know is that there's also a fair amount of (I hate this word) management that goes into pulling everything together for a release. On the Mozilla projects, much of that falls onto the shoulders of drivers@mozilla.org.

Drivers was created several years ago "to drive developers looking to help toward bugs needing assistance in a timely fashion, to moderate risk, and to aid commercial projects based on Mozilla in managing their product releases."

I've been a member of that group since its formation back in 2000. One of the areas I'm most involved with drivers is releases and in the last 4 years I've had my hand in about 65 Mozilla application suite releases, almost 20 Phoenix/Firebird/Firefox releases and about half a dozen Thunderbird releases.

On several occasions I've tried to write up a good blog post about what it takes to make our releases happen but have never finished. So this time, rather than try to put it into a post, I thought I'd just open it up to questions and see what you want to know about the process.

I'll read all of the questions here and then in a follow-up post, attempt to answer them and in doing so, hopefully give you all a better picture of our release process.

A great Firefox piece by Chris Arnold played on NPR's Morning Edition this morning. You can have a listen at Security Conscious Users Test Driving Firefox Browser.

I think he did a particularly good job explaining things for a non-tech audience.

Ben Goodger posted a brief response, so I thought I'd post one too.

We are providing choice and innovation for customers, and providing products that are better, faster, and safer. We have a powerful and capable community and an open development model that's just better.

We will continue to provide choice and innovation, a better, faster, and safer browsing experience, and we will grow our community and continue to lead open source software into the mainstream.

For the second day in a row, Firefox 1.0 downloads were up to 300,000. That's a significant bump when compared with the (roughly) 225,000 daily average over the last three or four weeks.

Is this just a post-holiday bump as people return to work and school, and their computers. Or is there a new wave of good press that I've missed?

What do you all think?

Steve, over at In Your Web makes a good case for adblock. I quite agree that putting the control into the hands of users is the best way to handle most content on the web.

In the world of television, I watch -- and even enjoy, some commercials. Others I mute, change the channel, or skip over (TiVo.) I hold the remote control and that empowers me.

With Firefox, we're working hard to give users just that type of control with that power and ease of use.

What bothers you about the Web? That should be the question we're addressing as we push Firefox toward the next release.

Today (last night at midnight, actually) the Mozilla development trunk (the place that all Mozilla 1.8, Firefox 1.1 and Thunderbird 1.1 development is taking place) has closed to normal checkins. During this "freeze" period, all changes that impact the Mozilla application suite will require an extra layer of evaluation from drivers@mozilla.org (in addition to the normal required reviews.) Drivers will be evaluating fixes for inclusion into 1.8a6 based on the risk that the change introduces to the applicationon and an assesment of the need to get the code in (either to fix a critical bug, or to get a piece of code landed in time for the more widespread testing that a milestone release gets.)

During this week, drivers will also be attempting to focus attention on the most severe problems, with a focus on fixing regressions, and trying to get the builds into sufficiently usable condition that we can call it an "alpha" release. If all goes well, we should have something ready by the end of the week or early next week.

If you know of bugs (especially recent regressions) that should block the release of this alpha or if you have a change that really needs to make the alpha in order to get sufficient testing before beta and eventually final, please get that on drivers' radar by either nominating the bug as a blocker -- using the "blocking1.8a6?" flag or by requesting approval to land the patch using the "approval1.8a6?" patch flag.

If you have questions about how the freeze process, drivers' approvals, or branching, etc. work, feel free to ask and I'll try to answer questions in the blog comments.

I mentioned in an earlier post that I wanted to start posting a little bit more about what goes on at MoFo and more about what I'm up to on a day-to-day basis. Here's a first attempt at giving you all a view into a part of one of my days.

This morning, Tracy, Marcia, Sarah, and I all shifted our focus to testing for the 1.8 Alpha 6 release that's upcoming. We've been mostly focused on the Firefox and Thunderbird releases for the last few months (with Tracy doing some Seamonkey smoketesting too.) Many folks, including QA, have been away on vacations, breaks, etc. so it wasn't a shock that today's trunk builds weren't in the greatest apparent shape when we dove in.

We met on IRC because we're all in different location and broke up the smoketesting according to platform with Sarah on Linux, Marcia on Mac, and Tracy and me on Windows (that's how we've been doing it for a while now with the Aviary builds.)

Sarah was focused on the GTK2+XFT Linux builds because I'm planning to move to those, rather than the old GTK1 builds, as the official release for 1.8a6. We don't yet have the installer ported to GTK2 (anyone out there interested in doing this?) but the advantages of the GTK2+XFT build seem to us (me, bryner, dbaron) to far outweigh the lack of an installer and maybe we can even do a couple of different RPMs for 1.8 final.

We don't have a set of basic functional tests set up in testrunner for the Mozilla app suite, like we do with for Firefox (completed run example) and Thunderbird (example) so our process for testing Seamonkey is to just run through the daily smoketests and ad-hoc the next deeper level of functionality (example) when we come up to a release.

If any of you are interested in helping to fill out a Seamonkey basic functional set, most of the applicable tests are available on the website and just need to be plugged into the testrunner tool (with minor updates). Then we'd at least have a more consistent approach and a place to record our test results. Right now we're tracking Daily Smoketests for Firefox, Thunderbird, and Seamonkey and Basic Functional tests for Firefox and Thunderbird in the testrunner system (a Bugzilla plugin that helps us manage testcases and record test results -- all manual right now).

Right away, this morning, Tracy reported on IRC that the Windows net installer build was failing to complete the install. After some investigation (and good tips from dbaron) we narrowed the regression window to change in the build system on January 2nd. Dbaron fixed that (turns out it affected both installers) and kicked off a new round of Windows builds while Tracy continued the smoketests on Windows zip builds.

About that time, Sarah reported a crasher in Composer when attempting to resize a table. Marcia tested it on Mac and could reproduce. I tested on Windows and saw the crash there as well. We had a good stack trace from talkback but I didn't come up with any matching bugs when I checked bugzilla so Sarah and I started binary testing and eventually located a ten day window in late November where this crash was introduced.

Unfortunately, there were no builds for us to narrow the window further. After some investigation in Bonsai (our CVS query tool) I was able to assemble a list of 5 or 6 people who had checked in to mozilla/layout (the crash was happening in nsHTMLReflowState::GetContainingBlockFor() which, had I not had a typo in by bugzilla query, would have turned up bug 273458). I cc'd that handful of potential regressors :-) and shortly after bz duped the bug against the one he'd fixed this morning -- great timing.

Marcia then reported problems with creating and SMTP server entry in Mozilla Mail (Sarah couldn't reproduce) and then a crasher in the Dynamic Profile Switching feature (this feature has never worked well, and I'd sure love to either trim it way down -- removing the "manage" part, or remove it alltogether).

I interrupted for a minute to get today's Firefox 1.0 download numbers and noted a nice spike in the daily numbers (about 50% better than the daily average over the last few weeks - we might beat 300K today). That cheered me up a bit :-)

By this time, the next round of Windows builds had arrived and Tracy jumped on those. The installer was working fine and he also noted that the resize table crasher had indeed been fixed by bz's earlier checkin.

Tracy concluded his smoketesting a few minutes ago with a PASS so we're done there for the day. Marcia and Sarah have finished up Mac and Linux smoketesting with a couple new bugs reported and I'm finishing my first round of triage on the 65 or so blocking1.8a6 nominations that were pending when I got up this morning. The tree freezes for 1.8a6 in about 7.5 hours. We'll get up tomorrow and run the smoketests again while drivers@mozilla.org (which includes me) start chasing down fixes that would block the alpha release.

update I guess I didn't make it terribly clear, but this wasn't final testing for the latest 1.8 alpha. This was just a regular day of smoketesting, something that happens pretty much every weekday for the various apps we ship.

Has anyone tried the FireFox Save/Restore 1.00 utility for Linux? I've played with Moz Backup for Windows and wondered if something like this existed.

Robin Good's network of sites have 20% Firefox visitors already. (Link via John Dowdell.) What kind of stats do you have?

Henrik Gemal (who, by the way, has filed over 2,600 bugs in Bugzilla,) posted a nice excerpt from this The challenge to Internet Explorer article over at ComputerUser.com. I think that the most important point in that article, similar to the PCWorld article linked in the post below, is this conclusion, "If open-source can produce the elegance of Firefox, then it doesn't have to play the features game with Microsoft. Our attitude toward software is changing; bells and whistles don't sound so good any more. What we want are important things done well, including making the complex seem simple."

Because I'm on a stats kick this week, and someone suggested it in the comments, I threw together this grap showing monthly blog posts since I started this blog back in April of 2002.

It looks like I started off fairly strong and then it just trailed off. Then in January of '03 I started to get serious about regular posting and it took me a while to get into the swing of things but all in all 2003 was a pretty solid year. 2004 started off with a big bang, my most blogged month ever, and was quite strong year with all the Mars rover posts and all the Firefox excitement.

I'm not sure what 2005 will bring for this blog, but I'd like to start doing a bit more posting about my work, what's going on at the Mozilla Foundation, what specific stuff I'm working on, etc.

What do you all think? What brings you here and what would you like to see more of, or less of?

I'm definitely going to continue posting about the things I find interesting, including Mozilla press around our releases, any space or astronomy topics that catch my attention, computers and the internet, and stuff like that, but I'm also open to suggestions. Maybe I can do something a little less focused than the Ask Asa posts and just try to generally blog more of the stuff you all have questions about or are interested in.

Let me know. I'll keep the comments at this post open as long as possible and check back regularly.

Blake pointed me to this great PCWorld.com article, How to Build Better Software: It's Simple which opens by posing the question, "Firefox is mean, lean, smart, and rock-solid. Why is that so unusual?"

Author Harry McCracken goes on to praise Firefox (and Thunderbird) for what I believe to be pretty much all the right reasons. He says "Firefox focuses on doing ordinary tasks uncommonly well" and concludes with "These apps aren't the most feature-rich in their categories, but they don't feel dumbed down. Matter of fact, they feel smartened up--and I'd love to see everything from office suites to system tools take some cues from them."

It's a great article that does a nice job highlighting what I love about what we've accomplished -- building smart applications that do ordinary tasks uncommonly well.

For that, PCWorld has crowned a new browser champion, saying of Firefox that it "is safer and livelier, and it offers a better Web experience than any other browser out there--and not just because Microsoft has made a mess of market-leader Internet Explorer."

Smokie, over at his SpreadFirefox blog has excerpted a page from the PCFormat magazine, January edition, which gives Firefox the highest rating of 6 tested browsers. Go check out his blog post.

+-----------+----------+--------+ +----------+--------+
| Month     |   IE     | Change | |  Gecko   | Change |
+-----------+----------+--------+ +----------+--------+
| January05 |  69.70%  | -1.10% | |  23.00%  | +0.50% |
| December  |  70.80%  | -2.70% | |  22.50%  | +2.00% |
| November  |  73.50%  | -1.70% | |  20.50%  | +1.70% |
| October   |  75.20%  | -0.60% | |  18.80%  | +0.60% |
| September |  75.80%  | -1.50% | |  18.20%  | +1.30% |
| August    |  77.30%  | -1.40% | |  16.90%  | +1.70% |
| July      |  78.70%  | -2.00% | |  15.20%  | +2.00% |
| June      |  80.70%  | -1.10% | |  13.20%  | +0.80% |
| May       |  81.80%  | -0.70% | |  12.40%  | +0.70% |
| April     |  82.50%  | -0.30% | |  11.70%  | +0.70% |
| March     |  82.80%  | -0.20% | |  11.00%  | +0.50% |
| February  |  83.00%  | -1.10% | |  10.50%  | +0.80% |
| January   |  84.10%  |        | |  9.70%   |        |
+-----------+----------+--------+ +----------+--------+

Today the early January browser stats have been posted at W3Schools. They've split out the Firefox results from the Mozilla results - which is interesting, but not terribly helpful for Web developers.

Here's a slightly different format for their browser stats

As you can see, the last year has been good for Gecko and not so good for IE -- at least among the Web developer types that visit w3schools.

Today we crossed the 15 million downloads mark (at the time of this post we're at 15,037,758) and we've done it in less than two months, 55.5 days to be precise.

15 Million downloads -- and with 200,000+ downloads per day, things are still going strong. Wow!

This is nothing short of amazing. Thank you to the tens of thousands of Firefox evangelists who made this happen. With you all leading the way, we're taking great strides to make the Web usable again!

Do any of you have any experience with the Gmail notifier Firefox extension? I'm wondering if/how it supports multiple Gmail accounts. I've got more than one and I'm looking for an easy way to find out when a new message comes into one of them.

I can't wait until they offer IMAP. I'm told it's coming.

Linux.Ars, Looking back at 2004 has awarded Firefox the best desktop application of 2004.

Desktop application of the year

Forum-goers chose the best desktop application, regardless of desktop environment, taking into account usability, functionality, documentation and stability.

When it comes to applications on your machine, there are some you never touch. I don't think I've used Floppy Formatter . . . ever. But there are those applications that are always open, possibly consigned to workspace 4, but always open because they're integral to your workflow or just not worth closing since you're going to open them again in about 5 seconds. And there's always just that one program that you feel rocks out with indie-level power.

Winner: Mozilla Firefox

This category was dominated by Firefox, which reached a 1.0 release on November 9th after several years of development and several name changes. Firefox has become the poster child and banner-bearer for the OSS community, and is probably the most visible project overall. By being easily customizable and extendable, Firefox has garnered support on multiple platforms and has also been the recipient of critical support from the industry as well as numerous press sources. With this kind of momentum, the future has to look very bright indeed for the members of the Firefox community.

User Friendly has a cute Firefox-related comic up today.

I can't recall if I linked to this or just sent it around in email. Anyway, this is a great blog post that's worth publicizing (and not just because it includes Firefox.) Spread the word about Scribbling.net's How to fix Mom's computer.

Welcome to MoFo, Dave!

I can't tell you all how happy we are to have Dave Miller joining the Mozilla Foundation full-time.

Once again, I found myself launching IE6 to test a potential bug in Firefox and once again I was confronted with how horrible this blog looks in IE. It's tollerable in Opera and Safari and looks (to my eye) pretty darned sexy in Firefox ;-)

Well, sorry to all of you IE users, sort of. I hope there aren't too many of you. Given that I don't have any stats for this blog, it would be nice if you all could chime in with how you read this blog. If you wouldn't mind (and that includes all of you pulling my rss feeds) please take a minute and let me know how you most commonly read these posts.

Thanks a lot.

Oh, and I'm gonna try to get to handing out all those Gmail invites I promised a few days ago. If you still need one and haven't posted to that thead, now's the time.

I'm looking for a free Windows (XP) anti-virus application. If any of you have any experience with free anti-virus apps and can recommend one, please let me know.