Non-Linear Growth

A glimpse around the next corner; mind the curves.

June 29, 2010 • 9:57 am 1

Soccer, Fail Whales and APIs

I played a good bit of soccer as a kid and even more in college. I mostly played defensive positions. One of the things I most appreciate about the game is that the smallest of errors can have game-changing impact. As a defensive player, an errant pass in the mid-field or a moment out of position in your defensive zone can result in a goal. To borrow a term I don’t really like, solid defensive soccer requires “constant vigilance”. As a defensive player, you have to have your radar up all the time; scanning, marking, closing gaps, nothing can get through. It is as much a mental exercise as a physical one. There is no room for downtime.

Which brings me to the real topic of this post; APIs. Twitter is perhaps the business most frequently associated with the term API. This week, when I think about Twitter, I think about soccer (the World Cup to be precise). And when I think about Twitter and soccer, I think about the fail whale. With the World Cup in full stride, I’ve seen a lot of him the past couple of weeks; you probably have too. The World Cup is wreaking havoc on Twitter’s infrastructure.

But, you know what, it’s OK! The worst thing that will happen is that your urgent tweet about what your dog ate for breakfast will not reach your several hundred loyal follows who are too busy tweeting about their own useless drivel to notice that they have missed this earth-shaking news that Fifi loves coco puffs. (See Tweeting Too Hard for lots of examples.) Twitter has lots of room for downtime, because it is not a mission critical application and there are limited consequences.

The fail whale has become a cute little visitor we cherish seeing every once in a while because it reminds us how frivolous our participation in the twitterverse has become. The risk, however, is that we develop a mental association between downtime and APIs. Lets not confuse the term API with what is behind the API; service delivery infrastructure. They are not one in the same. An API is simply an access point into an infrastructure based service. When it comes to understanding issues of downtime, reliability, etc., the service delivery infrastructure behind the API is what really matters.

Lots of APIs link to mission critical transactional infrastructure. Think payment services (IP Commerce, PayPal X); think about voice services (Ribbit, CloudVox, Twilio); think Internet advertising infrastructure, which is linked together through APIs. Unlike Twitter, the services behind these APIs are truly mission critical. One misstep and few thousand payment transactions don’t get executed, a couple of hundred thousand advertising impressions are lost. Downtime has consequences; they are economic, quantifiable and impactful. The high stakes are what make these services compelling, valuable and difficult to replicate.

In my opinion, the tech community has become way too cavalier about APIs. We can change that by understanding that when it comes to APIs, what is behind the API is what matters. So when you see that fail whale this week and start cursing that “boring, low scoring World Cup soccer thing”, remember that it is the constant vigilance required in soccer that makes soccer the World’s game. There is no downtime allowed in soccer; and we shouldn’t tolerate downtime in APIs that access mission critical services infrastructure. Then remind yourself, that Twitter does not qualify as mission critical and have a good chuckle about the absurdity of your Twitter stream.

UPDATE: Funny timing, but Twitter rate-limited its API several hours after I posted this. Mission critical services don’t get to automatically degrade the quality of service they provide by rate-limiting traffic. Lets not ever confuse Twitter with a mission-critical infrastructure service.

Filed under: APIs, Cloud, Platforms, , , , , , ,

June 12, 2010 • 1:30 pm 4

Platforms: Of Governance and Taxes

I like analogies. This week, Brad Burnham of Union Square Ventures wrote a thoughtful post based on an analogy between software powered platforms and governments. Bob Warfield of the SmoothSpan Blog did a follow-up post claiming that application developers should seek platforms that act like Switzerland; something Warfield has apparently been saying since 2007. The government-platform analogy is good, albeit imperfect. The most salient aspects of the analogy are in the area of governance.

Governance is a critical role for any platform provider. David Evans, who I consider a leading expert on platform strategies, has long said that platforms have three primary roles in their ecosystem, “building, stimulating and governing”. From Chapter 2 of Catalyst Code, a book Evans co-authored:

Catalysts create communities, and communities need governance lest they devolve into anarchy. Catalysts enact rules and impose punishments, and they promulgate standards of behavior.

Evan’s use of the term Catalyst is synonymous to platform. So how do you know if the platform you are working with is going to play fair? As with most governments, it’s all about the rule of law and taxes.

The rule of law

The platform gets to make the rules, codified in the terms of service. Evaluate them carefully and ask these questions:

  1. Are the terms of service stable over time or do they change frequently?
  2. Do they restrict your freedom to operate or do they enable your fee will?
  3. Do they bind you to monetization services offered by the platform, or do they offer you the opportunity to work with monetization schemes provided by third parties?
  4. Do they enable the platform to compete with you, or do they make clear that the platform was established to help you become successful?

Taxes and platform monetization

Governments get their revenue from the collection of taxes; and the government gets to set its own tax code. The same goes for platforms, they get to determine how they will monetize their platform. If you are building on a platform, make sure the tax code is well established, stable and predictable. If the tax code is not clear, you are at risk.

Lots of Twitter application developers wrote their applications well before Twitter knew how it would monetize its platform. Said in the context of the government analogy; the Twitter platform emerged before Twitter had a tax code. The increasing tension between Twitter and the application developer community can be traced back to ambiguity in Twitter’s monetization strategy in the early days of the platform’s emergence. As Twitter’s monetization strategy has become more clear, Twitter has been forced to evolve its platform strategy. I’ve argued that we should no longer view Twitter as a platform, but rather as a consumer application. In Twitter’s case, it is clear to me that they have decided that the best way to monetize Twitter is to own and control the consumer experience, enabling them to offer advertising capabilities. Facebook suffers from the same tension as it is both consumer application and platform. If you don’t understand how your platform will monetize itself, your business model may very well be at risk.

To summarize, make sure you understand how your platform partner will govern. The rule of law and the tax code will tell you whether or not the platform is there to help you succeed or if it may compete with you one day.

Filed under: Platforms, , , , ,

May 25, 2010 • 11:04 am 1

Twitter is No Longer a Platform

Twitter no longer deserves the label “platform”. There, I said it.

Its recent decision to lock out third-party ad networks, combined with its clear move in to the edge application space fundamentally alter what Twitter is. It is no longer a platform for application developers to productize around core stream functionality and monetize the edge of the Twitter network. No, if Twitter wanted to be a platform, it would keep its business focused on inspiring innovation on the edge of its network, managing the infrastructure and monetizing the stream.

Truth is, Twitter never was a platform. It has always been a consumer facing application. It is hard (perhaps impossible) to be both a consumer facing application and a platform. A true platform is a true complement with application developers. But a consumer facing application business is a pure competitor with application developers. Because Twitter hasn’t been able to sufficiently monetize the raw stream, it had no choice but to move up stack into the application and monetization layers of its value-chain. I don’t blame Twitter for moving in this direction; it’s totally logical and it was foreseeable.Tacky to quote myself, but in a prior blog post I said:

If you are an application developer on a consumer-facing platform, be sure the platform you build upon has a clear business model for helping you monetize the relationship you develop with the consumer. If not, be wary; what you do may eventually be consumed back into the platform. You may be left with no strategy for monetizing the user base you help to create.

So what is Twitter? Well, lets call it what it is – a consumer application – and a big, but narrow one at that. In the end, that is all it ever was.

I don’t have a dog in this hunt; I have not invested in any Twitter application developers for fear of the very outcome that has transpired – Twitter vertically integrating into apps and monetization with scale. I’m just a student of the platform strategy game. The lesson learned here should be noted by application developers on any consumer-facing “platform”. Be wary unless your platform is a pure complement.

Filed under: Platforms, Uncategorized,

January 21, 2010 • 6:29 pm 3

When Platforms Collide; Mobile and Payments

A few weeks ago, I wrote a post that covered my areas of investment interest for 2010. Three of the areas I find most interesting are the mobile ecosystem and the payments sector and the theme of “platform” business models. You can find that post here. The natural question I’ve since been asked is:

“What about mobile payments?”

My friends at PYMNTS.com asked me to join in the discussion in their Briefing Room on Mobile Payments. My answers are here. As you will see, the format of the briefing room is five questions, with the emphasis on the intersection between payments and mobile application development platforms. I tried to answer the questions as directly as possible, but in the process, a couple of things went unsaid.

So, to add to the Briefing Room post, I should say I’m a big believer in mobile payment. The phone will be your “wallet” some day, although I can’t tell when. My sense is that adoption for online and mobile web/application payment will precede mobile payment at the traditional point of sale. I’m most interested in mobile payment in economies where electronic payment is an emerging alternative like developing economies and in last cash markets where the connectivity enabled by the mobile phone provides an entry point for electronic payment services to displace cash.

Regardless of the sector, I’d argue that mobile payment has to add value to the payment process to fully take hold. It is not sufficient to simply replace an existing electronic payment transaction with a mobile originated payment. That will cost more to the merchant, because it adds layers to the value chain and fundamentally adds no value.

Show me an opportunity to invest in a payment business leveraging mobile with a clear value proposition in a market segment that is accessible in the near term and you are likely to find a very engaged and interested prospective investor.

Filed under: Mobile, Payments, Platforms

January 6, 2010 • 11:45 am 2

The most important app on your phone

The last couple of days have seen a flurry of activity in mobile. Apple announced its response to Google’s acquisition of AdMob by acquiring mobile ad network, Quattro. Google announced the much awaited Google phone, the Nexus One.  The bulk of the discussion has been around the mobile application battle between Apple and Google.  Henry Blodgett thinks Apple is poised to repeat mistakes of the past by remaining a largely closed (or at least tightly controlled platform). Bill Gurley thinks the battle between Apple and Google is largely a business model question and that there is room for both, serving different segments of the market with Apple in the high-end of the market and Google in the low-end.

The bulk of the discussion is over who will dominate in mobile apps. To which platform will developers flock? Who will have the most apps? Who will be most expert at app monetization? To me, this entire discussion is missing the point; because it ignores the most important application on your mobile phone.

The most important application on your phone is the browser!

Hasn’t the web taught us anything? The web obviates the need for many (and eventually most) applications by enabling them to be delivered from “the cloud” through the browser. When we look back in five years, I think we will see clearly that the app. phenomenon was a temporary bridge to a rich, and highly functional mobile experience dominated by the browser. 

You can replicate just about everything mobile apps can do in a browser. In some cases you can do more in the browser. And as Java, Flash and other browser display technologies continue to roll-out, the browser will only become more powerful. And as 4G networks begin to roll out the browser will have the advantage of a fatter pipe. Fatter pipes shift the economics of app development away from edge processing and toward the cloud. The mobile web also has huge advantages for application developers; no carrier approvals, no app store approvals; totally open.

Apple’s issue is not whether Google will surpass them in the mobile app battle, but rather the speed with which usage will shift from apps to the browser where Google has substantial advantages in delivery infrastructure and monetization (search and display).

Just my two cents. What do you think?

Filed under: Mobile, Platforms, , , , , , , , , ,

 Subscribe in a reader

My Twitter Feed

Follow

Get every new post delivered to your Inbox.