Meta

The new version is strategically important for Mozilla for multiple reasons. First, smartphones and tablets are at the center of a mobile-first transformation of the computing industry, and Firefox isn’t preinstalled anywhere right now. Second, with Firefox shut out on Apple’s iOS and Microsoft’s Windows Phone, Android is effectively the only route for Mozilla to bring its browser to the mobile market.

Last, Mozilla’s objective–to ensure an open Web–relies on Firefox. Right now, Apple and Google browsers based on the open-source WebKit project dominate mobile browsing.

Firefox for personal computers, and many of the add-ons that helped make the browser popular by making it more customizable, use an interface called XUL (XML User Interface Language). But because the XUL-based version of Firefox took so long to start up on Android and isn’t as responsive, Mozilla instead embraced Andoid’s built-in technology.

Mozilla is continuing its assault on the operating system, releasing an updated roadmap for its Boot to Gecko (B2G) project that sees its developers using the mobile platform as their primary phone device by the end of the year.

“We propose a project we’re calling ‘Boot to Gecko’ (B2G) to pursue the goal of building a complete, standalone operating system for the open web. We will do this work in the open, we will release the source in real-time, we will take all successful additions to an appropriate standards group, and we will track changes that come out of that process. We aren’t trying to have these native-grade apps just run on Firefox,” Gal claimed at the time, “we’re trying to have them run on the web.”

As well as a standalone platform, Gal explained that initial versions of the software would operate as a “low-level substrate for an Android-compatible device,” allowing tablets and smartphones based on Google’s popular mobile platform to boot into B2G as well.

The B2G project stands as an apparent answer to the success of Google’s Android and the work the advertising giant has done on the Chrome OS project for so-called ‘Chromebook’ devices. A combination of the two – a smartphone platform and a web app platform – B2G promises to appeal to those looking to offload their processing from a mobile device to the cloud.

In the latest version of the B2G roadmap, Mozilla claims that the first milestone is to get developers using a B2G device as their day-to-day smartphone – a goal it aims to achieve by the end of the year.

The project has a way to go, however: while B2G currently has access to smartphone features including the camera and the ability to make outgoing calls via Android, work has yet to be completed on messaging and full telephony functionality, along with power management, Android contacts integration and screen management.

Once complete, the team is planning to turn its attention to the nicer aspects: support for Bluetooth, USB and Near-Field Communications hardware is planned – although not yet scheduled – while plans to release an open web apps store= much like Google’s own Chrome Store, which lists web apps solely for use with its own browser – and add full Firefox-like functionality to the web browser are scheduled.

Once complete, that work will result in a public demonstration of the project as early as Q1 2012, the team claims, followed by “productisation” in Q2 – at which point the public at large will be given their chance to play with Mozilla’s creation.

The company has a long road ahead, however: Google’s Android is a popular platform, and while B2G promises to maintain compatibility with the system – likely by integrating a dual-boot functionality or using B2G as an overlay on top of the still-running Android OS where possible – it’s likely to struggle to convince non-technical types that it’s worth the effort.

Should the company secure a deal with a major handset manufacturer to ship B2G as standard with a smartphone, however, that could rapidly change.

This page is edited by brendan, cjones. Please don’t change without permission. DRAFT
[Brendan Eich co-founded mozilla.org and is currently the CTO of Mozilla. He is widely known for his contributions to the evolution of the Web, including inventing JavaScript and spearheading its ongoing standardization and evolution. See also: Mozilla’s Brendan Eich on the Birth of Firefox [Nov 9, 2011].]

Milestone 3: Productization Q2 2012

Back from JSConf EU and other travels, the minute with team is happy to return with a special episode from Brendan about the new Boot To Gecko (B2G)system. This is targeted to allow users of mobile devices to boot directly to a Gecko based browsing interface and to run web applications. It is really doing some stunning work around the new web APIs and privilege model that all developers should be aware of. Enjoy!

When I last spoke about the whole area of the rise of mobile smartphones and tablets really, and how Mozilla needs to climb the stack, use the Firefox desktop-heavy user-base to grow and make new product offerings, new projects, I did not talk about Boot To Gecko, but it’s, it was latent in what I, I did talk about, because we, we look around the world of mobile devices, and we see different operating systems that are increasingly locked in, vertically in terms of browsers or app models, or, even down to the OS and hardware, and that goes against Mozilla’s mission.

So what we really want is an offering that allows you to use the web to access all those great device APIs, with security, with user, user’s permission, with the principle of least-authority, so that there’s not a big security nightmare. But we do expect that the web languages, JavaScript especially, are capable of doing the high level sequencing and operations that you want, for things like your camera, USB connectivity, even futuristic stuff like Near Field Communication. That can all be just APIs exposed to JavaScript. You shouldn’t have to write native code that’s like Java interfaced on Android, or Objective-C, on, on, or C or C++ on another platform.

And so Boot To Gecko really is trying to make a thin OS layer, using open-source stacks like the linux kernel that’s in Android, or some similar linux kernel, and lib-c, and, you know, the Bluetooth open stack, and other things, to have a completely unencumbered operating system that gets you straight into the web languages as fast as possible. The, the launchers, home-screen, or the front-end of the user experience of the OS will really be realized with web technologies.

And, you know you might think this is similar to webOS, from Palm originally, now HP, and ChromeOS, there’s a lot similar in spirit. I would, I would say there’s some differences strategic for Mozilla and in what users will see there. What we’re trying to provide is not a new big fat JavaScript library or stack, but the web libraries that you find on Github, the ones you’re already using in your front-end development. We want web developers to be right at home, we don’t want to give them yet another, sorta framework. And I think that the webOS has some of that going on, which you know, may or may not be a strike against it, but it’s different from what we intend. We intend to be totally aligned with the grain of the web.

ChromeOS is fully open source, as fully as it can be, I think, more so than Android, at least Android Honeycomb, and that’s, that’s a good thing about it. It’s currently targeting you know notebooks, machines with keyboards, I think it’s, it’s also being brought up on some tablets, I’m not sure where that stands. And maybe even some phones, so the telephony, you know the dialer and the signaling stuff will be there. And not sure how that’ll play out. But ChromeOS is kind of Chrome, and therefore Chromium Webkit, and sort of Google dominated, to be fair. And I, so inspite of the philosophical alignment I feel with ChromeOS, it needs to be something like Android, which is really linux plus some Java stuff, I think Mozilla has to take a shot at something like Boot To Gecko.

We want to keep the Gecko code base relevant, even as it sort of dissolves into the operating system, becomes part of the ambient functionality you find on devices. So we’re looking for interoperation between Webkit and Gecko. We’re not just saying: “one open-source widely-used renderer is enough”. And, of course, as, as I mentioned last time, there’s a lot of, sort of, implicit version forking or vendor specific, you know, bug injection going on with Webkit. This is inevitable with any widely used codebase, it’s not something peculiar to Webkit.

But it, I think it even more raises the temperature on having another rendering engine, ideally open-source, like Gecko, out there, with a lot of users, even in the future where tablets and smartphones dominate the desktop population of devices, of PC’s and Macs.

So, Boot To Gecko is trying to differentiate by bringing web developers all those APIs that are going to take awhile to standardize. The stuff that Phonegap, from Nitobi, does well, we want to bring it as quickly as possible and feed it into the standards body, and, bodies, and iterate on it, and we want to run well on certain, certain devices. Now, this also requires making choices, because you can’t just say this is gonna be something users can download for any old phone. It, it, all the phones are different, you really have to flash into ROM, and you know, to burn, burn a ROM with this code. That’s part of the challenge, because for tablets, you might need some, some extra support that isn’t yet open-source. I mentioned Android Honeycomb.

We’re gonna persevere, and try to get this to be completely open-source, and running on relevant devices. There’s some really sweet hardware out there that we like a lot. We like the Samsung devices, the Galaxy II-S, we went with the Galaxy Tab 10 inch. Getting up on those right now with fully open-source stacks is a little hard. So part of our mission is to overcome that obstacle, and then interface the device APIs in the OS and down in the linux layer directly to the web.

And, so we won’t run equally well on every device, but we will pick devices that we think are likely to be popular, that are well executed hardware, that, you know, can actually give Apple a bit of a run for its money, and try to get something up and demonstratable in a few months.

So, I will be talking about this at least in, in October at a couple of conferences, probably Web 2.0 Expo in New York, and another one. And that, that puts a short fuse on the initial prototyping work for Boot To Gecko, so it’s paramount that we leverage what’s out there as open-source already, and then build on it with the Gecko technology that allows web developers to get at the device APIs. And I’ll have more to say about this as it progresses, but it’ll be exciting, and I, it’ll, I hope be really awesome on certain well designed hardware.

Mozilla believes that the web can displace proprietary, single-vendor stacks for application development. To make open web technologies a better basis for future applications on mobile and desktop alike, we need to keep pushing the envelope of the web to include — and in places exceed — the capabilities of the competing stacks in question.

We also need a hill to take, in order to scope and focus our efforts. Recently we saw the pdf.js [http://github.com/andreasgal/pdf.js/] project expose small gaps that needed filling in order for “HTML5” to be a superset of PDF. We want to take a bigger step now, and find the gaps that keep web developers from being able to build apps that are — in every way — the equals of native apps built for the iPhone, Android, and WP7.

To that end, we propose a project we’re calling “Boot to Gecko” [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web. It’s going to require work in a number of areas.

* New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
* Privilege model: making sure that these new capabilities are safely exposed to pages and applications
* Booting: prototype a low-level substrate for an Android-compatible device;
* Applications: choose and port or build apps to prove out and prioritize the power of the system.

We will do this work in the open, we will release the source [http://github.com/andreasgal/B2G] in real-time, we will take all successful additions to an appropriate standards group, and we will track changes that come out of that process. We aren’t trying to have these native-grade apps just run on Firefox, we’re trying to have them run on the web.

This project is in its infancy; some pieces of it are only captured in our heads today, others aren’t fully explored. We’re talking about it now because we want expertise from all over Mozilla — and from people who aren’t yet part of Mozilla — to inform and build the project we’re outlining here.

I’m all jazz hands about Boot To Gecko (B2G). I think B2G is really important to the Mozilla mission. Perhaps stemming from the early-and-open nature of B2G, there are some misconceptions about B2G that I’ve seen in articles and forums. I am not closely involved in the project, but I do know enough to identify and correct a few of these misconceptions with the following three B2G facts:

B2G will not run in kernel mode. To be clear, B2G will run on top of the Linux kernel; Gecko will run as user-mode processes. Furthermore, a crash in Gecko will not take down the entire phone: with Electrolysis (already being used in Firefox Mobile), different apps/sites will run in different processes.

B2G will (ultimately) not run on top of Android. To bootstrap the project, work is currently being done on top of Android. However, the goal is to incrementally remove each dependency on Android, leaving only drivers and low-level libraries. In particular, this means B2G would not contain the Dalvik Java VM which should significantly improve the patent–encumberedJavasituationas well as reduce the number of VMs needed to browse the web from 2 to 1.

B2G will use Gecko, but it’s not just about Gecko. A clearer name might have been “Boot to Web platform”. Gecko will, of course, be the engine used to prototype new Web APIs but since these are targeted at open standards developed in the open (as opposed to dumped in the open) [referring to a Dart presentation], a possible/desirable outcome is a separate “Boot To Webkit” implementation able to run the same home screen and apps as B2G.

If you are excited, feel free to contribute to the project; it’s just starting and there are many important problems to be solved.

Improving Web Capabilities

Mozilla has long been at the forefront of making the Web a more capable, rich and compelling platform. We continue this leadership today.

Identity

…

Apps

Apps represent a new, convenient way of interacting with the Internet, but they lack a number of the features that are great about the Web. The Mozilla open app ecosystemwill let users take their apps with them across platforms and devices. It will bridge contact lists and social graphs from different providers across the Web. It will allow users to discover apps in open and flexible ways, just as we discover other content on the Web.

What are the key projects for Mozilla in the next year? How do you plan to influence the market going forward?

Firefox continues to be a fundamental lever in driving the Web forward and advancing the Mozilla mission. At the same time, the Web is evolving and moving into new areas and so is Mozilla. In addition to delivering Firefox on mobile phones and tablets, we will focus on new projects in the important areas of Apps, Identity, Education, and more.

Do you see a continued need for an independent player like Mozilla, now that competition in the browser market has accelerated?

Absolutely, Mozilla’s public benefit mission and nonprofit nature enables us to advocate for the user and remain committed to keeping the Web open and participatory, rather than focusing on market share or profits. The desktop browser market is innovative and competitive, but no one other than Mozilla is organized solely for the good of the Web as a whole, and we believe that as people become increasingly aware and informed online citizens that more and more people will look for a Web browser, like Firefox, that answers only to them.

What was Mozilla’s total revenue for 2010?

Mozilla’s consolidated reported revenue (Mozilla Foundation and all subsidiaries) for 2010 was $123 million, up approximately 18 percent from 2009.

How does Mozilla generate revenue?

The majority of Mozilla’s revenue is generated from search functionality included in our Firefox product through all major search partners including Google, Bing, Yahoo, Yandex, Amazon, Ebay and others. Mozilla’s reported revenues also include very important individual and corporate donations and grants as well as other forms of income from our investable assets.

What is the status of the organization’s search partnerships?

We currently have partnerships with a number of search providers that differ by market. Our largest contract, with Google, comes up for renewal in November. We have every confidence that search partnerships will remain a solid generator of revenue for Mozilla for the foreseeable future.

Do Mozilla’s partnerships affect its independence?

Our mission and development process are completely unrelated to revenue or revenue generating relationships. Our open development process is governed by Mozilla’s mission and our commitment to improving the Web.

Are you exploring partnership opportunities to diversify your revenue stream?

We currently have several key business partnerships and are actively exploring search partnership opportunities and other potential revenue opportunities. We’ll continue to build great products that help people enjoy the richness of the Internet, and we’re confident that this allows us to identify appropriate sources of revenue.

The open Web is a great platform for rich applications. It would be even better if it had additional capabilities to ease discovery, acquisition, installation and use of apps, while also enabling monetization for developers. We designed and built a prototype of a system for open Web apps: Apps built using HTML/CSS/JavaScript that work both on computers and mobile phones, have many of the characteristics that users find compelling about native apps and provide developers with open and flexible distribution options.

Today, we are releasing technical documentationof the proposed system and a developer preview prototype that allows you to install, manage and launch Web apps in any modern desktop or mobile browser (Firefox 3.6 and later, Firefox for mobile, Internet Explorer 8, Chrome 6, Safari 5, Opera 10 and WebKit mobile). This prototype provides a simple mechanism to support paid apps and authentication features to allow apps to log users in upon launch.

The design proposed here provides the following capabilities and enables a new category of what we call “Open Web Apps” — apps that are truly of the Web.

Open Web Apps:

Are built using HTML, CSS and JavaScript.

Can be “installed” to a dashboard within your mobile or desktop Web browser, or to your native OS desktop or mobile home screen.

Work in all modern Web browsers, while enabling each browser to compete on app presentation, organization and management user interfaces.

Support paid apps by means of an authorization model that uses existing identity systems like OpenID.

Support portable purchases: An app purchased for one browser works in other browsers, and across multiple desktop and mobile platforms without repurchase.

Can request access to one or more advanced and/or privacy-sensitive capabilities that they would like access to (like geolocation) which the system will mediate, giving the user the ability to opt-in to them if desired.

Can be distributed by developers directly to users without any gatekeeper, and distributed through multiple stores, allowing stores to compete on customer service, price, policies, app discoverability, ratings, reviews and other attributes.

Can receive notifications from the cloud.

Support deep search across apps: Apps can implement an interface that enables the app container (generally the Web browser) to provide the user with a cross-app search experience that links deeply into any app that can satisfy the search.

Web apps are becoming a commonly used class of applications – often directly competing with native apps. Web apps offer similar features to native apps and are available through any modern Web browser (both desktop and mobile) from any place in the world. Yet, Web apps lack certain essential features around the user experience, including installation and launch, app discovery, monetization and some platform features, such as notifications and unified search through installed apps. App experiences are usually a tightly vertically integrated (e.g. iPhone/iTunes) with problems such as an opaque approval processes, lack of choice for developers, platform lock-in, high(er) development cost when going cross-platform, etc. Realizing these gaps and issues, Mozilla decided to build the underlying system to enable Open Web Apps – these apps are fundamentally built upon the Web infrastructure.

Q: Is Mozilla creating an Open Web App store?

At this point in time, Mozilla has no intention to build our own store or distribute apps ourselves. We expect to see app stores develop, which will provide access to both free and paid Open Web Apps. Developers will be able to publish their apps on their own sites and, if they choose to do so, charge for them.

Q: How are Open Web Apps different from add-ons?

Open Web Apps are applications produced on and delivered through the Web. Open Web Apps are complete applications such as office applications, productivity applications, image processing applications, games, etc. Open Web Apps run in any modern Web browser (both on desktop as well as mobile). Add-ons are extensions to your Firefox browser, which provide specific functionality to the browser itself.

Q: How will people discover new apps? Will there be recommended apps?We expect that we will see a whole array of directories and stores being developed to aid in discovery. This will be another area where stores will compete with each other. Further – as you can link into apps – a developer can market an app through the established online marketing channels such as keyword advertising.

Q: Will developers need to submit or create a new app?

All developers have to do to make their apps work in the proposed system is to provide a short manifest (as text document consisting of a few lines of JSON code). There is no submission process – the simple existence of a manifest is enough for the system to understand that the particular URL is an app. If the developer chooses to sell her app, she has to add some boilerplate code for purchase verification. We will provide example code and libraries for this purpose.

Q: Will the apps be localized and available globally?

This is completely up to the developer. An app can be distributed globally in exactly the same way you publish a website today – once the app is available through its URL, anyone around the world can access it. It’s up to the developer to decide if they want to localize, provide special features for certain geographies, etc.

Q: What is important about Mozilla’s proposed Open Web App infrastructure?

Apps are fundamentally of the Web; they live on the Web and you can link into them.– Apps can be published without limitations (on your own site, in directories, in stores), fostering innovation on the store fronts/directories, remove problems with approval processes, etc.

The system provides mechanisms for identification and authentication.
– You can easily charge for apps, similarly to experiences you have today on the iPhone or Android devices.

Apps run in any modern Web browser.
– You are not tied to a specific browser, your apps travel with you from browser to browser independent from the underlying OS (e.g. desktop to mobile). For developers, this means that they develop once and can deploy on every device that runs a modern Web browser.

There has been a lot of discussion and progress in the month since we announced our proposal for an “Open Web App Ecosystem”, and we wanted to provide a snapshot of our progress and current thinking. This post outlines a new feature, “Application Sync”, as well as several proposed technical changes to Open Web Apps.

Syncing Apps

The way the Web works today, changes made on a site are often transparently visible across all of a user’s devices, changes such as photos posted to Flickr or updates sent to Twitter. Given that many popular sites use server based storage behind an authenticated user account, this “feature” is quite natural for the Web.

Open Web Apps, on the other hand, are more similar to browser bookmarks than they are to photos on Flickr. The set of applications that a user has installed is persistent in a browser’s storage on the client, and is not stored on any central server by default.

A problem in user’s expectations arises here: the more and more the dashboard ends up feeling like a hosted Web application, the more a user will expect to see her stuff wherever she is.

To address this problem, we have included “application synchronization” as a first class feature. The goal of this feature is to allow a user to synchronize their applications between devices and browsers if they choose. We’ve begun prototyping synchronization, and you’re welcome to follow our progresson github.

Refining the Manifest

The application manifest format for Open Web Apps is a specification of JSON encoded meta-data that describes the presentation, launch, and capabilities of an Open Web App. This specification is central to the system we propose, as it will be an important integration point for application developers, browser vendors, and application stores.

Given the central role of the manifest, it has been the focus of a commensurate amount of attention. We have received feedback from standards groups, engineers working on “Installable Web Apps” at other browser vendors, companies and individuals interested in running application stores, application developers, and our own security experts here at Mozilla.

All of this discussion has culminated in a handful of concrete proposed revisions to the manifest format which attempt to build a more secure platform for Web apps that serve all parties involved in the ecosystem. You can learn more about the current proposed changes, and join the discussion, in a separate blog entry dedicated to refining the manifest.

Defining the Application Repository

One key component of Open Web Apps is what we’re calling the Application Repository. This is a client side entity that exposes an API to Web content: applications, stores, and dashboards. Its primary responsibilities are to manage the collection of installed applications and ensure that the user remains in control of them.

One interesting element of the application repository is that it is the piece that we propose be built into browsers as a native component. In the past month we’ve completed a first pass proposal and proof of concept (in the form of browser add-ons) of the API that the application repository will expose. This API can also be provided by a JavaScript library to support browsers that have no special support for Open Web Apps.

You can view the latest versionof this API specification on github, and we’re especially interested in feedback from browser developers on this API. Our hope is that it will be possible to implement this API on browsers across mobile and desktop environments alike.

Upcoming

In the upcoming weeks we hope to complete a first prototype of application sync, and we will have a complete revision of the application manifest ready for further community review. Finally, we should have prototype add-ons complete for multiple browsers available for people to try out.

Our longer term goal is to have an Integration Release of the Open Web Apps concept ready by early next year, which will serve as a blueprint from which we can work with members of the community to help spark a vibrant new ecosystem of rich applications for your browser.

Editor’s Note: Today, Mozilla Labs posted an update on the Open Web App Ecosystem project. Included below is an excerpt from this post. You can read the full details from Director of Mozilla Labs, Pascal Finette here.

The Web needs support for the co-existence of multiple Open Web App stores, and to enable users to use applications from these stores in a consistent manner. People buy their shoes, food and music from different stores on the Web today, and we see the same need for diversity and choice with Open Web Apps. We are excited to build a truly free and open market which is the basis for innovation and fundamental to the Web.

We recently launched a project to build the infrastructure for an Open Web App Ecosystem because we want to enable many different stores to exist and work in any modern browser across devices and platforms. The Open Web App Ecosystem will allow app developers to publish apps on their own website under their own terms, and will provide opportunities for individuals and companies to develop innovative services.

The Web needs support for the co-existence of multiple Open Web App stores, and to enable users to use applications from these stores in a consistent manner. People buy their shoes, food and music from different stores on the Web today, and we see the same need for diversity and choice with Open Web Apps. We are excited to build a truly free and open market which is the basis for innovation and fundamental to the Web.

We recently launched a project to build the infrastructure for an Open Web App Ecosystembecause we want to enable many different stores to exist and work in any modern browser across devices and platforms. The Open Web App Ecosystem will allow app developers to publish apps on their own website under their own terms, and will provide opportunities for individuals and companies to develop innovative services.

Concretely, the system consists of a machine readable format to describe applications (the manifest), a client side collection of the apps a users has installed (the app repository), a user facing application launcher (the dashboard), as well as the interactions to support commerce (such as proving a user’s ownership of an app).

Progress

Numerous app developers and companies have shared plans to build stores and services (search, recommendations, etc.) based on the Open Web App Ecosystem prototype we released.

On the technical side, we are in the process of finalizing the APIs and the manifest format for developers (read more about the details of this work here).

We are experimenting with new app capabilities such as notifications, app sync and the possibility for apps to exchange data directly if permitted by the user(allowing your email app access to your address book and calendar app for example). We also continue to work on multi-browser specific integrations of the user-facing application launcher (currently referred to as the Dashboard).

What’s next?

Our “integration release” is on track to be available in Q1 2011, and will have a stable manifest format and APIs, and will include initial custom browser support for most popular browsers (via extensions), application sync, and an application dashboard. Additionally we are actively working with developers of apps and stores to help them integrate a presence within the Open Web App Ecosystem into their plans.

We are excited to announce the availability of the first milestone release of Mozilla’s Web Application project. Web Apps are applications that run on any device, and can be distributed through any store or directly by the developer. This release contains stable APIs, developer utilities and documentation to help you get a jumpstart on building Web Apps and stores.

At Mozilla Labs, we’ve been experimenting with several concepts and ideas to build a Web of Apps. Today, we’re proud to release a new version of the experimental OpenWebApps add-on for Firefox that allows you to easily install and manage web applications in Firefox and aims to provide a tightly integrated app experience.

These features are aimed at developers and adventurous users and give you an idea of what to expect in the future. You can download the latest version of the add-on here.

With this release, you can try two new experimental features – Web Activities and App Discovery.

v0.3 release of the Mozilla Open Web Apps project

Web Activites

This experiment is focused around the concept of linking apps together.

For example, if you use Flickr to share photos, then the Flickr Web App should let you easily share and integrate your Flickr photos with other Web Apps. If you use Twitter to share links with your friends, then other Web Apps should allow you to easily share via Twitter.

This experiment is built around the notion that you should be able to discover interesting Web Apps as you browse the web. To try this, once you have installed the OpenWebApps add-on in Firefox, visit nytimes.comand you will see a prompt to install the awesome NY Times web app.

Note:We have faked this for the NY Times site to give you a sense and idea of what the experience might be as more web sites add support for browser-based App Discovery.