Dec 15

Chrome Frame for iPhone; Taking your HTML5 renderer with you

Mobile, Open Source, Open Web, Tech, Web Browsing 2 Comments »

I love the Web, but a couple of things have gotten me thinking.

#1: Netflix on PlayStation 3 via HTML5

I got to meet some of the awesome engineers behind the HTML5-fication of Netflix experiences, specifically folks in the TV group. They showed us various UI experiments and it was beautiful to see. The UI is slick and modern, and every effect is using CSS transition goodness, nicely hardware accelerated thanks to the PS3’s GPU.

At first it may seem a bit crazy that the team took Qt/WebKit with them as the rendering platform, but when you think about the huge number of devices that Netflix needs to support, it makes “wanting an iPhone and Android app” seem like laughable fragmentation.

#2: Trusting the implementations to catch up?

We have amazing browsers in modern devices. But as we push the Web forward, we are still facing buggy implementations and varying support. Although WebKit lives within Mobile Safari, that doesn’t mean that Mobile Safari has open sourced everything to WebKit. The touch support isn’t there. We can’t all use the same scrolling effects and the like. That has to be built up by everyone.

Ideally, with position:fixed (now in Android), you could use that and even flexbox to use the core scrolling of the browser itself so you don’t have to resort in the mimicry that frameworks have had to do until now.

Even the magical escape chute to the GPU via CSS3D isn’t a silver bullet.

matthew farag

Matthew Farag has a lovely portfolio site that uses the power of this modern goodness (using Scripty2 for auto hardware acceleration!). Works great on a desktop WebKit, but how about the iPad? It does pretty well, but you start to see some of the buggy issues where the GPU seems to run out of memory and you get weird artifacts.

So, when you put these two together, you realize that it could be nice to carry a great consistent Web runtime with you to allow you to get great experiences, especially while we are transitioning and getting everything flushed out. It would also enable us not to be beholden to the likes of Android and Apple to make sure that their Web runtimes are fantastic.

I may want Chrome Frame for devices more than I care about it on the desktop as it turns out. Hmm. Alex? ;)

Dec 14

If Chrome OS perishes or even merges, it will be a sad day for the Web

Google, Mozila, Open Source, Open Web 4 Comments »

People have often commented on how strange it is that Google has two OSes in Android and ChromeOS. Some talk about how it is doing the “Microsoft thing” by setting up an internal competition, and Google is big enough to do that kind of thing.

There were many who saw that “the Web will eventually win”, but as Android’s numbers get larger and larger, others are pondering things. Is the timing off? Has Android gotten too large to let itself lose to Chrome OS? Is the app ecosystem for Chrome OS not up to snuff with Android (let alone iOS)?

If Google pulled the plug on Chrome OS it would feel like a bad day for the Web. Chrome OS needs push the entire Web forward. Chrome is adding features to WebKit and Chromium at a very healthy rate, and the Chrome OS pieces make sure that features that flush out the Web to rival native environments come along. Without the Chrome OS project being part of the whole Chrome ecosystem, that may not quite be the case.

There are some projects that Google should go long on, and some that should be experiments. You could argue that Wave was an experiment that didn’t warrant continued evolution, but Chrome OS should. It moves the Web forward.

The Web has a lot of huge benefits, but it is still hard at it going up against iOS, Android, and others. We need a lot of investment to give the Web the SDK that developers are striving for, so they can deliver compelling experiences. We aren’t there yet.

With Google and Chrome OS, HP and webOS, and even a lot of other players (e.g. RIM and its Web support, Nokia and its, etc etc) we are seeing a healthy double-take on taking the Web forward and making the next big platform truly multi-vendor.

“Merging” with Android is interesting. Android’s web stack has gotten better recently, but it is very much lacking, and you could argue that getting the Chrome/WebKit talent and putting it on the Android stack could do a lot for the Web, and maybe bring the Web up to be a true Android platform. That could be a good thing, but would it ever truly be a first class citizen compared to the “Java but not really Java” stack?

I truly hope that Google double downs on Chrome and Chrome OS, and gives it time to have the Web come along for the next ride as more than the ghetto that some would like to see it become.

If not, time for Mozilla to create a Web OS :)

Oct 19

Open Web Apps: The Vapour infrastucture becoming real

Mozila, Open Source, Tech, Web Browsing with tags: , No Comments »

I mentioned Vapour, the Mozilla Open Web App Store. I didn’t know that it wasn’t released yet (even though the code was out there).

Well, now it has been released with the post on an Open Web App Ecosystem that has a prototype and technical documentation with it.

This is a huge deal, and I am jazzed that Mozilla is getting into the game here. The Web needs to give developers as many opportunities to monetize as possible, and needs to help consumers find the best possible content.

First we have the philosophy on what an Open Web App even is:

  • 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.

There are some interesting elements in there, such as calling out notification support as a first class required feature.

Then we get to the brass tacks. The tech behind this. I quickly peaked at the manifest and was happy to see that it looks very similar to Chrome (and the webOS appinfo.json). I would love to see us all get in a room and try to come up with some subset of JSON that we can agree on.

I also enjoyed seeing:

  • Permissions: The thought around permissions and what it means to be an app.
  • Verification: How do we actually make things like “buy on Chrome, use on Firefox” working? How do we allow distributed systems for payment and all of the services that tend to be silo’d right no?
  • Cross app integration: The Web is great at mashups, and we should lose that in apps

Great to see the word now fully out, and now we have the concept we can join Mozilla in helping to define how this all works, and how it can be useful. It is so very hard to compete with a unified system, and to make it happen takes real work and collaboration. What do you think?

Sep 28

Chrome Speak To Site; Give any input the power to listen to you

JavaScript, Open Source, Tech, Web Browsing with tags: , , 3 Comments »

Paul Irish gave a fantastic updated State of HTML5 talk at JSConf.EU. It is packed full of demos, including sharks with freaking lazer beams!

At one point he showed off the WebKit support for <input speech> implementation that allows you to talk into an input area. You click on the microphone, speak in, and it will get translated for you with the results. I am not sure if you can tweak how the translation is done (choose a Nuance vs. Google vs. …. solution for example), but it definitely works well out of the box.


I was surprised to see this already landed in my developer-channel Chrome, so I was incented to do something with it on the plane trip back from Berlin to New York City. Something simple would be to give the user the ability to enable speech on any input. I whipped up a Chrome extension using the context menu API, but was quickly surprised to see that there isn’t support in the API to get the DOM node that you are working on. Huh. Kinda crazy in fact.

Then the whizzkid antimatter came to the rescue with his cheeky little hack around the system. Here is how it plays out in the world of this extension:

The background page

First we enable the context menu on any “editable” element (vs. anywhere on the page, on any text, etc), and when clicked we fire off an event to the content script in the given tab:

    title: "Turn on speech input",
    contexts: ["editable"],
    onclick: function(info, tab) {
        chrome.tabs.sendRequest(, 'letmespeak')

Catching in a content script

A content script then does two things:

  • Listens for mousedown events to keep resetting the last element in focus
  • Catches the event, and turns on the speech attribute on the target DOM node
var last_target = null;
document.addEventListener('mousedown', function(event) {
    last_target =;
}, true);
chrome.extension.onRequest.addListener(function(event) {
    last_target.setAttribute("speech", "on");
    last_target = null;

Wire-y wire-y

Of course, it all gets wired up in the manifest:

    "name": "Turn on Speech Input",
    "description": "Turns on the speech attribute, allows you to speak into an input",
    "version": "0.1",
    "permissions": ["contextMenus"],
    "minimum_chrome_version": "6",
    "background_page": "background.html",
    "content_scripts": [{
        "matches": ["<all_urls>"],
        "js": ["input-speech.js"]

This trivial extension is of course on GitHub (I want git-achivements after all! :).

A couple of things trouble me though:

  • The microphone icon should sit on the right of the input, however when dynamically tweaked like this it shows up on the left by mistake [BUG]
  • I have also played with extensions such as Google Scribe. Adding icons like this doesn’t scale. Having them show up all the time gets in my way. I think I want one ability to popup special powers like scribe completion, or speech-to-text, without it getting in my way
  • When services are built into standard elements like this, it feels like I want to have the ability to tweak how they work (with great defaults of course, as 99.9999% of the time they won’t be changed.


Aug 31

Node is our turtle shell; Node.js now powers services on webOS

JavaScript, Mobile, Open Source, Palm, Tech, webOS with tags: 3 Comments »


At our last Palm Developer Day, Ben and I discussed future APIs for webOS including “JavaScript services” as a way to write code that runs on the other side of the device service bus using JavaScript.

If you think about it, node delivers a services platform for the cloud, so is there a way that we could work together? We got together with Ryan Dahl of Node to try this out, and it turns out that node works fantastically well on a mobile device! Major kudos should go to the V8 team for creating a great VM and to Ryan for writing efficient code that scaled down from the cloud to the device.

Today we announce that node is part of webOS 2.0:

The popular Node.js runtime environment is built into webOS 2.0, which means that you can now develop not just webOS apps but also services in JavaScript. The active Node ecosystem is on hand to provide community support and a rapidly growing library of modules that you can use in your webOS services.

Besides powering the new Synergy APIs, JavaScript services strengthen webOS’s support for background processing and add new capabilities—like low-level networking, file system access, and binary data processing—to the web technology stack.

I am really excited about this move for us. The node community is top class. I get to see this time and time again, most recently over the weekend and this week as I judge the node knockout. There is magic in the air with Node. It feels like the Rails days. I remember being so happy to jump to Rails and get away from the heavy world of Enterprise Java. It was a breath of fresh air to not have to argue with folks about every piece of the stack. “What about JSF with HiveMind and Commons-Logging and ….” Argh! Too. Much. Choice. And, a logging abstraction above Log4J was hilarious :)

Node is low level, yet simple. It is more like Sinatra than Rails. The event-based opinions keep you in good stead, and with cloud solutions such as Heroku and you have great deployment stories, unlike Rails back in the day.

If you check out the modules that are growing daily, and the fun real-time hacks from the knockout you will get a good feel for node.

It feels great to have webOS as the first mobile device that embeds node. With db8 we offer a JSON store than can sync to the cloud (e.g. sync with CouchDB). This stack is starting to look pretty great.

Aug 31

App Stores: Showing users the value of Farmers Markets compared to Wal-mart

Mobile, Mozila, Open Source, Tech with tags: 1 Comment »


I remember growing up walking past grocers and butchers, and having my Mum stop by to get fresh meat and veg on a daily basis. I look back fondly on that experience, as I contrast it to the later years of mega-stores. When I came back to England for a year stint, a few years back, I was shocked to see that Tesco didn’t just sell food anymore, but had branched out to credit cards and gas and lots of crazy things.

The local stores have been wedged out.

On Sunday, I took my kids to the farmers market (happens most weekends), which is what had me think back to the local stores from my own childhood.

I worry about the food chain these days.

Another sector that I think about is app economies and app stores. I have talked about what an open marketplace could be and Pascal Finette of Mozilla Labs has been doing a lot of thinking in this area.

Fast forward a few months, and we see a new project in a very early stage. Vapour (github repo has been removed) is the Mozilla Labs project that is “An experiment around an Open Web App Store.” I am excited about the project for two reasons:

  • Mozilla is uniquely positioned to deliver a marketplace that focuses on very different values than other companies
  • I see check-ins from two amazing people: Michael Hanson (who did the amazing work around “people”) and Lloyd Hilaiel (who recently joined Mozilla. I tried to hire him there years back, and he waiting for me to leave. Hmm :)

Also, I got to hang with the OpenAppMkt chaps at the Node Knockout get together last night. They have only just begun, and think they will do some great things.

I evangelize the farmers market. I market it. I try to sell it.

I think of the Mozilla effort as the farmers market of app stores. The values are different. It isn’t just about values though, it will be about product. Many folk go to the farmers market because the goods are better. It is incredibly hard to compete with the likes of Walmart. They squeeze the market and force their vendors in a race to the bottom around price. This is the trick that Walmart can play. They can hold on to: “Look, we are giving everyone cheap goods!” It doesn’t matter what they do with China, or how they treat workers. Surely it is all for good if we can get things cheap right?

The same is happening with the major app stores. These platforms sell consumers with a fantastic user experience and looking after their users. No viruses. No “bad stuff”. Clean. They offer true value, but there is always a cost.

The app markets are as strong as wal-mart. I am excited to see new endeavors that change the game and deliver great user value, while also giving great freedom.

Aug 21

JavaScript! The Doctor Is In.

Bespin, JavaScript, Mozila, Open Source, Tech No Comments »


Dimitris Vardoulakis has created a Doctor. A Doctor for JavaScript that does static analysis on your code to tease out the type information and more.

This is fantastic work, and is something that we were dreaming of when we first planned Bespin. What if the cloud was constantly analyzing your code and returning type metadata back to the clients that were accessing it? That metadata can be used for tasks such as code completion and documentation.

Give it a try to see what comes out the other end. The samples show you a lot, such as polymorphism:

function id(x) { return x;}
id('hello, doctor!');
// returns
id : function(<number | string>)<number | string>

and prototypes:

function Rectangle(w, h) {
    this.w = w;
    this.h = h;
Rectangle.prototype.area = function() {
    return this.w * this.h;
var a = (new Rectangle(2, 3)).area();
// returns
Rectangle : function(number, number) → any
area : function() → number

and exceptions:

function findLargest(a) {
    if (a.length === 0) throw new Error('empty array');
    var max = a[0];
    for (var i = 1, l = a.length; i < l; i++)
        if (a[i] > max)
            max = a[i];
    return max;
function foo() {
    var a = [1,2,3];
    try {
        return findLargest(a);
    } catch (e) {
        return e.message;
// returns
findLargest : function(Array[number]) → number
foo : function()<number | string>

and callbacks:

function call(f, x) { return f(x); }
function add1(n) { return n + 1; }
function truncate(s) { return s.substring(0, s.length - 1); }
var n = call(add1, 41);
var s = call(truncate, 'abcd');
// returns
call : function(<function(number) → number | function(string) → string>, <number | string>)<number | string>
add1 : function(number) → number
truncate : function(string) → string

Mike Shaver talked about the great work that is coming in JS land right now for Moz…. and it is showing. Can’t wait to see both Firefox and Bespin gain from this all!

Jul 12

Diffable; What if GitHub supported it natively?

JavaScript, Open Source, Tech with tags: 3 Comments »

Steve Souders told me about Diffable, when I saw him after his awesome Velocity conference.

Diffable is an open source project that allows you to only send down the deltas in your application versions, versus full new downloads (which may have a large amount of duplicate data).

In their presentation, Josh Harrison and James deBoer, talk about the details after the start with the core issues:


Frequently modified web resources must be downloaded in their entirety with every modification.
Even a small change invalidates the cache.
Rich internet applications often have large amounts of static content.


Initial application resources kept in cache.
Changes to cached versions transmitted as deltas.
Deltas merged client-side to generate latest JS version.


Faster page load times for users with cached resources.
Small changes to large resources incur only small costs.

Steve summarizes things well in his post:

Diffable uses differential compression to reduce the size of JavaScript downloads. It makes a lot of sense. Suppose your web site has a large external script. When a new release comes out, it’s often the case that a bulk of that large script is unchanged. And yet, users have to download the entire new script even if the old script is still cached.

Josh and James work on Google Maps which has a main script that is ~300K. A typical revision for this 300K script produces patches that are less than 20K. It’s wasteful to download that other 280K if the user has the old revision in their cache. That’s the inspiration for Diffable.

Diffable is implemented on the server and the client. The server component records revision deltas so it can return a patch to bring older versions up to date. The client component (written in JavaScript) detects if an older version is cached and if necessary requests the patch to the current version. The client component knows how to merge the patch with the cached version and evals the result.

With this technique in action, you end up sending down JS arrays as deltas that looks like:

[0,10,"red",40,3," leaps",25,15,16,3,"."]

The data that these guys share is impressive. The results seem to add up for applications as large as Google Maps. Do they measure up for smaller apps? If large apps have a lot of static content, couldn’t that content be put into another download and even app cached away?

Also, it is a lot of work to implement this for a developer. Work on both client side and server side. It would be great if we can experiment with Diffable and then move things lower into the stack. Why can’t HTTP itself be smart enough to deal with diffs?

It did make me think of my favourite chaps @github. I know that GitHub is about development rather than deployment…. but what if they supported this natively (since they kinda grok diffin’ etc already) and offered a client side loader so you could github.load("project", ...).

It all just makes me realise that GitHub is poised to pounce in many directions. Good on ‘em.

Feb 15

Building an Web application from the inside out; Using node.js to bootstrap a server from client JS

JavaScript, Open Source, Tech, webOS No Comments »

Over the winter holiday, Ben and I whipped together Project Appetite, an open source example that consumes the feeds from the Palm application ecosystem (both Palm Catalog and Web distribution). We didn’t have long to come up with something, and one of the interesting stories was how we took an API and mocked up the middle, allowing server and client to get going quickly.

The feeds that the Palm ecosystem puts out are RSS 2.0 XML feeds, with extra catalog-y info in an “ac” namespace. We converted the format to JSON to make life easier for the JavaScript client consumer. Although you can DOMParser() away (and use the Microsoft component) JSON is just so much easier. What lives at is the result of the munging, so others could consume JSON directly if they so wish.

The Data

We quickly put together some dummy data, and for ease, put it in a file app.js that the client could consume. Once we iterated on the format, one of us could go off and write the XML to JSON code. We actually implemented this in a variety of ways as we experimented. Ben created a simple JDOM translation, and I fought with databinding, which still seems to be a royal pain with Java. The reason I checked that out was to create an open backend on app engine, and I wanted to go from XML to JSON to Java for persistence via JDO. From one set of Java objects I could @PersistenceCapable and @XStreamAlias("asset_url"). It wasn’t worth the effort.

The Client

We created an Appetite object that would be able to query the model and get the data that was needed. The constructor took the apps data, and then it did its magic. In this case is created some caches to make querying fast.

The public API contained:

  • app(id, locale): returns a single app based on id
  • find(opts): the core engine for querying the app data
  • types: contained the logic for filtering on top rated, top paid, newest, etc
  • sorts: contained the sorting functions to return the data in the right order (e.g. by download count versus date)

Very quickly the client was mocked up and the frontend was build out using this API. Again, at this point the entire front end could be built without waiting for server infrastructure.

The Server

Since the client API mocked out the functionality needed for the frontend, the server could actually reuse this logic. This is when the node.js server was born.

To play nice with node, we went back to the other files and added logic to export the data. E.g. in the client.js:

// check to see if you are running inside of node.js and export if you are
if (typeof GLOBAL == "object" && typeof GLOBAL['node'] == "object") {
    exports.Appetite = Appetite;

Once that was in place, we could load up all of the information that we need:

// -- Load up the libraries
var sys   = require("sys"),
   http   = require("http"),
   posix  = require("posix"),
   apps   = require("./apps").apps,
   client = require("./client");

And then we can get access to the client API via:

var a = new client.Appetite(apps);

We created a simple mapping that enabled a URL such as /app?id=[id]&locale=* to be converted to a method call of app({id:id, locale:locale}). We did this in a generic way that enabled us to add URL endpoints by simply added to the responder hash. The functions would return an object that could contain error codes and the like.

For example, the app end point:

// /app?id=[id]&locale=*
app: function(params) {
    if (! {
        return {
            error: 501,
            body: 'I need an id!' 
    return {

We also added a magical DEFAULT handler to take care of bad URLs.

Finally, we would boot up the listening server and handle responses:

// -- Create the HTTP server binding
var host = process.ENV['APPETITE_HOST'] || 'localhost';
var port = process.ENV['APPETITE_PORT'] || 8000;
if (process.ARGV.length > 3) { // overwrite with command line args
    port = process.ARGV[3];
if (process.ARGV.length > 2) {
    host = process.ARGV[2];
http.createServer(function(request, response) {
    var path = request.uri.path.substring(1);
    var output;
    var responder = (typeof responders[path] == "function") ? responders[path] : responders['DEFAULT'];
    output = responder(request.uri.params);
    var contentType = output.contentType || "text/javascript";
    if (output.error) {
        response.sendHeader(output.error, { "Content-Type": contentType });
    } else {
        var body = (contentType == "text/javascript") ? JSON.stringify(output.body) : output.body;
        response.sendHeader(200, { "Content-Type": contentType });
}).listen(port, host);

After 86 verbose, commented code, we had a server that would respond to URLs and return data. And in this time the frontend continued to be built out.

Being able to reuse the client JS and wrap it to become a server was a lot of fun. I am definitely a big node.js fan! Now, I am looking forward to doing a lot more with Project Appetite…. but for now we are working on a pretty cool webOS application, and getting the developer platform better and better.

Some coffee in your Node

In an aside, the node hello world has been ported to CoffeeScript:

# To run, first install node and coffee-script
# Node:
# CoffeeScript:
# In a terminal window:
# $ cd coffee-script
# $ ./bin/node_coffee -r
# Tested with Mac OS X 10.5.8, Node 0.1.26, CoffeeScript 0.5.0
sys: require "sys"
http: require "http"
http.createServer( (req, res) ->
  res.sendHeader 200, {"Content-Type": "text/plain"}
  res.sendBody "Hello, World!"
).listen 8000
sys.puts "Server running at"
Aug 03

Open Source != Open Distribution

Open Source, Tech with tags: , 4 Comments »


With the iPhone / App Store debacle a lot of people are thinking about distribution these days. As more news comes in, I definitely feel a lot closer to taking the blue pill that is for sure.

I have also overhead several conversations in the last few weeks that conflate open source and the magic of distribution.

Alex (was so tempted to say Dylan here for a second, man! ;) posted about perspective and how not only is all open source not equal but that doesn’t make something on the lower end of the scale intrinsically evil.

I have to keep reminding myself of this. When a company comes along and open sources something I am open initially cynical due to the large usurping of the term “open”. If I feel that said company is using open source as a marketing vehicle only I get defensive. One example may be Flex and Adobe. You could look at the open sourcing of Flex with a wink and say “Erm, the core platform is proprietary, so by open sourcing the pieces on top….. nice work ;)” Or, you could see that Adobe has potentially added value to the Flex community there.

For one, there is huge value in having the darn source. For example, Francisco Tolmasky just said:

No amount of documentation can ever surpass just having the source in front of you (read: thank god webkit is open source)

If you run into a bug in Flex, you have another avenue to hunt it down.

However, that is just one important surface value. Adobe could potentially get so much more out of a more open development process, including the community, etc etc. They could do well to get some more points, although that doesn’t come without a cost to. Dealing with people is hard.

The thing is, the company in question gets to choose how they open source their software. When we jump up and down over the fact they use GPL, or how they don’t listen to us, we have to realize that. That doesn’t mean we have to be quiet, and that we shouldn’t review what their “opening” could mean…. but we can still respect them. I would love to see a podcast that talks about the various forms of “Open”. I think it would open up a lot of eyes to have rigorous discussion on various case studies.

To the distribution part. Open source is fine and dandy, but how do you get your bits out to real users? That is what matters, and that is what is causing the kerfuffle with the App Store. You are in lock-down. It shows us how friggin’ awful the mobile Web is compared to the wired Web. Imaging a world where you put a website up and had to ask ONE company “hey, can you allow people to go to please?” makes you shiver… but that is the way of the world on far too much of the mobile Web. As locked down as Apple is, the world is still vastly better than the world where the carriers ruled the waves. Making those buggers just in charge and competing on creating the best pipes to the ‘net is something I can’t wait to see.

The Web won majorly due to distribution. As long as you can get someone a URL, you are there. Getting URLs to people keeps getting easier with various viral and communication systems. That Google thing helps connect the docs too.

You don’t have to look too far though to see the closing of the walls in some ways. Facebook, and the like. It seems that they have seen this though and instead of wanting to stay in their ivory tower, they want to bring the tower to all websites via Facebook Connect.

With the lens of distribution you can look at technology such as browser add-ons, Gears, Flash, browsers themselves and see that you need more than open source. It is fantastic that I could take Gecko or WebKit/Chromium and create a browser. That doesn’t mean that anyone will use it. I really like the path that Yahoo! BrowserPlus is on….. not just because they are open sourcing the platform, but because they are working on a strategy to allow people to create their own services. Gears punted on this issue. You could write up a spec and try to persuade the Gears team to put a new Gear into the toolbox, but that would be really hard. For one, it has to be tested and secured on the list of platforms that Gears supports. And, thanks for version 1, but what about maintenance? Tough problems. It still feels like we need to allow developers to “experiment on the edges” and the best platforms allow just that (hence, hoping that Y!BP takes off).

So, maybe we need a 100 point guide to open distribution to go along with the open source one? They definitely overlap. A good open source community driven process will get you some points on the distribution ladder, but you could also easily have an open distribution mechanism on a closed platform.