@Rbpasker I didn’t mean to imply this architecture stack was limited to browser scenarios. I suppose I meant to say “client”. Delivering and running code _solely_ in the browser/client limits security and authenticity. This isn’t to say there are ways to improve the environment, but as soon as code is downloaded as source and executed (i.e. JavaScript), additional mechanisms need to be in place to ensure authenticity of requests, even if it’s just secure pipes (HTTPS/TLS/SSL). I agree that platforms that include a monetization component are key (and clearly more than just ad network integration). Imagine an e-commerce offering without a shopping cart and credit card processing; it seems absurd to think of it now! The market may be a bit immature yet, but I do think serious applications of the technology will emerge that will provide their own value to the market, driven by engagement via social networks and social applications that will continue to emerge across the Web.

@Chris Based on what I’ve heard (especially from e-commerce companies), I think you can’t help but have a monetization dashboard. No matter which of a dozen ways your particular app/gadget/widget can make money, it needs to be measured and tuned. If you choose to, you can also expose some of these statistics to the users. There will always be someone who won’t sign up until the ROI is justified, and without any kind of measurement, that’s going to be a tough sell. Some of the monetization models may augment or even replace other interactive marketing and advertising models as well, and we know those are highly metrics-driven. Bob Bickel wrote a good blog or two on that topic, comparing social application engagement to traditional keyword advertising here:

also, I’m not arguing that pieces are not done (eg Heroku), but rather than developers will come to rely on a suite of technologies to successfully develop, run, and possibly monetize their work.

Some of the items on this list should be handled by the “substrate” (the Fountain layer in your other slide set), and the rest should probably be part of a platform for social applications (which I don’t think are limited to widget/gadget). The widget/gadget architecture limits the possibilities of apps by running everything in the browser. The Facebook architecture is a little more interesting, since the application really looks like a traditional component in a platform stack. Interesting in how disruptive it is, too, taking over ground that was previously occupied by more complex technologies like WSRP (that never really went anywhere).

I certainly hope that the business management layer is about more than ads, though. I’ve written myself about how the business of applications needs to be more than just ad-supported, since traditionally applications compete with the networks that host the apps for ad space and mindshare (talk about channel conflict…). There will be opportunities eventually when social networking technology is more pervasive and more sites are able to integrate social applications into their core web presence.

@Seth I think the app dev parts are _mostly_ solved. The interface with social networks is currently limited to those actions the social networks are interested in supporting. There’s nothing inherently wrong with that, but applications might be interested in having more services provided by the networks they attach to. This is more than just Rails, etc.; it’s about how social context is passed around the Web.

However, it’s odd to me that AWS or GAE neither have a robust Application Management setup yet. No off the shelf backups, DNS management, recovery, etc yet.

I was looking into Amazon’s offerings last night and was impressed by the depth of the services they’re starting to offer. Too bad their documentation is a little sparse. DevPay in particular caught my attention with all of the stuff I’m currently working on.