Mozilla and the Future

I am delighted that Brendan Eich has been named the new CEO of the Mozilla Corporation.

At this time of transition, I would like to encourage Mozilla community members to focus on, and to blog about, the future they’d like to see for the project. I’d love to read where others think we should be going, and I hope Brendan would too.

Here are my thoughts:


  • We should make sure that our requirements on Firefox OS carriers and OEMs for openness, transparency and Mozilla-ness are stringent enough that least a few say “No, we can’t do that; we’ll go elsewhere”. If everyone agrees to your terms, you aren’t asking for enough.
  • We should have a community conversation about what those requirements should be. (Some of what I think is outlined by implication in my recent post Mozilla and Proprietary Software.) To that end, I’m delighted that today there’s a brown bag on the Firefox OS Brand Requirements, which is the document which defines them. (It’s not currently clear who can come to this brown bag; I’m trying to get clarity.)
  • We should get down to a price point for our lowest-end phone – say $25 – and then ride Moore’s Law up the hardware spec scale at that price point. That is to say, at some point we should stop trying to make Gecko smaller and focus on improving the capabilities without growing it faster than the hardware is growing at that price point. Let’s not bet against Moore’s Law.
  • We shouldn’t try and compete at the high end, but we do need to move into the mid market, because that’s where there’s both global volume and money. (At the low end there’s volume but little money, and at the high end there’s money but less volume.) If we can’t make our ecosystem pay for developers and operators, it won’t grow.


  • Brendan has talked about differentiating Firefox in the “trust” area. We should ship Collusion as part of Firefox for desktop, with surrounding explanation of what it means. We should build and ship Tor on Firefox OS (and find a way to extend the Tor network while doing so).
  • The average network connection of the average customer is getting worse, because more people are coming online in places where the networks suck – both in bandwidth and latency. We need to make that less painful. HTTP/2 is one way; perhaps there are others, in collaboration with operators and sites. And our offline app support needs to be awesome.
  • We’d probably need a consensus to do it, but we should try and build one, and make some new web features HTTPS-only.

Governance and Community

  • We need to figure out how our project should be governed, and how those governance structures mesh with the org chart of the Mozilla Corporation. Having clear community governance is vital if we want to grow the community and allow non-employees to take on positions of responsibility. You can’t take a position which doesn’t exist.
  • Our community governance structures need to cover all that we do, not just a portion as now, and they probably need to change to meet the needs of the Mozilla of 2014.
  • We need to help our new mobile partners live in our world and become fully-fledged participants and contributors. If we end up just being an upstream code source, that’s a loss for us.

Mozilla and Proprietary Software

Mozilla is both a principled organization and a pragmatic one.

Mozilla products run on proprietary operating systems, and on proprietary hardware. We are in the mobile OS business, and no-one, not even the mighty Google, has yet been able to make a 100% open source phone available in commercial quantities. So proprietary software is part of Mozilla’s life. But I think most people in our community would be rightly upset if Mozilla decided, for example, to take advantage of the provision in the MPL which would allow us to ship proprietary builds of Firefox on the desktop.

So, the question arises: where’s the line? Where in the big picture is it OK for proprietary software to be, and where is it not OK?

“You don’t have to make a case for open. You have to make a case for not open.” — Johnathan Nightingale

Over time, this question has been arising in a number of different contexts. And I think the answers we might give at the Mozilla project would be different to those you might hear from the FSF, or the Apache project, or the Android project, to name but three points on a wide spectrum of opinion. So I think it would be a productive conversation to try and work out some principles in this area – or, at least, to gauge the range of opinion. As johnath says, if we are using or distributing closed software, we need to make an active case for why we are doing it.

This post is therefore a discussion starter, and outlines where I currently think the line is – i.e. where a reasonable case can be made for closed, and where it cannot. It could be in the future, a case can be made for additions to, removals from or modifications of this list. But having a defined list at least helps to make it more clear what is a new situation where a case needs to be made, what is another example of something we’ve done before.

Note that this post represents my opinion only, and is not official Mozilla policy. Although it speaks of things that currently are, as well as things that currently are not, for ease of reading, I will write directly rather than using conditional language (i.e. “will” rather than “should”).


  1. The basic rule is that software written by Mozilla will be open source. Mozilla is a public benefit organization; we do not use money given to us to write proprietary software.

    Rationale: Manifesto Principle 7.

  2. Mozilla may distribute proprietary software written by others with its own software under the following circumstances:
    1. If it’s a missing important piece of functionality provided by an OS vendor for a proprietary operating system on which our software runs;
    2. If the software is required to make use of the hardware on which the product runs, and there is no open source alternative driver of sufficient quality.

    Example of A): the Direct3D DLL, included under the Binary Components policy. Example of B): hardware drivers for Firefox OS.

    These situations are seen as sub-optimal and we look for opportunities to eliminate them, as opportunity and market power permit. They are not seen as precedent-setting. This is a negotiating point in discussions with hardware manufacturers, particularly for reference devices.

    In the past, we shipped the “Talkback” crash-reporting software, which did not fall under either of these exceptions. We now use the open source Breakpad. This replacement took seven long years to arrive. Now that Talkback is gone, we should not go back there.

    Rationale: without such exceptions, we can’t ship competitive products (or, in the case of B, any products at all). But we need to define them tightly.

  3. Mozilla’s products will execute proprietary code in web content.

    Example: most JavaScript on the web today.

    Rationale: without this, our products would effectively not browse the web at all.

  4. Partners

  5. Mozilla may permit its partners to distribute proprietary software in a product using a Mozilla brand under the circumstances above. Mozilla’s partners may also ship proprietary apps in their versions of Firefox OS. Such apps must be uninstallable. Additions to the platform not falling under one of the exceptions above must be open source.

    Rationale: same as above, plus requiring that all default partner apps be free software means many popular apps could not be bundled, making our offering much less compelling. If we allow users to install proprietary apps, there is not significant additional harm in bundling (uninstallable) ones. Requiring arbitrary platform additions to be open source is necessary to allow users to build updated versions of the software for their phones. (Binary driver blobs use a known API and, while it’s sub-optimal, can be copied from official builds into user ones.)

  6. Mozilla will only allow Mozilla brands to be used for software on phones which are bootloader-unlockable.

    Rationale: Mozilla stands up for user freedom, including the freedom to hack one’s phone, and update the OS even when the vendor has ceased support.

  7. Software Added Later

  8. Mozilla’s products may sometimes automatically download and install deterministically-built binary builds of other open source software where we would prefer not to distribute it ourselves, e.g. for patent license reasons. However, there may be additional requirements we would want to be met before we solved a problem using this solution.

    Example: Cisco’s H.264 binary builds made from OpenH264. (Note: the exact user experience in this case has not yet been determined. I am just saying that I think it would be OK if Firefox downloaded and installed this software automatically.)

    Rationale: Software patents suck. Because Cisco have made H.264 free-as-in-price at the point of use for everyone, we managed to get a draw in this particular round of the codec wars. (The other options were much worse.) But fighting patents is done at the standards and industry level, not at the “make every user click a button” level. If the source is open and the binaries are deterministically built, then users are using binaries of free software which is bit-for-bit identical to that we could build for them ourselves, and so requiring a user confirmation here gains us nothing.

  9. Mozilla will allow proprietary software in the app stores and addons stores that it runs. Mozilla will make sure the license terms for software are clearly marked, and are searchable as a metadata field.

    Example: Firefox OS Marketplace, (Unfortunately, license metadata is not currently collected or available for searching.)

    Rationale: some people, including members of our community and vocal Mozilla supporters, wish to avoid using proprietary software; we should help them make choices in line with their ethics.

  10. Mozilla’s products may give the user the UI option of downloading, installing and running binary builds of proprietary software (e.g. an addon or plugin) but will not get to the point of executing such software without getting explicit or implicit user consent somewhere along the way. “Implicit consent” means that the user has taken some action (e.g. installing the Flash plugin themselves) which was not mediated by Firefox but which we know must have happened.

    Example: Mozilla allows users to download proprietary Firefox add-ons through the Add-On Manager UI. The Plugin Finder Service will point users at downloads of proprietary plugins such as Flash. But all require at least one explicit confirming click to install.

    Rationale: some people, including members of our community and vocal Mozilla supporters, wish to avoid executing proprietary software; we should not sneakily run it on their systems. However, even offering it is enough for Firefox to not be in the FSF’s directory of free software. :-|

  11. Network Services

  12. Mozilla prefers to use open source software for end-user network services it builds into its products. However, we are willing to partner with companies who use proprietary software and/or data. Such proprietary services must be able to be disabled by the user, and the API endpoint must be configurable by the user or 3rd party software such as an extension (e.g. an about:config setting in Desktop Firefox).

    Examples: Safe Browsing, geolocation.

    Rationale: Mozilla is starting efforts in geolocation, speech recognition and translation to either replace or avoid depending on proprietary services in these areas. But building e.g. a replacement for Google Safe Browsing, which protects many, many Firefox users from malware and phishing every day, would be a mammoth undertaking. And removing it would put our users at significant risk. Endpoint URL configurability allows people to reverse-engineer service APIs and implement alternatives which Firefox can then easily use.

  13. Development

  14. Mozilla’s products will run on proprietary operating systems, and therefore may require proprietary software, such as a compiler or SDK, as part of the build process for such systems. Mozilla’s products will not require proprietary tools to build on free operating systems.

    Example: Release builds of Firefox on Windows are built using Microsoft Visual Studio, and most developers on Windows use it for their builds too.

    Rationale: if one is using a proprietary OS, there seems no additional harm in using proprietary build tools.

  15. Mozilla strongly prefers to use open source software for network services it stands up for use by the Mozilla developer community, but may use proprietary software if no open source software of equivalent functionality is available. In such cases, Mozilla provides some resources (money or people) to help rectify that situation.

    Example: Mozilla uses Vidyo, and so Mozillians who want to use it have to use the proprietary Vidyo client, or Flash. But we are developing WebRTC in the browser, and hope that thereby solutions will emerge where people can participate in multi-party video using only open source software. We are also trying to get the SIP gateway working (that bug is restricted to the ‘infra’ group so you may not be able to see it) so people can video-call in using free software.

    Rationale: we should not compromise our effectiveness by using significantly sub-standard tools; but as a member of the wider open source community and as a public benefit organization, we have a responsibility to grow the commons in areas where we have an interest.

  16. Mozilla community members are free to use proprietary desktop software if they wish. Mozilla may therefore pay for licenses for particular bits of proprietary software for the use of Mozilla employees, contractors or interns. Mozilla will not implement systems which require non-employees to use proprietary desktop software to be part of the community.

    Example: Windows, Office, internal payroll or HR systems. (Vidyo doesn’t quite break that last rule, as someone can still dial in to any meeting by phone.)

    Rationale: there are no effective substitutes for some of this software. However, we should not lock free software advocates out of full participation in our community.

The Necessity of Management

Getting people to agree on what a project needs, and to work together to achieve it, requires more than just a genial atmosphere and a lack of obvious dysfunction. It requires someone, or several someones, consciously managing all the people involved. Managing volunteers may not be a technical craft in the same sense as computer programming, but it is a craft in the sense that it can be improved through study and practice.

– Karl Fogel, Producing Open Source Software

It Just Keeps Working

One of the great things about desktop software, and mobile apps, is that once you have some software, if you don’t do anything it generally just keeps working. Now there are exceptions to this – if you live in the iOS gilded cage, your cojones and your apps still belong to Apple, and they can yank them any time they like. But they don’t do that all that often. And if your app requires network interactions, perhaps the thing it interacts with will change, requiring an app update. But generally speaking, if I get a text editor app, it’ll still be able to edit text until my phone dies or I delete it. And that gives me a great sense of confidence and stability in my use of my technology.

The same is not true of web pages. They can go away at any time. As can cached copies, copies, or whatever.

So, as we build Firefox OS, and the line between apps and websites gets blurred, let’s make sure we don’t lose this feature. Once the user’s mental model of what’s going on suggests to them that an app is “theirs” (and that doesn’t just mean “they paid for it”), then we need to make sure that it just keeps working. Even if the original source goes offline.

My Travel Tips

There are internal discussions going on among Mozilla employees about how best to save money when travelling. Inspired by that, here are my travel tips. Some of them are money savers, some are just, well, good advice. Chris Heilmann has given us his; most are good, although I’m no fan of layovers.

Packing List

I have a “packing-list.txt” file on my computer, organized by “context” (Clothes, Tech, Abroad, Cold, Hot, etc). Before each trip, I print a copy 2-up on a side of A4, then go through and cross out the things I’m not planning to take. I then go and gather up what’s left. This requires so little “er, do I want to take this?” brainpower that I can normally pack for any trip in about 20 minutes, and it’s extremely rare that I forget anything important. If I notice myself writing the same thing on more than a couple of times, it gets added to the file. If I notice myself crossing something off almost every time, it gets removed.


Although I’ve had one less-than-stellar experience, I’ve also made 2 good friends through Airbnb. There are Airbnbs in walking distance of many of our offices (they are a bit thin on the ground in Mountain View). And you normally get nicer conditions at a cheaper price than a hotel.


  • Never leave you passport anywhere except in your bag or, while using it, your pocket. This particularly applies to on tables, in plane seatback pockets, etc.
  • Why rush onto the plane? You end up queueing for ages, and the worst that can happen if you’re last on is that there’s no room for your bag and the stewardess has to put it somewhere else and give it back to you when you get off.
  • While parked at the gate in your home country, use the Internet on your phone to check out reviews of the available films. Gotta be quick…
  • Online checkin and no hold luggage means that you can arrive at the airport as little as 1h 15m in advance and still be very relaxed going to the gate.
  • Buy a Thinkpad X-series and an extended battery. The 9-hour battery life is great for Europe-to-West-Coast.
  • If travelling for only a few days, don’t attempt to cross all the timezones. Get up early/late and go to bed early/late instead. Just because it’s 3am local time doesn’t mean you can’t be doing useful work, or calling your wife, or preparing a Bible study, or something else productive.
  • Arriving at Brussels on Eurostar, your ticket is valid to go to any station in the city. So don’t get a taxi, just go upstairs and head for the Central Station, 7 minutes away.

How Mozilla Is Different

We’re replacing Firefox Sync with something different… and not only did we publish the technical documentation of how the crypto works, but it contains a careful and clear analysis of the security improvements and weaknesses compared with the old one. We don’t just tell you “Trust us, it’s better, it’s the new shiny.”

The bottom line is in order get easier account recovery and device addition, and to allow the system to work on slower devices, e.g. Firefox OS phones, your security has become dependent on the strength of your chosen Sync password when it was not before. (Before, Sync didn’t even have passwords.) This post is not about whether that’s the right trade-off or not – I just want to say that it’s awesome that we are open and up front about it.

Why Is Email So Hard?

I want programs on my machine to be able to send mail. Surely that’s not too much to ask. If I wanted it to Tweet, I’m sure there are a dozen libraries out there I could use. But sending mail… that requires the horror that is sendmail.rc or trying to configure Postfix or Exim, which is the approximate equivalent of using an ocean-going liner to cross a small creek.

Or does it? I just discovered “ssmtp“, which is supposed to be a program which does the very simple thing of accepting mail and passing it on to a configured mailserver – GMail, your own, or whatever. All you have to do is tell it your server name, username and password. Simple, right?

Turns out, not so simple. I kept getting auth failures, whichever server I tried. ssmtp’s verbose mode seemed to show no password being shown, but that’s because it doesn’t show passwords in logs. Once I finally configured a mailserver on port 25 (so no encryption) and broke out Wireshark, it turned out that ssmtp was sending a blank password. But why?

The config file doesn’t have sample entries for the “username” and “password” parameters, so I typed them in. Turns out, the config key for the password is “AuthPass”, not “AuthPassword”. And ssmtp doesn’t think to even say “Hey, you are trying to log in without a password. No-one does that. Are you sure you’re not on crack?” It happily sends off a blank password, because that’s clearly what you wanted if you left the password out entirely.

<sigh> There’s 45 minutes of my life I won’t get back.

Uses of the Public Suffix List

For several years, Mozilla has maintained the Public Suffix List, a “map” of responsibilities within the DNS, as a service to the greater Internet community. We originally created it for browsers, but it has seen wider use in a surprising variety of places. There is now renewed interest in replacing it with something DNS-based and more robust. As a precursor to that work, I’m collecting a list of all the things the PSL is used for.

If you are a Mozilla hacker and know of somewhere we are using the PSL that isn’t listed, or if you know of uses of the PSL outside Mozilla, please add them.

BzAPI App Author?

Have you written an app or system of some sort which uses the Bugzilla REST API (BzAPI)? If so, please do as the docs have long recommended and make sure you are a member of the discussion forum. There are several upcoming announcements in the next few weeks and months which you will need to be aware of, and that is where they are going to be posted.

Living Flash Free: Part 2

I’m trying to live Flash-free on my desktop. In Part 1, I got YouTube and Vimeo working (although the addon I use to make YouTube work seems to make the player bigger than the video sometimes).

The Flash-based Vidyo doesn’t work, of course. When using Vidyo (which Mozilla uses quite a lot), I need to use the Vidyo client. This is not free software, so I’m trying to avoid installing that on my main machine too. Instead, at home, I have a tablet which I use almost exclusively for Vidyo. That’s fine (and also allows me to see and type on my main machine at the same time), but it doesn’t work when I’m on the road, as I was quite a bit in December. So I had to scramble to find some other machine or room with Vidyo support.

I can’t watch Air Mozilla streams live very easily. There are rumours of changes in the works, but for now AirMo live streaming requires Flash. And Flash seems not to be working in Firefox or the stock browser on my tablet, although it is installed. The only workaround is (ironically) if it’s also connected to a Vidyo room, when I can join that. But because Vidyo have not yet implemented our long-open feature request to allow rooms to have participants muted automatically when joining, doing that leads to everyone hearing a “ping!” and getting a brief flash of my face. Which is not ideal.

Some things, I can watch later – AirMo’s archived streaming uses HTML5. But if I want to interact with the presenter or the audience, that’s not an option.

Video doesn’t work on the BBC either, and I’ve not figured out how to make that work yet. The mobile site does UA sniffing to keep out desktop browsers; if you spoof, you can see it, but video won’t play (perhaps it’s using some mobile-OS-specific mechanism). Any ideas welcome.

about:credits – Name Order and Non-ASCII Characters

The Mozilla project credits those who have “made a significant investment of time, with useful results, into Mozilla project-governed activities”, and who apply for inclusion, in the about:credits list, which appears in every browser product Mozilla has ever made.

Historically, the system of scripts which I used to manage the list were not as internationalized as they could be. In particular, it did not support sorting on a name component other than the last-written one. Also, although I don’t know of technical reasons why this is so, many non-English names are present without the appropriate accents on the letters.

But I’m pleased to say that any issues here are now fixed. So, if your name is not rendered or sorted as you would like on about:credits (either due to name component ordering or lack of accents) please email me and I will correct it for you.

How To Run a Productive Community Discussion

I ran a session at the Mozilla Summit with the (wordy) title of “Building a Framework to Enable Mozilla to Effectively Communicate Across Our Community”.

The outcome of the Brussels session, cleaned up, was this document which explains how to run a useful and productive community consultation and discussion. So if you propose something to a colleague, they say “you should ask the community about that”, and a cold sweat breaks out on your forehead, this is the document for you.

Many thanks for Zach Beauvais for doing the initial wrangling of the session notes. Feedback on the current document is very welcome.