Archive for August, 2011

Recently Mozilla implemented a rapid release process, where we release a version of Firefox every 6 weeks. This has involved changing a number of our processes.  It’s also raised some new issues. For example, some enterprises find the idea of rapid browser change to be disconcerting at best and potentially unmanageable at worst.  Add-on compatibility is another.  I acknowledge these issues are complex and difficult.   There is work to be done to make the rapid release process smoother and hopefully more useful to more of our userbase.   I’d like to describe why I believe the rapid release process is important enough to pursue despite these difficulties.

Before Mozilla instituted the rapid release process, we would sometimes have new capabilities ready for nearly a year before we could deliver them to people.  Web developers would have to wait that year to be able to make their applications better.

A browser is the delivery vehicle for the Internet.   And the Internet moves very, very  quickly.    Philosophically, I do not believe a product that moves at the speed of  traditional desktop software can be effective at enabling an Internet where things happen in real time.    If we want the browser to be the interface for the Internet, we need to make it more like the Internet.  That means delivering capabilities when they are ready.  That means a rapid release process. If we don’t do something like this the browser becomes a limiting factor in what the Internet can do.

Sometimes we can address this problem without a new release of code.   For example,  if one goes to the Firefox Menu Item for “Add-ons” the content one sees is a web page.  This part of the browser enjoys all the benefits of the web.  It can be managed in the ways people have come to expect of a web experience.  The rapid release process is another technique we’ve adopted to allow the browser to deliver new capabilities quickly.

As my colleague Brendan is fond of saying, “There is no free lunch.”    This means we need to listen carefully to those who are experiencing difficulties.  We need to be creative and try to find practical ways of alleviating these difficulties if we can.   This is true for the enterprise use case, and it’s true for the add-on experience.  I know that’s not a perfect answer, and it’s not a promise that we can meet everyone’s needs perfectly.  Despite this, I believe the rapid release process is the right direction.

Recently I’ve been writing a series of blog posts about what I think Mozilla needs to do to remain relevant as Internet life changes. Testing the ideas in these posts through a community – wide discussion is critical.    This is because Mozilla doesn’t succeed based on the ideas of any one person. We succeed when an idea gains traction among a critical mass of Mozilla leaders. We succeed when those leaders take an idea and make things happen; when Mozilla contributors become a powerful force for bringing the Mozilla mission to life in new ways.

My post on Mozilla’s future are intended to start a discussion and chart a path for Mozilla.   Over the next few months, with Mary Colvig’s help I plan to  encourage this discussion by doing the following:

• Start with a series of online conversations with groups of key Mozilla contributors.    The current plan is to start with groups based on time-zone, then move to more diverse groups.
• Ask those contributors to take the ideas to their communities, giving more people the background to participate in subsequent discussions
• Continue the discussion at Mozilla meetups
• Have public online discussions
• Come to a shared understanding of where we agree and disagree
• Come to a shared understanding of Mozilla’s direction and goals for this era.

If you’ve got thoughts, questions, or suggestions, please feel free to leave comments here or drop into #mozillians.

We won’t reach perfect agreement. There will always be cases where some of us will disagree with some of the activities we undertake. Requiring perfect agreement will lead to paralysis. We need excitement, creativity, mutual respect, and shared goals for the nature of the Internet we’re building.

My hope is that we develop a path that is wildly energizing for the vast majority of us. This will be a path that builds the Internet we want to live in, and brings the Mozilla mission to life.

The Mozilla project uses the Mozilla Public License for much of its code, including that of Firefox and Thunderbird.   In 2010 we started the work of updating the MPL (The current version was written in over a decade ago.)    The process incorporates a number of  techniques we use for code:  we’ve released alpha and beta versions; we have a public comment tool, newsgroups for discussions, plus detailed feedback from a number of contributors, including both lawyers and developers.

Release Candidate 1 is now available, together with explanatory material.  I expect that the Mozilla project will adopt the MPL 2.0 for all our code that currently uses the  MPL 1.1.  The discussion about adoption and migration is also underway.

As the module owner for the MPL I am extremely fortunate to work with a group of interested and committed experts on this project.  The revision would not have occurred without this group, and the results would not be anywhere near as good without their leadership.   Therefore, I’m making the four people listed below peers of the MPL module.  Each of this group has deep knowledge about the goals of the license and the update process, the rationale for the changes we made, and our approach to thinking through the complexities.

• Luis Villa.   Luis holds the drafting pen for this version, and is intimately familiar with every word, every piece of punctuation, and  every decision.  Luis  spent a year as a Mozilla employee while starting this, and continues to contribute as a volunteer now that he’s moved to law firm life.
• Heather Meeker.  Heather is an attorney who has been a Mozilla contributor for over a decade.  She is a key part of the revision process.  She brings deep expertise in how licenses are used and what problems arise, along with a keen sense of balancing priorities and risk analysis.
• Harvey Anderson.  Harvey is the General Counsel for Mozilla’s product group.  Harvey launched the MPL revision project, created a setting where Luis could devote himself primarily to the MPL for the starting phase, and has been intimately involved in the drafting.  Harvey was a key sounding board for me when I wrote the initial version of the MPL.  He is also the person who suggested the idea of a  patent defense clause in the MPL 1.1.  To my knowledge that is the first patent defense clause in a FLOSS license.  (If you know of an earlier  one, I’d love to hear about it.)
• Gervase Markham.  Gerv is the non-laywer among the group.  Gerv has been deeply involved in Mozilla licensing discussions for at least a decade.  Gerv is leading the discussion about the migration of Mozilla code from 1.1 to 2.0  Gerv is also the key person in implementing changes such as the migration.

Mozilla’s mission is to bring openness, interoperability and user sovereignty to Internet life.  We should do this in the apps world.   We should embrace some aspects of the current app model as a complement to the browser model.   We should also provide an alternative to aspects of the current app model that aren’t so open to interoperability and user sovereignty.

There’s no reason why “apps” can’t incorporate the characteristics that are important about the web.  They don’t today because Apple didn’t build them that way.  There’s no reason Apple should; Apple has a different view of the world.  But we can.  In fact, Mozilla is one of the very few organizations that can do this.  We have reach, scope, and we are part of the infrastructure of the Internet already.  Only a few organizations in the world have this position.  And Mozilla is unique among them.  We are organized as a non-profit precisely so canmake  user sovereignty and interoperability central.

What’s Important About “the Web?”

What are some of the things about “the web” that we want to see alive and well in an open web apps model?  Here’s a starting list of characteristics:

• “plug and play”  — interoperable at many levels
• direct access between consumer  and developer
• innovation without permission
• easy to go from consumption to creation
• heterogeneous — works on multiple devices, operating systems, platforms, data types, languages, technologies, browsers, clients, etc.
• linkable
• decentralized
• the browser provides a locale of “user-sovereignty” that the app (and mobile models) lack

What do people love about “apps”?  Here’s a starting list of characteristics:

• convenience and fun
• task -based — quick and effective
• sense of ownership and being “close at hand” – icons, apps have a home on my device
• discoverability
• lots of innovation
• distribution channel for developers
• monetization channel for developers

What are some drawbacks of the current app experience?

• Apps are often device specific, platform specific
• Devices are the center of the world, not the person using them
• Little if any interoperability across devices or platforms
• System is implemented in a highly centralized model
• Difficult for app and content creators to reach people without approval of gatekeepers
• Requires permission at many levels — centralization allows a few App Store owners to control business model, pricing, relationships
• Learned helplessness:  if there isn’t “an app for that” then it’s not worth trying to do something
• Apps and web experiences live in separate silos

A Better World:  What Would an Open Apps Ecosystem Look Like?

A better world will marry the convenience and enjoyment of apps with the power of the web.  We will be able to:

• take our apps cross-platform and cross-device, so when we update our phones we can take our apps with us whatever device we select.
• bridge our contacts and social graph from different providers
• share “leader boards” and other multi-player game elements across the web
• control the access that apps have to our information; e.g., only allow apps to share information directly with our permission
• discover apps in open and flexible ways just as we discover other content on the web
• buy apps from multiple providers, who may add value through bundling, support, or services
• interact directly with apps creators if we choose to
• unify management of apps and website applications.

In this world both the browser and apps connect us to a universally accessible, interoperable Internet that encourages innovation without censorship.

This is a world worth building.

Today we access the Internet in many ways, with phones and tablets and new devices becoming more prevalent.  These devices have new operating systems, new business models, and new opportunities.  They also bring new challenges to interoperability and user-sovereignty.  How should Mozilla respond?  Should Firefox and Gecko be our only tools?  Or should we develop other tools?

I believe it is imperative we develop additional offerings.   We need open, open-source, interoperable, public-benefit, standards-based platforms for multiple layers of Internet life.

Where is the open source, standards-based platform for universally accessible, decentralized, customized identity on the web?  Today there isn’t one.  There should be.   Mozilla should build it.  When we do, it will complement the commercial offerings.  If it’s widely adopted then it will help drive the overall state of this part of life towards a more open, interoperable, user-controlled version.

Where is the open source, standards-based engine for universally accessible, decentralized, customized, user-controlled management of personal information I create about myself?  Today there isn’t one.  There should be.   Mozilla should build it.

Today many Mozilla contributors don’t think of these things as “engines” or “platforms” of Internet life.  These areas don’t necessarily handle javascript or CSS or the DOM.  We don’t even have standards or even an obvious web standards body for them yet.   They may be built primarily as server software or as applications separate from the browser.  But each of these — and others we’ll identify over time —  has the potential to be an “engine” or “platform” with power and scope analogous to that of Gecko and Firefox today.  They have the potential to move the Mozilla mission forward as a complement to the browser.   If people choose to use a device or operating system where Gecko and Firefox can’t reach, we can still offer one or more platforms for standards- based interoperability and user sovereignty.   And when used in combination with Firefox these engines will have the potential to create “defense in depth”  for user sovereignty.

Will additional offerings reduce our impact?  I think not, for several reasons.

1. Firefox will cause a number of people to pick a cell phone / tablet that runs Firefox well and we will work hard to make this an easy choice.   But it won’t cause everyone to do this.  We know this from the iOS.   iOS users tell us regularly that they would like Firefox on their device.  But they are still using those Apple devices, and Apple sales are strong.   If we can solve problems for people with Gecko-based offerings, that’s a tremendous win.  If we provide platforms in addition to Gecko for different layers of Internet life, that’s also a tremendous tool for our mission.
2. Requiring all innovation to fit inside a specified container — even an immensely powerful one like Gecko — puts immense strains on that container.  Instead, we should figure out what are the most important things for the Gecko platform and equip the platform team to pursue those tasks whole-heartedly.
3. People who love a new Mozilla offering may well be drawn to try Firefox and Gecko.

The discussion about iOS and systems like it remind me of discussions we used to have about Linux vs. Windows.  Windows is a locked down operating system compared to Linux.  One is proprietary, one is free software.  In the early days some Mozilla contributors urged that we should care only about Linux.  They felt our mission would be better served by limiting our offering to platforms that align well with  the Mozilla mission.  We choose a different path.  We chose to take our values to where people live.  People were living on Windows, so we went there.  We made it easy for people to switch from Windows to Linux by providing key functionality across platforms.  If we hadn’t, the web would be a very sorry place today.

We should bring Mozilla values to where people are living today.  We should do so at multiple layers of Internet life. Some of these will be Gecko and Firefox based.  Others may be available across browsers.  This gives us multiple engines of interoperability and user sovereignty.  It provides multiple ways for people to choose Mozilla.

This future has immense challenges.  It offers huge potential rewards for Internet life.

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.