Categories:
jennifer hudson,
short hair
Read more »
Dramatic Updo
Updos continue to rule this season. Here is a dramatic style that will suit any black bride.
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):
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).
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).
.jpg)
Conference time
I'll be doing the Grande Tour des Conferences in the San Francisco area next week. Let me know if you'll be in town and want to meet. My contact info is here.
On Monday, I'm speaking at Mobile Web Megatrends in Berkeley. My topics are:
Mobile data: Convergence or divergence?
The press is predicting a clash of the titans as Apple, Google, Nokia, and a host of other players all try to dominate the smartphone market. How is the battle likely to turn out? Will one company dominate the market? And where should a mobile app developer invest?
and
Apps for mobile devices - What happens next?
Apple's iPhone app store is getting a lot of publicity, and some industry players, such as TMobile USA, are rumored to be working on something similar. What's the future of mobile applications? Will the market grow explosively? What are the barriers to growth? Can a competitor beat the iPhone app store, or is everyone just going to play catch-up?
The speaker lineup is interesting, and I'm looking forward to it.
On Tuesday and Wednesday I'll be at the Tech Crunch conference in San Francisco (not speaking there, just taking notes). On Thursday it's CTIA, and then on Friday I'm an un-panelist at the Mobile Jam Session at CTIA. The folks at WIP have set up some very interesting discussion sessions.
I'll be posting some notes on what I hear, both here and at Rubicon's website.
On Monday, I'm speaking at Mobile Web Megatrends in Berkeley. My topics are:
Mobile data: Convergence or divergence?
The press is predicting a clash of the titans as Apple, Google, Nokia, and a host of other players all try to dominate the smartphone market. How is the battle likely to turn out? Will one company dominate the market? And where should a mobile app developer invest?
and
Apps for mobile devices - What happens next?
Apple's iPhone app store is getting a lot of publicity, and some industry players, such as TMobile USA, are rumored to be working on something similar. What's the future of mobile applications? Will the market grow explosively? What are the barriers to growth? Can a competitor beat the iPhone app store, or is everyone just going to play catch-up?
The speaker lineup is interesting, and I'm looking forward to it.
On Tuesday and Wednesday I'll be at the Tech Crunch conference in San Francisco (not speaking there, just taking notes). On Thursday it's CTIA, and then on Friday I'm an un-panelist at the Mobile Jam Session at CTIA. The folks at WIP have set up some very interesting discussion sessions.
I'll be posting some notes on what I hear, both here and at Rubicon's website.
