what devs need (the "apps pump")

[Michiel de Jong]

hi!

today, like any day, is a good day for a brainstorm! :) so let me know what you think of the following analysis:

i've been saying we need an "app store", without defining what that is, and i'm starting to see some more details now, i think.

the apple app store is a monolithic closed thing. on the web, it makes sense to not only make it open source, but to keep its separate functional parts independently open. towards the user, as well as to the developer, you need to give a coherent experience, but the different aspects of what's behind it don't need to be developed as one monolythic thing at all, i think. Six parts:

- the web apps metadata standard. this is the interface between the app and the "store". mozilla has already defined this. their definition of the manifest file is largely compatible with the chrome one, so that's more or less already a solved problem.

- indexing: i was thinking about the monolithic app store earlier, but if you are talking strictly about reviewing, categorizing and recommending apps, it makes more sense if people just blog about apps, and create feeds and wikis about them.

- monetization: there is a monetization problem for web apps, because banners are more likely to be clicked on when reading about apps than while using them. when you're browsing apps, you're looking for something new. when you're using an app, you're busy. that means clicks of sponsored links go to the reviewer, not to the publisher. so the reviewer would need to channel that money back to the publisher somehow. with brandware, this might be possible.

- mirroring. my proposed alternative to chrome's centralized repository of packaged apps is a sort of hash-based hosting. this is really fun stuff, i've been calling it "apptorrent". like bittorrent for apps. but over http! Basically, once a web app is packaged, you can do two things with it: 1) move it around to mirror sites, and 2) calculate/publish/verify its checksum hash. a trusted bootloader web app can fetch a web app, check its hash, cache it, assign a fake subdomain origin to it, and start it up. this enables peer-distribution of apps, independent of DNS. all from the browser of course, just plain old http mirroring. but setting apps free in a significant way, i think.

- publishing tools: i think we should take ace (the editor of cloud9) and connect it to a packaging script that warns about which parts are missing, and if everything is correct, outputs the manifest (hosted) or a handy one-file sausage, and push that directly into hash-hosting. (and while we're at it also push it through the PhoneGap builder to make 6 more sausages, so we can reach out to those poor users in the non-free worlds).

- a launch pad app: an app that shows you icons of the apps, like a dashboard/launchpad/control panel/desktop surface/start menu, full of nice icons. after all, that's what this is all about in the end: access. one-click launch. install, group, regroup, move, delete. that is what the "app" metaphor adds compared to the web as it is. that, and ways of finding new apps and publishing your own apps, finding new lists of apps, and publishing new lists of apps.

So six parts. we would need to put time and effort mainly in the developing the last two: good publishing tools and good launch pad apps. the hash-hosting is easier to hack together and keep revising as the other two evolve, metadata and indexing are more or less solved, and monetization can evolve afterwards. at least that's what i'm thinking today. this is all live brainstorming, so i might think something else tomorrow.

cheers!

Michiel