Recently in Transcript Category

Sean: Good morning everyone. As Lee said, I'm a founding of Nauiokas Park. For my sins, I was a banker, a trader, for about 15 or 16 years. Maybe to my credit, I resigned from that industry at the end of 2006. I thought it was remediably broken. I've since started my new firm which is focused on principal investments strategic advisory in technology-enabled disruptive business models, financial services, and markets.

Why am I at eComm? I'm not really sure. I'm very pleased to have been invited. It's very exciting, but I don't know anything about telecoms, other than as a customer, both enterprise and consumer. But, I think there are a lot of similarities between the two businesses, and increasingly so, and that's because they're digital businesses.

I'm going to talk to you about platforms, markets, and bytes, the economic landscape of the sixth paradigm, or maybe I should have said the industrial landscape of the sixth paradigm. I'm going to try to answer these questions in 20 minutes. I'm going to be broad, not deep, so indulge me if I skate over a few points, and some of these I explore in my blog in more depth. I'm happy to discuss them afterwards in more depth.

In a world where everything can be expressed in 0's and 1's, the way we define our economy, the way that industries are structured, are they still relevant? If not, what new business models or structures are going to emerge, and maybe to focus on this and to give an example; what's the difference between a bank and a telecom company?

Before I get into that, I want to give a little bit of background in terms of a framework of what I'm thinking. What is the sixth paradigm? If you haven't read it, you should, Carlota Perez is a Venezuelan economist. She wrote a book called Technological Revolutions of Financial Capital, builds off of Schumpeter, talks about long economic cycles that, in her thesis, are driven by technological revolutions.

Since the first one of the modern era, which was the Industrial Revolution, she posits that there have been five. Each of these revolutions is accompanied by a set of best practices. The economy, the society, and the institutions need to adapt to this revolution they change. You get interesting affects in terms of how the economy diverges from the financial markets and a lot of this, again skating over it, has to do with the fact that technology tends to move exponentially or adoption of new technology moves exponentially whereas our social and cultural institutions move linearly. There is a divergence and it takes us time to get our heads around the way the world will work in this new paradigm. She calls it a "techno-economic paradigm".

Here are the five that she's identified: Industrial Revolution, Steam and Railways, Steel/Electricity, Mass Production, and the last one is the Age of Information and Telecommunications. My thesis is that we're coming to the end of that fifth paradigm and we're about to enter the sixth paradigm.

There are a lot of similarities, I think, between this one and the one at the end of the 19th Century, in terms of what we're seeing. Today, the financial crisis we lived through might be analogous to the oil crisis marking the end of the Age of Information and Telecommunications. I'm not going to go into that too deeply.

What will drive the sixth paradigm? Guessing, because as she points out you can only really tell in hindsight; it's very hard to identify these as they're happening, but I'm going to have the hubris of a banker to try to guess that maybe this is it; cloud computing - cloud computing may be a catch phrase, but ubiquitous computing storage might be the technology that drives the sixth paradigm, where you have "everything as a service".

She picks archetypal points - Intel's release of the first microprocessor in 1971 launched the Information Age. It's not that simple; it's a cluster of technologies, a cluster of people, but if you have to pick one for this, maybe it's Amazon Web Services 2006/2007 launching EC2 and S3.

Another factor driving the sixth paradigm is what I call "exchange ubiquity". I didn't really have a good catch phrase for this. Exchanges are now everywhere. Traditionally when we say exchange we think of financial exchanges. Betfair took the exchange model and applied it to another business very directly, which is the business of betting on sports. It goes beyond exchanges. Really, it's marketplaces and everything. iTunes is a marketplace. It's a marketplace that started for music, now videos, and tomorrow any digital goods - maybe. Facebook is also a marketplace. You've got the applications on top. Maybe it's a stretch, but things like Skype are marketplaces for voice communications.

Underlying marketplaces, and maybe this is where eComm - communications is at the heart of a digital economy. Alexis Richardson, who is the Principal behind RabbitMQ, which is an open-source messaging software, said "The difference between bank messaging and telecom messaging is disappearing." That's more and more true, every day.

The last one is maybe digitization. This one is fairly self evident but if you look at when I'm talking about digitization, it's transforming physical goods into digital goods for the purpose of trading and managing them. A great example is ISINs in the securities industry. Not so long ago, 30 years ago, the securities business was a physical business. You had certificates that were biked around the city of London, biked around, or driven around New York when you wanted to trade shares or bonds. Today obviously, it's a book entry. Every security is identified by its QSIP or ISIN.

VoIP, I'm not going to teach you guys anything. Obviously, voice is turning into a data business. Amazon, Jeff Bezos, his insight was with the ISBN database he could transform books into a digital good that could be sold and managed. There is obviously a physical supply chain, but it's right at the end of the business. The heart of the business is a digital business.

To take this a step further, there is a disclosure; Zoopla is a company we've invested in. It's a U.K. property portal, but it's a very interesting one. It has a database of prices on all 27 million U.K. residential properties and an enormous amount of metadata around it, and using AI, increasing every day. You can imagine a future not too far away where every property has a Zoopla standard identification number, and you can trade that property, manage it, insure it, mortgage it based on that number. If that existed today, or 10 years ago, we wouldn't have had the extent of the problems we had in the securitization markets, which were driven by bad data.

How does this translate? I think there are two people that are worth thinking about when you're thinking about how this affects the new industrial or economic paradigm, Ronald Coase and his Theory of the Firm; basically transaction costs drive the optimal size of a firm in any industry. I would posit that transaction costs are changing and dropping massively, and that's got to have an effect on the way the companies are structured, and industries are structured. I'm not sure it has, yet, but it's inevitable.

The second person I think is worth reading and understanding is Herbert Simon, who is a psychologist of polymath, who really did a lot of research on complex, adaptive systems. Our economies are clearly complex, adaptive systems and his thesis was, or what he discovered was that complex, adaptive systems wherever you found them, in nature, in our economies, in mathematics, tended to be more evolutionarily fit if they had a property called "nearly-decomposable," a mathematical property that essentially, without putting up the back of all the mathematicians here, means that systems that are formed of components and subcomponents, modular. Again, this is something that intuitively, I think all of us know, especially in the computer or software industry. You build programs in nested objects and decompose the complexity of the system.

This leads us to a world of bytes, and to give you a quick example, I'll let you read this, but I just want to prove the point that almost anything is becoming a digital good, in the heart of the system. At the edges it might be physical, but in the heart of the system, it's a digital good.

Here, gas, the industrial company Shell, you think that's not a digital business? I think it is. Markets, any structures that allow any buyers and sellers to exchange any type of goods, services, or information. Again, abstract markets further out and you could start doing that in this digital world. Platforms are absolutely key in terms of business models and strategies, going forward. This is something that, again, is second nature to the computing industry, but I think in the digital world it's going to become more and more relevant for almost industry.

You've got a new stack for a modern economy. You've got physical platforms, digital platforms, and if you haven't read Invisible Engines, and you want to understand digital platforms and how they work and the economics of them, you have to read this book. On top of those digital platforms, you have APIs, which serve applications and services at the top of the stack.

The traditional industry of corporate structure was very much a vertical structure. If you look at Tyrannosaurus Telecom and Bank Brontosaurus, these are vertical entities. J.P. Morgan, British Telecom, KPN, they have everything from top to bottom and they're organized on the principles, I think, of the fourth paradigm, which was Sloan's Mass Production hierarchies and where transaction costs were very high. It's not that these business models are intrinsically wrong, they were very well adapted to the 20th Century. I think they're very ill adapted to the 21st Century, and I think some of the things we've seen happen over the last decade, first in the telecoms industry in the late '90s and the financial industry more recently, are manifestations of this misalignment of the structure of these industries against the fundamental economic structural underpinnings.

I think the new optimal industry corporate structure will be much more of a horizontal structure. You can have various different components in the stack within the same organization, I think, but the way of thinking about it needs to be much more horizontal. You have physical platforms again, and this is something I always laugh about; I'm not in telecoms but whenever I read articles about the latest, greatest new thing a big Telco's doing, it's to avoid becoming a dumb pipe.

What the hell is wrong with being a dumb pipe? Being a dump pipe can be a great business model. In fact, what's more important; the problem with the vertical stack is the capital structure is horrendous to align properly to an organization that is organized vertically. Dumb pipes, you finance them with debt; they're cash flow driven businesses. There are a lot of businesses in the world that would be considered dumb pipes. If you look at the satellite business, they don't sell services. They sell satellite access. These businesses are performing very well. You just need to align your objectives with your capital structure with the way that you're structured. You have real economies of scale here. This is a dimension where size does matter and you can use it to good effect.

Next up, the stack - the problem with these stack analogies is you have bottom, middle, and top. Everybody thinks that minds are tuned to think top is better. I'm agnostic. They're just different things in the stack. Digital platform, it's a substraight - you create a substraight for an ecosystem of services. Selling trust, I think, is one of the ultimate things you're doing. It's necessary that you have the technical capability to build something useful, but it's not sufficient to be successful. I think to be successful, you need to effectively sell trust that it will work and that people can rely on it. In doing so, you create markets.

Here again, you also have economies of scale, different economies of scale, but economies of scale nonetheless and probably more pointedly, this is where Metcalfe's Law of Networks, especially for multisided markets comes into effect. I love quote from ReadWriteWeb, "Well built developer platforms are the future of every industry," and I think they got that spot on.

Digital platforms, with APIs allow people to build services and applications at the edge and this is where innovation should happen. This is where you need rapid adaptation. This is the Cambrian explosion. This is where any big company will structurally fail if they try to play in this edge.

I speak from experience. I tried to do this. My last employer, Dresner Klein, which is part of Alliance which is a huge financial conglomerate, I guess my "aha" moment was understanding it wasn't because any particular manager or group of management was dumb or didn't get it, or was wrong. Structurally, these big firms, actually the better run they are the harder it is for them to innovate at the edges because innovation is looked at as a virus and the corporate antibodies, the well-oiled machine does everything it can to stop that from happening.

Here you have dis-economies of scale. Dis-economies due to complexity, so bigger here is not better. It's worse. It's not even neutral. Low capital intensity - take an extreme example, the startup world, you're financing it with options through equity. You don't have debt finance. If you look at businesses where you have a mix of the two, and there are a lot of them in the financial business because you've got risk capital; Imagine the telecoms business, as well, risk capital at the bottom which is almost the equivalent of a physical platform, which might be debt financed or the expectations in terms of returns are limited but relatively certain. At the top you've got very deep, out of the money options, highly volatile, low capital intensity. You try to marry those in the same instrument, the same capital structure and nobody is happy.

Coming back to this example of Shell, in that example; who is the bank, who is the Telco, where is value created? It's not as obvious as it first seems. This is a friend of mine, Richard Water who works for IHS. He said, "Isn't it just all FX?" It's gas molecules, FX transaction to electrons, FX transaction to Sterling if the electricity is sold in the U.K., FX transaction to Dollars; back to Shell, paying for the gas. It's all a digital transaction and just modifying the same thing across the value chain.

Already, banks and telecoms are more similar than they look, and a lot of digital businesses are. If you look at the process stack of these two industries, and you could probably expand it, you've got enormous similarities. In the front office, again this is probably least intuitive, but if you're managing massive trading flows, they're digital now, the problems that you face are very similar to the problems that telecoms operators face in transacting and managing massive flows of data over their networks.

The other factor is customer account service: online payments, security, customer statements, customer support, and the trust around that. These are maybe more obvious, but again, it's the same thing.

If we're not there, or if that's not the right business model, then what is? I think the companies that will emerge over the next two decades in the sixth paradigm, that will become the giants of the sixth paradigm, are companies that are Messaging and Co., Trust Inc., Identity Ltd., where they're integrated along the horizontals. That will allow us to have an ecosystem of banking as a service.

Disclosure, this is a company we've invested in, FX Capital Group, RabbitFX. They offer FX physical brokerage, so if you need to buy Euros, if you live in the U.K., or vice versa, they offer one thing, one very small thing, very simply, very well, and they only exist because they have an enormous infrastructure e-platform, digital platform underneath them - the banking system, the payment system, the trading system that allows them to do that.

Another example is a fantastic example and really is a convergence of telecoms and banking. It's Frontline SMS, some of you might have heard of them. They just launched Frontline SMS Credit. They're focused on developing markets but they could operate anywhere, I think. This is a company I'm not involved in but I'd like to get involved in. They actually run as a not-for-profit, but they have built a platform that allows you to do messaging, building off of the global mobile network, via a computer, to do mass messaging and manage that. With the credit adaptation, their tagline is fantastic "It's a bank on a laptop" and that's what they'll be able to offer.

On the telecom side of the equation, voice is a service. We have that already, companies like Ribbit and others, so what I'm saying is not that companies won't be organized or have elements of all of this stack, but if they do have all of this, if it is a very large company, they need to be thinking about it in this way. Then perhaps, maybe get involved in some of the stack at the very top level, as a proof of concept or shop window, and also where it's obvious they have brand value.

Telecoms company and voice, banking and some of the payment services - they need to have open architectures and learn from the computer industry; where are the AWSs of banking, of telecoms? Where are these platforms? Why isn't J.P. Morgan opening up its platform and saying, "You guys innovate on top of it," instead of trying to do all of it in house? Where is the AppStore for finance?

You look at companies like Amazon, Apple, Facebook, Microsoft, all enormously successful, and much of their success if predicated on the fact that they build these platforms that allow other people to innovate and work on top of them.

My conclusion is that in our industries of finance and telecoms, we need to shake up the stack and we need to think of this new industrial landscape. We need to start thinking in a context of a sixth paradigm, not a fifth paradigm; 21st Century businesses, not 20th Century. Thank you.

Chair: That 20 minutes should be expanded into a book. It's quite clear that all the topics covered there each would be a chapter. I'd be really excited to see if a book gets made out of it. I think a book should be made out of it. I really enjoyed that. Questions from the audience? We have Jim here. You may need to stand up so we can see you.

Audience: I notice an emphasis, everyone wants to talk about the bits, and Negroponte used to think we have to talk about both bits and atoms. The atom side of what you just discussed, I've worked with hardware distribution models. Again, it's the same sort of thing. The distributor is running on top of a layer of financing to move goods from one person to the other. I'm really seeing and I'm getting into that area again. My question is; have you looked at these in terms of that sort of thing too, in terms of distributing hardware and hard goods?

Sean: I think the poster child there is probably again Amazon. Amazon couldn't exist or their business wouldn't exist without a very excellent logistics and distribution arm. Part of Bezos's genius was A) raising a billion and a half dollars from a convertable bond before the dot com bust happened and B) spending that money building the physical infrastructure he needed to properly run his business.

In this vision of the future, the point is not that the physical world will disappear, but the management thereof can become an abstraction, which liquefies it enormously. Both the management and a point you raised that I really didn't touch on, the financing, and one of the reasons I left banking was I became increasingly frustrated at the way that finance was delivered.

The way that banking and finance is delivered hasn't changed in 400 years, since Monte di Pietà in Italy in the Renaissance. It's the same thing, just bigger, faster, better. I'm sure that now with the tools that we have, it can be much more modular, flexible, adapted - this idea of abstracting from a pool of risk capital to the way it's engineered and placed.

The great example is a company we're invested in called WeatherBill that does weather insurance. The way we build the company is the underwriting is done by a weather fund in Bermuda. We've abstracted - all we do is price and originate the risk within WeatherBill. Again, the reasons the banks don't like that is that when you do that, there is an element of transparency and the more you do that, there is more and more transparency because the stack can only work if there is transparency. Banks love the fact that there is this big black box and there is opacity. They try to, and are often very successful in taking oligopolistic rents from that lack of transparency.

I think inevitably, the tide is moving that way and you'll get this abstraction of the economy into various different layers that's made possible because of this digital technology. Conceptually, you probably could have thought of this 200 years ago, but actually translating it into something that pragmatically works, at a cost that is not prohibitive is only something that's happened in the last few years, and it's continuing to happen.

Audience: Do you think that such platform companies should operate publicly toward the end customers, or should they hide between [00:24:42.06 ?] aggregating platform services vertically, and proposing niche services towards parts of the classical customers for big [00:24:53.10?]

Sean: I think it's the latter. I think it's a mix. For instance, take the example of either a telecom or a bank, and it was a point that I tried to make at the end; not that they should completely retreat from that edge, and I actually think that could be dangerous. You want to have, whether it's a shop window or certain areas where your brand or expertise really does add value at that part, and even the last thing and probably the most important over the long term is just to keep yourself honest, eat your own dog food, to have applications or services that are consuming your own platform. It's an early warning system of does it work or not.

I think the risk is, and humans work as pendulums, maybe the pendulum will shift too far the other way. When I speak to people, I probably emphasize more this idea of really separating those two businesses, because most of the people I speak to or most contexts is they're so deeply embedded. I'm trying to over exaggerate that separation.

The short answer is I think it's a mix, but the way that management thinks about it is absolutely important. It's not trivial, the fact that if they're looking at the business in that way, even if they're doing every element along the value chain, it's very important for the way that they're going to structure their offering.

Audience: Your proposition of "everything is a service" seems predicated on people neither wanting to own things or that providing them services is always the most efficient, when practically speaking you're going to have issues of network capacity, or availability for example. How do you blend the "everything is a service" vision with the more pragmatic desire or requirement of people to own physical devices, applications, and so on.

Sean: That's a good question. First of all, if Carlota Perez is right and then in terms of her thesis of how the economy evolves, and then if I'm right in terms of this is the start of maybe a new paradigm, I think what you just raised is a perfect example of the divergence in technology in our social and cultural intuitions and frameworks that we work in.

I think for the next few years, there is going to be an increasing disconnect between those two, and at some point, maybe 10 or 15 years from now, it might actually boil into something that's quite traumatic for the economy, as the technology pushes our economies into that direction of everything is a service, and our cultural prejudices mean that we're not adapted to live in that kind of a world. Forty years from now, those will realign.

I think the reason these cycles happen maybe this way is partly generational. The cycles have to do with human lifespans, to some extent, because people who grow up in a certain paradigm get comfortable with that. They actually reach positions of power very late in that paradigm, probably, and that's where you get this tension. But, the new generation coming through, so anyone who is born today or my children for instance, probably won't have the same context in terms of how they consume goods, services, and how they relate to the world around them.

I think naturally, that adaptation will happen only with time, and in the short term, you'll get the classic tensions between where the technology is pushing us and us digging in our heels, not wanting to go there.

Chair: Thank you very much.

Sean: Thank you.

Chair: It's Stuart Henshall. Please welcome him.

Stuart: Thanks Lee. Yesterday, I was pretty excited when the first presenter of the day, Martin Geddes, said "Today we've got missed calls. Tomorrow, the phone will tell you why you should call back." I thought that was great. I've sat and listened, and I've listened today to a number of comments about messaging. I thought, "Hmmm, maybe I'm on the right track." I want to find out from you, today, whether or not I've got a really interesting solution that I can take on the right track.

I'm going to try to push Martin's solution a bit forward. I'm going to use Twitter, but Twitter is not really the only way we could handle this solution. If you search Twitter, you'll find out for "call me" that all sorts of people are using Twitter to talk, all the time. Everybody talks; it's natural on a social network. At the same time, they're also saying "Skype me" so what happens? They jump out of the Twitter network. They jump onto another network. They find another ID and they expose themselves in another way. There are a whole bunch of things wrong with that.

So, she says "call me, text me" but I'm not even sure who it's directed to. One thing that is different about Twitter in comparison to all the IM networks is that an @ message is similar to a ring. Everybody gets it. It's always delivered. Hmmm, timely delivery - if any of you have played with Twitter, you'll know that unless you've got some special notification app or otherwise, these @ messages might be picked up three days later by the person you're trying to communicate with.

We just saw a great demo from Tim. I think this is a really neat and important element. It says when we put calls in the flow, that's actually where we want them. There are a lot of advantages for that because the calls also become searchable. We still have this problem. DM or Skype user name, there are too many extra steps here to actually escalate this conversation. All this person just wants to do is have a quick conversation. It's a one-off event. We also know that Twitter can be public or private and some of these things should be private. It's great that they've got a notification system that actually accelerates things through DM and in some cases SMS messaging, which actually arrive on time and very quickly.

Here is another message. It looks like he's having a Skype call on Sunday. Isn't this something you do all the time on Twitter, you pile in on a conversation. Wouldn't it be nice if you could pile in on this Skype conversation? Think about it; Twitter provides a pretty neat sort of caller ID. It's my profile. I've chosen how to name it. I've chosen how to declare it and share it. I've also got some reputation elements to it, the number of followers, people I'm following, and how many tweets I've done. But it's also got this added advantage that says here is the context; this is what I want to talk about. This poor guy obviously failed to send his direct message correctly, but he was just learning. Let's fix it for him.

Let's talk about the next generation, Twitter talk. What I want to talk about is a potential consumer code, if you will, adding it to Twitter so we can talk. Where this is really important is for calls that are outside our current buddy list, for people that you want to rapidly escalate with. It will be increasingly important in relation to location-based communications. If you're following Twitter, you'll realize that soon every URL on every tweet has the potential to have a location-based location next to it.

The second thing you need to be worried about is control over interruptions, access; who has access to me and how are you actually going to get the notifications? The other thing we're all dealing with is this proliferation of channels and networks that we belong to.

In Pweet alpha which we launched in July 2008, we came up with a system that said let's dump the URL into the Twitter stream, and when somebody clicks on that URL, we'll be talking. We thought that was pretty sweet. You click on the URL, it launches in the browser, and gives you the opportunity as to whether or not you accept or decline. If you accept, you're talking. At the same time, because it's to a bridge, you can manage whichever channel you want to connect on, or even change to a different channel during the call.

But there were some real problems with it. The biggest single problem with it was the latency. I sent an @ message, somebody got it three days later. I never got the call back, and all sort of missed things. There is an expectation that it will actually happen quickly. Usually, when we hit the ringer, it happens almost immediately. The second problem was you had to go off Twitter to set up another URL to create the tweet. The third problem was we set up an API and said come on twitterverse; add Phweet buttons to all your apps. Despite trying to push that along, that didn't happen either.

Here is a simplified Phweet beta. What have we done - plus, Stuart Henshall, star. What is the context, what is the description, what do you want to talk about? That's it; that's all that's required. We eliminated the URL. We allowed somebody to write it in any client.

Here is an example. Geico "Call me" and at the same time, I can let my friends know I have a problem, crashed the car, and the rest. What do I expect? What happens? Geico gets a notification from Phweet with a URL including the profile and the context, notification to John Smith who says who is going to call from Geico and when. Geico makes the call connecting the parties, and the parties also have a shared URL available. It's a much more transparent transaction.

Here is another example. Guess what? No call tree. I've also made my inquiry public so I could even track the response rates the different companies provide me. Hmmm - Comcast, they're always a problem for me, but perhaps this didn't need a call. What happens? They send me a message back that says there was an outage in your area.

Okay, but it can always be private - "dePhweet", send a message to Mr. Blog, "Let's discuss if we should hire Tom or Steve as the CFO." Or, something more interesting, you're in India and you want to set up a conference call. All you have is SMS in your hand and you're one of the 100 million Airtel users that now have access to Twitter. For one rupee, you simply make this tweet, and a conference call is set up.

Or perhaps this one, more importantly, this is undirected. This is an ad. Phweet, here is my topic; this is what I want to sell. Remember, this is a location-based tweet coming. I proved it. In the original alpha, here is the example. Something for sale, and you can see it already works - approve, reject.

The solution, what we've done differently is all in the notifications. The signaling is outside the control, effectively, of the carrier. Phweet is managing the contextual notifications between the parties. There is no need to share numbers or visit the Phweet site to set up, make, or complete the call. The profile is the caller ID, smart caller ID finally - my choice, my identity. The URL represents the exchange contract and it may be public or private. The solution really doesn't need to be limited to Twitter.

What are we actually trying to do? We're trying to show that we can actually bridge the gap, if you will, between social communications and the people that I want to handle my identity layer, and traditional telephony. In fact, what I'm setting up is a world in which you can push your requests, can control your access, can choose your own identity, and you can select your own channels, without being dictated to by anyone else.

The way I look at it is; this is telephony my way. It's my name and I'm no longer a number. You can reach me @stuarthenshall on Twitter. Thank you.

Chair: Any questions from the audience? Maybe people are feeling the same degree of tiredness that I feel. Today has been very intense to say the least. If you have a question -

Audience: Stuart, could you go over one more time what the user experience is? One thing that confuses me is; is this a situation where let's say I'm at Home Depot. Do I have to set up, a priori, a relationship with you and then once that is done I can get these inbound things?

Stuart: Let's just assume that Home Depot doesn't actually even provide the service. You tweet "home depot" and Phweet will immediately send you something back that says, "Sorry, Home Depot doesn't support this yet," and what I would like to do is jack you straight into Fonolo. In other words, I can put that call straight the way through to a 1-800 number. Any time somebody identifies a company that isn't playing ball, we can bring it back.

Chair: It will be interesting to see how this goes the next one or two years. I'm getting this growing sense of fruition coming at some point. Thank you very much Stuart.

Stuart: Thank you.

Chair: I would very much like to welcome, again following the Google Wave theme, David Wang of Google. Please welcome David Wang. David Wang is one of the lead technical architects of Wave, so please take it away, David.

David: Hi, thank you for coming to the Wave Federation talk. I've heard a lot of excitement in the audience, just before this talk, and I hope you've all gone to Lars and Stephanie's talk just then and saw a quick demonstration of Google Wave. At the point, I hope you're all excited about Google Wave.

In this talk, I will give a very quick overview of what is federation and where we are up to, today. For those of you who know Google Wave, I would like to reiterate that Google Wave is actually a product. Wave is actually a technology. You can imagine Wave is to Google Wave as email is to Gmail. That means that anyone is welcome to write another Wave server just like Google Wave.

What is Wave federation in that context? Wave federation is about basically enabling different Wave providers to interoperate with each other. A Wave provider is someone who is running their own Wave server. We already have a draft federation protocol spec available at waveprotocol.org and I welcome everyone to have a quick read at it. Also note that this specification is currently being iterated on. It's not final. I welcome everybody to give feedback on it, and we do need everybody here to give us insight.

Here, I have a diagram of three organizations. As you can see, there are two organizations here that are actually not Google, both of which are running their own Wave servers, and those people, we call them Wave providers. In the protocol spec, it simply says how you can run your own Wave server, and how you should talk to other Wave providers.

Why does Google want to do Wave federation? In short, I think Google wants to be successful at Google Wave, but we also believe that we want Wave, the technology, to be successful. We believe for Wave the technology to be successful, we need to have a wide adoption of Wave, just like how email is a widely adopted technology. We want to do that by being open and because the Internet is built on open APIs and open protocols, we believe we can do the same, just like email, by letting everyone participate in this. Even more importantly, we don't want to be an isolated communication tool that you have today, like IMs where you have five different IM clients just so you can talk to your friends.

Because this is open protocol, anyone can actually develop their own Wave servers, and users will have a choice. They can pick whichever Wave provider they want, based on price, features, or whatever. As an outcome of this federation, we also want to avoid different organizations building Wave-like systems that don't really interoperate. That means you can develop Wave servers yourself, but we would really like that users don't have to suffer the consequences of having different Wave clients opening up, just so they can communicate with their friends.

This brings the next point; if you're thinking about federation, you're probably thinking about what it takes to become a Wave provider. The bottom line is; anyone can be a Wave provider, as simple as that. It's just like running your own SMTP server. Let me give you some technical background about Wave federation. Hopefully it will make it easier to understand how simple it is to run your own Wave server.

Raise of hands for anyone who even knows what this diagram is about? Ah, great - I can breeze through this now. A Wave interim data model is very simple. It's basically a collection of Wavelets, these Wavelets. They are basically just boxes which contain a list of participants and a list of documents. You can think of a participant as just an address, and document as just and XML document. It's technically not an XML document, but it's much easier to describe it as an XML document. It contains annotation as well.

A Wavelet is what we call a "unit of concurrency control". That is, this is the thing that runs the live, concurrent editing code, the operational transformation. This is what I also call the "unit of Wave federation" this is the object that is shared between different Wave providers. In terms of federation, it's actually really straightforward. All you have to do is run your own Wave server, which runs the LT algorithm, and it's very important that everybody runs the same algorithm. Wave servers simply share updates to their Wavelets with each other, much like how clients do it today. You have a bunch of updates, you send them across the wire, and magically things will get synced together by the operational transformation algorithm.

It's very important that only one server owns a Wavelet. That is, if you are in initech [initechcorp.com domain] and somebody started a Wavelet on your server, you actually own the Wavelet forever and ever. It's currently unspecified if your server goes down, whether someone will take over or not, but we welcome comment about that.

When you look at a Wavelet, how do you know who owns the actual Wavelet? This is defined by its ID. A Wavelet contains both a domain and a arbitrary string. The domain tells you where you can go and fetch a copy of the Wavelet, well a canonical copy. When does federation actually happen? It's a very simple process where the minute you add someone that's from another Wave provider, you actually have to go and start sending operations to that provider. Straightforward?

A very simple example is Bob has a Wave open and he adds a new participant called milton@initech-corp.com, which is where his provider is, looks up [Initech Corp's] Wave server and says, "It's not me, it's someone else," so it basically starts pushing the "add participant" operation and any further operations to that external server. I won't go into more details about that.

From a very high architectural perspective, you can see that when you have your Wave server and you own the Wavelet, you have to promote all the deltas, which is essentially a list of operations, to external parties through this thing called federation host. Basically, you're like a web page. You're hosting this Wavelet and you're constantly broadcasting Wavelets to everybody else.

If you were a remote Wave server, someone who doesn't own the Wavelet, you'll be constantly receiving operations through this and you can optionally store it for caching purposes, so that when users of your Wave provider come online, you don't have to go all the way to the root. You can serve up a cached copy so it's much faster. Of course, from this, you can see there is a mirror image at the bottom, as well.

This hopefully makes it clear that it's easy to see because there is one Wave server owning a Wavelet, data stays in your network, provided you don't add anyone outside of the network. You can actually have an on-premise solution for your corporation, and talk between each other, and nothing will go out of your network until you add someone from outside the network, much like how you can send emails between each other today, and provided you don't forward the email to someone outside the corporation, nothing goes out of your network.

Where are we today with federation? Today we've actually published two main specifications, the Wave Federation Protocols Specification, and the Wave Conversation Model Specification. Both are available on the website. We've also open sourced about 40 thousand lines of code, and it's available at the address below. We've released it at very liberal license, which is Java Apache 2.0. I don't really know the exact details, but basically you can do whatever you want with it; that's my understanding.

One of the reasons we want to give you code is we believe it's critical that everybody runs the same algorithm for operational transformation. It's much easier if we just give you the code. You can see we'll give you the operational transformation and the model, which is how to interpret the operations into an XML-like structure.

But also, we're going to publish a very basic prototype which is sort of the simple Wave provider prototype. It's very dumb and it has a very simple crypto library attached to it. Crypto is actually very important in Wave context because with crypto, you can actually validate who actually sent the message. This is very important. This is a big problem we're addressing that we see in email today. You don't know where the email came from. With the crypto library, you know where the Wave came from. In fact, when we exchange messages over the wire between various Wave providers, we're exchanging them over TLS, in XMPP as well. In that sense, it's also encrypted on the wire.

The client that I've just mentioned, which is a very simple client-server pair, basically contains code that tells you how to use the wire protocol. Please don't use it and think it's a reference implementation. It is a very basic piece of code that demonstrates how things work, like first year computer science degree courses. You wouldn't take that and make a product out of it.

This is what it looks like it, for those computer geeks out there. I'm sure you prefer this over our live client. What are we doing right now? We're trying to open up the Outdoor Federation Port on wavesandbox.com. This port will be very experimental. This is because we're constantly iterating on it and we haven't ironed out all the bugs yet, and we do want everybody to participate and help us to achieve, in a sense, a reference imitation from that.

We also are updating the Fed-1 client that you saw previously, to do a much better job in using OT so that characters are more live and concurrent. This is work which is continuously going on right now. Also, if you want to contribute to the code base, we've just released the licensing agreement so you can actually go in and send code reviews to us. We'll liberally accept your code. I've just heard; right before the presentation that someone in Sydney hadn't slept for three days to cook this up for you guys here.

This is my regular Google Wave account, and this is the Google 6 or Solos Org or some other domain. It's a Wave service provider in another domain. I can, in this case, create a Wave and say, "Hey the other David, I'm in Amsterdam. Where are you?" I can go and add this person in acmeWave.com, so he's in a completely different domain to me. He's being added.

Back to my cool text client, I can see a Wave has just popped in. I open the thing. Don't tell me about UI. I'm no UI expert here [laughs]. I can reply to the person and say, "I'm here too. Want to get drinks at 6?" The Blip will appear on the other client as you see here. If I make this a little bit smaller, like so, I will show you a very cool feature that somebody hadn't slept many days, just to implement it for you guys.

As you can see in the Fed-1 client, characters are showing up, character-by-character. It's a bit flaky right now because it's in Sydney so the ping time is a bit bad. But you get the picture. An even more important thing is this, "Let's invite Alex." I'm going to invite Alex, who is a great software engineer on the team. I'm going to make a private reply to Alex and say, "Knowing you, don't be late." As you can see, I can see the private reply on my screen, but it does not appear, in fact the bytes don't even arrive at the other organization. The other organization has no idea what's happening in the background, and this is critical if you want to protect your information and Federation provides that.

So, where are we heading? As you can see, the demo is very primitive. We're still iterating through it and we want to get to a reasonable set of specifications, and of course using everyone's feedback here. Using your feedback, we want to gain more experience and we want to open the federation port to everybody. When I say to everybody, I mean open it on the actual production server which is wave.google.com. Currently, we're just doing it on the test platform which is wavesandbox.com.

We also of course, open source a lion's share of Google's client server code, but right now we're really busy with implementing lots of features everybody has been requesting. Certainly, some key components we're shooting to open source very soon include the editor, which is critical if you actually want to implement an online, live, concurrent edit platform.

Also, we want to iterate our existing implementation, the open source implementation to provide something that is of production quality, and that can only be done if we open source some of our server components too. We want to do this soon, but we can't do this without everybody's help here. Bottom line is I think we'd like to work with everybody here to achieve a true open standard. I have about 3 minutes left for Q&A.

Chair: Thank you David.

Let's open it up to the floor. One thing I noticed, before we go to Jay here, is that it seemed to me, and I'm glad you made the point so clear at the beginning; far too many people seem to look at Google Wave and instantly look at the UI and think this is Google Wave. They didn't seem to get that this is technologies. This is standards. This is a platform for essentially changing the way we communicate. That transformation is going to take a couple of years. Thanks for making that. I've been really surprised at the press for just thinking this is just a Google app and here it is, today.

Audience: I know you haven't decided how you're going to handle server failures in the federation protocol, but what are some of the ideas that you are tossing around for how you could handle that?

David: There are many ideas. One idea that has been suggested already was that there is some method of passing ownership of a Wavelet to an external server. That was one idea. There is some complications then in deciding which server to pass it to, etc. The other option which has also been suggested is simply not to pass the ownership at all; you just say the Wavelet is dead. Because other Wave service providers will have a cached copy of it, users can choose to make a copy of that Wavelet and keep going. We are still discussion what are the pros and cons of each option.

Audience: Looking at Google Wave as it stems, and the fact that you're going to integrate to Google Talk with it, it looks a lot as if you're putting a lot of effort into transferring things from HTTP world to an XMPP world. Do you have any plans to provide Google Search in real time format?

David: I'm not sure I'm the right person to answer that question.

Audience: It struck me as significant.

Chair: This is a tech lead. What's the tech question? Thank you.

Lars: I'm not 100% sure I heard the last part. The question was whether we would be able to search? I guess I just stole your microphone. I didn't hear the last part. Tell me and I'll repeat it in the microphone. The question is whether we will do a real time Google without also doing the search in real time. It's not something we've thought through a great deal.

You'll see that the search we provide over Waves is a real time search. You can see if you do it with public, you see things bubbling up really quickly, but as a gentleman in the back pointed out after our talk, the quality of the search is not very good. The challenge we have is to marry the real time in this, which is hard from a systems point of view with the ranking, which hard in an entirely different way. I think when Wave takes off, there will be a tremendous amount of goodness to come from that, and enough people will work on it that will figure it out, if I can make it any vaguer than that.

Chair: That sounded good to me. Last question. Anymore questions? Thank you David.

David: Thanks guys.

Chair: : Please welcome Stephanie, who is the Lead Product Manager for Google Wave and was previously the Lead Product Manager for a small app some people might know called Gmail. Over here, we have Lars. Please welcome Lars. Lars cofounded, I believe, Wave along with his brother Jens. They've graciously come here to demo, which is challenging enough, and to take your questions. Again, thank you very much.

Stephanie: First, I want to thank Lee. It was such a privilege to be invited here. He's been incredibly kind to us so thank you. I also want to thank all of you. I know we gave you Wave accounts and you're experimenting with it as a back channel for the conference. That's really invaluable for us. We look forward to talking to you after this presentation and seeing how it's going.

You might know us as the people who made this YouTube video. Has anyone seen it? Alright. As flattered as we are that almost 6 million people have watched this, it kind of creates a high bar for entertainment. I stayed up all last night trying to think about how to make this presentation fun for you guys. I'm going to run a few of my ideas by Lars.

The first thing, has anyone seen this site? It's called "Which is Easier to Understand than Wave.com?" It happily presents you two options, and you can vote. Why doesn't the audience help me; Google Wave or lipid solubility? Shout it out; Wave - easier to understand.

Lars: How about Wave with a healthcare reform bill? Wave. How about self-balancing binary search trees? Oh that's easier than Wave.

Stephanie: How about Google Wave or Sarah Palin? Shout it out. Palin.

Lars: If there are any bugs in Wave, it's because we spend all day playing this game.

Stephanie: Wave or a Microsoft Visio 2004? Alright, this is a good crowd. They're voting for us. If that wasn't funny enough, I thought maybe a lot of government people have been excited about Wave, especially for the playback feature. I thought it would be fun to take a famous document, like the Declaration of Independence, and try to imagine how it might have been created in Wave. That's hilarious right?

So, I have it here in playback. You can see I'm logged in as Thomas Jefferson and John Adams started a Wave with me. He's like "Oh, John by the grace of God, the King of England, Lord blah, blah..." and I said, "This doesn't seem very original. Don't get your wig in a fluff." They re-edit it and so on. If you can believe it, we made a full Declaration of Independence. It might have been in the wee hours of the morning leading up to our September 30th launch.

If that didn't work out, I think I had Halloween on Saturday. Who likes Halloween? Okay, that's a lot of people. So in our team in Sydney, Friday is already over; we had a big Halloween party. Our developer relations lead, Pamela, dressed up as a robot. If you can't tell, she made the first ever Google Wave robot which is called "Cartoony". It takes all the text in a blip and changes it into this huge cartoon. If you need Halloween ideas... and my very last thing - Lars hasn't actually read any of the press since May 28th. I thought - Lars, just look straight ahead.

Lars: I'm looking straight ahead.

Stephanie: I'm going to show you guys the best headlines that we could have possibly seen. I tell Lars how great the press is, and make him feel good.

Lars: Everyone loves Wave.

Stephanie: But in truth, we're going to try to answer a lot of the questions that are raised in this press today. I think you had one other idea.

Lars: I had my favorite video. You guys have to see this. You know that you've made it big on the Internet when you get to be played off against "Keyboard Cat".

Stephanie: Lars, this is where you do the dance.

Lars: Yeah, everyone look at me, don't look at the screen. [The Wave Dance] There are not a lot of people in the world that can have their demos as spectacularly fail in front of 4,000 people, and not break a sweat.

[Wave/Keyboard Cat Video]

Lars: She's right; we should have rehearsed this before coming this morning.

Stephanie: That's all we have. We're done with all of the hilarious intros. Just for fun, I put together a gadget where you can vote. If we do this presentation again, we'll only pick one of them. David Wang is going to link it from our Session Directory Wave, and go in there for some amount of fun. Just to go through the agenda of the real content, we are going to do a short demo, not an 82 minute demo but about a 5 or 6 minute demo because I don't think it's fair to assume that every single person in here has seen Wave. We certainly want you to know what it is. It's a new tool for communication and collaboration.

Then I'm going to say how the preview's going. On September 30th, we started rolling out Wave to users. I'll give you some user feedback, what we're hearing. And then Lars is going to answer some tough questions. These are things we got from you in the Wave, and also things users have said, or the press has said. Then we're going to do some really quick keyboard shortcuts because there are a few helpful tips we think will be useful as you start to use Wave, and then give a shout out to David Wang who is giving a talk after the break. I think I will hand it over to Lars.

Lars: Thank you Stephanie. Normally, we take about 80 minutes to do a demo, but we're going to try to do it in 6.5 minutes. I've tee'd up a Wave here for Stephanie while she was offline preparing for the hilarity. It says, "Hey Steph, help. We only have 6.5 minutes for the demo at eComm. It normally takes 80. What are we going to do? Lars" So now Stephanie comes online and she sees this Wave waiting for her. Just like an email, she can make a reply down at the bottom, like this - actually, you can say that. You've got a mic this time. You don't need any more sweat stains on your t-shirt. Okay. So the first benefit you can see of Wave is that you can switch seamlessly back and forward between email type of conversations and instant messaging type conversations.

I can go here and use the blue line at the bottom to make an insightful reply, "But, but, but" like this. As you have noticed if you've tried it at all, unlike the instant messaging clients we're used to, we actively show what the other person is typing, character by character. The primary reason we do this is to speed up the conversation. In general, you can predict how I'm going to end a sentence long before I'm done talking. That speeds things up a lot.

In Wave, you can add a message anywhere in the content. Stephanie is going to show you how to add a message inside mine. She double clicks the last word in a sentence and she gets this little toolbar that says "reply" and she hits reply. Now she is making what we call an "inline reply" and I can continue with another insightful panicky message like this. So instant messaging and email-type conversations can take place in the same tool.

The next thing I want to show you is how you can go back and edit a message after the fact, not just your own messages, but in fact, you can edit each other's messages as well, which has a very nice benefit that you can collaborate on content inside a Wave. I'm going to add our colleague David sitting over here, who will give the next talk, and then all of us - I'm going to hide Stephanie's inline reply here, and the three of us are going to edit this message together, to throw together a much too short demo script.

They say, "create a panicky Wave, make chatty jokes, maybe we should make a reply somewhere like this," so you can see that we can edit comfortably right next to each other. If you tried this, your first experience is very chaotic. But once you get used to it, you'll be surprised how much faster you can collaborate on putting together content when you get to do this live, character by character editing simultaneously.

Let's see what else is there? Let's show [00:08:57.20 ?] one open. I'm going to leave this Wave here. I'm going to close it and then David and Stephanie are going to continue typing while I'm not looking. A little while later, this could be 5 minutes, an hour, a day, a week; tell me when you are done.

Stephanie: We're done.

Lars: You'll see that already it's bald here because there is new material since I left, and when I come back in, the first thing I see is exactly what has changed since I was there last. The rule is whenever you open a Wave, you see new messages marked with a green bar at the left, and edited messages are marked up with this yellow and pink to see what has changed.

Let's see, where did we go in the script? What's the next thing? Let me show you playback. Imagine you come late to a Wave. It's reached a certain level of complexity and you want to see what happened. You click "playback" and you get to go through step-by-step when it was created. You see I started the Wave, I added Stephanie, I changed 7 to 6.5, she made a message there, I went there, then we started inline replies, and then you can see also the editing step right here. You can see the next one, then I added David, and so on.

Let's show you how to add images. I luckily have some entirely unrelated images sitting here on my desktop. All you have to do is grab them from your desktop and drag them into an open editor like this. You'll see how we automatically thumbnail them, send the thumbnails across to Stephanie's screen, upload them, and so on. Do you have any entirely unrelated messages yourself?

Stephanie: Yes, I will drop some ski photos in.

Lars: Stephanie has some ski photos and you'll see how quickly they appear. It's because we actually create the thumbnails on Stephanie's machine and send them across the wire before full pictures upload. I can grab this button down here and view everything as a slideshow. You'll see that I'm seeing both my own pictures here and Stephanie's pictures. Wave is a tool for collaborating on all kinds of content. We've showed you how to collaborate on text, but you can collaborate on photo albums. We'll show you later, how Wave's extensibility will let you collaborate in real time on pretty much anything. Here is Captain Athena; here is the hard life down in Sydney. We love showing that one. It's winter in the North. Back to the script. What's next?

Stephanie: Extensions

Lars: Extensions - I want to show you my favorite extension is a Sudoku game. Let me add this Sudoku game to this Wave here.

Stephanie: Maybe you should say what an extension is.

Lars: An extension is something that third parties can build using one of two APIs. One is one where you can build robots. I will show an example of that later. The other one here lets you add client-side code. We call these things gadgets. This is a Sudoku game. The way it works is that the programmer writes this game here and all I have to do is store this data of the game in the Wave, using an API we make available. The Wave platform automatically synchronizes it between all of the clients playing it. This was actually an existing gadget that an Israeli company called LabPixies had built where you could play alone against the clock, which is how Sudoku normally works. With just a few weeks of work, they put it inside a Wave, and now it was intended to be a collaborative effort, but somehow it became competitive along the way. You can see how we're all running around in here with our little squares, competing.

Stephanie: You guys in the audience are supposed to be helping me play Sudoku, David.

Lars: You're running around. Stephanie loves playing this, in particular, when I'm giving a presentation, because then she actually has a chance.

Stephanie: Lars, I'm going to insert a map to show them where our Sydney office is.

Lars: Excellent idea, since no one here in the North knows where Sydney is, Stephanie is going to add a map gadget here and you'll see in the same way; I'm not touching my keyboard, but anything Stephanie does on her screen automatically shows up on my screen. The programmers who did this, which was Pam you saw in the robot outfit earlier, doesn't have to do any of the hard work here of synchronizing, or even if Stephanie and I are editing a map at the same time. She doesn't have to do any of the hard work of resolving conflicts. The Wave platform does that automatically.

I want to show you the other types of extensions. I'm going to show you my favorite one we built, which is a robot that's on all your Waves that does spellchecking for you. Can you guys see what I'm typing here? This is my "favorite been soup" demo. "Can I have some..." it's hard to spell wrong in the right way. "It has bean so long." Here, I'm carefully spelling things wrong in a way that hits legal dictionary words. You'll see that our spellchecker knows that I meant "been" instead of "bean" here, and that I meant to have "bean soup" instead of "been soup".

There are two things I want to call out here; one is that our spellchecker is a classical example of the power of cloud computing. We have a huge language model that is constructed from the Web, sitting on several hundred machines in a big datacenter. We have a robot, which is a server-side piece of software, that interacts with a Wave just like a human. This robot can see what I'm typing live, just like Stephanie can, and it can take a collection of words I've typed and match them up against this enormous language model. It can use statistics to see that I've spelled something wrong, and then inject suggestions into the content. In fact, if Stephanie had been faster than me, she would have seen those suggestions as well, and she could have fixed those spelling errors for me.

Stephanie: That's all the time we have for our demo. You already ran over, and I'm going to move right into "how is it going". On May 28th, we started a developer preview. We gave out about 35,000 accounts in the sandbox. On September 30th we started what we call a "preview" and these are very very early days for Google Wave. You might even call it pre-beta. It's still buggy. It still crashes. It's not always reliable, and it's not feature complete. There are still a lot of things we're finishing. Why did we want to start this preview?

There are a few reasons. First, we've been using it on our own team for all of our document and communication work for almost a year and we found it invaluable. There was probably a period of time at the beginning, where we were getting up to speed and it was sort of hard to give up tools that we were used to, but over time we sort of migrated our world into Wave. We do design docs there. We chat there. We take meeting notes there. We plan boat trips there. It sort of has changed our work. When we go back to something like email now, especially Lars often makes mistakes.

Also, there is a broad set of things that Wave does and we think it's helpful to get it in the hands of users. Google has a philosophy of launch early and iterate. Users will help us figure out how to pick the right things to spend our scarce engineering resources on. The other thing is testing. When you have this much interest in a product, more than 2 million people signed up to get Google Wave accounts. To launch a new product like this, you have to make it scale. You can do all the load testing in the world, but there is nothing like real users to push your system and stress it in new ways, so we thought doing the preview and doing this slow growth would help us make the service robust. How is it going? Put on the user chart.

Lars: Can I just ask the control folks here, can we switch the monitor to Stephanie's computer? You can't do that, okay.

Stephanie: That's okay. This is a graph. We track things like 1-day active users, 7-day active users, 30-day active users, and how many people have ever logged in. Although we've told people we would send out 100 thousand invites, that was just the beginning. We send out invites every day that we're having a good day, so you can see on the left is September 30th. We have continual growth. We're at a couple hundred thousand seven-day active users now.

This graph is fun. The blue line is simultaneous user sessions, so how many people are online using Wave at the same time. You can see it goes up and up, and then flattens out, and then up and up, and then flattens out. That's the periods of us sending out invites. The orange-ish or yellow line is people accepting invites. You can see sometimes we had to stop sending out invites after that first kind of flat line. We had a user who put a 100 thousand character word into a Wave. Why? Why did he do that? We didn't test that. Some bad things happened. Then sometimes the blue line flattens out because we hit a scaling bug or we need more machines, and we fix it and we keep growing.

Where are the invites, or who did they go to? Everyone asks us that. We sort of seeded Wave with people we thought would be great ambassadors or help us get good users into Wave, which includes the first people on the external signup list, and the developers who had been in the sandbox. We also enabled Wave on some domains, so we think there are natural groups of collaborators in education and business. We have a Google Apps Suite of products and we enabled Wave on some domains. The controversial thing out there is that the people who were nominated by one of these seeds didn't get invites. They all want them and they don't have them yet. We're sort of working on the best algorithm to put the invite Wave back in peoples' accounts. This fact that the nominees didn't get invites creates something we call the "lonely waver" phenomenon, which means some people get in there and they don't have anyone to Wave with. We are certainly trying to scale as fast as humanly possible, and get Wave out there.

One thing we're proud of is that even though it's an English-only interface, people are using Wave all over the world. If you look on the left, that's where people are accessing Wave from. About 40% are from the U.S., which is the top, but you can see a vast number of countries that represent our user base. On the right, we can detect what languages people are typing in a Wave, and these are the top 12 after English, so you can see lots of different languages being typed into Wave. All of the ones with an asterisk, we have the spell detection that Lars just showed you. The quality varies in different languages, but we're using this preview to improve it, and lots of users typing.

Just because we're short on time, I'll quickly go through some user survey graphs. We did a survey of 1,000 of our early adopters and asked them questions about what they liked and didn't like about Google Wave; that's very important to us. They liked things like the visual appeal and security and want us to work on things like the speed and stability.

The top likes include the concept of a Wave, which is great because that's what the product is; "the ability to collaborate with others and all my communications and docs integrated". The dislikes or issues are "my friends and contacts aren't in there so I don't have people to Wave with" and that's exciting; if that's what people want, more people on Wave, that's a good thing. "I already have too many information sources" or "it's slow, buggy, it crashes" so the info source is something Lars is going to talk about later in the tough questions.

This is a lonely waver. So sad. There is something that happened in the sandbox that has been helping the lonely waver. Users found the ability to make a Wave public, and that's exactly how you guys have been participating in this session, kind of Waving, so if you can go to your account. Lars is typing with public. Any user can make any Wave public. As you can see, it's streaming down now. People are updating the Wave second-by-second. There are always different things in here.

At the beginning, it was "I'm from Alabama." "I'm from Thailand; I want to find people to Wave with." Then sometimes the discussions migrated into "I want to use Wave for research or journalism." Sometimes people talk about an issue of the day. We were actually in public Waves when Obama won his peace prize and instantly people were in there talking about it. You can see there are a lot of different languages. If Lars does a language restrict, for example, we can look for just public Waves from Chinese. This feature has really taken off and it's a way that people are finding each other. Now, we have to make a decision. We didn't intend for this to be the primary use case, but it's very popular. Do we want to do things now like try to rank your public Waves in a way that's meaningful to you?

One thing that is really exciting to us is seeing users helping each other inside of public Waves, so more experienced Wave users will be answering questions for newbies. There are even people writing documents, like manuals, like Wave's Greatest Hits. That's sort of a guide to Wave. That's an interesting phenomenon.

I want to share an interesting stat with you. Once public Waves took off, I thought maybe all our Waves were public Waves. We've done a lot of analysis and only half a percent of our Waves are public, so a lot of the early usage of Wave and what people were doing in there, is within small groups, or private Waves. About 8% of people have contributed to a public Wave, and 14% of people have touched a public Wave. Just out of curiosity, our longest Wave is 1,134 blips, and 772 is the maximum number of people who have contributed to a single blip. That's exciting for us, to have a lot of people in there. The largest Wave is about 100KB which is our enforced maximum, and 10% of people have tried attachments, primarily being photos. That's sort of where we are with the preview.

I want to turn this back over to Lars because we had this 5-month developer preview and we promoted these different APIs we talked about, both to extend Wave itself, and to be able to embed Waves anywhere on the Web where you want a rich UI for collaboration and communication. He's going to talk a bit about how that went.

Lars: If you have time, search on Google for Google Wave featured extensions and you'll see this page I'm showing you now. There are two things I want to go through quickly that excite us a lot. These are prototypes. This one is built by SAP. They built something I thought I would never see in my life. It's a business processing modeling tool that's sexy. They built this gadget here that you see behind me that lets users draw business processes. They already had a tool where you could draw these things and save them as a file and exchange them in the traditional way, but when they saw Wave, they took that same UI, put it inside Wave and suddenly this process of building business processes becomes real time collaborative. They put together this great video where they go through a scenario where three people get together and build this process here. They bring in a robot that checks the semantic process; they bring in a manager who plays back everything to check the work. In the end, they grab the product and they export it into this enormous software package that SAP has, that turns the graph into an actual website that interacts with SAP's users, or the users of the customer of SAP software. In the end, they put another gadget inside the same Wave that actually does real time monitoring of the performance of that website. You can both see the input to the website and the monitoring and you can go and fiddle with the graph, pull that handle again, go through the process, and very quickly see the result of your work.

The other thing I want to show you is a prototype of a Wave application built by Salesforce.com. They have a customer relations scenario where a Salesforce.com customer, a mobile phone company has a customer in turn that has some problem. The mobile phone company customer conjures up a support robot that comes from the mobile phone company. They can go and type - the robot is called "Buyah". The customer goes in and types in what they're looking for. The robot looks in a knowledge database what the answer might be, puts that in a gadget in a way that the user can interact with, and the user can either say yes, I've found my answer, or no, I need more help, in which case a robot adds a human support person. That human support person sees the Wave embedded in their Salesforce.com control panel and they can bring in more colleagues and collaborate on getting the user an answer. The entire flow is recorded in a single Wave that you can use later.

These are exactly the kind of things that we like to see built. We think that at least half of the appeal of Wave is that you can take existing work flows, and with relatively modest amount of work, not trivial amount of work, but you can make them real time collaborative and everything gets integrated into the same box.

Stephanie: We have to move on to tough questions. I hope Clint, if he's watching this video later, doesn't mind that I was working on slides yesterday for our tough questions and realized that he wrote an article for eWeek that had a lot of points I wanted to make, so I'm going to have Lars do - you have about 45 seconds on each of these, just so you know. The first question is about draft mode, live typing freaks some people out.

Lars: Yes, live type freaks people out. A lot of people react to live typing by saying it's the coolest thing ever. Other people react by saying they feel rather exposed and a bit unnerved by it. So, we've found that then after a while when you have your first "Wave moment", typically you're writing a question and you're carefully formulating it and then two people jump in the Wave and answer your question before you're even done typing. You can really see how it speeds up things.

Of course the other thing you notice is that everyone one else also can't type, which tends to make things easier to deal with. However, there are cases where you don't want this. We are perfectly aware of this. We are planning what we call a "draft mode" where you can choose whether you want other people to see your changes live or whether you want other people to see them only when you hit the "done" button. We haven't implemented it yet, in part because we down prioritized draft mode because we wanted people to really get a chance to see how useful live typing is before presenting them with a choice where people might pick the safer option before getting a chance to see the benefit of live typing.

Stephanie: The next one is Twitter. Are we trying to kill Twitter?

Lars: And the answer is no. For starters, if we killed Twitter my wife would kill me, which would be unfortunate, but I think it is sort of the downside to doing a big splashy demo before the tool gets out there. Then you start getting a lot of speculation. I think Twitter of course is known for being very real time, and Wave also quickly became known for being very real time and people thought we would be competing with each other. It's like saying because our interface is blue we're competing with all the other blue tools on the Internet. Obviously, what's happening is that increasingly everything on the Internet is becoming more, and more real time. Please don't try and use Wave like Twitter. You'll have a very bad experience. What we hope will happen is that Wave extensions will be part of the very large collections of Waves you can interact with Twitter. We hope that if Wave takes off it will actually help tools like Twitter proliferate more.

Stephanie: I think this question is about "I don't want another inbox. I already have too many."

Lars: Me too. Stop using email. I'm just kidding. Our second-most requested feature is integration with email and so on, so you can have all your stuff in a single inbox. The first most requested feature being more Wave accounts so you have people to Wave with. We are going to do a few things with email integration. We are going to make it so that you can receive a gentle email notification when something changes in your Wave, so you don't have to go check both inboxes all the time.

An actual full-fledged integration where income emails would turn into Wave and you could reply to them inside Wave - we put that on the back burner. We used to think it was going to be a really important part of Wave, and we actually built a prototype of this. We started dog-fooding Wave ourselves, earlier this year, with such a prototype running. We found it was a really bad experience because what happens is when you first adopt Wave, early on, all of the people you communicate with, or 95% of them, are email users. So all of the Waves you end up with are really just emails. You can't take advantage of the features of Wave because all of the other users on Wave are really just using email. We found the "real Waves" where the other users were completely drowned in this flood of email. We never even used it. It would take years and years before we could possibly give a good email experience as you could get in a more mature tool, like Gmail. We moved it to the back burner, but you could imagine once Wave has kind of had a chance to find its own feet and reach a critical mass in your communication lives, then we might kind of bring in email, just to close off this gap of having too many inboxes.

Stephanie: That's way more than a minute, so tighten up. Permissions, now everyone can do everything in Wave? is it going to stay that way?

Lars: It is not going to stay that way. We're planning three types of participants, one that can do anything, which is the current type; one that can only read a Wave; and one in the middle, who is only allowed to add content to a Wave, but they can only remove or edit their own content, not other peoples' content. You don't need permissions, so currently, as you've noticed, anyone can add you to a Wave, and that Wave shows up in your inbox. It gets noisy very quickly. We're going to make it more like a chat client, where someone needs permission before they get something to appear in your inbox. The way it will work is very simple. If you add me to a Wave, that Wave only shows up in my inbox if I've made you a contact inside of Wave. The act of making someone a contact, implicitly gives that person permission to put Waves in your inbox. If you add me to a Wave and I don't have you in my contacts, instead of the Wave, I'll just see a little notification that so-and-so wants to Wave with me, and then I can choose to ignore or add that person to my contacts and see the Wave.

Stephanie: I think we're going to make this the last question and then I'm going to put the keyboard shortcuts, for those people who want to be more power users, into the Session Directory Waves. The last question for Lars before we finish is, "The learning curve." A lot of people get in there and say it's hard to use, I don't know what to do.

Lars: Yes, and I think they're right. We were never trying to pursue simplicity on an absolute scale as a goal in itself when we built Wave. We believe the tools in our lives that really make us productive all have the property that they take a little bit of time to learn. If you have been in the meetings I've had with my manager over the past two and a half years, he always says, "Okay Lars, what keeps you up at night," my answer is always the same; it's the question of whether users will perceive the benefit of Wave as being big enough that they're willing to go through that learning curve. That's really the crux of whether Wave will be successful. Our initial preview here has been promising. We have a fairly high retention rate, and we can watch in these public Waves, in particular, how more experienced users help the newbies get up to speed and people seem to have a good time with that.

Stephanie: I just want to conclude; we're getting late-breaking news from our team because we're in the last few hours of trying to open up a Federation port. We didn't get to talk about Federation yet, but Wave was born with an open protocol. We hope other people put up Wave servers, and everyone will have a choice in which one they prefer. David is going to talk more about that after the break, and hopefully, if things go well, a port for people to actually test Federation will be open on the developer's sandbox later today. Thank you for your time.

Chair: : One speaker couldn't make the next session, so what we're going to do is slide things forwards. It does give us a few minutes for Q&A. Do we have any questions for our Wavers here?

Audience: Are you planning to integrate Google Talk?

Lars: Google Talk - plan is a bit too strong a word. It is one of our top requested features and I'll personally love to see it happen. You could imagine that every Wave automatically has a shared voice channel and if the other people on the Wave have the appropriate trust relationship with you, you could see whether they're on that voice channel. When you go there, you can jump on the voice channel and you can talk to each other, or even start what you might think of as a phone call by starting a Wave with someone who is online and jumping on that channel. In particular, for things like the Sudoku game, where you don't really have time to be chatting with text, or even the SAP gadget where you're collaborating on this drawing, it would be so much faster if you could also talk to the person.

Audience: Are you hoping that ultimately Google Wave is adopted by advertisers as a way of starting a conversation with individuals in a different form from the way they do now?

Lars: Yes, but then -

Stephanie: I just want to say I don't know if we have a lot of ideas - we're far from it, but one of my favorite ideas is the late nights on the team, we often order Pizza Hut and how cool would it be if I had a coupon from Pizza Hut, and then it also had a gadget where I could collaboratively pick the pizzas with other members on the team and just submit it, and suddenly the pizza arrives. When we have to collaborate on a shared delivery order, it's kind of a pain. I think we think there is a lot of potential there.

Lars: I was going to say that after a brief pause.

Audience: Thank you first of all. Fantastic stuff. One of the things that I am working on is mobile web, mobile communications. With no disrespect intended, but it looks like something that was designed by people that spend all their time in front of 30-inch screens. Have you done any thinking about how people would use this on a mobile phone, on a mobile device of any kind? It looks like way too much information presented on a small screen.

Lars: Yes, I completely agree and in fact even on a desktop screen, or any screen for that matter, there is a lot of information there and we'll probably tone it down even for larger screens. If you do have a high end mobile device like a 3gsi phone or a new Android, try going to wave.google.com and you'll see a screen that the browser is not supported, but there is a link in the bottom right where you can click through anyway. You'll see that we have actually done a fair bit of work presenting a mobile version of the interface. You can read Waves. The reason we put that screen up there is because it's still much too slow for us to claim those browsers are supported. That will give you a good idea. I think most mobile devices you won't be able to take part in the rich text, live collaboration, but you'll certainly be able to go and add a message to a Wave, which will be a good start.

Audience: One really simple question; why is the search construct within Wave not the Google search construct, which is already universally known, accepted, and used widely?

Lars: I'm not sure I understand what you mean by -

Audience: Tag, inbox, directory, colon, word, find, whatever is there, versus you simply go to a search box and type what you're looking for without have to use tag, directory, colon etc. That's not consumer. That's not easy.

Lars: Have you tried just going in your search box and typing what you're looking for?

Audience: [distant]

Lars: Gotcha, now I understand. Okay, we have work to do. I completely agree.

Stephanie: I would also say we've had a lot of debate about the search operators and probably had more discussions about how they relate to Gmail because in the Wave world, we weren't sure whether to leave people with the constructs they were familiar with, like from and to, or try to move them to something like participant, contributor, viewer, and things like that. We are certainly taking feedback from our users, and if they prefer sets of operators we don't have yet, we're going to keep iterating.

Audience: How do you envision the desktop Wave clients impacting the Wave community and I imagine because you're working on the Chrome OS and the Chrome browser - the de facto browser for Wave it seems, do you envision operating systems like OS X shipping Wave clients, just like there is an L.app there could be a Wave.app where it becomes that much of a standard for desktop productivity and the desktop clients could contribute even more richness to the experience.

Lars: I would love to see something like that happen. I think it will probably be a bit in the future. One thing you have to realize is that unlike mail, the content inside Wave is very webby. I think you could undoubtedly render a Wave in a non-web browser type client, but you would essentially have to embed a web browser. For example, all of the gadgets we showed could not be rendered without a web browser. I should also say we're working hard standardizing a server-to-server protocol, so that anyone can build their own Wave server. David will talk more about this in the next talk. We haven't done any work at all standardizing protocol between a client and a Wave server. Currently, that's completely fluid and won't change. Say a year or two from now, it would be nice if it was such that anyone could build a client and plug it into any server. It will take some time.

Chair: : Time for three short questions.

Audience: Very quickly, to you have a plan to implement philosophies for Google Wave, and by philosophy I mean the philosophy embodied in the book Getting Things Done, the philosophy that for this lecture format of how to speak, how to listen, which helps people think about the conference. As it is, I found this enormously distracting and not very helpful in this particular setting. Is there any method or means or thinking about that topic?

Lars: Yes, the direction we're going with the extensibility of Wave is to implement applications that implement a particular philosophy or particular work flow. Currently, Wave is just one application that is good in some context and not so good in other context. In the context of having live Waves happening during a conference, you probably want an entirely different view of the Waves that are happening. The idea is the APIs we're building will be powerful enough that other people could build such a thing. We won't possibly have enough time to build all the different ways you could use Wave.

Stephanie: I think this question is also a bit of Wave etiquettes, like how could you communicate with a bunch of people on a Wave, that there are certain protocols you might follow.

Lars: Right now, Wave - the word anarchy gets used a lot. Everyone can do everything; you see everything in real time. That's not always appropriate, so often you'll see people forming various etiquettes where they describe look this way, in fact some of the Waves we helped start for this conference here starts with a text description of how we'd like this particular Wave to be used. What we think we'll do, and this is sometime in the future, is to formalize this concept of etiquette.

For example, if you have a Wave where you like it to be kept fairly brief, not too much discussion inside it, everyone can edit the content to build a directory of Waves for each talk in a conference. You would be able to describe this etiquette in a way where the Wave client will understand it as well. If a user violates this etiquette, the UI will gently warn them, "The person who created this Wave asked that you don't use his Wave in this way." Then at least you would know if you were violating. We hope the best of both worlds where you still get the flexibility if the etiquette is no longer relevant, but you also get some support for maintaining that kind of thing.

Audience: When I look at an application that is going to have the impact that Wave is going to have in the next year, and I think about all the users in the world that have a very - billions of users with a very low Internet connectivity relative to the type of thing we're used to, I'm interested in your longer term view of an offline mode for it, whether that's important or not, what your architectural vision is for that. Is there anything you can say about that type of offline or very low connectivity, intermittent connectivity type usage?

Lars: Super important. The algorithms that underlie our current editing work equally well in a live setting and in an offline setting and anything in between, like a flaky connection, high latency type setting. In fact if you want, you can try disconnecting your client. Keep typing and reconnect, and you'll see the stuff you typed while you were disconnected will eventually show up over the other person's screen. You'll occasionally see that what comes in from other people is kind of junked because their connection is kind of flaky or your connection is flaky. What we haven't built yet, which we very much want to build, is a means for you to persist the changes you're making on your local machine when you're not connected. That's the full offline mode; you're in a plane, not going to have a connection for another half a day but you can start new Waves. You can make lots of replies to lots of Waves and then you can close your computer, go to sleep, and then when you wake up the next morning and plug it in, and all the things you've made seamlessly get merged into the Waves you've touched. That's where we're going to end up.

Audience: What about connecting cameras and streaming video, or will it blow-up the Waves?

Lars: I think there was a question about voice earlier. I'd love to see an integration with video conference type things. There is an extension by a company called Six Rounds where you can have some pretty fun two people video conferencing inside of Wave, but you can imagine you're on a Wave, notice someone else is on the Wave and you link up with a video connection, which helps with collaboration but also helps you just take a piece of the video you're creating and recording it and putting it inside the Wave for other people to see. That's the sort of thing we'd like to build. But it's so much easier for me to tell you that than to actually make it happen.

Stephanie: Let me finish up by saying that's one of the reasons we were so excited to come to this conference because we both think you're a group of people who can help us make Wave better and pick the right features, and also a set of people who might be interested in building these types of extensions that we won't get to for a very long time because we're just a small engineering team and we have a lot of work to do to make the whole product stable, scalable, and fast. We're really excited if you want to check out our APIs, if you want to talk to us at the break, it's code.google.com/apis/wave and we love talking about them.

Chair: I would like you to give a very warm thank you to Stephanie and Lars

Stephanie: Thank you.

Lars: Thank you.

Chair: I think the room is filled up enough. On that note, I would like to say again a very warm thank you to the headline sponsor, Skype. Again, it allows us to be together in a nice venue, with great production, instead of a sort of low-ceiling hotel, sort of lobby place with nailed down carpets, which really doesn't do it for me. I would like to welcome Sten: Tamkivi, all the way from Estonia, who is Skype's chief evangelist. A very warm welcome for the keynote of the headline sponsor.

Sten: Good afternoon. It's a pleasure to be here, and thanks Lee for pulling together eComm and I'm especially happy that this happens, not only in the U.S. where most of the things in this industry happens, but also in Europe. As you might know, Skype also comes from Europe and is one of the few success stories coming from here.

First of all, there is the usual thing that I do that I doubt if I should do here, but how many of you actually use Skype? Thank you. I love you too. I really wanted to see 100%, for the first time in my life. I usually get about 80%. Thanks for that.

What I wanted to talk to you about today is some of the basis of this talk is actually public knowledge. Skype has been around since 2003, only, so we're a six year-old company. Some might call us a startup still, but during that period, we have significantly gained market share of international calling minutes, all over the world. In 2005, maybe there was less than 3% than all calling minutes, internationally, going through Skype. Last year we crossed 8% and it's growing.

I want to give you some background around why this is happening and on which fronts it is happening, and what are some of the very specific issues that we see when we're addressing a truly global user base. Those minutes are generated by about 520 million users that live in 225 countries, all over the world. That's pretty much every single country and territory in the world, except for one, and you can guess which one doesn't have Internet.

Why are we growing? If you think of that, there have been VoIP applications before. There have been IM applications before. There have been hybrids of those before. There have been ones that are based on open standards. There have been other attempts based on proprietary approaches. Why Skype?

The rest of my half an hour we will split into two buckets. I will try to bring those buckets together again later. First, there is this notion of rich, intimate conversations you can have when you don't have the limits or barriers of cost. Earlier, I was looking at Twitter. One of the earlier presenters here was speculating on how much revenue Skype drives away from telecoms if we serve about 100 billion minutes a year. My answer to that is it's not about pulling those away from telecoms because most of those minutes probably would never have happened if we had to pay for them at the high rates. A very typical example is a video call, which is always longer than a voice call, because of the rich and immersive experience you have.

A good example of that is if you have ever tried to have a sensible voice conversation with a four-year old, over the phone. That usually lasts for three minutes, four minutes, and that is the attention span. You put the same kid on a video call with the grandparents, and all of a sudden you get an hour of playing together and drawing together, and all of these other things. Calls become longer and calls become more intimate.

At the same time, the growth of Skype, or the reason we can develop the product is that we make money from interconnecting to the PSTN network. All of our investments, after the first rounds of venture capital, there have been no cash injections into the company. We've been profitable for about 11 quarters now. We keep reinvesting the money we make from the PSTN to make that first rich bucket much better.

Let's talk about the video bit first. When we ask you users how they see Skype and the contact list of people they have on Skype, it's really interesting; the average contact list on Skype is a single digit number. The average Facebook contact list, for example, and they do an excellent job of recommending people you might know, and all of these other drivers that drive people on the contact list, it's tens if not hundreds of times bigger. Our users tell us that it's quite a harsh decision if I want to add this person to Skype because this means that I really want to talk to that person. The value of the members of that contact list is much higher, or they are much more intimate parties in a conversation that's about to happen.

Recently we've seen, and this is still a heavily growing number, which actually is a bit scary, about 1/3 of all call minutes - again, we're serving 100 billion of those a year, 1/3 of them carry a video signal. At peak times, when there is something special happening, like Christmas or New Year or Mother's Day in some part of the world, this goes well above 50%. It's huge. Video is out of the geek sector. Video reminds me of the early days of Skype. In the office, a few of the developers were placing bets on how many users Skype would have after launch. One of the core developers said this is never going to fly because people don't have headsets. Fortunately, he was wrong. Skype was valuable enough that people got headsets.

We've gone through the same transition from approximately 2005, where again we launched video and people didn't have decent cameras. They had trouble setting it up. Different cameras have different drivers under different operating systems and all these other hassles. Now, the video calling part, because of the huge value it provides to people, people have gotten over that. It has helped that Notebooks come with built-in video cameras and all of these other enabling factors. This is for the masses. It's not a technological subset of users or something like that, anymore.

Moving onto the PSTN bit, or the International Long Distance, or ILD as some people call it and what's happening in that space. ILD, over the last five or six years has been pretty stably growing at about 4% a year. It looks like a decent number. Anybody who is trading stock, it looks on the lowish side, especially if you look at the prices of telecommunication endpoints, like phones going down and minute prices going down. If you look behind those numbers, that's actually what has happened. The growth is low because the volume is growing at a decent rate of 13% on average. What happens behind that is that both the retail and wholesale prices at which you can buy minutes when you have tens of millions of them to connect, then that sort of evens out the decent 13% growth in volume, and the size of the industry grows much slower.

There is a definite shift of those minutes going mobile, and going mobile in both directions - between mobile phones and also from mobile to land line and from land line to mobile. I'm sure that everybody knows that so I won't speak about that much longer, but there is something much more interesting which Lee kindly started introducing. These minutes are spread across many, many more calling corridors or country pairs than they used to. Just as a comparison point, there is one of the leading research providers on the market still maps out and monitors about two thousand top corridors. That is the old school telecom view of the world, that these are the corridors that matter.

When we look at the actual Skype usage, there are about 40 thousand calling corridors that are worth paying attention to. Just to give you an example of what a calling corridor could be, in the U.S. to Mexico is the most active international corridor there is in the world, and they serve about 500 million hours of calls a year. That gives us the number one ranking. That's quite a decent amount of calling minutes.

If you look at the top 30 calling corridors, again out of the 40 thousand or the 2 thousand that are currently researched in the world; those top 30 U.S. to Mexico and 29 others only sum up to the 37% of all calls happening. There is a 63% long tail that nobody has ever been able to address because the telecom industry had always been very focused on the local market, or some of them are regional and some may cover a continent quite well and focus the business and offerings there. Before companies like Skype, where we are not a telecom but we are a software provider that utilizes, as Michael put it so nicely this morning, the pipes that telecoms provide, with our software solutions and very flexible software solutions we are able to address this whole global space with pretty much the same offerings. It doesn't matter which country in the world you live in; you can still get access to Skype-to-Skype calling and SkypeOut calling to PSTN connections.

Another obvious statement, but let me go a bit behind that. When we survey our users, taking the intimate, rich, full conversation together and the basic needs of just talking to someone at an affordable rate, in the U.S. about half of our user base tell us that they are using Skype for making video calls. If you ask the same question in the users from China, and there are many other markets that I would say are far more emerging than China is as far as Internet penetration and the availability of decent computers and all of that. In China, you can cut that number into half. On the flip side, if you talk to those people, that has historically been a weird situation because Skype brand is so much connected to real time, live conversations, many people don't know we have a really cool, persistent chat system or the IM system. In the U.S., 5% of the users say they use Skype for IM, whereas in China you would see that number being 1/4 of the users. That starts to build up to a point where there are extremely high geographic differences in what people see as communication and what are the modes of communication those people are willing to go for, balancing their equipment, wishes, and needs for richness and so forth.

Taking that, you can make a much more interesting view on the long distance calling space than the previous mobile chart was. It's too obvious that people are using mobiles and don't want to use land lines. If you're running a global communication network, or a cloud of conversations, then one way you can look it is how are these conversations happening between the developed and emerging markets? On the bottom, on the X axis you can see the originators and then the destinations. You can split those in pairs.

What I did was to take the top 30 corridors, again for the sake of sensible data processing, not the whole 40 thousand, but split that out and it starts to build out something very interesting. Developed-to-emerging is the most important way of communication, or initiating communications among the highest volume corridors in the world. Of course, U.S. to Mexico is a great example of why that is. It's usually people moving from emerging markets to find a life in a more developed market, and then starting conversations back home.

Secondly, from developed-to-developed, again it's quite obvious. If you have a bunch of what we call developed countries, by GDP means or whatnot, in Europe, each of them call the U.S. enough times, and the U.S. calls a bunch of them back, then you get to 10 out of 30 top corridors. That's understandable.

Compare those developed market originated corridors to the ones originating from the emerging ones, and it's a really sad picture. It ties in with what I showed you with the IM interested users in Asia, for example, there are probably a number of good reasons why they don't find - for long distance conversations, what is blocking them of using real time, rich, audio-based, video-based calls to satisfy that need. If you try to generalize this, this is a very weird attempt on a graph; if you have the emerging markets on one side and the developed ones on the other, on the emerging market side, the poorer the country the less Internet penetrated the country. The less telecom penetrated the country. If you look at Africa, there are tons of people who will never have access to a cable in their life, and maybe if they're rich enough they will get access to a mobile phone, which has coverage in their village.

If you think back to the good old Maslow pyramid of human needs, if you have those needs of clean water, and children's health and education and these needs unsatisfied, your price sensitivity is extremely high or the alternative cost of putting money behind communications or making communications happen. You have many more things to worry about and there needs to be something special about communication to even compete with the daily problems you're actually facing.

Whereas, in the emerging markets, the capacity or the capabilities of even handling any real time communications is almost zero. For the sake of simplicity, take the GDP as the basis of how to compare these countries. As a side remark, why I'm stressing it's for the sake of simplicity, there are some other real trends which are probably worth a session on their own, whereas in a very developed market, very developed user segments, when you go into testing new solutions much more eagerly, the actual reliability of communications can go down. Let's say there is an ex-Soviet country with a phone system installed in the '50s but basically works. On a day-to-day basis you might have a better connection to the outside world than the guys who are trying the latest version of LTE on a device that's not out of beta. That's a different story, so let's stick to GDP.

As you move more towards the developed markets, then you will see that people don't worry; the price sensitivity goes down enormously. If you live in the U.S. or in Europe, you will probably have a bunch of competing telcos who are offering you a TV Internet connection in a triple or quadruple package which has also zero cost calls to 30 or 50 countries in the world, so the last thing you worry about is how you are able to afford that, or you're not going to switch to some Internet application because of the price. The price sensitivity goes down and that's not the selling argument for those people at all, to come to emerging communication tools.

Whereas, because they have their needs on the lower end of the Maslow pyramid solved, they don't worry about food, water, and education; they have time to worry about other things like seeing their grandchildren that live on the other side of the country or on another continent, seeing their children who went to college on the other coast of the U.S. and so forth. Both the capabilities but also the drive or need for richness, intimacy, and they have the time to spare to keep in touch with their loved ones, and all of the soft things start come into play much more.

What happens here is that over time, theoretically taking the assumption that humankind will develop slowly but steadily towards some common level of development, which I don't know if you believe it or not, you can draw the line or move the line from right to left a bit, so there are more countries in the developed segment or less in the emerging but it's highly unlikely that it will ever hit 100% that everybody is zero price sensitive and 100% richness oriented, but that's how the market develops. It's not flipping from one end to the other or one end is not coming to replace the other.

With a company or an emerging communications provider, whether it be software or hardware, some new business model based on the existing software and hardware, or something else; as long as you pick one of those ends, what I'm saying is that in the foreseeable future, there will not be a high quality video conversations provider with a global footprint. There will not. People who will play in that segment will always be limited to the developed or well established communication markets or telecom markets which they can build upon.

On the other hand, establishing a next venture, and MVNO that's trying to do a price arbitrage, a new calling card system, or anything like that which is only focused on price with the same low or narrow-band audio quality, with a - what is the number - before, a call setup time with 8 seconds on both ends and all of these other things, the non-quality things will never be able to have a global footprint because people in the developed markets just won't care and it will help the number of people in the more emerging markets or expats from emerging markets in the old markets. It's still going to be a niche.

In order to truly cover the global communications needs of humanity, you have to do both. Basically coming back to the title of this presentation, there is the love and peace component and there is the good old analogy PSTN component that you need to serve in order to truly enable the world's communications as we wish, as we are doing at Skype. With that, I am running ahead of time so there is plenty of time for questions, if you have any.

Audience: What happens if you succeed and get 100% penetration? What do you make money on?

Sten: First and foremost, it's fortunately some while ahead. Skype has 520 million registered users and a subset of those are truly active users. There are about 1.2 billion PCs connected to the Internet. There is about 2 billion mobile phones that are equipped enough to run the a third-party voice application basically. All in all, there are 6 billion people in the world. Even though half a billion users look really big and we're happy to have achieved that in the first 6 years, at the same time it's still the very beginning of the curve. In turn, that means that we have a lot of time still to figure out sensible monetization models, if and what we need to do with the non-PSTN users, experiment with those, and we're in no rush to roll something out on a global basis and make Skype paid or anything like that.

Audience: Would you see an advantage or a disadvantage for Skype to switch from its proprietary protocol to an open standard like SIP?

Sten: We've been quite successful with a proprietary one, so any switch like that would need a very good reason. It's one of those where you don't fix what's not broken. I think what is more immediate for us is the question of how to interop with others, and something we launched this year into beta was Skype for SIP. The other related project is Skype for Asterisk; where it's about how do you connect to other end points who are not Skype nodes; which of the standards of protocols are the ones you pick to communicate with those. As you can see, we're doing SIP and Asterisk in parallel because that gives us new learnings of what works, what doesn't, where do open standards fall short.

If you think back into late 2003 where those decisions around Skype's architecture was made, then I don't think we would be where we are if we had gone with open standards at that point. Some of those reasons have been mentioned today, as well. If you ask the users why they picked up Skype in the early days, they usually say Skype solved the problem of setting up the client. Me personally, the first time I tried to use a VoIP client in 1995, or 1996, and being a fairly technical person, I couldn't get through the proxies and ports and all this other mess I had to set up. Once I got the client running there was nobody to talk to. Those two problems, Skype solved, and a lot of that solved is our proprietary invention of how to solve it. That's explaining where the roots are. Today, we are looking more to how we open up to these open standards rather than replace what we have with something else.

Audience: To follow up on Adrian's question, there have been a lot of rants on the Web about the interoperability behind your P2P technology and the fact that Skype might be bought out by ventures and peer-to-peer technology would then be part of the [00:25:09.29 ?] software.

Chair: What was the question? I didn't understand it.

Audience: The question was would you go on open standards because of IP problems?

Sten: Of course, I can't comment on ongoing litigation, but right now we're just running our business as normal.

Chair: Let's not have blog-type questions. People can go on for a week commenting on blogs online in these topics anytime. Are there any other questions for Skype?

Audience: We've just heard you refer to your various corridors, calling corridors between emerging and developed countries. I couldn't help noticing a lot of them seem to parallel some of the biggest remittance routes in the money transfer business, and some of the ones that have outrageously high transaction fees attached to them. Have you ever considered implementing a credit transfer or mobile money transfer like an extension for Skype? It seems intuitively almost obvious that given this has become such a big part of the business, that you'd be interested in that.

Sten: We've done experiments in that space, and most notably Skype has been since 2005, part of eBay and another company that is part of eBay is PayPal. We experimented with some product integrations with PayPal, like bringing PayPal send money to Skype between users and all of that. I think the main hassle, which again has been mentioned here today, is the individual regulations of individual countries are not ready for a pan-Internet fluid payment system. In the worst case scenario, and that's the business where PayPal is, that PayPal is becoming a bank in more, and more countries as far as legal status. We believe our mission is to enable the world's conversations, so we have not decided to take that step and start becoming a bank. We have enough hassle with many countries trying to regulate us as a telecom even though we're not. That's probably mainly a question of focus.

Chair: If you have questions, it's quicker if you stand up, so you're seen.

Audience: Just a question about are you planning to develop the social network capabilities of your platform? Are you planning to develop Skype into more of a social network platform itself?

Sten: What do you mean by social network, first?

Audience: I guess I kind of view Skype as a social application in that it allows you to connect with others and have presence, and that is an overlap with some other capabilities within social networks like Facebook and others. To what extent are you growing that capability set within your platform? Are you thinking about Skype as a social network itself?

Sten: Definitely, I think Skype is a social network because there are people, real people, there are social connections, and there are graphs you can analyze. I think what you're more referring to is exposing that all more in the clients and all of that. Yes, there are some things we have done and probably will do in the future. One thing that comes to mind is a few years ago is we did an integration with MySpace when MySpace was the number one social network. You didn't have to build your own profile on Skype but you could link to your MySpace profile and pick the new image from there and so forth. For the shared user base it had some value, but it was not something that was a game changer.

We are taking that carefully though, because of the intimacy slide that I showed. The nature of the usage pattern of people currently relying on Skype for their conversations is heavily, or the perceptional value they see is heavily different than the web-based social networking sites. If you mix them up too aggressively, like as a Skype employee and a heavy Skype user, I have 1,000 plus Skype contacts. That's a geekish thing to have currently. The clients are much more optimized for the segments of users who have a smaller number but more intimate relationships on Skype and they use those other sites for the whole thing. I'm sure you will see more experiments with different partners and opening of different APIs on both sides, and what not, happening.

Chair: We have time for one or two more quick questions.

Audience: I'm from Slovenia and I have a user question regarding you have peer-to-peer technology but it's not a pure peer-to-peer technology because it has a client server part. What happens to me, for example, I have a Wi-Fi community at home. When the Internet connection is broken because of a break in the fiber connection somewhere, I couldn't communicate with my community. Are you working on that area also, to be the pure peer-to-peer application?

Sten: I'm sorry; I don't think I got the question.

Chair: The question was Skype is a hybrid, it's a peer-to-peer, and it's centralized in terms of having a login directory. Do you ever plan to go fully decentralized?

Sten: I think we're looking at use cases, case by case. There are some things - for example, we keep your contact list on the server. When you install a new computer, log in, you get your contact list back. Some things like media streams only use peer-to-peer so we find that hybrid to be very flexible.

Chair: It's hard to see the audience; it's a little dark. If there are no more questions, please thank our headline sponsor, Skype and Sten:, for coming all the way. Thank you. We appreciate it.

Sten: Thanks Lee.

Martin: Thank you, Lee, for inviting me, and thank you all for coming here to this very special community of eComm. What I would like to do this morning is to present to you some ideas about the future of communications and future business models. These ideas are very much my own; they're not British Telecom's corporate position. I'm still working on that. If you could put up my presentation, then the thesis I have this morning is a very simple one, which is that the era of minute-based telephony is going; however, there is a huge opportunity to replace it with something new. I'm calling that something new "moments" rather than minutes. These moments will be when a global communications platform helps to make business processes and communications between enterprises and their customers more efficient and more effective.

Goodbye minutes. Back in the 1980's, BT was advertising telephony, front and center of its offering. The message was that there was huge social value in telephony. It was no longer a luxury product that was restricted to business use or essential needs; however, a mere seven years later, the advertising had changed. Production values had gone up. The adverts are much more expensive. There is more celebrity endorsement, but the truth was the product had become one promoted on price, and was essentially a dull commodity.

Roll forward another decade, and telephony disappeared. All of BT's adverts for the consumer space are based on broadband and media. It's the same story, very much in the business space. It isn't just fixed-line operators who have this dilemma. The mobile party is over too. Two charts here, they show you the revenue for the top four operators in the U.K. and it's a similar story for other developed markets. As you can see, the revenue for both voice and messaging is peaking and it's starting to decline.

It's not just price competition. Users are starting to migrate to other tools and services. For example, kids are starting to use BlackBerry Messenger because it avoids SMS charges. However, there is a natural lifecycle to any industry involving technology. Just as wireless communications came along, and cellular technology, and spawned the mobile phone; every kind of technology or products that emerges is put to uses that were never anticipated by its originators. Those new uses spawn new needs, which in turn spawn opportunities for new technologies and products and business models. That, in a sense, is the heart of the message that was put to you this morning; these new needs create a huge opportunity to replace the dying minute model.

What could those new needs actually involve? I'm going to pick as a case study a core telecom's product, which is voicemail. The example I want to share with you is a real voicemail that I personally received from the U.K. tax man. It was about two days after I filed my tax return. I'd done my tax return and it said I owe them some money. Presumably they're calling up to say, "Please pay us some money." I think it's typical of the millions of interactions that occur every day between enterprises and their customers, and very clearly highlights some of the problems involved. I'm going to break for the audio/visual gods and play the first half of the voicemail. I want you to listen very carefully, think hard about what you're really hearing in this voicemail. Think beyond the immediate words. [Audio] "First saved message, from September 29th, at 9:39 a.m." "Good morning, this is a message from [04:43:15] Customs, for Mr. M.R. Geddes. If you could return my call on telephone number ..."

Martin: Okay that's enough. It's boring enough. What did we really hear there? The first thing we heard was a container for the message, which announced the message. It gave us one piece of meta data which is the time of the message. It didn't in any way relate to the specific content of the message. It was completely dumb. The second thing we heard was the medium of the message, which was relatively poor quality audio. You could hear that transition from the better quality audio of the container to the very poor quality audio of the actual message itself. It's hard to understand. Then it was the message content, which was a sequence of business objects which have been encoded in a one-way manner into human voice. Finally, we heard the container again, and the container said, "Press hash to return the call," but was also dumb and in no way related to the actual content of the message. Let's call them back. [Audio] "This is a test message. The service on this number is currently inactive."

Martin: As a special bonus for today only, they'd even given me the wrong number. I think this example highlights very powerfully some of the inadequacies of voicemail as a channel for businesses to communicate with their customers. The first problem is it's ineffective. It relies on me as a customer, writing down all those details, the numbers called back on, the reference number, being in a context in which to do that when I receive the message, remembering to act on that and actually then going to act on it properly.

Also from the perspective of the enterprise, which in this case is a tax man, it's given me a poor customer experience. Before I've even arrived into their call center, I'm already not a happy customer because I've had to go to the poor user interface of the voicemail system.

The second problem is it's highly inefficient. They've had to pay somebody for that one-minute voicemail, to sit there for one minute and hand craft - it's like the hand weaving of the 21st Century - this message. Even if I call them back, they have to then pay someone to re-identify me, and re-authenticate me, which is a process that is both expensive and can go wrong.

Finally, it's an insecure process. You might note; there was no reason given to me in the message for why I should call them. That, presumably, is because the tax man can't know for certain that it's really me that's going to receive the message. In return, I can't really for sure know it's them. That's not a minor problem because even at BT we have a problem with people phoning up BT customers, pretending to be BT, and trying to defraud them in various ways. For the telco, it's made about 7 euro cents worth of termination fee for that one message, and that's a declining figure that's being regulated downwards.

It isn't just telecom's products that have this problem of being inefficient and ineffective at communicating between enterprises and customers. For a moment, forget about BT being a telco. BT is a business like any other business that needs to communicate with its customers. We've been experimenting with new channels to reach our customers, and in particular; we've been using social media to try to discover customers who are talking about BT products and services, or maybe having issues with those products, and to proactively reach out to them.

We have had a major trial and we've had over 17,000 interactions with our customers, through Twitter for example. It's proving to be a very effective channel to reach customers. Of our enterprise customers we've talked to, over 50% subsequently go on to spontaneously make a positive comment about BT in a public social media space, so it shows a very high rate of customer satisfaction with this channel. Whilst we've received tremendous support from social media players in running these experiments, we have found limitations in this channel as a customer support tool.

Firstly, around support and accountability is we're still using fundamentally a consumer product with consumer-termed conditions. If we started to have to support millions of our customers, those terms and conditions may not be appropriate for that use. Secondly, there are various systems limitations that affect our use of the product. 140 characters may be appropriate for consumer-to-consumer chatter, but if we want to send the customer, "Here are the instructions to fix your problem," it's a bit hard to do that in 140 characters. We may need richer interactions. Things like the ratio limits on followers to following may be inappropriate for servicing millions of customers.

Next is the security private data. Telcos are entrusted with some of your most personal data, who you talk to. We need to know, for example, that your account number could never become searchable in an index. The limitations of the system constrain the types of conversations that we can have with our customers.

Fourthly, is the timeliness of the data. We're able to poll for new mentions of BT and its products and services, and analyze that contextual data about every fifteen minutes. In that fifteen-minute window, the customer could easily have called into the call center and we could end up double handling the call, which not only increases cost, but then further creates customer dissatisfaction.

So, what's the real need? It's that communication service providers, whether they're telcos or online Web 2.0 type players need to return back to fundamentals. Fundamentally they're to make communications simple and easy; however in doing this, they have to confront two inescapable realities. The first one is that the public increasingly expects the actual services themselves to be free. They want the delivery of those services, the distribution of them, the voice minutes, the MB to also be free but they aren't quite getting it yet. There are products like Google Voice and they're bringing it. Even when they pay, and they are willing to pay sometimes for quality and convenience, they should increasingly feel like free, as part of a standard priced bundle with no extra charges.

The second inescapable truth for enterprises is that minutes waste time, and therefore money. There is a fundamental disconnect between the product that's being sold to enterprises and the revenue model around it, and what they value. Time on the phone is generally undesirable because it costs labor, rather than desirable. The challenge that operators have in replacing the lost minutes is to find new revenue streams. The revenue streams are limited either to the consumers or the enterprises on their own, face limitations. On the consumer side, media as a value chain is very fragmented and undergoing its own world of turmoil. On the enterprise side, cloud computing and unified communications are more tightly associated with IT enterprise players than with telcos.

I believe the real opportunity lies in the space between these two. Enterprises have always communicated with their customers through a variety of different channels. Once upon a time, your customers had to come to your physical premises. Communications over a distance was so expensive using horse and hand that only states and the most enormous enterprises could afford it. The postal system, brought on top of the railroads, democratized communication. The telegraph and telephone brought communication at the speed of light to everybody. Those media in turn spawned others, like couriers or SMS.

However, there is still a very limited range to choose from, and we're still adding to that range with products like IPTV. However, the Internet has fundamentally changed things. The Internet is a kind of meta medium that can spawn new media every day. That creates both a problem and an opportunity. The problem is an increasing complexity in how to deal with customers. The opportunity is a greater range of means of interacting with those customers. Therefore, the challenge to anyone who is trying to sell a communications service faces is to build a rich interface to those customers.

Commercial conversations will migrate to the media or channels that offer the best combination of reach efficiency and effectiveness. The consumers will be attracted to channels that offer low price, and they'll pay in terms of their privacy and their attention. The enterprises will be attracted to channels that give them a breadth of customers, the number of people it can reach, as well as the depth in terms of the types of interactions they can have.

To reinvent the telecoms business, there are three things that have to happen. The first one is that we have Telcos have to use their existing communication channels more effectively. How might they do this? The first is the prerequisite; they have to keep the customers on their existing channels, which is by making sure it's a fixed price bundle and not overcharging, and reducing termination fees. If you think back to the voicemail example I was talking about earlier, there are tools out there already that help to try and fix this. You might hear, later in the conference, about Phweet, as an example, which would let you send a text message to the user with a subject, why do they want to talk to me, and a hyperlink embedded. If I click on the hyperlink, it will set up a phone call and I will be put through to the relevant person.

However, there is a revenue option that's being missed here for telcos. This involves one bulk SMS and two originated phone calls being bridged together. These three things could be packaged together as a bundle, and sold together to solve the customer contact interaction problem, and promoted in price differently. Currently they're not.

The second thing that has to happen is operators of communication services have to start to enhance the existing channels to support more efficient and effective communication with customers. How? Let's think about that voicemail example I gave you earlier. Here are five ways in which voicemail could be reinvented to make communication with enterprises and their customers more effective.

Firstly, simple APIs: insert, update, delete. A common scenario is something like this. The tax man calls me to leave me a voicemail saying, "Please pay your taxes." I didn't listen to that voicemail immediately. I know I have to pay my taxes. I've just submitted my tax return. I go back to the website, and pay my taxes. I then pick up the voicemail, and it tells me, "Dear Mr. Geddes, you haven't paid your taxes." I call their call center and make an unnecessary call to their call center, and it's wasted another 10 Euros cost to them. If they could have simply expired the voice message when I went to the website and paid my taxes, then that was a chargeable moment that would have improved that business process; nothing to do with minutes.

The second example is if I can't understand what they're saying, the business process doesn't go forward. If the customer experience is poor, it doesn't go forward. Why can't they record the voice message for me in high-definition audio, locally, move it around as a file as just a bag of bytes, and say if I've got visual voicemail, I can play it back in high definition? There are no dropouts in the cellular system in the middle. That's a chargeable event.

Thirdly, personalize the interaction. For example, if I am on a business trip to China and it's 3:00 in the morning. If you call me to remind me to pay a bill, I will not be happy. If you try to call me to make a sale, I will be even more unhappy. However, if I'm in the U.K. and it's good timing; great. If I'm a prepaid user, sending me a text message with a hyperlink embedded may make me unhappy because there are high data charges. If I'm an iPhone user on unlimited data, it's fine.

Fourth, make the container smart. That can be done in various ways, for example, it could be the container lets you put a voice XML document rather than just a bag of audio bytes. I can have an IVR right there inside the voice message, and I can complete voice processes inside the voice message; no calling back to a call center. Or, it could simply be press hash to have the voicemail system set up a call, or call you back when their call center reopens.

Lastly, make communications multi-modal. For example, BT with Ribbit offers voice-to-text function. Start bundling that and selling that with the termination fee to the call center.

That was voicemail. What about social media? Well what does Twitter for business look like? Two things have to be done. Firstly, an enterprise customer experience, that means service level agreements and enterprise support. Companies like BT, thinking of BT as a generic enterprise, would be willing to pay for that because it is an efficient channel.

Secondly, create the features enterprise as required, so yes, multimedia messaging enriches the level of communication we can have with the customers. Federated identity, if you recycle a Twitter account and it's assigned to someone different, we need to know. All our employees using a single Twitter ID, how can we federate our employee IDs with the Twitter IDs? Security, authorization features, we need to know that certain types of data that we send to customers maybe it doesn't get re-tweeted. And, make it real time. It's all about "now." Taking the lag out of the business process is where the value is.

The third thing to do is to create whole new channels for interacting with customers. The example I'd like to give is everybody in this room has a cell phone either in their pocket or in their bag. It has a call log: missed calls, dialed calls, received calls. I believe, maybe five years from now, there will be a huge battle over placing on the idle screen people who want to talk to you and why, and who gets on there, and in which order they're presented, and how it's presented will be a huge business. If telcos don't do it, somebody else will.

For example, Google in Google Mail has a new feature of sponsored messages where a little icon appears next to the mail and you can roll your mouse over, and you can interact with that enterprise without opening the email, let alone going to their website. It's talking away the friction.

BT is also in this game. We're trying to enhance the range of communication channels to customers, so we're the preferred voice engine for Google Wave and that's creating a richer set of end points and a richer set of interactions that enterprises can have with their customers. What's interesting is it also opens up potentially, in the future, upsell for future transaction which in this case is an advert.

That's really the hope to how we need to think about fundamentally reimagining the offering. Businesses everywhere engage in six common business processes that fundamentally add no value underlying goods or service, and these business processes often find a bottleneck in the interface to the customer. By intelligently reimagining their products to solve those interaction problems, there is a huge opportunity.

For example, every day in call centers around the world, call center operators are paid to transcribe names, addresses, credit card numbers of people for whom the telco they're placing the call from already knows. Trucks deliver parcels to homes where the telco knows you're already out. Utilities send out bill payment reminders by post to people for whom the telco already knows the email address, the Twitter ID, the mobile phone number associated with that home.

To solve those problems, there has to be a platform that has three functions: the ability to connect the enterprise to its customer to make the bits flow, to interact with that customer in some way, and then to be able to transact the business process. I'll give you some examples.

Here is what the revenue model might look like for these moments. Let's imagine we're delivering a high-definition audio voice message into a voicemail system. The conventional wisdom for conventional HD audio tries to charge the customer for this improved feature. The unconventional wisdom is charge the enterprise for leaving a high-definition audio voicemail.

Interact - what if that voicemail avoids a call to the call center because it has a voice XML document and IVR embedded; don't charge for the minutes. Charge for the business process outcome and avoid a call to the call center. Think of my taxes; if I'm going to pay several thousand Euros in some transaction, potentially I could have completed that actually inside the voicemail, and that PayPal for voice product, if you compare the transaction fees to say maybe a Visa or MasterCard, it could have been a tenuary opportunity. There is a huge amount of revenue being left on the table here.

I believe that solving these problems is going to spawn a global race to become the platform that enables this. The platform is required because there is enormous complexity in the middle of this ecosystem. There are too many combinations of enterprises, communication channels, and telcos for any one player in this market to be able to act on its own, no matter how big. These platforms will aggregate together the enabling capabilities of telcos, so for example, APIs to insert into voicemail system. They'll aggregate together enabling capabilities in Web 2.0 properties. They'll aggregate together data about customer profile an preferences. They'll offer these rich interaction services as a communications-as-a-service offering as part of a global cloud computing fabric.

Featured communications is global. The Internet is the global on ramp. The Web is the global user interface. However, the applications for that user interface, today, exists in little stovepipes and they're unable to interact to communicate with each other, and that's where the inefficiency in these business processes come from. The trillion dollar question is who will profit from operating that platform; will it be telcos?

Telcos actually have, naturally, quite a large head start. We have the users. We have the people using our products today. We control those channels. We can innovate around those channels. We have real-time customer data about those people - your location, your presence, your calling history. We're able to bill for millions of events that would naturally be produced by this platform.

However, there is also a danger that online players and new entrants come and re-intermediate telecom's value chain. For example, could a Salesforce.com start aggregating together CRM data from multiple CRM enterprises and start to paint that picture of this is how this customer communicates. "You, Mr. Enterprise, know a lot about your customer in terms of their grocery purchases or the furniture or whatever it is that you do, but we know a lot about that customer in terms of how they communicate."

Or will it be someone new? Just as how Skype, Google, and YouTube, and all these good things burst on the scene and were not ever forecast to be the way they are; will we see a whole new raft of entrants come in and seize this opportunity? Regardless, I think we'll see an unfolding of a new stage in the evolution of the business model of the communications industry. Over the last hundred fifty years, we've seen five stages to this journey.

The first one was born by postal system and telegraph and telegram, which was bringing to everybody the ability to communicate at a distance with messages, and SMS is the current manifestation of that.

The second was an increased democratization of that technology. The telegraph was the specialist activity. The telephone everyone could use, and mobile telephony brought communications everywhere, but only for one application.

The third stage was data. Data enabled any kind of application to be run over generic data networks. The current focus of many operators is on media, which is how to package and deliver that content; not just to move the bits and bytes, but also to be able to present it as an edge device.

I believe we're seeing the birth of the fifth stage of evolution of communications industry, which is moments. These moments are when enterprises connect, interact, and transact with their users to create business process efficiency. That, I believe, is the foundation of the future. I am very interested in hearing from any of you who would like to join me on that journey. Thank you very much. Moderator: That tied in very nicely with my dreams of efficiency. Can we have a bit of Q&A with Martin, here? Please, over to this gentleman at the back.

Audience: : I wonder if you could speak to the privacy concerns. What I saw you write earlier is that you have a very nice BT-centric view that BT will spy on me as I leave my home, track where I go; my bill collectors who thank God are not after me right now, will have the opportunity to remorselessly pursue me down the street. I personally have well over 200 email addresses for the purpose of preventing privacy violations, but what I heard over here was a massive privacy violation. BT will sell my data to the bill collectors so they can pursue me.

Martin: Quite the opposite. Imagine there is this evil company called Google that continuously tracks everything you're interested in on the Web. I have Google Latitude on my phone that watches me everywhere. I, as a user, love it. I opt in because I get something in return. It's completely transparent as to what they're doing and I get value out of it. It's an exchange of value, so I do not want to ever receive again a little on my door saying, "We are sorry you were out. We sent the truck to your door to send you this little note." I don't want it.

It's definitely not a class of how do we flog our customer data, because that would be a disaster. The question is how do you offer both sides of this equation value; the customer increasingly gets cheaper or free services and in return they allow their data to be offered up and to be used in very specific and limited ways. Yes, I too used to recycle email addresses and there are a few enterprises I could name who have had definitely privacy spillages, but I think operators are trusted - trusted is a dangerous word to use. There is confidence in operators and they also have huge expertise in managing very private data and managing the regulatory and legal concerns around that.

Audience: : Hi Martin, thanks for the great presentation. Coming back to the comment that was made and building on what you said, do you see the carriers going through a revenue transition from subscriber-funded services, which is the bulk of their revenue base today, to the types of revenue models you are describing here? Do you see those models coexisting, or is it really an either/or proposition?

Martin: I believe the transition will be messy. It will happen at different speeds in different regions. Different types of players will emerge with different kinds of platforms. There will not be just one global platform but will be different sets of platforms. There will be lots of coexistence and it's too early to tell. I wish I had a crystal ball as clear as that.

Chair: Martin, would you describe it as a bloodbath, or is that going too far?

Martin: No, because often these changes are more dramatic and take longer than expected.

Audience: : Martin, are operators trusted or tolerated, and do you think customers would like to break the link between identity and numbering so you do not know who I am because you're not paying me to know?

Martin: Are they trusted or tolerated? I think it's a mixture of both. The operators have this partial and incomplete knowledge about households and users - the person that has the bill and the person that uses the phone; however, they have more of this information than anyone else and if they're clever enough to work out "how do I partner with the right players to make these business processes more efficient and effective", then I think users will be - the trust and tolerance thing kind of goes away a bit. "You want me to do what in turn for what; okay, that's a clear deal. I'll do it."

Imagine that voicemail example - there is potential to ask the customer, in real time, "Would you like your operator to give us this piece of information in return for this piece of value to you? Press 1 if you agree," or enter your PIN. That's the opportunity. It's not a generic - solve this problem for every business process in the world. It's like let's just deal with little problems at a time; how do I return a call to a customer when they are actually likely to be able to answer it? How do I deal with the text message? It's pre-paid versus post-paid. Are you willing to tell us what kind of contract you're on? That's the kind of very small privacy release that improves the customer experience.

Chair: I'm not sure how to pronounce your name. Is it Jap or Jahn?

Audience: : Yap is okay. Martin, you speak about quality moments. Isn't the key issue the perception of the users instead of the efficiency and effectiveness? Do you really look into what users see when they look at you?

Martin: Last night, I was editing my slides on the train here. I was wondering whether that last slide to say "Moments to Efficiency," or "Moments for Experience" because efficiency that is very obviously a benefit to enterprise and experience is the thing that benefits the customer. In reflection, having heard your question, the next time I present this it's going to be "experience."

Chair: Okay, one final question from the gentleman over here.

Audience: : I wanted to ask about regulation because we've had quite a nice few years where lots of these services like Amazon and so on, have invented themselves and have given us the luxury of being able to interact very easily and buy things very easily, but now it seems that the state and regulation has caught up with that and is kind of a force that's trying to break that again. Recently, I've had several examples of companies telling me the Data Protection Act was a reason they couldn't do things for me that I wanted to do, for example, be able to suspend my daughter's phone account because her phone had been stolen. [chair interruption] The question is what is the regulation factor?

Isn't regulation going to take over and stop this innovation from happening?

Martin: No, because Google exists. Clearly, our existence proofs of business models based on the users voluntarily sharing their personal data and the data protection is a set of very good principles around which any good enterprise rebuilding its business, so no, I don't see regulations being a major hurdle.

Chair: Thank you very much Martin.

Click to listen

Download the audio file - 20.5 MB

Right-Click (PC users) or Control-Click (Mac users).