Complacency and Web 2.0

A number of recent events suggest a potentially significant evolution of Web 2.0 from a business perspective. Those who fail to notice these early signals may find themselves sidelined as Web 2.0 continues to unfold. 

Om Malik did a posting late last week on “Web 2.0: The End of Innocence” which nicely summarized some of these early signals:

The Web 2.0 story so far has been about taking APIs, mashups, low cost infrastructure and building applications that are then offered to customers for pretty much free, backed by an ad-supported business model. Think of this as the tie-dyed-free-love hippie phase. The Web 2.0 conference held in San Francisco in Fall 2006 was its Woodstock.

A lot of good things happened, innovation blossomed, but now we are entering a more pragmatic phase, where the large players like Google and Amazon who distributed the API elixir are taking control back.

APIs (Application Programming Interfaces, for my less techie readers) – especially open, standardized APIs – have been a key building block of Web 2.0, allowing one set of developers to leverage a growing array of functionality already available on the Web and bootstrap their way into delivering more value to Internet users. Rather than investing time on building applications or databases already available, developers have been able to focus on building truly distinctive functionality.

This has had a host of business implications.  It has dramatically reduced the investment required to establish an online service offering.  As a result, it has led to a proliferation of start-ups, all vying for audience attention (viral marketing diminishes in power as the viruses multiply) and, for those seeking to scale their offerings, investor dollars. For the large Internet players, Web 2.0 has been a great distributed innovation lab – watch and see what sprouts, then acquire the interesting players.

This has lulled many Web 2.0 entrepreneurs into a false sense of complacency.  Many, if not most, of the Web 2.0 start-ups are features masquerading as businesses. Business models? Fuhgeddaboutit! Their founders have little intention or ambition to build self-sustaining businesses – their exit strategy is to be acquired by one of the cash-rich gorillas. Business strategy: feed off the functionality of others long enough to get bought out, then start all over again. 

Well, recent actions by some of the large API providers like Google, Amazon, MySpace and Firefox suggest that there may be another, less welcome, exit – having the API rug pulled out from under you or, almost as bad, finding out that your friendly API provider has just introduced a service that competes directly with your own. Neither event is conducive to nailing that big acquisition exit deal. Apparently, the large Internet players are wearying of the high acquisition premiums for attractive Web 2.0 companies and are increasingly deciding to grow their own copy when they see an interesting venture.

Here’s the lesson that I draw from these recent events.  The only sustainable edge in Web 2.0, as in all businesses today, is to get better faster by working with others.  This isn’t a sprint where you can come out with a nifty new feature or service and then sit back until the buyer knocks on your door.  Web 2.0 is a powerful bootstrapping opportunity. It is most likely to pay off for those who take the resources available and rapidly build viable businesses with some reasonable barriers to entry – especially relative to the API providers you are bootstrapping on.

There are basically two ways to do this.  First, you can accelerate the innovation in the services you offer so that you are constantly one or two (or more) steps ahead of those tempted to copy you.  Second, you can find ways to use your service offerings to build trust-based relationships with your users, ideally with some powerful network effects that will make it very difficult for later entrants to pry these people away from your service. Ideally, these two approaches can be integrated by motivating your users to enhance your services themselves so that the more users you have the better your services become – the essence of Web 2.0.

In addition, you should explore the potential business trajectories of your API providers and try to make sure that you are not standing in their way.  At best, you want to be on the periphery of their field of play. When a supplier of anything decides to compete with its customer, it can be challenging for the customer.

For the large Internet API platform providers, there is also an important caution.  Sustaining a straddle between a platform business and an end-user business may become increasingly challenging.  If you become too greedy in terms of expanding into the end-user businesses of companies using your API platform, you may find that your platform business becomes less attractive. Before you start eating the young that are nourished by your APIs, you might want to be sure there are no other food sources to sustain you.

I suspect that sustaining the right balance in the Web 2.0 ecosystem over time will hinge on a new development – charging relatively nominal fees for API use.  This will put increasing pressure on API users to come up with viable business models and reduce the incentive for API providers to compete with their API users.

Comments

[sayen]

Perhaps the optimistic future lies with open source Web 2.0. Compare Ning (Web 2.0 and ads) with Elgg (open source with Web 2.0 variants such as eduspaces). WordPress is another hybrid model. There is hope.

[Jim Alateras]

I suspect that it is more about the data than the api. The api to the data/resource is much uniform. Protocols such as the Atom Syndication Format and the Atom Publishing Protocol are providing a standard mechanism for publishing and syndicating data, which is at the core of web 2.0 (mash-ups).

[Fabio Masetti]

Mr Haghel I really aprreciate your work since Net Gain and Net worth.
I founf interesting this Vecosys post I wrote about in my blog.

http://www.vecosys.com/2007/05/18/mapstraction-provides-a-common-mapping-api-insurance/

[Tom Smith]

What are mashups for anyway?

[Ty Graham]

My feeling is in line with John here, if the business model can benefit from charging people to use the API then why not? If an infomediary provides services to consumers that companies want to tap into, for convince of both parties the API must have some sort of transactional component to leverage the cost of maintaining the benefit of the APIs service. Only time will tell, John, but soon, everyone is going to get blipd :)

[kid mercury]

i am surprised you forsee API usage being charged for. i was thinking the ones who issue the API are primarily infrastructure players, and that they will include ads in their APIs and share revenue with reconstructors that use the API. for instance, amazon affiliates can use amazon APIs to create their own custom amazon storefront and profit from affiliate fees on sales.

[Charlie Wood]

The tension between companies that are both platform and application providers (think Microsoft and Oracle) and the ISV's that build applications on their platforms (think Lotus and Salesforce.com) isn't unique to Web 2.0. The successful platform vendors and ISV's have been able to manage that tension to the benefit of all.

Salesforce.com runs on a big Oracle database while at the same time competing with Oracle applications. Lotus Notes runs on Windows... OK, bad example. :-)

But I disagree that the solution is to charge ISV's for API access. Microsoft made its billions not by levying such taxes on its ISVs, but by cultivating a fertile ecosystem. Of course it ultimately decided to crush the most successful ISV's in that ecosystem, but one could argue that its doing so coincided with the beginning of its decline.

Salesforce.com is beginning to require a $5,000 "certification" fee from ISV's that want to build and sell applications for its platform. Google on the other hand doesn't even require registration to use its API's. Time will tell which is the more successful approach. My money is on Google.

Regards,
Charlie