Extending our Reach — Let’s Talk Gecko

August 2nd, 2011

To fulfill the Mozilla mission, Mozilla  needs offerings on new operating systems we find on phones, tablets and elsewhere.   These new operating systems and their ecosystems are quite different from the desktop operating systems we’ve been accustomed to.  They bring new challenges and new opportunities.  To meet these, Mozilla needs to do adapt our current product offerings and to do some new things as well.

As a starter, we need to make Firefox available for a host of  new devices.   We may make products based on the Mozilla platform that underlies Firefox, known as “Gecko,” that may not have the “look and feel” of a traditional browser.   I believe we should also develop new offerings in addition to Gecko-based products.   I’ll talk about the last in the next post; here I want to focus on the importance of Gecko-based products.

There are very, very, very real reasons for wanting Gecko to remain strong.  Reasons that have nothing to do with Mozilla, and everything to do with the future development of the Internet.  The prevalence of Gecko on the Internet is a big part of what allows Mozilla to make the Internet better.  This isn’t necessarily intuitive or immediately clear to the majority of people who use Firefox, so I’ll spend a minute on this.

As I noted in a previous post, the “browser” has a few different layers of software.  The engine or platform –“Gecko” for Mozilla, (Trident for Microsoft, differing versions of “webkit” for Apple and Google) is the part of the browser that interacts with web servers and translates the response to our PCs, phone and other devices.  It’s the part of the browser that negotiates the exchange of information in a machine-to-machine conversation.   (The “application” layer is the part that allows a human to interact with the content.  The “user-sovereignty core is the part of the browser that allows you to control what’s happening.)   Because so many people use Firefox and thus Gecko, the number of servers on the web that want to be able to talk to Gecko is very high.  And because of this Mozilla has been able to do two very important things:

  1. Increase interoperability dramatically.  Before Firefox, web applications wrote their code to work in Internet Explorer only.  Firefox is the reason web applications began to return to the use of identified, open-standards, created by a legitimate standards body and implementable by all browsers.   This is why you can use a number of browsers today and see most sites render correctly.  Firefox, and in particular the Gecko platform layer, has caused the web to be much more interoperable, and thus much more open to competition and innovation.
  2. Bring new capabilities to the web.  Again because Firefox / Gecko is so prevalent, we can make new things like video on the web realistic.  When we implement a new standard in Gecko, it reaches huge number of people through Firefox.   Application developers don’t want to implant new features until enough of their audience has software that can respond to it.  (In the past other browser vendors have periodically not implemented new standards, preferring that their own proprietary technologies outpace the web.)   These features include innovations such as video, our new initiative to develop web APIs for the capabilities (such as phone access) of new devices, and user sovereignty innovations such as Do Not Track.

No one, no one is focused on interoperability among all the giant ecosystems of the web the way Mozilla is.  Gecko is a very powerful tool for making the web both interoperable and capable.   The more places we can offer Gecko the more interoperability and user sovereignty we will be able to offer.

This means being creative.    It means thinking about what Firefox can do on these new devices.  It means looking at Firefox in a “chromeless” mode, where the entire Firefox application is on the device with a different user interface.  It means looking at new ways Gecko can be effective on these devices, such as the very early stage “Boot To Gecko” initiative.

Gecko is a powerful tool that we must continue to invest in.

21 comments for “Extending our Reach — Let’s Talk Gecko”

  1. 1

    Chris Hubick said on August 2nd, 2011 at 3:13 pm:

    The Firefox/Mozilla “platform” in a “chromeless” mode, interesting – you could call it something like “XULRunner” 😉

  2. 2

    Irakli said on August 3rd, 2011 at 1:22 am:

    What about improving gecko embedding story ? Most of the manufacturers go with webkit just because it’s so much easier to embed it!

  3. 3

    Regnard Raquedan said on August 3rd, 2011 at 2:06 am:

    Hi Mitchell!

    I think making things interoperable is a noble, but daunting task. It’s also not cheap, considering that interoperability is not something most companies are scrambling to make happen (for business reasons, I would think).

    I know Mozilla is a non-profit (yeah, I’ve been volunteering for the last 2 years), but what do you say when a some folks think interoperability is a strategic black hole?

  4. 4

    Robert Kaiser said on August 3rd, 2011 at 5:47 am:

    In that regard, we really need to think a lot about how we can change that Gecko is or is becoming only the third engine in terms of usage – behind not only Trident, but also WebKit.

    And we really need to find a story to not have everyone out there doing anything that embeds the web using WebKit as their engine of choice. We need to make Gecko on option, and a good one at that.

  5. 5

    mitchell said on August 3rd, 2011 at 7:54 am:

    Renard: without interoperability one has only the option of vertically integrated stacks; interoperability is one of the traits that make the web. Building a vertically integrated Mozilla stack to compete with those of the big commercial ones isn’t worth doing.

    Also, i’m not so sure it is a black hole. Mozilla is TINY compared to our competitors. We need the power of an open, distributed system.

    And thanks for your contributions

  6. 6

    Pingback from Mozilla Chairman Hints To New Range Of Products | ConceivablyTech

    […] deferred the explanation of this sentence to her next post, but outlined that Gecko is Mozilla’s way to […]

  7. 7

    Jeffrey said on August 3rd, 2011 at 9:27 am:

    Mitchell, couldn’t Mozilla also use Webkit to promote interoperability and new features?

  8. 8

    Skoua said on August 3rd, 2011 at 5:50 pm:

    That’s just my opinion but to me Gecko’s rendering is better than Webkit.

    It would be silly if Mozilla drops everything they created for years (and some others before that) and use something else.

    The company which should throw its rendering engine away and adopt Webkit (or Gecko) is Microsoft.

  9. 9

    mitchell said on August 3rd, 2011 at 8:56 pm:

    Jeffrey: We need the ability to move forward without asking Apple and / or Google for agreement. Trying to share the webkit repository wouldn’t allow this.

  10. 10

    Jeffrey said on August 3rd, 2011 at 10:24 pm:

    Thanks, Mitchell.

    That didn’t quite answer my question but gave me another. How would sharing the Webkit repository hinder Mozilla from moving forward before agreeing with Apple/Google? It doesn’t look like Apple and Google have to agree on anything before moving forward with their features or technologies.

  11. 11

    Paul Cooper said on August 4th, 2011 at 8:11 am:

    Only 3 or 4 years too late but would be good to finally have a gecko embedding API and have Mozilla market Gecko to developers as a standalone project.

  12. 12

    mitchell said on August 4th, 2011 at 10:34 am:

    Jeffrey: there’s a lot of interaction between engineers in the shared repository.

  13. 13

    Jeffrey said on August 4th, 2011 at 12:31 pm:

    Mitchell, that’s true of all open source projects (including Mozilla’s). It would be hard to develop any open source software without interaction between engineers in a shared repository. Yet the Chrome and Safari teams have a added several technologies external to Webkit that required no agreement with each other.

    Again, what features or technologies would Mozilla not be able to move forward with if they shared the Webkit repository?

  14. 14

    Regnard Raquedan said on August 4th, 2011 at 10:03 pm:

    Thanks for clarifying Mitchell. I got a better sense of how Mozilla will make itself relevant against the competition. 🙂

  15. 15

    Pingback from 451 CAOS Theory » 451 CAOS Links 2011.08.05

    […] Mitchell Baker explained the Mozilla Foundation’s Gecko […]

  16. 16

    Pingback from Links 8/8/2011: Many New Games, Reviews | Techrights

    […] Extending our Reach — Let’s Talk Gecko To fulfill the Mozilla mission, Mozilla needs offerings on new operating systems we find on phones, tablets and elsewhere. These new operating systems and their ecosystems are quite different from the desktop operating systems we’ve been accustomed to. They bring new challenges and new opportunities. To meet these, Mozilla needs to do adapt our current product offerings and to do some new things as well. […]

  17. 17

    Pingback from Mozilla Hacks Weekly, August 11th 2011 ✩ Mozilla Hacks – the Web developer blog

    […] the importance of Gecko, Mozilla’s rendering engine, when it comes to Mozilla’s strategy. Extending our reach – let’s talk Gecko. The post is followed by another one, Many Layers of User […]

  18. 18

    Benoit Jacob said on August 12th, 2011 at 5:48 am:

    @Jeffrey: Not all features added to Chrome and Safari can be added external to WebKit. Features inherent to the platform have to be added to the platform, or not at all. Examples include the HTML, CSS, SVG, WebGL, etc… implementations. In these case, the only way that Chrome or Safari could develop such features independently from each other would be to maintain local patches against WebKit, which has a high maintainance cost. Consequently, Chrome and Safari engineers usually don’t do that and really share mostly the same WebKit. Also, when you look at how things happen in practice, there are many areas that are developed mainly by one company and then just used by other companies, e.g. some parts of WebKit are developed virtually entirely by Google and then just used by Apple who just trusts Google to do the right thing.

    My point is that it’s very unclear that we share rendering engines with Google/Apple without losing sovereignty.

    As an example, the WebGL spec has a function to expose precise GPU identification information to Web content. In Gecko, we decided to NOT implement that and just identify the renderer as “Mozilla” without exposing any private information to Web content. Our reasons were to avoid introducing a new “User Agent string sage of fail” and to protect user privacy (some advertisers would like to know if you have a big GPU typical of hardcore gamers). By contrast, WebKit exposes full information (GPU identification, driver version…) to Web content. This is an example of how just trusting another company to do the right thing for us in the browser engine, would make us lose sovereignty without even noticing.

  19. 19

    Jeffrey said on August 12th, 2011 at 4:07 pm:

    Thanks Benoit Jacob.

    I think that answers my question. Although, I believe the idea that Google and Apple just trust each other is false. They both have to pass through code reviewers and abide by the contribution policies and the projects goals. But it’s clear from what you said that Mozilla has distinct goals for it’s rendering engine that aren’t apart of the Webkit project.

    Still, it makes me wonder if a fork of the Webkit project by Mozilla couldn’t add some goals and policies to remedy this. The other idea is do like others here are suggesting and turn Gecko into separate more general purpose rendering engine (independent from Mozilla Firefox development) like Webkit.

  20. 20

    asdad said on August 14th, 2011 at 1:10 pm:

  21. 21

    asdad said on August 14th, 2011 at 1:10 pm:

Skip past the sidebar