Two videos for mobile app developers

Just a quick note to let you know about a couple of informational resources for mobile developers.

--Motorola is starting the online publicity for its upcoming Android-based smartphones. They did a brief interview with me, asking how mobile app developers can distribute their software (link).

--Elia Freedman of Infinity Softworks did a great presentation on his experiences selling through the iPhone App Store, and the lessons he has learned. It’s well worth watching the video here.

It's best to watch both of these, and think about them, before you develop your mobile app.

App stores and APIs: It's the ecosystem, stupid

If you make a web application or mobile platform, one of the trendiest things you can do is add APIs and a software marketplace to it so developers will extend your product. Google is previewing its application market for Android (link), T-Mobile USA has promised a new applications store for its phones (link), and many people I've spoken with believe Microsoft bought Danger in order to get its software store technology.

The idea of encouraging third party developers dates back at least to the early days of MS-DOS, but it was associated mostly with operating systems until Web 2.0 applications took off a few years ago. Google played a big role in that change, by exposing APIs to Google Maps that made it possible to embed maps in other web applications. That helped Google Maps quickly blow past established mapping services like Mapquest, while the installed base of Google Maps extensions made it hard for Microsoft's web mapping product to gain traction.

The drive for web APIs got another big boost when Facebook enabled developers to extend its functionality, driving an explosion of widgets for Facebook that helped it grow past MySpace to become the #1 social network in the US (at least according to Alexa).

The web app people all noticed Google's and Facebook's success and furiously started adding APIs to their products. Today it's unusual to hear about a new web app that doesn't have some sort of API story or future plan to add them.

In mobile, applications have an interesting history. Lately some new mobile players have generated huge attention for their application marketplaces. The chart below shows the one year growth in the developer base for a certain well-known mobile platform:



If you're like most people in Silicon Valley, you probably think that's an Apple iPhone developer chart. But actually it's Palm OS ten years ago, from 1998 to 1999.

Disturbing, isn't it? The idea that a platform could take off like that and then crash and burn...makes you wonder if the same thing could happen to the platforms that are popular today.

And in fact, if you look at the history of APIs on both mobiles and web apps, the failures are more numerous than the successes. If you're a developer trying to pick the right platform to create your apps on, that choice is very dangerous -- you're betting the success of your company on something that has a better than 50-50 chance of failing.

If you work at a web or mobile company creating APIs or an app store, the news is equally disturbing: The odds are that you won't succeed.

So it's very important to look at the history of those failed platforms, to figure out what goes wrong and how to avoid it. When you do that, the answer is pretty clear:


It's the ecosystem, stupid

The success of a developer program is not driven just by the beauty of the APIs or the store, but by how the overall ecosystem works to enable developers to prosper. The two parts of the ecosystem that are most important to developers are the ability to create something cool, and the ability to make money. Coolness gets developers to try your platform in the first place. Most developers, especially the innovative new ones, gravitate to a platform that lets them easily create something cool that will impress their friends. But as those developers get older and more responsible, they eventually get tired of drinking lemon drops with Mark Cuban (link). They need to pay rent, buy food, and do other things that require money. If they can't make money from a platform, they will move away to the next one. So the financials are what makes developers stick around over time.

If the ecosystem breaks down anywhere in the chain, the developer community will eventually collapse. You can see this in process driving the history of some prominent web and mobile platforms:

Facebook. Earlier I said Facebook apps were a success because they helped the company grow. That's definitely true from Facebook's short-term perspective, but if you talk to Facebook developers the story is much more mixed. Some people online say there are lots of ways to monetize Facebook apps (link), but other reports say it's difficult to actually make the revenue come in (link). The online attitude toward this when Facebook's platform launched in 2007 was pretty dismissive. One commentator wrote (link):

The problem of not making money with your app is not a Facebook problem. It's your problem!

That's the right attitude for a developer to take: Control your own destiny. But monetization becomes a Facebook problem if nobody can make money. Developers poured into the Facebook platform like the tide in the Bay of Fundy, but a lot of them couldn't make money and promptly poured back out. I can tell you from personal experience that some are pretty bitter and unlikely to do anything with Facebook again.

Mobile Java's problem was that it's not a real platform. Handset vendors and operators were allowed to break compatibility between their implementations of Java, forcing developers to tweak their java apps almost endlessly, dramatically raising their costs and making it hard to scale their companies. The selling model for Java apps was also seriously broken -- to get prominent placement on a phone, developers often had to cut special deals with carriers. Some of the most successful mobile Java game developers have survived because they're great deal-makers; they figure out how to develop for a big brand that wants to create a mobile presence, or they hook into the promotion of a movie. This business model favors a few companies with the skill and contacts to cut the deals; the current mobile Java world is not an ecosystem that can support huge numbers of developers.

Palm and Windows Mobile both succeeded at first in enabling developers to create a lot of interesting applications. Although both operating systems had technical flaws, they were reasonably open to any developer, and the "write once run anywhere" idea mostly worked. Unfortunately, the marketing and sales model for those applications started out mediocre and got worse over time. There was no software store on device, so users had to go out on the web to find apps. This cut the number of people looking for applications. Those who did look online usually landed in the mobile application stores, which over time took a larger and larger share of the developer's revenue. Eventually, the stores' cut grew to more than 50% of revenue, making development uneconomical for many companies. When sales of Palm OS and Windows Mobile devices failed to grow rapidly, the financial model for many developers fell apart, and the ecosystems faded.


What to look for in an ecosystem

If you're a developer looking to find a viable ecosystem, or a platform vendor looking to build one, here are the things to look for.

How easy is it for developers to create something cool? How powerful are the APIs? Can the platform be programmed using standard development tools? Eclipse seems to be the preferred platform among much of the web app crowd, and it's free.

Is the platform programmed in a language that's obscure or difficult to use? This has long been one of the big barriers to Symbian native app development.

How do applications get visibility? Is the store displayed at the first level of the smartphone? How easy is it for users to navigate the store? Online stores like Handango are notoriously hard to navigate; the user experience is about like walking through a flea market.

Can good apps rise to the top? In some software stores, the developer has to pay for prominent placement on the store. This is incredibly corrosive to the ecosystem. The big software companies with money to pay for placement are often the least innovative. So users see an app prominently featured, try it, are disappointed, and never try another one. If web search worked this way, there's a good chance that the web as we know it would never have developed. The practice of pay for placement is a self-defeating, regressive tax -- it penalizes most the small developers who are most likely to create compelling new apps that make a platform more successful.

Ideally, placement on the store should be based on independent user reviews, so the best new apps can rise to the top naturally.

What are the terms of business? Can a developer bill for an app through the user's phone bill? Forcing people to input their credit cards separately slows adoption of software. Can the developer choose different forms of payment? Developers should be enabled to experiment with freeware and subscription payment systems, just as they do on the web. How much of the developer's revenue does the store keep? The ideal cut is no more than 20%.

Are there restrictions on the application's functionality? This is a sore point for iPhone developers. Apple won't allow intermediate platforms that run other applications. So no Java, no Flash, and no emulators like StyleTap's Palm OS emulator (link). This also inhibits other developers who want to expose APIs within their applications.

What is the overhead for security? Some platforms require applications to pay for a new security certificate every time the app is revised. The cost is typically a few hundred dollars, which doesn't sound like much to a big operator or OS company, but is a huge burden to a small company with several apps. They're basically punished every time they fix a bug, which is very unwise -- you want developers to fix bugs instantly, because that increases user satisfaction and reduces support calls. Basic security certificates can and should be issued automatically by the software store, at no charge.

How big is the user base? This will be a more and more important issue over time. For a developer, the ideal platform would let them sell to the whole base of mobile phone users, not just one brand or model.


Room for improvement

Based on those tests, no mobile platform offers an ideal ecosystem today. Apple probably comes closest at the moment. Here's how I'd grade it:

--Power: A-. The iPhone APIs give developers a huge amount of power, and there was a lot of delighted commentary on the web when the APIs were first revealed. But there is a learning curve for iPhone development; Apple has its own tools and its own variant version of C. And support for some typical OS features (such as cut and paste) is missing.

--Store: A-. The store is built into the device prominently, so apps are easier to discover. And there is a user-driven rating system. Developers can bill through Apple's iTunes system; not as convenient as billing through the carrier, but not bad. Apple takes 30% of revenue, which is not ideal, but is better than the 50% or more cut that burdens mobile app developers elsewhere.

--Terms: C+. There are significant, ambiguous restrictions on what a developer can do on the iPhone. The most onerous terms restrict the ability of developers to add functionality to applications and create software that run other applications. The terms cause a lot of confusion among developers; I'm on a mailing list for iPhone developers where they have been trying to figure out whether they can download content to an iPhone app. The answer: it's unclear as to whether content is a form of functionality, and you should ask Apple's lawyers. That is an incredibly intimidating message to app developers. It feels far too much like doing business with the operators.

--User base: Incomplete. It's relatively straightforward to make money from iPhone apps today because the number of developers is still relatively low. But over time, I think it's unlikely that Apple will be able to grow its user base at the same rate as the developer base is growing. If that happens, life will get much less pleasant for iPhone developers.

The ideal mobile app ecosystem would have the API power of the iPhone and the discovery experience of the iPhone store, coupled with business terms that allow add-on APIs like Flash, Java and Google Gears, all working across a much larger base of devices.


What it all means

If you're a software developer and some platform vendor or web company comes around evangelizing their software store or their APIs, you should evaluate the overall ecosystem they're providing, not just the store or APIs alone. If they haven't thought through issues like billing and discovery, it's a big warning sign.

If you work for a platform or web app company that wants to create a developer community, you need to plan the whole ecosystem and make sure it'll all work. This is especially important for a mobile company that wants to compete with the iPhone store. The way to fight iPhone for developers is to create a superior ecosystem. Apple's weak point is the business and technical restrictions on its developers, and the limited reach of the iPhone APIs. If another vendor -- say, Nokia or Google or Microsoft -- can pair a great store and powerful development with more openness and broader reach, they might be able to give Apple some serious competition. Elia Freedman had some good suggestions on ways to start (link).

____________

PS: Thanks to MobHappy for including my post on smartphone share in the Carnival of the Mobilists (link).

Adobe frees mobile flash: It's about time

Today Adobe announced a series of changes to its emerging web applications platform. The changes include:

--The next version of the mobile Flash runtime will be free of license fees. Adobe also confirmed that the mobile version of the Air runtime will be free.

--Adobe changed its licensing terms and released additional technical information that will make it easier for companies to create their own Flash-compatible products.

--The company announced a new consortium called Open Screen supporting the more open versions of Flash and Air. Members of the new group include the five leading handset companies, three mobile operators (including NTT DoCoMo and Verizon), technology vendors (including Intel, Cisco, and Qualcomm), and content companies (BBC, MTV, and NBC Universal). Google, Apple, and Microsoft are not members. It's not clear to me what the consortium members have actually agreed to do. My guess is it's mostly a political group.

Adobe said that the idea behind the announcements is to create a single consistent platform that lets developers create an application or piece of content once and run it across various types of devices and operating systems. That idea is very appealing to developers and content companies today. It was equally appealing two years ago, when then-CEO of Adobe Bruce Chizen made the exact same promise (link):

If we execute appropriately we will be the engagement platform, or the layer, on top of anything that has an LCD display, any computing device -- everything from a refrigerator to an automobile to a video game to a computer to a mobile phone.

If Adobe had made the Open Screen announcement two years ago, I think it could have caught Microsoft completely flat-footed, and Adobe might have been in a very powerful position by now. But by waiting two years, Adobe gave Microsoft advance warning and plenty of runway room to react -- so much so that ArsTechnica today called Adobe's announcement a reaction to Microsoft Silverlight (link).

Also, the most important changes appear to apply to the next version of mobile Flash and the upcoming mobile version of Air -- meaning this was in part a vaporware announcement. Even when the new runtime software ships, it will take a long time to get it integrated into mobile phones. So once again, Microsoft has a long runway to maneuver on.

Still, the changes Adobe made are very useful. There's no way Flash could have become ubiquitous in the mobile world while Adobe was still charging fees for it. The changes to the Flash license terms remove one of the biggest objections I've seen to Flash from open source advocates (link). The Flash community seems excited (link, link). And the list of supporters is impressive. Looking through the obligatory quotes attached to the Adobe release, two things stand out:

--Adobe got direct mentions of Air from ARM, Intel, SonyEricsson, Verizon, and Nokia (although Nokia promised only to explore Air, while it's on the record promising to bundle Silverlight mobile).

--The inclusion of NBC Universal in the announcement will have Adobe people chuckling because Microsoft signed up NBC to stream the Olympics online using Silverlight. So NBC is warning Microsoft not to take it for granted, and Adobe gets to stick its tongue out.


What does it all mean?

Nothing much in the short term. As I mentioned earlier, this is mostly a vaporware announcement (other than the license changes). Some people are speculating that this will put pressure on Apple to make Flash available on the iPhone (link). That's possible, if Apple's real concern was that they didn't like Flash Lite. Now they can port full Flash, or someone else can do it. But if Apple is in reality unwilling to let anyone else's platform run on the iPhone then we'll see other objections to Flash emerge.

The marketing competition to control the future of web apps is continuing to heat up. Microsoft is trying to take the whole thing proprietary by creating a comprehensive architecture, Adobe is trying to drive its own platform, Sun is trying to re-energize Java, Google is making its own moves, and so on (link). Plus, of course, most web app developers today are happy with what they're using now and have little interest in switching to any of the new architectures (check out the dandy commentary by Joel Spolsky here).

It's an enormously complex situation, and it's going to take months, if not years, before we can start to see who's winning and who is losing. Rubicon is working on a white paper that will try to clarify the situation a bit. I'll let you know when it's published.

In the meantime, enjoy the marketing fireworks. The intense competition is forcing companies to innovate faster and open up their products, as Adobe did today. I think that process is good for just about everyone in the industry.

The iPhone SDK: Apple gets it right

I have time tonight for only a quick note on Apple's iPhone software developer kit announcement. Overall, it is deeply impressive how many things Apple got right. We still need to see more details on terms and conditions, and a lot will depend on Apple's execution, but here are the problems they appear to have solved:

--Mobile applications are hard for users to find and install, so Apple is building the applications store into every device. Apps are installed automatically when you buy them, and you can also be notified of upgrades when they're available.

--Third party applications stores take far too much of a developer's revenue -- 60% or more. So the Apple store takes 30%. That's a bit high (20% would be better), but everyone else has been so greedy that Apple looks like a charity.

--Getting applications certified for use on mobiles is expensive and time-consuming, so Apple has streamlined the process dramatically. Developers pay $99 a year, and apparently get automatic certification of all their apps. We need to learn more about how the app approval process will work, but if it's not burdensome this service alone justifies Apple's 30% cut of revenue. Apple takes responsibility for ensuring that iPhones remain secure and do not abuse the network, something that no one else has been willing to do.

--Developers want to get access to the features of the phone, so Apple has exposed a very rich API set including access to the accelerometer and other special features of the iPhone. This is not a sandbox; it looks like it's access to pretty much the whole OS.

--And oh by the way, Kleiner Perkins is creating a $100 venture million fund for iPhone developers. Makes Google's $10m contest for Android developers look like a popgun.

It has been obvious for at least six years that all of these changes were needed in the mobile market, but until now no one in the US and Europe has had the courage / political muscle / intelligence to carry them all out. The other mobile platforms now look pretty pathetic by comparison -- not so much because their technologies are bad, but because their business infrastructure is so primitive.

At the announcement today, John Doerr called this Apple's third platform, which has a very specific meaning in Silicon Valley. It means they're planning to drive rapid growth in apps, which will make the iPhone more attractive to customers, which will in turn attract more developers, bringing in even more users, and so on in a virtuous circle.

I don't know how far Apple can drive that, just because their sales are so small compared to the total number of phones out there. I still think it's likely that web apps will eventually displace most native mobile apps, because the addressable market will be so much larger. But eventually can take a long time, and if anyone can buck the trend it'll be Apple. They have created by far the best overall proposition for mobile developers on any platform in the US or Europe, and I hope they'll do very well for a long time.

Apple is challenging the rest of the mobile industry to compete on its terms. It will be very interesting to see how the other mobile vendors react, Nokia and Microsoft in particular. Nokia seems to be focused on a strategic positioning activity around seeing who can collect the most runtimes, while Apple is solving real developer and user problems. It's a striking contrast.

The rest of the industry is still trying to figure out how to respond to the system design of the iPhone, and now they need to also figure out how to run an ecosystem as well. Right now Apple is changing the terms of the competition faster than the other guys can react, which is exactly the right way to beat a group of larger competitors.

Nokia and Microsoft, sittin' in a tree...

There's so much hype in the mobile industry that I'm always reluctant to use a word like "shocking," but nothing else fits Nokia's announcement today that it will support Microsoft Silverlight.

If you missed the press release (link), Nokia said that it's going to make Microsoft Silverlight available for all of its mobile platforms -- Series 40 (the low-end phone OS), S60 (the high-end OS), and its Maemo Internet tablet. (It's not clear if Silverlight will be bundled or just offered as a download.) Silverlight is a web app graphics and interface layer, intended to displace Adobe Flash.

The announcement was shocking for several reasons:

--Up until now, Nokia and Adobe had worked together closely. Nokia is one of the few companies paying to bundle Flash on its phones, and Nokia had featured Adobe prominently at some of its developer events in Silicon Valley. So the announcement I was expecting was that Nokia would bundle Air, the next evolution of Flash, rather than its competitor.

--Nokia has generally treated Microsoft as the spawn of the devil. The whole Symbian OS consortium was designed primarily as a way to prevent Microsoft from getting a controlling role in mobile software. Now Nokia gives Microsoft's software layer a huge boost?

--Although Microsoft had hinted vaguely about taking Silverlight mobile, it had given no definite plans at all. So this is a huge step forward for Silverlight.

--Just a few weeks ago, Nokia bought TrollTech and announced that its software was going to unify development across Series 40 and S60. Now Nokia endorses Silverlight, which will also run across Series 40 and S60. Which one are developers supposed to focus on?


What in the world is going on?

I don't know. Nobody from Nokia has explained it to me, so I have to read between the lines. Nokia says in the press release: "Nokia aims to support market leading and content rich internet application environments and to embrace and encourage open innovation. By working with Microsoft, we are creating terrific opportunities and additional choices for the development community." Okay, so I guess what they're saying is that they want to support every platform and development option out there. Presumably the benefit to them is that they can claim their phones support more software than anyone else.

I doubt that's the only motivation, though. By supporting numerous platforms, Nokia reduces the possibility that any one of them can dominate the market and push around Nokia. It also lets Nokia play the sides off against one another. I'm sure the threat of embracing Air made Microsoft give Nokia a very good deal on Silverlight, and no doubt Nokia will now use its Microsoft relationship to get business concessions from Adobe (assuming that Nokia still plans to work with Adobe at all; that's not entirely clear).

Anyway, I can sort of see how this all works for Nokia strategically, although it feels like Nokia is trying too hard to be clever. I'm not as clear on the benefits of all this for mobile developers and users. As was covered in last week's post on mobile apps (link), many developers view the proliferation of platforms as a problem, not a benefit. Microsoft itself said in the Nokia press release:

"We want to make sure developers and designers don't have to constantly recreate the wheel and build different versions of applications and services for multiple operating systems, browsers and platforms."

That's a pretty danged funny quote coming from a company that now offers at least four mobile platforms (two versions of Windows Mobile, Silverlight, Tablet PC, and does .Net CF count as a fifth?), in a press release from a company that apparently wants to support every platform available. If you really think platform confusion is a problem, guys, look in a mirror.

For users, the benefit of all this deal-making is unclear. We're stumbling into a world where you'll need to know details of which platforms are loaded on a particular phone in order to know which apps it can run. I can't think of a better way to discourage use of mobile applications.

Mobile applications, RIP

Summary: The business of making native apps for mobile devices is dying, crushed by a fragmented market and restrictive business practices. The problems are so bad that the mobile web, despite its many technical drawbacks, is now a better way to deliver new functionality to mobiles. I think this will drive a rapid rise in mobile web development, largely replacing the mobile app business. This has huge implications for mobile operators, handset companies, developers, and users.


The decline of the mobile software industry

Mobile computing is different from PC computing.

For the last decade, that has been the fundamental rule of the mobile data industry. It was the central insight of Palm Computing's "Zen of Palm" philosophy. Psion came up with similar ideas, and you can hear echoes of them from every other successful mobile computing firm: Mobile computers are used differently from PCs, and therefore must be designed differently.

We all assumed this also meant mobile devices needed a whole mobile-specific software stack, including an operating system and APIs designed specifically for mobility, and native third-party applications created from the ground up for mobile usage.

That's what we all believe, but I'm starting to think we got it wrong.

Back in 1999 when I joined Palm, it seemed we had the whole mobile ecosystem nailed. The market was literally exploding, with the installed base of devices doubling every year, and an incredible range of creative and useful software popping up all over. In a 22-month period, the number of registered Palm developers increased from 3,000 to over 130,000. The PalmSource conference was swamped, with people spilling out into the halls, and David Pogue took center stage at the close of the conference to tell us how brilliant we all were.

It felt like we were at the leading edge of a revolution, but in hindsight it was more like the high water mark of a flash flood. In the years that followed, the energy and momentum gradually drained out of the mobile applications market.

The problem wasn't just limited to Palm; the level of developer activity and creativity that we saw in the glory days of Palm OS hasn't reappeared on any mobile platform since. In fact, as the market shifted from handhelds to smartphones, the situation for mobile app developers has become substantially worse.

That came home to me very forcefully a few days ago, when I got a call from Elia Freedman. Elia is CEO of Infinity Softworks, which makes vertical market software for mobile devices (tasks like real estate valuation and financial services). He was one of the leaders of the Palm software market, with a ten year history in mobile applications.

I eventually moved on from Palm, and Elia branched out into other platforms such as Blackberry. But we've kept in touch, and so he called recently to tell me that he had given up on his mobile applications business.

Elia gave me a long explanation of why. I can't reproduce it word for word (I couldn't write that fast), but I've summarized it with his permission here:

Two problems have caused a decline the mobile apps business over the last few years. First, the business has become tougher technologically. Second, marketing and sales have also become harder.

From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several -- two versions of Windows Mobile, Tablet PC, and so on. [Elia didn't mention it, but the fragmentation of Java makes this situation even worse.]

I call it three million platforms with a hundred users each (link).

The second technical issue is certification. The walls are being formed around devices in ways they never were before. Now I have to certify with both the OS and with each carrier, and it costs me thousands of dollars. So my costs are through the roof. On top of that, the adoption rate of mobile applications has gone down. So I have to pay more to sell less.

Then there's marketing. Here too there are two issues. The first is vertical marketing. Few mobile devices align with verticals, which makes it hard for a vertical application developer like us to partner with any particular device. For example, Palm even at its height had no more than 20% of real estate agents. To cover our development costs on 20% of target customer base, I had to charge more than the customers could pay. So I was forced to make my application work on more platforms, which pushed me back into the million platforms problem.

The other marketing problem is the disappearance of horizontal distribution. You used to have some resellers and free software sites on the web that promoted mobile shareware and commercial products at low or no charge. You could also work through the hardware vendors to get to customers. We were masters of this; at one point we were bundled on 85% of mobile computing devices. We had retail distribution too.

None of those avenues are available any more. Retail has gone away. The online resellers have gone from taking 20% of our revenue to taking 50-70%. The other day I went looking for the freeware sites where we used to promote, and they have disappeared. Hardware bundling has ended because carriers took that over and made it impossible for us to get on the device. Palm used to have a bonus CD and a flyer that they put in the box, where we could get promoted. The carriers shut down both of those. They do not care about vertical apps. It feels like they don't want any apps at all.

You can read more of Elia's commentary on his weblog (link).

Add it all up, and Elia can't make money in mobile applications any more. As he told me, "Mike, it's time for you to write the obituary for mobile apps." More on that later.

Although it's a very sad situation, if Elia's experience were an isolated story I'd probably just chalk it up to bad luck on the part of a single developer. But it mirrors what I've been hearing from a lot of mobile app developers on a lot of different operating systems for some time now. The combination of splintering platforms, shrinking distribution channels, and rising costs is making it harder and harder for a mobile application developer to succeed. Rather than getting better, the situation is getting worse.

I've always had faith that eventually we would solve these problems. We'd get the right OS vendor paired with a handset maker who understood the situation and an operator who was willing to give up some control, and a mobile platform would take off again. Maybe not Palm OS, but on somebody's platform we'd get it all right.

I don't believe that any more. I think it's too late.


The mistake we made

We told ourselves that the fundamental rule of our business was: Mobile is different. But we lost sight of an even more fundamental law that applies to any computing platform:

A platform that is technically flawed but has a good business model will always beat a platform that is elegant but has a poor business model.

Windows is the best example of inelegant tech paired with the right business model, but it has happened over and over again in the history of the tech world.

In the mobile world, what have we done? We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen.

But we never figured out how to help developers make money. In fact, we paired our elegant platforms with a developer business model so deeply broken that it would take many years, and enormous political battles throughout the industry, to fix it -- if it can ever be fixed at all.

Meanwhile, there is now an alternative platform for mobile developers. It's horribly flawed technically, not at all optimized for mobile usage, and in fact was designed for a completely different form of computing. It would be hard to create a computing architecture more inappropriate for use over a cellular data network. But it has a business model that sweeps away all of the barriers in the mobile market. Mobile developers are starting to switch to it, a trickle that is soon going to grow. And this time I think the flash flood will last.

If you haven't figured it out yet, I'm talking about the Web. I think Web applications are going to destroy most native app development for mobiles. Not because the Web is a better technology for mobile, but because it has a better business model.

Think about it: If you're creating a website, you don't have to get permission from a carrier. You don't have to get anything certified by anyone. You don't have to beg for placement on the deck, and you don't have to pay half your revenue to a reseller. In fact, the operator, handset vendor, and OS vendor probably won't even be aware that you exist. It'll just be you and the user, communicating directly.

Until recently, a couple of barriers prevented this from working. The first was the absence of flat-rate data plans. They have been around for a while in the US, but in Europe they are only now appearing. Before flat-rate, users were very fearful of exploring the mobile web because they risked ending up with a thousand-Euro mobile bill. That fear is now receding. The second barrier was the extremely bad quality of mobile browsers. Many of them still stink, but the high quality of Apple's iPhone browser, coupled with Nokia's licensing of WebKit, points to a future in which most mobile browsers will be reasonably feature-complete. The market will force this -- mobile companies how have to ship a full browser in order to keep up with Apple, and operators have to give full access to it.

There are still huge problems with web apps on mobile, of course. Mobile web apps don't work when you're out of coverage, they're slow due to network latency, and they do not make efficient use of the wireless network. But I believe it will be easier to resolve or live with these technical drawbacks in the next few years than it will be to fix the fundamental structural and business problems in the native mobile app market.

In other words, app development on the mobile web sucks less than the alternative.

Here's a chart to help explain the situation. Imagine that we're giving a numerical score to a platform, rating its attractiveness to developers. Attractiveness is defined as the technical elegance of the platform multiplied by how easy it is for developers to make money from it. The attractiveness score for native mobile app development looks like this over time:



This is why mobile app developers are in trouble. Even though the base of smartphones has been growing, and the platforms themselves have become more powerful, the market barriers have been growing even faster. So attractiveness has been dropping.

Now add in mobile web development:



Based on what I'm hearing from mobile developers, the lines just crossed. The business advantages of mobile web development outweigh its technical limitations. More importantly, if you look at where the lines are going, the advantage of mobile web is going to grow rapidly in the future.

I'm not saying all native mobile development is dead. In fact, we're about to see the release of Apple's native development tools for the iPhone, and as Chris Dunphy just pointed out to me, they are sure to result in a surge of native development for that platform. But I think even a rapidly-growing base of iPhones can't compare to the weight of the whole mobile phone market getting onto a consistent base of browsers.


What it all means

If you're a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website. That's what Elia did, and he said it's amazing how much easier it is to get things done. Even mobile game developers, who you'd think would be the last to abandon native development, are looking at web distribution (link; thanks to Mike Rowehl for pointing it out).

See if you can create a dumbed-down version of your application that will run over the mobile web. If the answer is yes, do it. If the answer is no, try to figure out what technology changes would let you move to the web, and watch for those changes to happen.

There are exceptions to any rule, and I think it makes sense to keep doing native development if your app can't work effectively over the web, and it's a vertical application so popular that you can get about $50 or more in revenue per copy. In that situation, you probably have enough resources to stay native for the time being. But even you should be monitoring the situation to see when you can switch to the web, because it will cut your expenses.

If you're a mobile customer, make sure your next smartphone has a fully functional browser that can display standard web pages. And get the best deal you can on a flat-rate data plan; you'll need it.

If you're an operator or a handset vendor, get used to life as a dumb pipe. By trying to control your customers and make sure you extract most of the revenue from mobile data, all you've done is drive developers to the Web, which is even harder to control. You could have had a middle ground in which you and mobile developers worked together to share the profits, but instead you've handed the game to the Google crowd.

Congratulations.


Oh, about that obituary...

In loving memory of the mobile applications business. Adoring child of Java, Psion, Palm OS and Windows Mobile; doting parent of Symbian, Access Linux Platform, and S60; constant companion of Handango and Motricity. Scared the crap out of Microsoft in 2000. Passed away from strangulation at the hands of the mobile industry in 2008. Awaiting resurrection as a web service in 2009. In lieu of flowers, the family asks that you make a donation to the Yahoo takeover defense fund.

Palm OS on Nokia: Strategy or tactic?

I was stunned today when I saw the press release from Access Company saying that they're giving away a beta version of the Garnet emulator for Nokia's N-series Linux tablets (link).

The Garnet emulator lets you to run most Palm OS applications. So in layman's terms, Access is giving away Palm OS for use on any N-series tablet.

I hadn't previously heard any hints from Access about offering Garnet for other platforms. I thought it was only supposed to be available with Access Linux.

I got excited by the announcement, figuring maybe Access had realized that the real innovation is going to come in the applications layer, not the core OS plumbing. I imagined all sorts of scenarios for what they might be planning:

--How about porting Garnet to some other Linux implementations. Hmm, what comes to mind? Maybe Google's Android? Access would need cooperation from Google in order for the emulator to talk directly to Linux. Would Google help with that?

--There is a need in the market for a mobile application environment that's truly "write once, run anywhere." Might Access intend to use Garnet to compete with Java? That would involve porting Garnet to operating systems other than Linux. How about Windows Mobile and Symbian? How about the iPhone?

--There are several ways Access could make money from this:

• Give away the emulator in beta but charge for the final version.
• Give away the emulator on N-series but charge for it on other platforms.
• Give away the emulator everywhere and make money by selling support software and bundling a software store and taking a cut of the purchase fees for apps (a derivative of the iMode and Acrobat models).

Intrigued by the possibilities, I talked to folks at Access. They shot down most of my speculation. As it was explained to me, this is a tactical move. By porting Garnet to the Nokia tablets they can get some testing for the emulator, and also give a "more interesting ongoing proposition for current developers." (It says something about the momentum for your OS when you feel the installed base of Nokia Linux tablets is an attractive developer target, but I guess you take what you can get.)

Access might try to put the emulator on other standard Linux implementations, but they're very busy working on software for licensees they can't talk about yet, and don't have time to port to anything else, including Android.

That's a shame. In my opinion, there's more of a market for Garnet on other platforms than there is for a Linux phone OS now that Google is giving one away.

But Access believes Google's nonstandard approach to Java and Linux is not going to go down well with the mobile development community. They said Android faces big challenges and a likely backlash.

Okay. I guess only time will tell whether that's justified self-confidence or denial of reality.

Meanwhile, I'll go play with Garnet on my Nokia tablet and wonder about what might have been.

Google's Android revealed: Component software for the mobile world

Google today released a lot more details on its Android mobile operating system, including the software development kit. It looks like it would be fun to write apps for Android. The most interesting news is that Android puts a heavy emphasis on component software, encouraging developers to create software modules that can be shared with other developers and reused across applications. It's similar in spirit to what happened with mashups in the web apps world, although the technology involved is quite different.

If the developers follow through, this could make Android a very attractive and flexible development environment.

Google is offering $10 million in prizes to the best Android applications. That's an astonishing amount of money for the mobile apps space, where developers are used to living on stale bread with an occasional beef jerky chaser. For comparison, $10 million is probably more than the total marketing program budget in my last year at PalmSource.

It must be nice to work at a company that has limitless financial resources.

The price also says something about Google's business strategy for Android: Collect a lot of compelling applications that will generate user demand for Android phones. I think they can get the apps, but whether those will generate user demand remains to be seen. Having a big apps base didn't help us as much as you'd expect at PalmSource.

The other interesting news is that this is an entirely Java-based development environment, with a lot of extensions provided by Google for things like multimedia and font management. Although Android is based on Linux, as far as I can tell it's being used strictly as plumbing; the applications can't access it directly (at least not in this version). Data exchange between apps, and application access to phone features, can be locked out by the operator or handset manufacturer.

This should make Android a pretty secure operating system, although it won't be much fun for developers who like to mess around with the low levels of an OS.

Can Android become a standalone runtime? The reliance on Java raises the possibility that the Android applications layer could be ported to other operating systems. I think this would be a pretty cool strategy for Google, as it would enable it to drive the applications experience on a lot of different phones. But it wouldn't be a lightweight layer -- Google has built a huge amount of middleware on top of Linux that would probably have to be ported as well. Unless Google designed the Android apps layer to be portable, something they haven't mentioned, I think the port would be pretty difficult.

Some other tidbits about the OS:

--Features supported in the OS include a built-in browser, 2D and 3D graphics, SQLite database, video and audio playback, GSM, Bluetooth, WiFi, 3G wireless, camera, compass, GPS, and accelerometer (if the appropriate hardware is included in the phone). That's a pretty standard feature list.

--There's also a set of optional APIs that can be excluded by an operator or handset manufacturer. They include mapping APIs and peer to peer messaging between phones. Google positioned the peer messaging as a way to let two users play checkers, but you could also use it to create an instant messaging application that bypasses SMS. I'll be interested to see if any operators allow it on their networks.

--The development environment is a plug-in to Eclipse, another standard approach. The SDK includes an emulator so you can test your apps before the hardware ships. That's essential, since Android phones are about a year away.

--Core apps included with the OS include mail, SMS, calendar, browser, contacts, and maps. The mapping app is the only unusual one.

--There is support for multitasking threads, and an application can run in the background (this should enable things like MP3 playback while you're browsing).

--Each application runs in a separate Linux process. This helps with security. Apps remain running until they're no longer needed and the system decides that it wants their memory. This feature seemed slightly weird. Windows Mobile also tends to leave code running until the space is needed, and that has resulted in performance and stability problems. Presumably Android will handle things better.

The other thing Google warns you about is that if your application doesn't use the proper calls to explain what it's doing, the OS may assume it's not important and shut it off arbitrarily. That can also happen to a properly-written application if the system runs low on memory. This is kind of spooky, and could result in lost user data, especially if the user loads up a lot of applications.

Call me old fashioned, but I prefer applications that quit only when I push the quit button.

--The security model is heavily sandboxed (meaning applications are isolated from each other). To reach outside the sandbox (to exchange data with another app, read the address book, or access the phone's features), applications have to ask permission at the time they are installed. Permissions are based on "trusted authorities and interaction with the user." In other words, an operator or handset vendor can lock them down, and if not then the user will be asked to grant permission. Users will not be asked again when the application is run; if permission was not granted at install, the app will just fail. I believe this is going to be a serious support problem -- it means the same application may work on a phone when it's on one network, but may not work on that same phone on another network. Good luck explaining that to the user.

Google may be counting on user complaints to force the operators to turn on permissions.

--The user interface needs work. Google says it's still working on the final user interface for Android, and that's a good thing. Engadget nicely posted a bunch of screen shots from the current interface today, and they have problems (link).

The first thing that bothers me is the icon carousel at the bottom of the screen.



I think it's a great design, but it's awfully reminiscent of the interface in Yahoo Go. Maybe that's just a coincidence, but Google lately has shown a disturbingly Microsoftian tendency to borrow ideas from others.

The overall interface design is relatively clean, at least compared to the overdesigned clutter that you see on a lot of smartphones. But it's optimized to look pretty on a computer screen rather than be usable on a real-world phone.

The giveaway is contrast. Most computers are used indoors, in a room with moderate lighting. By comparison, mobile phones are used in all sorts of settings, including outdoors in bright sunlight. In those conditions, subtle differences in contrast between text and background can easily be lost. For a good example, check out the screen shot below:



Looks nice on your computer, huh? But let's reduce that screen image to about what it would be on a real phone:



Already the text gets hard to read. Now take your computer outside into the direct sunlight. Go ahead, I'll wait for you to get back...

Done already? What you saw is that the words "Call Back," "Done," and so on pretty much disappeared because they're written in dark gray on a black background. You can find a lot of other examples like this in the Google screen shots.

A recommendation to everyone who creates phone interfaces: White on black. Black on white. Large fonts. It may not be the most beautiful design, but at least people will be able to use it.


What it means to the industry. I continue to think that the ultimate success of Android will depend on the creativity of the devices built on it, and we can't judge that until those devices ship. But in the meantime, I'll be very interested to see what sort of applications appear. Google can definitely excite developers, especially when it shovels money at them. This is an immediate challenge to Microsoft and especially Symbian, which has struggled to get developers to work with its very complex native APIs. The more that Android sucks up developer activity, the harder it will be for other platforms to get developer support. Android is a much cleaner design than older platforms like Symbian, and the component development model might drive the rapid creation of a lot of interesting applications.

Will Android be limited to the mobile space? That's the other key question. There's nothing in the Android development model that limits it to mobile phones, and in fact Google says openly that it's appropriate for use on all sorts of devices. Let's wait a few years for the Android applications base to mature. If it does well, we might eventually see Android devices that seek to directly challenge PCs.

=====

PS: Thanks to Ubiquitous Thoughts for featuring last week's post on the Android announcement in the latest Carnival of the Mobilists.

Impact of Amazon Flexible Payments Service: Computing as a utility

The announcement of Amazon FPS made my whole week, on a lot of different levels. I'm excited about the service itself, I'm excited about what it means for the development of web applications, and I'm excited about what it'll eventually do for the mobile data world.

Okay, I'm just excited.

About FPS. Before I talk about what it means, I should give a quick overview of what it is. FPS is a web service, meaning it's a set of online APIs that the creator of a website or web application can use to perform tasks. What FPS does for you is billing -- you can use it to accept payments for something you sell online. Basically, you transmit the customer's info to Amazon, and they take care of the credit check, credit card processing, billing, and so on. They send you the money, less a percentage cut that they take.

That's not at all revolutionary. PayPal and Google Checkout offer the same thing already. Amazon's cut is about the same as PayPal -- about 2% to 3% of your revenue, depending on the amount of business you do, plus 30 cents per transaction. Google is a tad cheaper, plus you get AdSense credits for using it.

(For more information on FPS, there are good articles here and here).

What impressed me about FPS is its flexibility. Amazon says you can set different payment terms for every customer, set up subscriptions and multiple payment schedules, manage a store in which you pass payments from a customer to your suppliers, set up either pre- or post-payment systems, and most importantly you can manage micropayments down to a couple of pennies per transactions (link).

The competing systems either don't offer this at all, or do it badly. I think FPS is a really important change to the competitive situation in payment services. And, because the payment services are all available to any website, that means it's an important change to the whole web platform.

New forms of online business. So far, e-commerce online has been limited mostly to selling things that we could already get through regular stores -- books, clothing, software, etc. One of the main culprits for this was payments. The current credit card system, with its strong discouragement of small transactions, makes it very hard to sell anything priced below a few dollars online. I think the most interesting use of online commerce will be the creation of markets for things that we can't buy through stores today. Most of those things are intellectual property of various sorts, and the natural market for them is a buck or less a copy. So the payment system is a big barrier.

I won't recap my whole argument for minipayments; I wrote about it recently, and you can read it here. Minipayments have already changed the world in music, where Apple's proprietary minipayment system in iTunes has revived the market for music singles, something that was virtually dead in stores. Another example: iStockPhoto has created a market for low-cost stock photography. By creating an easy system of practical minipayments, Amazon FPS will help to enable the creation of lots of iTunes and iStockPhoto equivalents for other products and forms of intellectual property. Think short stories, art, games, and probably a lot of other things we haven't even thought of yet.

I know FPS isn't perfect -- for example, small payments have to be aggregated and then billed in a single larger transaction. But it advances the state of the art dramatically, and more importantly it challenges Google and PayPal to improve their own minipayment handling. That competitive dynamic should eventually result in a truly great minipayment mechanism online, no matter who makes it.

Amazon vs. Google: A contrast in strategies. I think Amazon's approach to web services makes Google look bad. Both companies are taking on PayPal, but Google's approach so far has been pure blunt force -- duplicate PayPal's features, underprice them a bit, and tie it to another Google product (you get AdSense credits for using Google Checkout). Let's see...you compete by duplicating someone else's features, underpricing, and tying back to your dominant product. Does that remind you of a certain company in Redmond?

In contrast, Amazon has been trying to find holes in the infrastructure that nobody has filled yet. Its storage and compute services provided very important infrastructure that helped accelerate the growth of Web 2.0 companies. Although its payment system is not as unique, the emphasis on minipayments is, and I think it too will play an important part in the online ecosystem.

Bottom line: Google is often copying, Amazon innovating. I'd say that I'm disappointed in Google, but actually given their size they would crush everyone else if they were also innovative. So maybe we should be grateful.

What will Amazon do next? Their pattern is clear -- they're picking out things that they know how to do well (because of their retail operation) and turning them into services for other developers. A logical next step would be if they offered developers the infrastructure needed to set up an online store -- order tracking, support request tracking, inventory, displaying merchandise, etc. That would work with their other services, and would put them in a position to start draining business from eBay.

I'd also love to see them offer some sort of unified product and content discovery system. One of the things missing from the online ecosystem is an easy way to find goods and services that are for sale online, and comparison shop between them. You can use search for it, but it's not very well organized, and comparisons are difficult. eBay kind of does that, but you have to be registered as one of their sellers, and eBay does the billing. I'd love to see a looser directory than eBay that doesn't take the payments directly, but just points you to things you can buy.

That's what I thought Google Base would evolve into, but Google hasn't made the move yet, so there's still time for Amazon to seize that territory.

What it means for mobile. You can probably guess what I'm going to say here. The operators consistently charge up to about 50% of revenue for any songs, games, or other content sold through their networks. The mobile software stores like Motricity and Handango charge about the same. Amazon, Google, and PayPal each take about 2-3% of revenue, and that cost is likely to decline due to competition. As the wireless Internet takes hold, how many users will be willing to pay 50% extra just for the pleasure of having a game appear on their Sprint or Verizon bill rather than their Amazon bill?

If an operator bit the bullet now and priced competitively, they might be able to hold onto about 10% of revenue in exchange for the greater convenience of running content purchases through the mobile bill. But a 50% cut is like waving a red flag in front of a bull. There's no way Amazon and friends will be able to resist the temptation to target the mobile web. The question is not if, it's when.

The name of the game is infrastructure. In an open, decentralized computing environment like the Web, the best way for a software company to succeed is to create a control point -- to offer a piece of critical infrastructure that others need, and build a franchise around it.

Google understood that concept with search + advertising, and did well with maps, but has been remarkably inept at creating other strong points. I think that's because, to be blunt, engineering PhDs don't necessarily make the best business strategists. Google, if you want to go to the next level, ya got to hire business people who are as smart as your technical people. And you have to give them some authority.

Microsoft seems to get it, but is still trying to retrofit its applications into services rather than really thinking through what's needed in an online ecosystem. Apple seems to understand, but so far hasn't been interested in opening up its services to others (it could easily have turned iTunes into a content discovery and billing service, long before either Google or Amazon hit the market). Some other big Internet companies, like Yahoo, don't seem to really understand yet that this is the competitive battleground of their future.

Amazon is the one major web company that seems to both understand the situation, and be able to consistently come up with good new services. They already have two strong points (computing services and storage), and payments looks to be the third. If some of the other players don't wake up soon, Amazon's going to end up in an extremely powerful position online.

What we're learning from Web apps, part 3: Breeding new types of media

The argument over the viability of Web 2.0 applications misses the point -- most of the applications on any new computing platform die. What matters are the innovations and new business models that we learn from them (link).

Last time in this series I discussed what we're learning from Web 2 about managing a community online (link). This time I want to talk about the role the Internet is playing in the creation of new forms of media.


Is the internet a new medium?

I should start with a definition of what a medium is. Webster calls it, "a channel or system of communication, information, or entertainment" (link). I want to build on that a little. To me, a medium is something that moves information and/or entertainment between people. Movies are a medium, newspapers are a medium, oil painting is a medium. So is the telephone call, when you think about it. Each medium has its own distinct usages, economic model, and audience.

A lot of people have written about the Internet and/or the Web as a new "medium." A quick online search will give you thousands of articles and weblog posts on the subject. But there's something funny about the articles -- although they all call the Internet a medium, they define that medium in many different ways. For example...

--The Internet is a medium for mixed-media communication.
--It's a medium for online music broadcasting.
--It's a medium for making politically-motivated attacks. (And an unregulated medium at that. Heaven forbid we should practice unregulated politics.)
--It's "a perfect medium for the sale of software and other digital products."
--It's a medium for interactive, moving content.
--It's a "new medium for business communication."
--It's "a medium of news dissemination."
--It's "a new medium for design."
--It's a new medium for video.
--It's a new medium for communication by individuals.
--It's a new medium for socializing.

I think that in reality the Internet is not a new medium for anything. It's a transport mechanism. It is to data what a road is to eighteen-wheel trucks. And the Web isn't a medium either; it's a set of protocols for accessing and delivering data. To abuse the road analogy, it's the warehouses and truck stops that load, unload, and service the trucks.


The Internet is a meta-medium

When we talk about the Internet as a medium, we're confusing the delivery mechanism with the goods being delivered. This is a crucial distinction, because if you think of the Internet as a medium you won't understand its real power. The Internet is a meta-medium. It's a medium for creating new types of media; a general-purpose mechanism that spews new media as quickly as people can think them up.

And spew it does. As I hope you know if you've been reading this weblog for a while, I am not a fan of hype and overblown predictions. But I think the evidence shows that the Internet is enabling an explosion of new forms of media at a faster rate than ever before in human history. I believe this is one of the most revolutionary effects of the Internet, but we're so close to it that we don't think about it much.


Freeing media from the distribution mechanism

In the past, each new form of media was generally tied to a unique distribution infrastructure, technology base, and economic model. For a new medium to arise, you generally had to create a whole new production and distribution mechanism for it. For example:

Novels required the development of the printing press, a distribution infrastructure consisting of publishers and bookstores, and an economic model in which the reader pays and revenue is shared with the publisher and distribution chain.

Radio serial drama required the invention and sale of millions of radios, the construction of studios and transmitters, the creation of production companies and networks, and an economic model in which advertisers paid for the programs.

Movies required not just the creation of motion picture cameras, but also studios to produce the films, modified theaters to show them, a distribution system to deliver the reels of film, and an economic model in which ticket revenue and in-theater food sales combined to pay for the whole thing.

The huge effort and investment involved in creating these distribution chains severely limited the growth of new forms of media. For example, it took about 20 years from the invention of television and movies until either of them reached broad commercial distribution.

In contrast, new media proliferate on the Internet as fast as people can visit new websites and install plug-ins. (Obviously, this applies only to media that can be distributed electronically. But that still covers a lot.)

This chart gives you an idea of how the pace of change has accelerated.


This chart was based in part on a fantastic media history here.

Some people would say that most of the Internet media types I listed on the right edge of the chart aren't actually new media; that they're just a tweak on existing media. For example, Henry Jenkins argued in a great article for MIT Technology Review that you have to differentiate between media, genres, and delivery technologies (link):

Recorded sound is a medium. Radio drama is a genre. CDs, MP3 files and eight-track cassettes are delivery technologies. Genres and delivery technologies come and go, but media persist as layers within an ever more complicated information and entertainment system.

I think he's right from the perspective of classifying things analytically, but if you follow that thinking religiously then it's almost impossible to create a new medium any more, unless smell-o-vision or machine telepathy comes along. I think in practical terms, you have a new medium as soon as you create a substantially different set of audience and business dynamics, because those are the changes that create meaningful new economic opportunities for creative people and businesses.

Here's the test: if you can't take material created for some other medium and replay it unchanged, then I think you've invented a new medium. CDs were not a new medium because they were created and sold in the same way, to the same people, as vinyl LPs. But radio drama was a new medium, because it had its own distinct audience and rules. You couldn't just take a stage play and turn it into a radio drama unmodified.

By this standard, the Internet is spawning new media forms faster than bunnies breed in Australia.

Of course, not all of these new types of media will be successful long-term. But it's exciting to see so much experimentation happening so quickly, and I believe it will have a profound effect on the ways we communicate and entertain ourselves in the years to come.


The revolution in front of you

Okay, so that's the theoretical foundation on what's happening. Let's discuss some examples -- three new forms of media we're creating, the rules and opportunities they create, and what comes next.


Online video

Oh, man. This one's so complex that you could write a book on it. The term "video" includes a huge variety of different things -- music videos, TV shows, animation, movies, video clips from amateurs, even commercials. Each one appears to have a different online audience and different financials.

Some of them have already run through a cycle of excitement and disappointment. For example, some people speak of an "internet animation era" that came and went at the start of the decade (you can read more about the expectations here). Usually the culprit for the disappointment is the failure to find a sustainable business model.

The hottest area in online video today is obviously short clips like the ones you see on YouTube. The ironic thing is that this form of video had virtually no traction prior to the Internet. Meanwhile, movies and TV shows -- which everyone predicted would move onto the Internet quickly -- don't have nearly as much momentum online.

Why YouTube is successful. Using YouTube is like eating potato chips ("crisps" if you live in the UK). When you're bored, it's great to browse short video clips looking for things that are funny or amazing or just plain weird. The brilliant aspects of YouTube (in my opinion) are that the video loads fast (can you imagine eating potato chips if you had to unwrap every chip individually?), and that the YouTube site links you to lots of other related videos, so it's easy to wander. If one video is boring, you're only moments away from something else.

This instant gratification factor turns the rules of traditional video on its head. In traditional video, quality and an immersive experience are king. To suck people into a television program or a movie, you use incredibly high quality images, editing, and sound. (If you want to know how important this is, look at all the enormous amounts of money the industry is spending to move to high-definition broadcasting and higher-capacity DVDs.)

That's why short online video is a different medium. Rather than immersion, the goal is instant gratification.

But how do you make money? The problem with short online video is that no one's sure how to make money from it. You pay to see a movie. You watch ads on television (well, you're supposed to, unless you use TiVo). Many companies are trying to attach commercials to online videos, but the result is often extraordinarily annoying to viewers.

That's not intuitive to the broadcast folks. Depending on what country you're in, to watch free TV you'll typically watch nine to 20 minutes of commercials in order to see an hour of programming (link). That's a ratio of between 15% and 30% commercials.

Apply that same ratio to a short online video, and you're watching a 30 second commercial to see a two minute video clip. Sounds reasonable, right? It's actually borderline intolerable to viewers because it breaks the instant gratification cycle. The whole idea is to beat boredom, not generate it.

Remember, this is a new medium. It has its own rules.

Maybe the answer will be very short ads, but no one knows what's short enough, and if those short ads will even work. Or maybe the answer is putting print ads on the website alongside the video. But unlike search, you don't know what topics a video viewer will be interested in, so it's much harder to target the ads. How will you individually track the demographics of people viewing more than six million separate YouTube clips? You'd basically have to build a database on the individual thoughts and behavior of every Internet user. That, I presume, is why YouTube was a good strategic investment for Google. It's also why I'm deeply skeptical about the high-profile efforts by entertainment companies to create sites competing with YouTube. Without Google's demographic and ad-targeting infrastructure, it will be hard for a competitor to monetize its videos.

And oh by the way, it's not clear that even Google can make this whole video thing work financially.

So let's classify short online video as an emerging medium: Proven audience, unproven economics.

Video in the mobile world. This is the current Flavor of the Month in the mobile data world. (Or maybe it was last month's flavor, and this month is GPS.) Anyway, there are a lot of people predicting that video is going to be very hot in the mobile space.

As was the case with PCs, you have to ask what sort of video you're talking about. The most intuitive use is short video. We know people use mobiles as boredom-busters, and short video is almost custom-made for that. But we run into the same economic problems as we have on PCs, only more so. It's not clear how many commercials people will tolerate in their mobile video.

Broadcast video, viewed on mobiles, is becoming popular in Asia. But by my standard that's not a new medium -- it's just building a television into your phone. And it bypasses the Internet, so it's not relevant to this discussion. (I recently wrote a long article on mobile video; if you missed it you can read it here.)


Virtual Reality as a Medium: Second Life

Most people think of Second Life as a game, or maybe a cult. But my Rubicon colleague Bruce La Fetra recently wrote an article (link) making the case that it's a new medium, and I believe he's right. Think about it. Here's the test of a new medium:

--Facilitates interaction between people. Second Life certainly does that.
--Has its own distinct audience. Double check. That's why some people look at Second Life as a cult.
--Has its own economic model. Triple check. This one even has its own currency.

A virtual meeting place. Second Life is so flexible that it's very hard to say what it'll turn into ultimately. It's already a meeting space for some people, and the upcoming addition of voice should improve that dramatically. Supposedly Cisco is providing pre-built avatars for employees, and a number of tech companies are using it for meetings (check out the slightly breathless but eye-opening article here).

Second Life is a tool for holding three-dimensional visual conversations...I know some people can't hold a serious business conversation without a pen and paper to draw with; Second Life is made for those people....One day, you'll be able to import sales data from an Oracle database, create a three-dimensional diagram of that data that changes in near-realtime, and hold a meeting of top corporate executives all over the world in Second Life to discuss the results. --Mitch Wagner

Prototyping the physical world. Another clear use for VR is allowing individuals and corporations to create interactive experiences for others. For example, as Bruce points out, hotels are starting to test lobby layouts using Second Life. Brands like GeekSquad are using Second Life to reach out to customers, giving them another way to engage (read more about it here).

Some of this commentary is so enthusiastic that it reminds me of the commentary we saw in the bubble period. Second Life is definitely a geek playground, but I'm not sure how many "normal" people will want to mess around in virtual reality. We won't know until we try.

Is it a business or a standard? The ultimate business model for Second Life is still up in the air. Land owners pay real dollars for virtual real estate and corporate avatars, giving Linden Lab a revenue stream. However, the company is in the process of open-sourcing its server code. This will make it possible for anyone to create their own "land" without paying Linden Lab, and dramatically increases the likelihood that Second Life's technology will become a generalized standard for virtual reality. That's very healthy for the medium, but leaves Linden Lab without an obvious business model. There's an interesting discussion here.

The process of moving from a captive platform to the base of an open ecosystem is incredibly tricky. I think Linden is right to do it, because otherwise an open standard for virtual reality would have eventually emerged, pushing Second Life completely out of the picture (think of what happened when AOL went up against the Internet). But now Linden will need to find some parts of that open ecosystem where it can provide valued services. I think managing the virtual currency is a good start, but I haven't been able to find any clear statement of what the company's long-term financial model will be; please post a comment if you find one.

So the status of Second Life is similar to that of online video: Definite audience, unclear financials.

Virtual reality and mobile. Virtual reality thrives on large screens and fast processors. I think it's probably safe to say that it'll be limited to PC-sized devices for a long time (at least until we get flexible screens and fuel cells powerful enough to drive high-end graphics processors in a mobile). Until that day, I wouldn't be investing heavily in creating a SecondLife client for Nokia S60.


Feeds

Actually, these are several new media that I have grouped together for convenience: Text feeds, audio feeds, and video feeds. Plus more types of feeds to come.

Different feed types have different audiences. Steve Olechowski of Feedburner gives a great speech summarizing the feed world and what's happening in it. One of the interesting tidbits he gives out is that different types of feeds tend to be dominated by different subjects. Text feeds most commonly focus on technology, while audio feeds are most often about music, social issues, and religion ("Godcasts"). So different forms of communication -- text vs. recorded speech -- attract different types of creators and audiences. I suspect that video feeds are going to be different yet again, although it's probably too early to judge today. You can hear one of Steve's speeches here.

The thing I like about feeds is that they're efficient. Rather than going to a website to read or listen, you can bring the content to you and access it on your terms. A lot of people use online feed readers like Feed Burner, but my favorite is Feed Blitz, which consolidates all your feeds into a single daily e-mail. That lets me scan about a hundred articles a day in a matter of minutes.

Text feed vs. weblogs. One problem with text feeds is that they take readers away from your weblog, meaning they won't see the ads. That creates a lot of concern for weblog authors who rely on advertising. So they do things like putting only article summaries in their feeds, or embedding ads in the feeds, neither of which are popular with feed users.

Olechowski argues that authors shouldn't worry -- that the people who read feeds are different from the people who read websites, so there's little cannibalism. He says that providing a full-text feed from your weblog actually increases visitors to the site, rather than reducing them.

He has an incentive to say that, since his business is distributing feeds. But I think he may also have a point. Let's use Mobile Opportunity as an example: About 80% of the readers coming directly here are referrals from other websites and web searches, not returning readers. I think the general pattern for readers is that they come here from a web search or other link, and if they like the content then they subscribe to the feed. That's why I put extensive introductory information and links to previous articles in the sidebar on the right side of the page. If a web search visitor is interested in the sort of things I write about, I want to make sure they can determine that quickly so they'll either bookmark the page or subscribe to the feed.

The feed readers never see the sidebar, but they don't need it because they know what I've written about before. People who read via feeds have a different set of special needs. Chances are they use a feed reader that consolidates a lot of different feeds, which they then skim quickly. That makes it very important to use self-explanatory headlines for articles, and clear sub-heads within each article so people can skim easily. Web links are a special problem -- because they're colored and underlined, they stand out from the text. But they're not usually the things you want people to skim, because they don't summarize the content. That's why I've started putting links at the ends of sentences, rather than embedding them in the flow of the sentence.

I'm not trying to make money from this site, but if I were, I'd have to think very hard about what sort of ads go on the web page vs. in the feed, and where they get placed.

The bottom line: you write a little differently for a feed than you do for a weblog, and the financial model is subtly different as well. So it's a slightly different medium.

Status of feeds: Text feeds are quite well established, and audio feeds took off rapidly once they were enabled on the iPod. The financial model (to the extent that there is one) appears to be advertising, but I haven't seen a good discussion of the economics of advertising within feeds (please post a comment if you know of one). Presumably Google's recent purchase of FeedBurner is intended to allow them to stream ads into feeds, so we'll probably see more activity there. The dynamics of other types of feeds (video, etc) are still to be determined.

Feeds and the mobile world. Feeds are a spectacular fit for the mobile world; actually a much better fit than browsing. In general browsing is something you do live, while feeds can be fetched in the background, cached on the device, and then read or listened to whenever the user wishes.

A text feed is also much easier to reformat for a small screen. In a lot of ways, it's designed to be reformatted.

If I were working on a mobile data device today, I'd push this feature very hard -- figure out who my target customers are and what feeds they'd be most likely to enjoy, cache the top ten our so automatically, and give a great discovery mechanism so people can easily find more. Feeds are a commodity in that you can get them for free, but easy navigation and discovery of feeds is potentially a very attractive area for innovation.

I know third party developers are already doing this; if I were at a mobile hardware company I'd be making it a standard feature in every device.


What comes next?

What other media are emerging? Many more new forms of media emerging than I've listed here. I'm very interested in your ideas -- what do you think are some others to watch, and what's special about them? One I'd love to investigate more is the rise of casual games -- quickie games, usually based on Flash. Games like this were very popular in the early days of personal computing, and they seem to be making a comeback on the web. You can find some nifty ones on sites like Kongregate (link; check out Fancy Pants).

The transcendent need for a billing mechanism. When I said that the Web is a tool for creating new media, I left out an important detail. It's three-quarters of the tool. We have a great delivery system, and Google is well on its way to dominating the advertising part of the financial model. What's missing is a standard mechanism for people to pay for content that's not supported by advertising. Some types of content work fine with ads, but I think some other types are better when paid for. Novels, short stories, music, and research reports all qualify. Creators and readers would both benefit from a system in which people could easily pay a few dimes or a few dollars directly to the author, but today we generally have to fumble with credit cards and awkward systems like PayPal. And credit card vendors strongly discourage small payments.

Minipayments vs. micropayments. The Web community chewed over this issue and spat it out several years ago. They believe that micropayments are dead, and the subject is closed. You can find examples here and here and here and here. Wikipedia has a nicely balanced discussion of the debate here.

This is one of those cases where the groupthink tendency of the tech industry is a liability. It reminds me of MP3 players before the iPod -- a lot of people have tried something, nobody's gotten it right yet, and therefore it must be impossible. It'll continue to be impossible up until someone does it right, at which time everyone will suddenly agree that it was inevitable.

(Quick aside: Whenever everyone in the tech industry agrees on something, bet against them. A perfect consensus is a sign that healthy questioning has ceased, and there's bound to be a blind spot.)

In this case, I think the blind spot was that people predicted the wrong role and features for micropayments. Some people made it a payment vs. advertising debate (link). It's not -- some types of media are good for advertising, some good for payment. We need both, with a creative tension between them.

Another problem is that some of the advocates of micropayments envisioned a very fine-grained payment system, in which people would pay hundredths of cents for all sorts of content, like the way natural gas or water is metered. That sounded logical, but it didn't work in practice because gas and water are predictable commodities; you don't mind metering because you know exactly what you'll get. You don't know how good a website will be until you've visited it, by which point you have already paid if you're metering. We need larger payments for content that people can preview and read reviews about before they pay. Apple has proved decisively that on the wired Internet a payment system that charges about a buck for discrete chunks of content can indeed succeed.

Call it minipayments.

We desperately need a generalized minipayment system for content on the web. Because people have to trust it, it needs to come from a major vendor, and it should be exposed to developers as a web service so it can grow rapidly. Ideally, it should be tied to a lot of existing content with an easy discovery mechanism (again, like iTunes). Yahoo would be the perfect company to provide this service. Microsoft could do it too. Unfortunately, a lot of companies are focusing a huge amount of their energy on the almost hopeless task of beating Google in search advertising, when the better opportunity is owning a different piece of the infrastructure, one that doesn't have a dominant vendor yet.

Other companies that could do it include Amazon, Apple, eBay, and even Linden Lab. Google could do it too, of course, but it appears to be more interested in stealing PayPal's customers than in building something new.

I'd put this service on the list of computing products I want desperately, right after the info pad. Somebody's going to do it eventually. When they do they'll get a great business franchise, and the explosion of new media on the Web will accelerate even further.

I can't wait.

Next time: The Web as a software development platform.