The “app store” concept has been very successful for Apple (iTunes App Store) and Google (Android Market) in the mobile space. But, what would an app store for web apps mean? During Google’s announcement for Chrome OS, Sundar Pichai, Vice President of Product Management, said “the Web offers hundreds of millions of applications” and that Google’s job will be “to make people aware of them.” (starts around 48:38). “Hundreds of millions” is a big number but in the context of 1.7 billion Internet users worldwide (with many users using multiple applications) the arithmetic “smells right.” So, what would a web app store do? The purpose of any app store is to reduce the friction of connecting a user to applications. What are the areas of friction that can be greased?
Vital Stats and Payment
There are many companies that are working on digital wallets. A web app store could integrate with 1 or more of these. This means that the customer only needs to enter vital info once and, potentially, payment information once and then easily share that among all of the different applications purchased.
Customer Acquisition
The web app store creates a marketplace for applications that drives customers to the apps. This means that the application developer cedes a portion of the revenue of their app to the app store since the application developer will be incurring lower customer acquisition costs.
Aggregation
Most tasks take more than one application to complete. I wanted to create a favicon from a PNG logo and it took 3 tools to do the job. Being able to blend multiple applications together into a single holistic solution is extremely powerful since people buy solutions.
Web App Store Road Map
Instead of a closed web app store (like the iTunes App Store), let’s use an open standard. That way, applications can show up in multiple stores or be “added on” by other applications (like BigBrassBand does with Spreedly). The app owner should get to decide which web app stores they show up in and what the pricing is to that web app store. The API should be simple to implement, accessible over HTTP, and return results as XML.
With this in mind, I give the world the Web App Store API (draft). 
Here’s a summary (in a theatrical bent):
The Actors
- App Store – The web app store. This could be a dedicated store or an application that wants to be able to include other applications as add-ons. Heroku’s AddOn’s page is a great example of this (you can buy SendGrid service, New Relic service, etc… as you are buying hosting or even after).
- Customer – The person with money who buys applications!
- App Owner – The application developer who is offering a web application for purchase.
The Props
- Agreement – A ToS, Privacy Policy, or other legal notice the customer must agree to before purchase.
- FeatureLevel – A feature level of the product that the app owner is selling. You’ve seen this before — Silver, Gold, Platinum, and Diamondium are all popular names for feature levels.
- SecretKey – A secret string known only to an App Store and an App Owner. This is how an App Owner positively identifies which App Store is calling.
The Script
There are seven (7!) methods in the API. They are all implemented by the App Owner and called by the App Store.
- featurelevels – the list of products available to the App Store. This could just be a static XML file.
- agreements – the list of agreements that a customer must accept to purchase a product. The App Store promises (honest!) to make the customer accept these agreements before allowing the application to be purchased. This too could just be a static XML file.
- customerrules – Does the App Owner require the customer’s e-mail address? Does the App Owner require a username? Are there custom fields that should be presented to the customer? These questions and more are answered by the return from this method — quite possibly a static XML file.
- paymenttypes – the list of payment types (credit cards, Amazon FPS, PayPal [an Adaptive Payments Chained or Parallel payment could be very compelling here], etc…) that the App Owner supports. A static XML file? Almost certainly.
- validatecustomer – This is an optional API and the first one that really, really needs to validate the SecretKey. It checks username uniqueness, that all required fields are present, etc…
- submitcustomer – This takes the same arguments as validatecustomer and returns line items that will appear as a charge summary (product price, sales tax, etc…). This is everything that is required to generate a “Purchase Confirmation — Click Here to Purchase” page.
- activatecustomer – This signs up the customer — just like if they had signed up at the App Owner’s site.
What next?
Dave Winer says on open standards that “someone goes first.” We’ve taken that first step. Now, it’s your turn.
Comment on this open API below: Critique, point out what’s missing, suggest things to change. By firing this standard in the crucible of a public discussion, we can end up with something we all want to use and not have to live with arbitrary store rules laid down by Google or Apple.
natedog
Recurly
This is an intriguing idea- and I think one that is beginning to finally coalesce as greater levels of openness and inter operation are being embraced by developers. This collaborative approach to solving the multiple challenges around enabling a user to find an app, and then purchase it in a seamless and secure is something we definitely support. We'd love to find out more as this develops and see where we may be able to assist. So far, sounds good 
Post a NEW Comment :
WHAT DO WE DO?
Your business is spitting out lots of data that you either ignore or spend too much time looking through.
BigBrassBand relates and presents your data in an action oriented format so that you:
1) do the things you need to be doing to be successful,
2) reduce the amount of time it takes to do those things and
3) have more time to spend building your product, going to conferences, or playing with your kids.
teich
Interesting idea. First blush, I wonder if a standard will work, or if the customizations necessary for each “store” (like our add-on catalog) will mean that there's so little transportation that it's not worthwhile.
Some specific feedback – how about JSON instead of XML? We're 100% JSON.
I think there may be two actors (or more) missing:
* the app itself. Separate from the app owner, the app is a running service with it's own lifecycle and needs
* the service that is running this stuff. Big Brass Band isn't the app store. You have an app store on big brass band, like we do with our add-ons. those concepts are separate though. Once is the catalog, the other is the integration of services actually running.
There needs to be an API callback FROM the app back to the store. If the app changes something (a server dies and has a new IP address, username is changed, update to some object, etc) the running service needs to know about it.
Probably a lot more, but off the top of my head that's what comes to mind.