My Mum makes the world's best hamburgers. Mama Boothby Burgers simply rock. And I'll fight anyone who says otherwise. But, unfortunately, only an insignificantly tiny portion of the population has ever had the opportunity to sample these incredible culinary delights.

The problem is distribution. There are tens of thousands of McDonald's restaurants. But only my Mum and I know the recipe for Mama Boothby Burgers. We lack the distribution channel.

Distribution on the Web - OurSite.com

In the world of the web, the dynamics and economics of distribution are completely different. It costs money to open up new restaurants. It takes time to build a huge distribution channel in the physical world. And, for the first ten years of the web, people assumed that the same was true. Out of force of habit, they thought of cyberspace using a Real Estate metaphor. URLs became really valuable. Search has changed that. Star blogger Robert Scoble went from scoble.weblogs.com to scobelizer.wordpress.com to scobelizer.com with barely a blink in his technorati ratings because people could still find him with search tools like Google and Technorati.

The new rule on distribution: It's not how many people visit your site, what counts is how many people you can reach.

This is the lesson of YouTube. Figure out a way to embedded your service in our people's distribution channels. And, for Software as a Service vendors - figure out how to make money while doing it. OK.... maybe YouTube hasn't figured out how to make money. But the writing about distribution is on the wall.

By distribution, I mean new ways to deliver web services within the context of what an end user is actually doing. Here are some practical examples of what that means:

• A blogger who is more likely to write about a video if the blogger can embed the video in their blog.
• An employee who is more likely to use an enterprise 2.0 solution if blogs as Activity Centric Blogs, which are focused on helping that employee get their work done.
• A sales person who finds it useful to be able to access their address book in the context of a sales tool, but also wants to use that same address book on their phone, in their email.
• Anyone trying to leverage their social network outside the barriers on an online social networking service.

Emerging from Under the Radar

In a few of weeks, Teqlo is going to be presenting at UNDER THE RADAR | Why Office 2.0 Matters. [Just to let you know, I work for Teqlo] It's going to be an interesting event.

I think it will be remembered as one of those conferences where an inflection point becomes obvious. In this, it is the beginning of the movement from the read/write web that has propelled the success of blogs, wikis and every kind of user created content vision Web 2.0 to the executable and recombinatorial web.

The executable and recombinatorial web is a new phase in how people will use the web. They will leverage a collection of technology including things like Pipes, Open Kapow, and Teqlo, and combine them with services such as Big Contacts for managing their contacts, or Extentech for managing their spreadsheets, or DabbleDB for storing their relational data, or Strongspace for their back-ups.

The end result will be highly customized applications that exactly fit the context of whatever people are working on.

What are the business implications?

Here are some questions that businesses will need to think about:

• If the web is refactoring the way that software is delivered, and used, what are the common services that everyone will need? I can tell you, for example, we all need an address book.
• How do you handle Identity in this framework? AOL, for example, just annouced that they are going to support OpenID for all their users. What's not clear here is whether they are going to accept OpenID authentication from other authentication services. Can I use my bank to authenticate me into my AIM session. If not, AOL's OpenID isn't exactly open. More importantly, for all the small vendors out there, are they going to be willing to work with a federated ID system. The point is that if you combine 12 different web services in one mash-up, how do you handle ID?
• How do web service vendors with APIs to high value services make sure they get paid for those services?
• What's the end user ease of use tipping point? How drag and drop easy does it have to be before people suddenly catch on?
• Do screen scrapping robots like Open Kapow mean that SaaS vendors have to figure out how to open up their systems? The Lotus Notes crowd, for example, doesn't believe that you can screen scrap your way into a sophisticated application. Open Kapow, of course, proves that they are totally wrong about that. Regardless, will end users simply migrate from closed systems with no API to open systems because they want access to these services in the context of a DIY mashup application?
• How do you handle metering for services? Mashery has one answer.

It'll be interesting to see how it all plays out.