fidzu : Mozilla

I started as the Support Community Manager at Mozilla two weeks ago and I thought it would be a good idea to share my view of Mozilla and support, so you can see where my enthusiasm comes from

Firefox is used by around 350 million people all over the world. There aren't many commercial applications that can claim that and I don't know of any free and open source software that has a userbase even close to that. And what is even more amazing: Almost all of our user have chosen our product over another one. Almost all of them already had a browser on their system and still did download our software.

But even more amazing: We are competing with Apple, Google and Microsoft, the biggest IT companies in the world. Having even only one of them as a competitor is crazy, but we are competing with ALL of them and we don't have a real advertising budget. In fact our whole income is not even close to the marketing budget of even one of our competitors. And what is even more amazing: Not only are we able to compete with them, but we even do better than them. People are choosing us actively over Apple's pre-installed Safari and Microsoft's pre-installed Internet Explorer.

While this is all … well … amazing it also puts a lot of responsibility on us. A great mind once said: "With great power comes great responsibility". A quarter of the Internet population trusts us with their data (passwords, browsing history, bookmarks) and their browsing experience. They trust that we will make sure they will never ever lose their data and they trust that we'll make sure that their browser will just work. Always.

That's a lot of pressure coming from 350 million people. We work hard, everyday around the clock (benefit of having contributors in almost every time zone) to make sure we meet the expectations of our user. Still, nobody is perfect. In some cases we may have screwed up, after all we have 350 million users on just as many different computers with different operating systems. In other cases someone else may have screwed up and may affect the browsing experience of our users. In a perfect world that would never happen, users would know the manuals by heart and no software would ever be released with any bugs left in it. Well, the world is not perfect, users don't know all the tricks needed to get the software to do what they want and software, operating systems and applications do have bugs. This is our opportunity to shine. We can't create a perfect world nor can for example doctors, but like doctors we can help people and heal what is broken.

That is the power of support. We can give people aid in how to prevent problems and we can give them instructions what to do if something goes wrong. Sure we seldom engage in life and death matters, but neither do most dentist or optometrists. I still wouldn't want to live without them. There are even more parallels if you think about it: nobody want's to go to a doctor, but everybody is hoping for them to be available should they ever need them.

Unfortunately tech support has a bad reputation. Most organizations see support only as a cost center. But cost centers have to be held down, nobody will praise you for having doubled your expenses for a cost center. That is why people dread tech support and just hope to never have to deal with it. That is both, the giving end and the receiving end. Fortunately though Mozilla sees support as an important part of the project and one more way to be a pioneer for free and open source software. There are not many projects to take cues from on how to offer support for 350 million people, but that makes it all the more challenging. And since it is our goal to offer the best possible support experience in the world, the winners will be all users, not only ours.

12 Mar 2010 10:45am GMT

We've seen a huge spike in traffic to getpersonas.com due to our prompted update for Firefox 3.0 and 3.5 users to upgrade to 3.6. Some users may have seen a degradation in site speed and reliability during the past 12 hours.

Our amazing IT team has been hard at work keeping the site up and has fixed most of the performance issues. We also turned off search functionality temporarily to alleviate load. We'll turn it back on as soon as we can, thanks for your patience!

12 Mar 2010 9:55am GMT

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

Just a quick note to tell y'all that I have moved my Firefox-related posts off Planet Plone, so if you want to subscribe to everything I write about - not just Plone-related stuff - take a pick from the feeds offered at the main site.

12 Mar 2010 4:04am GMT

While most of the KompoZer 0.7.10 language packs have been upgraded to KompoZer 0.8, we've set up a Narro server to help localization teams work on new locales. The Finnish locale has been the first one to be fully translated, other locales are still in progress: Irish, Korean, Ukrainian, Brazilian, Swedish, Turkish, Bulgarian… and Slovenian.

The Slovenian localization has been done by Roman Bobnarič. The only untranslated strings were related to the css.properties file, and there hasn't been any progress on these strings for months. But yesterday we found out that these strings weren't translated for other official Gecko 1.8 applications either, so Cédric Corazza (l10n lead) and I had a little talk about that.

Cédric's opinion is simple: if any single string is untranslated, the locale isn't ready, period. He doesn't care if some losers working on an unknown project like Firefox don't have similar quality standards. :-)

However, this css.properties file has been fully translated for Gecko 1.9.2, so I've copied as many strings as possible from the new file. On the 89 untranslated strings, 73 could be updated and 16 couldn't be translated.

As these strings only show up in the JavaScript console to describe CSS errors, and since KompoZer's JavaScript console doesn't display CSS errors by default, Cédric finally agreed to use this file "as is" and leave 16 untranslated strings. He still insists that it'd be much better if a Slovenian contributor could finish the job.

Anyway, the result is that we've just published Slovenian builds of KompoZer for Windows, MacOSX and GNU/Linux on the download page - 20 languages are now supported by KompoZer! \o/

Note: there's little work to do to finish the following locales:

• Brazilian (pt-BR): ~70 strings
• Irish (ga-IE): ~180 strings
• Korean (ko): ~ 280 strings

Feel free to drop a message if you're willing to help on these locales. Of course, if you feel like contributing another translation, you're very welcome. :-)

Update: Matjaž Horvat has just submitted a patch to fix the 16 untranslated strings (and a little more…). Thanks! Cédric will sleep much better now. :-D

12 Mar 2010 3:57am GMT

One common way to reduce the load on a web server is to use gzip or deflate compression when serving to a supporting web browser. When Firefox requests an Ogg media, it advertises that it can handle a gzipped or deflated response; the HTTP request includes the Accept-Encoding: gzip,deflate header. But despite Firefox advertising that it supports gzip/deflate, you probably don't want your web server to gzip or deflate Ogg media. If you serve an Ogg media compressed, Firefox won't be able to seek in the media, or determine its duration. Since the video/audio data in Ogg files is already compressed, gzip/deflate won't actually save you much bandwidth anyway, so you probably want to disable compression when serving Ogg files.

I have added this tip to the Mozilla Developer Center article on configuring servers for Ogg media.

12 Mar 2010 2:31am GMT

I posted previously about colour conversion libraries. To replace the liboggplay conversion routines we decided to try the Chromium libraries.

Bug 551277 adds the Chromium code and integrates it with the new video layer painting code. The Chromium code uses a C fallback if MMX is not available but this is done at compile time. I modified it do runtime detection using Mozilla's SSE.h and moved the generic C routine from the Linux specific implementation to be used on all platforms that don't have MMX. Some other minor modifications were done (function name, namspacing).

I added an 'update.sh' script that can be used to update against the latest Chromium code. Given the path to the Chromium source it applies a patch for the changes I made.

Bug 551378 adds YCbCr 4:4:4 conversion (YV24). The Chromium code supported 4:2:0 and 4:2:2 (YV12 and YV16 respectively). Theora also allows 4:4:4 per spec. There aren't many 4:4:4 Theora videos out in the wild and the fix in this bug only adds support in the slower C implementation. I detect if the video is a 4:4:4 video and fallback to the C code.

At some point optimized MMX routines should be done for this. I've raised Bug 551844 for this. This would probably make a good first bug for anyone who wants something small and self contained to work on. It would be good to contribute this back to Chromium when done too.

Xiph has a test suite with example videos in the different formats.

12 Mar 2010 12:30am GMT

I'll be out of the office for a few hours tomorrow morning. After some severe discomfort/pain the other day, my doctor wants me to get my gall bladder checked out, so I'm going in early tomorrow for an ultrasound to see if I have gallstones.

Best case scenario: I have gallstones, and we schedule me to have my gall bladder removed.

If the ultrasound comes up negative, they'll be immediately taking me in for another test, this one involving injecting a radioactive tracer and following it through my system to see how my liver and gall bladder are functioning. This involves an injection (thereby triggering my intense aversion to needles) and then a lot of waiting around while they take periodic pictures of my insides.

If that test comes up clear, then the problem was something other than my gall bladder and I don't know what happens next.

If that test indicates a problem, I presume my gall bladder comes out then too. I'd obviously prefer that the first test be the one to determine that my gall bladder should be removed, since I don't particularly want to deal with the second test. Going through both, especially if both are negative, would kind of suck.

At any rate, this is a longwinded way of saying that I won't be around until later than usual tomorrow, although I'll certainly be tweeting and checking mail as holding patterns in the testing allow. If the ultrasound is positive, I'll probably be at my desk by noon or so Eastern. If it's negative, and I have to have the other test too, then it'll probably be early to mid-afternoon instead.

12 Mar 2010 12:09am GMT

These are excerpted from my notes each night while traveling through India on Mozilla work.

February 28, 2010

We're in Bangalore. I'm excited to have sethb and ragavan hang with me in my home town, meet some of my friends, and generally get some exposure to the city where my parents live. As far as work trips go, this one has been a rollicking good time so far. We got a chance to visit a Bollywood studio in Mumbai, actually had a celebrity sighting or two, and met some amazing people. But the Mozilla DevDay we are organizing in Bangalore is really the main part of our trip. We've "co-organized" the event with Mahiti, an open-source non-profit based in Bangalore, and the Centre for Internet Society. We bought plenty of schwag: t-shirts, wrist bands, posters, and even a few Firefox plushies. We're expecting over 200 people (at least!) at the National Institute of Advanced Studies campus, where the event is held.

sethb acts as MC, and gives us a glimpse into Firefox.next. We've also got Lucian Teo and John Britton joining us to talk about Mozilla Drumbeat and Peer to Peer University. I give a demo-driven overview of the web platform's promise similar to the one I gave at GNUnify in Pune, but this time, there are plenty of questions, and a 45 minute session runs to about an hour and half. We've also got Mahiti's CTO, Sreekanth Rameshiah talking about Mahiti's projects, and the Centre of Internet Society's Pranesh Prakash talking about software patents, and the relevance of these to video on the web. ragavan runs a session on Mozilla Labs, once again prompting great questions. Each session is interactive, with lots of questions, even though the delicious lunch organized by the CIS folks introduces a kind of postprandial stupor.

Vineel Reddy, one of our campus reps and regional leaders, then shares a little bit about what it's like to be part of the Mozilla Community. Vineel's been interviewed by the New York Times for the slick video he produced likening Firefox to a sports car. That video, made on a shoe string budget, went viral very rapidly. Marketing, typically a corporate function in most "classic" companies, is often a community outreach endeavor for our project, with volunteers expressing their passion for participation in creative ways. Vineel's story is inspirational, and he gets a lot of follow-up questions when folks approach him after his talk.

In the afternoon, I do something a bit scary. I run a "hack" session with live coding on screen. I think my example is simple enough: I solicit a camera from the audience (but end up using my Nano) and shoot some video of the MozDevDay folks applauding, which I then embed in a web page (with the <video> element and some JS, of course). It works, but it's not smooth sailing. If you tempt fate, you'll encounter the proverbial obstacle - Firefogg's transcoded OGV file has to be renamed with a *.ogg extension to work. It's not quite a bug I can diagnose, since *.ogv files do appear to work in general. Maybe it's a Firefogg thing.

I could give you my own breakdown of MozDevDay in Bangalore, but what others say about the event is far more interesting:

• Lucian Teo on MozDevDay
• Ragunath Jawahar on the experience
• Manish's breakdown of things
• And thoughts from a self-professed Chrome user in India

We may not have a dedicated office in India (yet), unlike other browser companies, but we do have a vibrant community of volunteers. They showed up in numbers to our Bangalore event, and I'm absolutely thrilled. We can't succeed in India without them.

11 Mar 2010 11:11pm GMT

In the past 50 days, Firefox 3.6 has been downloaded over 100,000,000 times by people looking to improve their web experience, and install the world's best web browser. Mozilla believes that the user's choice of web browser matters, and is extremely proud of how many people have chosen to use Firefox.

Starting today, users running older versions of Firefox will be offered the choice of upgrading to Firefox 3.6. We're presenting this upgrade offer for our users who may not realize that a new version is available:

As always, users will be able to choose between:

• deferring the decision for 24 hours ("Ask Later"),
• declining the offer ("No Thanks"), or
• accepting the free upgrade ("Get the New Version").

The offer screen will only appear after 60 seconds of keyboard inactivity to ensure we don't get in the way of anyone's activities. If a user declines the offer and later regrets that choice, they'll be able to get it again simply by selecting "Check for Updates" from the "Help" menu.

Firefox 3.6 has already been chosen over 100,000,000 times by users, and we're proud to offer it to the remaining Firefox user base. It's fast, stable, compatible with over 90% of the thousands of Firefox Add-ons, and contains new features such as lightweight themes and plugin version checking.

11 Mar 2010 10:32pm GMT

Background:
As we get closer to having unittests running on windows mobile, I am starting to wonder how long it will take to complete a test run. Just like maemo with the n810's we will be running the tests in parallel, but can we see full build + test + results in < 8 hours for a nightly?

For desktop builds, we have an enormous amount of building and testing that we do. This means we would be running tests for about 512 checkins/month (just less than 1/hour) and double that if we wanted to include the try server.

Proposal:
What I propose doing is running a small set of unittests on each checkin, such that we get simple coverage on each build and it runs fast enough so we have results in the same time window as our other test data comes in for desktop tests. Right now when you check into m-c or 1.9.2 tests are only run on desktop builds, this would run tests on windows mobile as well.

The big question is what tests to run. Here are a couple ideas:

1. Run a small smoketest for each test suite (reftest, mochitest, xpcshell) which covers different areas, but not as in depth. Save the full test for the nightlies
2. Iterate through a series of chunks (say 30 chunks for mochitest; desktop builds split it 5 ways) and for each checkin just run a single chunk. After the course of 2 days we will have done a full cycle of little chunks.

Personally I like the second option best, but really I am trying to think out of the box for ways to reduce regression windows while getting feedback on a per checkin basis. What do you think?

11 Mar 2010 10:12pm GMT

That's right, we've announced our second mobile add-on challenge, starting today, March 11 and ending Monday, April 12.

Add-on developers are challenged to develop a compatible Firefox mobile add-on that shows innovation and considers the mobile context (small screen size, touch screen, out and about, etc.)

At the end of the Challenge period, our panel of judges (consisting of members from the Mobile and Add-ons teams) will select ten winners who will receive a new Nokia N900 in addition to other great mobile merchandise!

The last challenge resulted in many fantastic add-ons. Check out our previous winners' award-winning add-ons that have been recognized by press around the globe. Despite these awesome innovations, there is much more room to help enhance the look, feel and functionality of Firefox on mobile devices. Here are some themes the Mozilla Mobile team finds especially interesting:

• Using device APIs: js-ctypes (Fennec 1.0) might be used to hook into the device (addressbook or camera) and add functionality to a Web app by making a pagemod (jetpack- or greasemonkey-like add-on)
  Check out these helpful resources around js-cytypes:
  ctypes on Mobile Developer Center
  blog post using GStreamer js-ctypes
  
• Photo, media, social and sharing tools: Create a social aggregator for quickly viewing streams from Twitter, Facebook, etc; Create a tool for sharing images, links and text
• Saving files and Session Restore: Save as PDF, Save Image, Remember last open tabs, etc.

So what are you waiting for? Develop an add-on for Firefox for a chance to win a new phone, and most importantly, see your innovation used by people around the world on multiple platforms and devices! See the complete contest details and rules here.

Many thanks to Forum Nokia, Nokia's Developer portal for supporting this challenge!

11 Mar 2010 9:45pm GMT

Wasn't the whole ballot thing about preserving the users choice? Then wtf is this:

Procedure to reproduce:

1. choose to install your prefered browser, but not IE (actually, my prefered browser, SeaMonkey, is not in the list, even when it is the 6th most popular desktop browser in Europe... That's a big fail too.)
2. close the ballot screen by clicking on "Choose later (Später auswählen)", because you couldn't find a "Close" button
3. install the downloaded browser and set it as default
4. restart your system
5. see the ballot screen asking you to set IE as the default browser

Is it just me, or does this look like a violation of what Microsoft has signed in Brussels?

11 Mar 2010 7:50pm GMT

Dietrich blogged a "wake up and smell the startup" executive overview of startup issues caused by our extension practices. This post is a "numbers" followup. For this experiment I installed a brand-spankin-new copy of Linux Firefox 3.6. Firefox is installed on a 7200 hard drive, the rest of my system lives on an SSD. The CPU is core2duo, keep in mind these numbers will be significantly worse for people running on netbooks and other common hardware. The numbers vary +/- 150ms, but the general picture is pretty clear.

Results

I just doubled cold startup time for Firefox by merely adding 4 extensions. It takes weeks or even months of developer time to shave off every 100ms off Firefox startup, but mere seconds to undo any of those gains by installing extensions. These are just the top-4 extensions in the list (presumably they are higher quality too), I'm sure there are lots of other extensions with more drastic performance hits.

Dietrich's post details some of the remedies that should reduce the startup cost of extensions. For the inquisitive minds: I used SystemTap to produce a report of files read by Firefox on startup ordered by their startup cost.

Update:
Dietrich asked me to summarize warm startup too:

• Without extensions: 550ms
• With above Extensions: 1800ms

Note that this is a developer blog, so by "remedies" I meant "things developers can do to". There is little normal users can do short of complaining to the extension authors.

This post isn't meant to shame specific extension authors into speeding up their extensions. The aim is to show that a measurable percentage of startup is due to extensions and that we need to:

1. Educate extension developers about it
2. Provide better tools to measure slowdowns caused by extensions
3. Make sure that the Firefox side of extension handling is sufficiently efficient

11 Mar 2010 7:20pm GMT

Editor's note: On Mar 11, Mozilla announced over 100,000,000 downloads of Firefox 3.6 to date. Firefox users on prior versions will be offered an upgrade to Firefox 3.6. For more details, check out Mike Beltzner's Dev News announcement, reposted below.

11 Mar 2010 6:40pm GMT

What it does:

• Adds a "-couch-json" option to bsmedberg's pymake that takes a URL that crams the state of (global, non-rule associated) variables into a couch document for each makefile context executed. Variables are grouped by general origin as well as specific Makefile origin where relevant. The code as it stands only tells you about make variables that were accessed because this cuts down on things you (I) don't care about. (For example, if FOO and BAR are defined but only FOO is ever expanded, then only FOO goes in the couch document.)

I think there's a fair bit of potential in this (pushing "make -p" style data/make output into couch), at least in situations where there's no escaping make, you don't already have usable/appropriate tooling, and python/CouchDB/JSON is one of your religions.

I'm hoping to avoid touching the mozilla build system in any meaningful fashion from here on out, so I am unlikely to work on this much more, but it could be useful to others, hence this post. The repo is here, check out the "understand" (p)branch. (The changes are not suitable for upstreaming as things stand.)

11 Mar 2010 6:26pm GMT

Your online identity, which is key to enabling a personalized Web experience, is not simply a single atom of data. It is a dense cluster of your accounts (e.g. e-mail, banking, shopping, etc.), relationships and other personal information, spread across the Web and throughout all of your personal computing devices.

Your Web browser, as your most trusted relationship in your life online, has nearly perfect knowledge of everything you do on the Web. We envision a world where your browser will play an even more active and critical role in helping you control and shape your online experience.

To realize this vision, we need to increase the browser's understanding of your online identity and provide a platform for building new capabilities that securely take advantage of this rich, dynamic set of data that represents the digital "you."

And so, today we are announcing an initiative as part of the Mozilla Labs Concept Series to explore these and other new concepts for online identity in the browser.

Ideas, Use Cases and Open Questions
Here are some of the initial ideas, use cases and open questions to help get things started.

• As you connect with new sites and people online, how can your browser help you manage all of your account information?
• How can your browser help when you discover something cool on the Web that you want to share with your friends?
• What role can your browser play in helping you manage your Web contacts and relationships?
• What can your browser do to enable you to securely share data with websites and third-parties in return for context-rich Web experiences?
• How can your browser help you manage and stay informed about how and where your data and data about you flows on the Web?

Guiding Principles
We believe any solution that helps people take control and manage their online identity should:

• ensure that it is easy for people to set up their own services (as needed) with freely available open standards-based tools
• provide users with the ability to fully control and customize their online experience, including whether and how their data should be shared with their family, their friends, and third-parties
• respect individual privacy (e.g. client-side encryption by default with the ability to delegate access rights)
• leverage existing open standards and propose new ones as needed

Initial Concepts and Prototypes
Over the next few weeks, you will see a wide range of activities as we begin a focused exploration through the Mozilla Labs Concept Series and host discussions with the wider Internet community about your online identity. We hope that you'll add your voice to the discussion.

To kick things off, we will be releasing a series of initial concepts and prototypes to provide thought, facilitate discussion, and inspire future design directions for Firefox, the Mozilla project, and the Web as a whole.

How to Get Involved

• Read more about and explore the initial concepts and prototypes for Online Identity
• Learn more about the Mozilla Labs Weave project
• Discuss, debate and add to the conversation around online identity in the Online Identity Concepts discussion group
• Join us in #labs on irc.mozilla.org.

- Ragavan Srinivasan on behalf of the Mozilla Labs team

11 Mar 2010 6:25pm GMT