API

Apple’s naked self interest

by alec on April 12, 2010

Any vendor in the platform business knows that their primary product is programming interfaces – the so-called APIs that developers depend upon in order to deliver applications. The API exposes features of the platform, and differentiate applications running on that platform from all others. Lose control of the API, and you will lose control of the developer. Developers are the leading indicator for platform success. Ergo, lose the developer, lose the platform.

Steve Jobs’ protestations about quality aside, Apple’s recent moves to bar developers from using any but Apple approved technologies to write iPhone applications is naked self interest… nothing new. For example:

In 1992, Borland was kicking Microsoft’s rear with Turbo C++ and a development framework called Object Windows Library (OWL) which abstracted the underlying Windowing system out of existance, allowing developers to write applications that run on several OS platforms, including IBM’s competing OS/2. In Canada, Microsoft’s developer market share was below 30% in 1992. They were about to lose the entire Windows franchise to Borland – a company that made programming languages. Microsoft responded by releasing C7 with the Microsoft Foundation Classes (MFC), Visual Basic, and a number of other tools that eventually became Visual Studio. Within less than two years, market share amongst developers had climbed back over 70%.
In 1993, IBM made their famous statement that OS/2 was a better Windows than Windows. They allowed Windows applications to be run inside a virtual machine on OS/2, giving them instant access to the thousands of Windows applications on the market. Having done that, however, developers chose to write applications for Windows instead, knowing that they would run well on OS/2. IBM never made significant inroads into the developer community, and OS/2 never gained traction.
In the telecom industry, Nortel (and many others) routinely asked developers to sign NDAs before allowing access to the APIs for their products. The NDA was a legal mechanism by which vendors could prevent their APIs from falling into the hands of competitors, and thus hinder the development of compatible knock off technologies.

Controlling APIs by tying them to the use of specific development tools is simply a bare-knuckled way of retaining control of the platform, which is critical to the health of the iPod/iPhone/iPad franchise. It’s not about screwing Adobe or developers who use Flash. It’s about not allowing Adobe and other cross platform vendors to screw Apple.

As Microsoft learned from their experience with Borland, Jobs and co need to be mindful that developers will naturally migrate to tools which offer advantages such as productivity improvements, cost savings, or user experience benefits. Prohibitions, unfortunately, will only work for Apple for a short time. Ultimately, they must choose to compete for the hearts and minds of developers. I expect that they already know that, however, and are planning one or both of:

a licensing program to allow third parties to build development tools that use the iPhone API natively.
a suite of modern development tools and languages that give productivity benefits in line with what developers are used to in the web development world. MacOS already comes with Ruby built in. Why shouldn’t iPhone OS also support Ruby or something similar?

Either would also be in their rational self interest.

{ 0 comments }

Snapvine API releases today

by alec on April 15, 2008

I had an opportunity last week to chat with Joe Heitzeberg and Lori Roth of Snapvine about the Snapvine API, which launched today. The Snapvine API, now freely available at www.snapvine.com/api, uses lightweight JavaScript that can be implemented in a minimal amount of time and gives website owners immediate benefits:

Increased engagement by allowing users to add their voice to any photo or text element, through the mic on their computer or by dialing a telephone number from one of 15 supported countries.
Viral distribution of content with a ‘share’ button for users to easily post photos and voice content to MySpace, Facebook, or other web sites.
Increased site traffic and enhanced SEO (search engine optimization) via a branded link on all shared content that takes users back to the originating website.
Quick and easy client-side integration with media hosting and bandwidth provided by Snapvine.

And with the announcement of their API, Snapvine also announced a mittful of partners. After all, an API with no developers isn’t worth much.

Now I have to say that Snapvine’s product offering — the ability to be able to create recordings and add them to different web components — doesn’t do the company’s vision justice. Today, however, with the release of the API, we get an inkling of that vision. And here, in CEO Joe Heitzeberg’s own words, is more elaboration.

Joe Heitzeberg [ 1:57 ] Play Now | Play in Popup | Download

They’re a bunch of internet guys, who think that voice has a place in every application, and that the way to voice enable a social network is through the voice interface we already all have — the phone. Hallelujah!

{ 0 comments }

De Facto or De Jure… does it matter?

September 2, 2007

Ivor Tossell's August 31 piece in the Globe and Mail summarizes the open social networks vs Facebook debate. Titled Why I Believe Facebook's Days Are Numbered, Tossell sees Facebook's closed network, and the mostly uninteresting applications developed for the Facebook API so far as signs that that the Facebook fad will come to an end. He [...]

Read the full article →