• Speed. Firefox will be faster due to less cache pressure, less paging, and fewer/smaller GC and CC pauses. Changes that reduce memory consumption but make Firefox slower are not desirable.
• Stability. Firefox will suffer fewer aborts/crashes due to virtual or physical memory exhaustion. The former is mostly a problem on 32-bit Windows builds with a 2GB or 4GB virtual memory limit, the latter is mostly a problem on mobile devices that lack swap space.

The engineers working on MemShrink asked the Metrics team to help discover and quantify what variables affect variables that related to MemShrink. Key among these is RESIDENT_MEMORY which is the resident memory that Firefox occupies. For a given installation, multiple measurements are taken before the data is submitted. The data, for a given installation, is recorded as a histogram (so we dont have serial correlations between observations …), and the final value used in modeling is the weighted mean.

The Data Set

We already have some variables at our disposal, them being

• version :: the version of Firefox (10,11 or 12)
• number of addons
• does the installation have Firebug? (Yes/No)
• memory size
• Number of CPUs
• RESIDENT_MEMORY

The data set was a 70% sample taken from the Hbase Telemetry table from 2012-01-01 to 2012-01-31. With those variables, we first looked at QQ Plots ( see http://en.wikipedia.org/wiki/Q-Q_plot ) to see the distribution for variable transformations (e.g. truncation? log transformation?). After that, the sample was further randomly sampled 1000 12.5% samples of the 70% sample. ANOVA was run across each of these samples and the quantiles of the residuals, the parameters and adjusted R squareds were taken.

Results

The following diagrams are scatter plots of some of the covariates vs. RESIDENT_MEMORY. This is used to consider interactions or transformations.

In the following graphs, Y vs X implies Y on the vertical axis and X on the horizontal. ‘log(A,2)’ is the log of A with respect to base 2.

1a). log(RESIDENT_MEMORY in bytes,2) vs. Log(# of Addons,2) by Version

1b) log(RESIDENT_MEMORY in bytes ,2) vs. Log(Memsize in bytes,2) by Version

1c) log(RESIDENT_MEMORY bytes,2) vs. HasFireBug by Version

1d) Quantiles of log(Resident Memory bytes,2) by Version

• Note, there doesn’t seem to be interaction with version except for a feeble one in (1c)
• 1d) is also called the Empirical Cumulative Distribution Function.. If the distribution were uniform, it would be  a diagonal at 45 degrees.  The panel for ’12′ indicates that 60% of the obs. are less than 2^18 bytes .
• In summary, he data set is extremely noisy. Though the assumptions of modeling are met (independence etc)
  the variables only explain 35% of the variation (not even 50) as seen from the ANOVA R^2.s
  1a) definite increasing trend with log(addon+1) but there is so much variation! and no difference across versions.
  1b)   same as (2) except that in 12 the flattening happens earlier though flattens at a higher value than 10,11. I expect some flattening to happen, why would RESIDENT_MEMORY increase continuously  just because memory size is bigger?
  1c) – marginal difference, but again so much noise.
• 1d) the distribution of RESIDENT_MEMORY  is almost same for 10,11,12 with a slight upward shift for 12.

We cannot expect a great fit with these variables. The next is a panel display of QQ plots of 100 random ANOVA residuals. Statistical inference in in this particular case study requires that the residuals be Gaussian distributed. Here ‘normal’ means  the Normal distribution. They aren’t perfectly Normal, but the departure looks acceptable.  Not included are the other displays such Scale-Location plots, though upon inspection they show no relation between scale and location (i.e. variances does not depend on mean).

QQ Plots for Residuals for a Random 25

Interpretation

Averaging the coefficients of 1000 regression produces the following parameter table. Though the estimates are precise the R squared itself is not the highest – a lot of explanation is required. Explanation of the table follows below it. The model is log(RESIDENT_MEMORY,2) ~ version + log(addon+1,2) + hasFirebug(fb) + log(memorysize,2) .

The first column of numbers is the left end of the 95% confidence interval of the  coefficient, and the 3rd column is the upper end of the 95% CI.

                          2.5    mean coef     97.5
(Intercept)       13.85290273 13.89114640 13.92939007
version11         -0.02897665 -0.01986893 -0.01076121
version12          0.09062749  0.10488013  0.11913277
log(addon + 1, 2)  0.28370203  0.28668868  0.28967534
fbTRUE             0.08945122  0.11898676  0.14852230
log(cpu, 2)        0.06480277  0.06965200  0.07450124
memsize            0.23214017  0.23590406  0.23966795

What this means is that, (‘keeping everything else fixed’)

• version 11 reduces memory consumption about 2% (on average, but keep in mind there is a lot of variation) over v.10
• version 12 ups it by about 11% over v.10 (see the distribution at top of log of RESIDENT_MEMORY by version)
• Presence of Firebug extension causes a slight increase (on average of 12%)
• if one doubles the number of addons (and add 1 to this)  the RESIDENT_MEMORY increases ~ by 33%

Future:

The thing with large data is that even the smallest difference can be called ‘significant’. What is true that 12 seems to use more memory. And that the difference between using Firebug or not decreases for 12. But equally importantly the collection of variables explains only 36% of the variance  – so though the estimates are precise, there is a lot of variance around any estimate. Results should be taken with caution.

All the computation and analysis was done using RHIPE (see https://github.com/saptarshiguha/RHIPE ). We have only covered some variables we thought might affect RESIDENT_MEMORY. There are however 215 variables captured by the Telemetry project and we could well benefit doing some tree-based analysis (randomforests anyone?) to discover useful variables (that affect RESIDENT_MEMORY). More on this later.

Sample RHIPE Code

This is the code producing marginal plots.

yy <- function(location,var,N=3){
  m <- ewrap({
    Var <- unserialize(charToRaw(Sys.getenv("varname")))
    N <- unserialize(charToRaw(Sys.getenv("N")))
    r <- r[!is.na(r$memres) & !is.na(r$memsize) & r$memres>-Inf & r$memsize>-Inf,]
    Y <- r[,"memres"];X <- r[,Var]; V <- as.character(r[,"version"])
    for(i in 1:nrow(r)){
      rhcollect(list(version=V[i],var=X[i],value=round(Y[i],N)), 1)
    }})
  mapred <- list(varname=rawToChar(serialize(var,NULL,ascii=TRUE)),
                 N=rawToChar(serialize(N,NULL,ascii=TRUE)))
  reduce <- summer
  z <- rhmr2(m,reduce=reduce, combine=TRUE
           ,ifo="/user/sguha/telemetry/samples/1/p*",of=location
           ,mapred=mapred)
  rhstatus(rhex(z,async=TRUE),mon.sec=5)
  z <- rhread(sprintf("%s/p*",location))
  library(Hmisc)
  version <- unlist(lapply(z,function(r) r[[1]][[1]]))
  varble <- unlist(lapply(z,function(r) r[[1]][[2]]))
  value <- unlist(lapply(z,function(r) r[[1]][[3]]))
  count <- unlist(lapply(z,function(r) r[[2]][[1]]))
  z1 <- data.frame(version=version,var=varble,value=value, count=count,
                   stringsAsFactors=FALSE)
  colnames(z1) <- c("version",var,"value","count")
  z1 <- z1[order(z1$version,z1[,var],z1$value),]
  z2 <- do.call('rbind',lapply(split(z1,list(z1$version,z1[,var])),function(r){
    P <- 1:19/20
    data.frame(version=r[1,"version"],var=r[1,var], p=P, q= wtd.quantile(r$value,r$count, P),stringsAsFactors=FALSE)
  }))
  colnames(z2) <- c("version",var,"p","q")
  z2
}

library(lattice)
library(latticeExtra)

###############################
## Plot of memres vs addons
###############################
addons <- yy("/user/sguha/telemetry/tmp/b","addon")
pdf("~/addons.pdf")
asTheEconomist(
              xyplot(q~log(addon,2)|version, type='p',
              main='Quantiles of Log(RESIDENT_MEMORY,2) vs. Log(addon,2)'
                     ,data=addons,pch=1, cex=0.3,col='#00000030'
                     ,layout=c(3,1),aspect=1,ylab='Log(RESIDENT_MEMORY,2)'
                     ,panel=function(x,y,subscripts,...){
                       panel.grid(h=-1,v=-1,lwd=0.5)
                       panel.xyplot(x,y,...)
                       panel.loess(x,y,col='red',lwd=0.7,type='l')
                     })
               ,type='p',pch=16, cex=0.7,col='#00000060')
dev.off() ##cut at 6
#############################

These observations lead to the following question: how does one’s willingness to recommend Firefox relate to their knowledge that Firefox is made by Mozilla, a mission-driven non-profit?  As an initial hypothesis, we posited that one’s willingness to recommend Firefox would be positively related to their knowledge of Firefox as a product of a mission-driven non-profit.

Using the beta survey interface, we asked Firefox 3.6 users the following questions:

1. Did you know that by using Firefox, you are supporting a mission-driven non-profit organization?
2. How likely are you to recommend Firefox to a friend or colleague? (0-10)

The response scale for question 2 was then used to calculate a Net Promoter Score (NPS), which is a marketing metric to gauge users’ willingness to recommend a product or service.  A person who responds at 6 or lower is considered a “detractor,” whereas one who says “9″ or “10″ is considered a promoter.  All else are considered “neutral.”

We calculate an NPS by subtracting the proportion of detractors from the proportion of promoters.  Thus, scores are between 0 and 1 and higher is better. By using this metric, we are able to investigate the relationship between the knowledge that Firefox is made by a mission-driven non-profit and one’s willingness to recommend Firefox to others.

As a survey experiment, we also reversed the presentation of the questions, meaning that for some of the time, we asked respondents to give their willingness to recommend before they indicated whether they knew Firefox was made by a mission-driven non-profit.  We did this in order to determine if simply informing users of this fact was enough to induce a “knowledge” effect.

Figure 1a shows that over every level of response, there are more users who say they did not know that Firefox was produced by a mission-driven non-profit than those who say they did.  In particular, the amount of “neutrals” (which can be interpreted as the 5s, since it is the midpoint) is greater in the “without knowledge” group than in the “with knowledge” group.  These data lend some credibility to the idea that knowing Firefox is made by a mission-driven non-profit relates to willingness to recommend and that more people are unaware of this fact than those who are.

Figure 1b shows the initial results of the question ordering.  By asking users to indicate knowledge first, it appears to reduce the amount of 8s, 9s, and 10s from users.   A potential explanation of this effect could be that users can tell that we are trying to induce positive feelings towards Firefox by asking them this information first.  We can interpret these data to indicate that simply telling users that Firefox is made by a mission-driven non-profit is not enough to boost their willingness to promote.

Figure 2 demonstrates the relationship of willingness to recommend by knowledge group.  This effect is quite pronounced.  The NPS of these groups (“Yes, I did know” versus “No, I didn’t know”) are different from each other, where those with knowledge are much more likely to say that they are willing to recommend Firefox to others.

These results support our initial hypothesis: one’s willingness to recommend Firefox is positively related to one’s knowledge that Firefox is made by a mission-driven non-profit.   Note that this is not a causal relationship; from this data, we cannot say that knowledge directly boosts one’s willingness to recommend Firefox.  No statistical tests of inference have been performed.  However, this survey study strongly indicates that this relationship bears further investigation.

1. Measuring Usage Activity

1.1 Our Current Approach: Blocklist Cookies

Mozilla has a mechanism for maintaining installed add-ons called a “blocklist” [https://wiki.mozilla.org/Blocklisting]. This involves a  scheduled request to retrieve an updated blocklist file from Mozilla servers.  The request is currently performed not more than once per 24 hours by several Gecko powered applications maintained by Mozilla (e.g., Firefox Desktop and Mobile). Because the request only happens once per day, we can study the pattern and volume of requests to understand how many active installations of a product there are on a particular day. While requests do not collect or use any personal user information, they are currently using a cookie to study how many unique active installations we see during a given time period.

1.2 From FF4 Onwards: Days Since Last Ping

It’s been our experience that using cookies for tracking unique usage is somewhat unreliable  and cookies raise privacy issues for our users. Cookies can be cleared by the user and sometimes even corrupted via proxies. Because of these reasons, the Mozilla Metrics team filed bug 616835 [1]  to implement a new method for tracking unique installations without any need for a cookie or any other form of identifier. This not only gives us the ability to get better usage metrics, but also to strengthen user privacy by removing the old cookie entirely.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=616835

Design and Implementation of Days Since Last Ping

Each time a request is made for the blocklist data, the request includes a new parameter that indicates how many days it has been since the last request. There is very little possibility to derive a fingerprint from this new parameter since it is a low number of bits, it changes on every request, and users will not maintain outlier values unless they consistently have a pattern of extremely occasional usage (i.e. months between usage of the application). If Firefox is left open unattended for 2 weeks, the days last ping value will be 1 for every day even though the user might never have been at their computer.

Computing Active Installations

For each day in the desired time period, we add all the requests with a value indicating that either this is the first ever request to blocklist (a new installation), or the last time the application made the request was before the time period we are analyzing. This means that on the first day, we count all requests with a valid parameter (i.e. between 1 and max_valid). On the second day of the time period, we count all requests with a parameter between 2 and max_valid. After iterating through each day of the time period using this algorithm, we sum all the counts together and we have the number of unique active installations in that time period.

Example

Consider the date range 04 March – 07 March. We proceed as follows:

1. For March 4th, add the ‘new’ count and the number of days last ping (dlp) ==n, n>=1.
2. For March 5th, add the ‘new’ count and number of dlp==n, n>=2. We ignore dlp==1 because those installations would have made the blocklist check with some of value of dlp on March 4th.
3. Similarly for March 6th and March 7th, add ‘new’ and counts of dlp==n, n>=3 and n>=4 respectively.
4. Add all the counts in (1)-(3) to get number of unique active installations in the above period.

With this metric we can also compute the number of new installations being added on a daily basis. Also, we would like to confirm that we have a high proportion of profiles with days last ping equal to 1. This is not the same as a ‘daily user’ but it is encouraging to see a lot of installations using Firefox for two consecutive days.

Limitations

What we can’t compute the number of installations using Firefox for exactly ‘k’ days in a week or retention patterns.

2. Visualizing the  Behavior of the Days Last Ping Metric

Firefox 4 was released on 22nd March though beta and release candidates were available before that. This is a great opportunity to visualize the dynamics of a metric for a new product.

2.1 New Installations

We are eager to see what proportion of our daily ‘blocklist pings’ come from new installations. Figure 1 displays the proportion of blocklist pings that come from new installations. The heartening observation is the positive slope of the red smoother curve. The peaks are not day of the week effects but correspond to release dates. It is difficult to comment on day of week effects here because of the significant events that occurred in the time period. Nevertheless, new profile percentage appears to around 3.5-4.5% on a daily basis with a slight increasing trend towards the end of the period.

2.2 ‘Daily’ Usage

Figure 2 is a display of the proportion of blocklist updates that come from installations with days last ping equal to 1 which means the installation is active today and the previous day. The proportion varies from 72% to 86%, with a mean hovering around 82%. The red smoother indicates not much change. The 1st,3rd and 5th week have a similar pattern: a low at the beginning of the week (a value of dlp equal to 1 on Monday means that the profile used FF on Sunday), peaking towards the center of the week and dipping as we approach the weekend. The 4th week was the week of the release. Understandably this looks very different. In both Figures 2 and 1, week 2 looks different , probably because of the RC release. I would like to say there is no weekly effect, and indeed the shape is same (except for the two exceptional weeks) but the highs and lows are different.

2.3 ‘Recent’ Usage

Together with counts of days last ping less than 7, we capture more than 90% of the users. Figure 3 shows the proportion of blocklist pings that come from installations that last contacted between 2 to 7 days back. The alignment of troughs and valleys is opposed to the dlp==1 display (Figure 2). There does not seem to be an increasing trend, with the mean around 12-14%, peaking on Thursdays. Why is that? Because the bulk come from dlp=3. On average (across day of week), 95.3 % of the blocklist pings have dlp<=3 and 98.9%<=7. Figure 4 displays the mean cumulative percent of different values of days last ping (between 2 to 7) by the day of week. The key observation is that the curve doesn’t change much – meaning there is little interaction involved here.

2.4 ‘Infrequent’ Usage

Finally, in Figure 5, we get to see the dynamics of the days last ping distribution for a new product. In Figure 5, we plot the density of days last ping greater than 14 for all the days. Each row is 7 days so we can fix a day of week by moving along columns.

Firstly, we see the distribution shifting out to the tails. On one hand this is expected as there is more time available for installations to be used after a long period of inactivity. Also the maximum proportion (see Figure 6) decreases steadily over time from 0.1% to about 0.03 % on 3rd April, dramatically so a few days after FF4 launch. However in both Figures 5 and 6, we see the peak starting to rise again. This means we have more 14 days plus inactive users using FF4. Whether this panel stabilizes is something we can see over the next few months.

2.5 Daily Actives vs. Weekly Actives

Surprisingly, if we look at unique actives over a week, vs the mean daily actives in a week, the numbers are relatively stable, for the 6 weeks the ratios are: 0.692 0.593 0.666 0.994 0.685 and 0.672
In future, we can look at rolling 7 day periods and other window lengths( e.g.  14 days, monthly etc ) and week on week on growth for unique actives.
Reassuring results, and we are all very eager to monitor the progress as FF4′s adoption increases.

Credits:

Thanks to Daniel Einspanjer for the introduction to the cookie usage and the background on the metrics ping.

Figure 1. Location intensity of cities. Blue is rare, bright yellow is high.

Though the above picture is heartwarming at the same time it is disappointing. There are swaths of the world pitch black. The location information is constrained by the accuracy of the geo-location service but that is also related to internet penetration. With Internet access rapidly becoming (in the not too distant future)  a public utility, it is sad that the ‘have not’s have one more item on the list.

Based on reader input I’ve attached a large (2248 × 1268, 1.1MB) PNG file.Click here to download.

Users overshoot their estimated browsing time

The graph above demonstrates that users tend to simply overestimate how long they use Firefox. Those that typically use the browser less have a more accurate assessment of how long they are browsing. But for users who state a longer browsing time per day, the actual browser usage is lower than their own estimate.

First, a note about the methodology behind this graphic. We estimate the average daily browsing time by aggregating the session lengths of Test Pilot users over the course of the study. Previously we have defined a browser session as a continuous period of user activity in the browser, where successive events are separated by no more than 30 minutes. We subset on the users that state they only use Firefox, to avoid the problem of a different primary browser. 

We thought of a few possible explanations as to why, for heavier users, the estimated time is lower than the stated time. Those users might, for instance, be online and using their computers quite a bit during the day, but have integrated their online workflow with their offline ones. Software engineers are a good example of this – we might expect a programmer to be working on a computer all day, leaving the browser open, and using it every once in a while.  So there may be the perception of constant browser usage.  This certainly rings true from the experience of the Metrics team – we’re on our computers almost all day, with Firefox open, despite working.  This is, however, only speculative at this point, since we don’t have data about when users are on their computers.

There are still some obvious methodological issues with this approach: a user might, for instance, use Firefox on a work computer (with test pilot installed), and a different one for home use, which could account for the difference. As such, we hope to include a survey question asking “How much time a day do you spend on this computer?” in the next version of the study.  At that point, we can update this research.

As part of that original proposal, we note Mozilla web sites relying on our web analytics tool. And fast forwarding to present day, we’d like to be able to assist all Mozilla web sites that request analytics support with our web analytics tool; we’re also making a switch in tools to Webtrends.  Our fundamental commitments to user privacy remain unchanged:

• Mozilla will use the web analytics data only to determine aggregate usage patterns for our website. We will not seek to determine personal information from this data.
• Our tool provider will use the data from Mozilla websites only to provide and maintain the service for Mozilla; it will not share the information with others or use the information for other purposes.
• Our tool provider will not correlate and report on any Customer Data with any other data collected through other products, services or web properties.
• The domain names in Mozilla cookies will clearly identify their affiliation with Mozilla and the vendor providing the service.

These improvements have the potential for fostering a greater impact with web analytics within the community, while simultaneously maintaining our commitments to individual users. In addition, we’ll continue updating the pages related to our web analytics implementation (e.g., url list, opt-out instructions).

Additionally, we’ve expanded the scope of our testing efforts. Look for tests to go live on support.mozilla.com and addons.mozilla.org this week!

In the remainder of today’s post, I’ll discuss a few experiment results and share our website optimizations plans.

Experiment Results
Getting Started
In this test, the Marketing team wanted to determine how adding Firefox tips and tricks to the Getting Started page would affect user behavior.

Unfortunately, after running an A/B test, we didn’t see any improvement in visits per user, pageviews per visit, average time per visits, or bounce rate. For the most part, the differences were minor. The only statistically significant decrease (at the 99% confidence interval) was in visits per user.

First Run Design #1
In the first of 3 A/B tests on the First Run page (bottom image), 6.3% more users interacted with the page and total interactions increased 82.4%. The early results are encouraging, but we need to run the test longer to achieve statistical significance.

Note that the design with more interactions per user isn’t necessarily better. Our final analysis will focus on specific outcomes (i.e. Personas installed and clicks on the “stay connected” buttons).

StumbleUpon Promotion
For this test, we hypothesized that promoting a specific Add-on would be more effective than promoting Add-ons generally. Currently, both the experimental variation and control promotions have a .7% click through rate.

Surveys
In addition to running tests, we used our (highly recommended) website optimization tool to run two simple surveys. With the first, we learned that 47.8% of users open new empty tabs from the new tab button, 30.4% open from the file menu, and 21.8% open from a keyboard shortcut.

With the second, we learned that 46.9% of First Run visitors are first time users, 8.5% used Firefox for under 1 year, and 44.6% used Firefox for over 1 year. The response rate for both surveys exceeded 15%.

Have an idea for a survey you’d like to run on mozilla.com? Let us know in the comments!

Upcoming Tests
Two Additional First Run Designs
We will launch 2 additional A/B tests on the First Run page. Both use tab oriented designs.

IE download page
We will test at least 4 new designs for the the IE download page. We are still in the design phase, but expect to push the first experiments live next week.

IE Multivariate Test
In addition to testing entirely new designs, we want to understand which current design elements are most effective. Accordingly, we will run a multivariate test, switching in and out 4 page elements. Look for a blog post discussing the results soon.

AMO Landing Page
In our first addons.mozilla.org test, we will measure how the featured Add-ons promotion affects bounce rate and Add-ons installed per visit.

SUMO Landing Page
The SUMO team wants to know whether we should reword article titles as questions. Our first SUMO test will do just that.

In addition to running these tests, we plan to test the download confirmation page and run 3 A/B tests on the Update page.

Many thanks go out to Laura, John Slater, Steven Garrity, Royal Order, and everyone else involved in this process! Next up, I’ll suggest a streamlined process for proposing and running tests.

Over the last few months, improving Firefox’s stability has become a top priority. And our early results are encouraging! Both our survey data and crash reporter data show a downward trend in crashes. We should be careful, however, not to read too much into this data.

Due to privacy concerns, we do not store user ids when collecting crash data. Accordingly, our crash data suffers from a number of limitations. For example, we can only determine the number of crashes per daily session, not per session length. As a result, the number of crashes per user will appear to rise if users browse more often per day. Changes to the crash reporter UI will similarly bias our data. A 5% increase in the reporter response rate will lead to a 5% increase in reported crashes.

Perhaps most importantly, the lack of a user id limits our ability to draw inferences about the distribution of our data. Why does this matter? If Firefox crashes are skewed, we may reduce overall crashes by 10%, but have 80% of users experience more crashes.

A quick look at the “Week in the Life of a Browser” study suggests that crashes are indeed highly skewed. By examining start-up events without corresponding shut-down events, Jono calculated the number of unexplained session interruptions per user. While there are other causes of session interruptions, such as a computer losing its power, we can reasonably assume that session interruptions serve as a (perhaps highly overstated) proxy for crashes.

Session interruptions per user does not take on the bell-curve shape of normally distributed data. Rather, it follows a power law distribution. 49% of users did not experience a single session interruption, while 70% experienced one or fewer. The mean number of session interruptions, however, was 1.4. If our crash data follows a similar distribution, the average crash per user metric tells us little about the experience of a typical Firefox user.

Anecdotal evidence supports this hypothesis. While we all know people who swear by Firefox’s stability, we also know people who complain of frequent failures. I, for one, haven’t experienced any crashes since upgrading to the 3.6 beta a few weeks ago.

With this in mind, I suggest we use Test Pilot to run a longitudinal study of true Firefox crashes. Because Test Pilot is opt-in and allows users to review their data before submitting it, we’re able to consider data at a more granular level. As with previous TP experiments, we will go to great lengths to respect the privacy of participants.

In addition to crash events and session length, I would like to collect data we can correlate with crashes. Firefox version, operating system, and Add-ons installed immediately come to mind.

Have suggestions for additional data that we should, or shouldn’t, collect? Please leave them in the comments.

The Mozilla community includes thousands of people in Haiti, and in our metrics, we can see the hole this disaster has left in our community.  The chart below shows Firefox usage in Haiti this week (it’s based on a once daily “ping” that we see from active users) and it’s broken down by hour (local time in Haiti).  This picture is not pretty and it suggests that much of the communications infrastructure within Haiti has been adversely affected.

Everyone in Haiti could use our thoughts and help, and we’d like to put out a personal plea to the Mozilla family to consider these members of our community and donate if you can.

(Thanks to Daniel Einspanjer for contributing to this post.)