Yihong Ding [04.27.07 11:53 AM]

Excellent post. Thank you for digging the secrets of "FREE" to the public.

  ian [04.27.07 12:12 PM]

true dat!
often overlooked/not thought of, but very on point.

  John Orford [04.27.07 12:16 PM]

Seems like you can apply precisely the same logic to MS and Apple OS APIs.

Wonder when people are going to offer data and services under truly free licenses?

  gnat [04.27.07 01:05 PM]

Hi, John. Yes, exactly--Microsoft and Apple have found themselves in competition with their platform ecosystem in the past as well. My point is that the dynamic of APIs isn't new, it's something we're intimately familiar with from desktop systems.

  Michael R. Bernstein [04.27.07 01:59 PM]

Hmm. I'm not sure that #4 is entirely true... it would seem to only apply to value-added APIs, as opposed to commodity infrastructural ones.

All search engines, for example, build upon the HTTP GET API of the web in general, search engines have always found it much easier to build upon this API than the sites they crawled. There are other less dramatic examples, of course.

  Bob [04.27.07 02:04 PM]

Well said, Nat. I wish more tech journalists were this honest about the purpose of web service APIs. Too much fluff has been written about blogs portrarying web services as something they are not.

Free APIs are like the minor leagues. Companies offer them to get developers trained on their product. The result is you wind up with a lot of engineers you can recruit to work for you, and a lot of new ideas that you can copy to enhance your product.

  Don MacAskill [04.27.07 02:16 PM]

I'm afraid I have to disagree with #1. Or at least say there are exceptions to that rule. :)

Every which way we've looked at it, we can't financially justify SmugMug's open API. I'm hoping some day something materializes, but that's just a hope.

Luckily, SmugMug is my company and I get to do things that other companies with concerned board members do not. :)

I'm a geek, I love APIs, so we have one. It's that simple. And I'll bet I'm not alone - just rare.

  Louis Ewens [04.27.07 02:46 PM]

Well said.

Whether it's online or in life, there's no such thing as a free lunch. There is always a motivation and a reason for it.

But regardless, it's nice to see companies putting some of their expertise out there for other people to benefit from.

  Phil Wainewright [04.27.07 02:51 PM]

>> Free APIs are not a god-given right. Businesses offer them for their own self-interested reasons.

> I'm a geek, I love APIs, so we have one. It's that simple.

So what happens when you merge/ get bought out/ go public? Your self-interested love gets supplanted by self-interested profit motive.

Get used to it. APIs must have a business case. There is no such thing as a free lunch. Anyone who builds their business on a free API better understand what is the quid pro quo. And if it's not explicit, then go somewhere else because one day you'll discover what the terms are and they may not be to your liking.

  Don MacAskill [04.27.07 03:12 PM]

@Phil Wainewright:

Pick a handful of the biggest companies in the valley. Mix in the biggest and best VCs on Sand Hill Road. Now imagine they've all come knocking on your door, checkbook in hand. Now imagine you've turned them all down without even hearing what the number is.

That's our situation and it's real. I can't predict the future, obviously, but we have zero incentive to sell. Our business is profitable, growing, and we love it. Why would we turn it over to someone else who's unlikely to love it as much?

Going public sucks even more than getting acquired. It wrecks your company - we know, we've been there before.

So the odds are that SmugMug will be private for a long, long time. We'll keep saying "No" for as long as we possibly can because we love our business. And our customers beg us on a daily basis to keep saying "No."

  Oren Michels [04.27.07 05:05 PM]

Not so fast...

Hmmm ñ is there nothing between a free unlimited API and ìowning and controlling every piece of your applicationî? The OíReilly site has search powered by atomz ñ has the conference biz been lucrative enough for Tim that he can afford to have his team write and manage their own search engine? After all, even things you pay for can suddenly become more expensive and threaten your way of doing business...just ask the people who raise howls of protest each time eBay raises its fees.

Take this post and remove the term "API" and substitute other things that people rely on and currently get for free, and you'll have the same "danger". "VOIP". "Craigslist listings". "Search Engine". "IM". "Twitter". ìDiggî. Any of these things can go away anytime our benefactors wish for them to. In the meantime, people who move quickly can build very cool services ñ and successful businesses ñ that harness these free services.

And as for ìowning and controlling every piece of your applicationî, I submit that if that if a developer insists on that constraint on any new web application they build, they will quickly fall behind competitors willing to risk that they might have to unplug one module that becomes unavailable (or expensive) and replace it with a competitor that sees strategic value in encouraging use of its API.

I discuss this a bit more in this post.

  Michael R. Bernstein [04.27.07 05:21 PM]

Oren Michels' post that he referred to is this one.

  Bob [04.27.07 08:44 PM]

Oren, did you not notice the word "Free" in the headline? Nat is warning about FREE APIs, not APIs in general.

  specops27 [04.28.07 07:50 AM]

Of course Google and Amazon expose their API's for their own benefit, but the benefit is mutual. They understand the financial upside of enabling individuals to create compelling sites without the need for significant upfront capital and complex contracts. They also understand that if they start charging for access then the majority of users will disappear.

Open API's are one of the building blocks of Web 2.0 and the potential upside is huge. There are always risks with any endeavor but the idea that larger companies like Google and Amazon can work alongside indviduals in a way that both can benefit is something we should embrace not oppose.

  anselm [04.28.07 09:49 AM]

how about openid - not an api - but again a case where a core mission critical role is outsourced.

  kellan [04.28.07 10:59 AM]

A time when #4 isn't true ("provider of your API will find it easier to implement services on top of their API than you will") is when you're providing a UI/feature/service to a niche audience.

The API provider has to consider the cost not only of offering the feature at scale, but the cost in complexity for their larger community if they make it a core offering.

So when adding complex/niche/unique features its often easier/cheaper for a 3rd party to offer a feature. (though the other rules still apply)

  drew [04.28.07 11:12 AM]

Yeah, dude. You're always going to be out-gunned by the creator of the 'free' API. I'll have to keep that in mind when designing my next API-based feature.

Thanks!

  David Ward [04.28.07 11:37 AM]

Excellent post, you are 100% correct and timely for the trends that seem to be taking place on the web today.

  Andy Wong [04.29.07 04:33 PM]

Yes. Agree.

Comparing with APIs of OS like Windows API, Web API is easier to adapt, but
1. The deployment of API is easy, because there's no deployment.
2. The evolution of API is more dynamic, less consistent. And you dear codes need to be upgraded more frequently as some API functions will be obsolete soon.
3. The terms of use evolve fast.

Both OS API and Web API are computing platforms, vendor specific. Use them at your own risks.

  Dave Sanders [04.29.07 08:24 PM]

"Wonder when people are going to offer data and services under truly free licenses?"

Probably about the same time energy can appear from thin air and no one in the entire world is hungry, or has to work, or has to buy ANYTHING, or ever dies. As long as competition, supply and demand and life and death exist, nothing will be truly "free." (And then we'll probably find something to replace it with so we can maintain a scarcity model - Like "Whuffie.")

I think the point of the article is spot on, and I've been watching these mashups proliferate with growing concern. You simply cannot build a business model where you do not have some say in its foundation. Free Stuff is all well and good, and may be perfect for getting up and running quickly, but you have to replace it if you are seriously going to continue.

  Jacob Jay [04.30.07 02:46 AM]

#1 "delivering the value" does not imply a direct financial imperative. This "self interest" can be effected through knock-on value such as building customer loyalty--through the growth of additional functionality delivered by third-parties using the API. That in turn can lead to customer retention etcetera which translates to a financial benefit and thus "delivers value" producing the self-interest in the provision of the API…

@Don: This would suggest that there is no exception to the #1 rule. If your API was not delivering value in this way (i.e. customers were not benefiting) would you have continued to maintain it?

  Charlie Wood [05.01.07 06:58 AM]

Even though I tend to agree with the spirit of this post I'm not sure I should. Isn't this just the old argument that you can never completely rely on a platform unless you own it?

The comparison of web API's to OS services (Win32, Mac Toolbox, whatever) is apt I think. Maybe some huge ISV's have legal agreements with the OS vendors that their platform API's won't change for some period of time, but I've never heard of such a thing.

My company's products are built on the GData API--if it goes away, so do we. Obviously Google has an interest in making their, er, platform attractive to third-party developers so they can fill in the functional gaps (like sync for Google Calendar) but I have no idea what the numbers in their financial model are.

A new Google product manager might decide the cost of supporting the GData API (which is nontrivial) is higher than the benefit of providing it and shut it down, ala their SOAP search API. But I'm betting my business that they won't do that. So far, that bet has paid off nicely.

Regards,
Charlie
Spanning Sync

  Tony B [05.01.07 07:55 AM]

Assuming these six truths prove out over the long term, the 'A' in API will eventually stand for 'Affiliate' rather than Application.

  viksit [06.19.07 06:30 PM]

Excellent post.

  KwangErn Liew [06.21.07 06:26 AM]

Am afraid this wouldn't deter web companies from using free APIs or glue 'emselves with a particular web company.

In the end, everyone is hoping to have more profits and/or get bought out by being part of the circle, no?

  Mark Patterson [06.28.07 06:15 AM]

Very interesting article, I wish I had read it prior to developing an application that used Google's API (GData) as the backend.

I wrote an application called mobileGCAL that accessed Google Calendar data and presented it in a wireless user interface. Things were going great and I was getting upwards of a 100 people a day signing up to use the service. The GData folks at Google were impressed enough to use it as a showcase for their API.

But then the Product Manager for Google Calendar found out what was going on and contacted me with an intimidating email requesting that I change my domain name. After being told by their legal staff that they had no grounds to shut me down, I received another email from the PM stating "We are always happy to see Developers use our API. Keep up the good work". Three days later Google Calendar released their scaled down (and far inferior) version of a mobile calendar.

Be advised, if a company that runs an "open API" sees potential in the application that you've developed they WILL take the concept for themselves.

(#5) Never again will I develop an application that uses an open API. A complete waste of time, energy and money.

Mark Patterson

mobilegCAL Developer

  Jason Etheridge [07.09.07 08:55 AM]

Just to clarify, everyone seems to be talking about "open" API's into single proprietary systems, but what you really want in an open API is multiple implementations across different systems. If I could write an application against either MapQuest or Google Maps with one API, that'd be awesome. My bias is to code against open source systems, which is my guarantee that an API will stay open.

-- Jason

  Richard Friedman [07.12.07 12:06 PM]

Nice post about the 'truths'.

So business must first be built on to of your own 'captured' data, and then second improved upon (mashed up) via secondary services, third be valuable so others build to your APIs. Everyone becomes additive.

What the APIs enable
a. isv/developer community to form
b. b2b monetization. I use your data and now have some mechanism by which to throttle and control.
c. tracking of copyright and reuse.
d. preventing others from building better interface into same captured data

Who out there is building an open platform? Where the data pushed in is available to all, human or machine? Will an open platform be able to provide greater adoption than a closed platform?

Closest I see is wikipedia, but they need better APIs.

Rich

  Colonel Nikolai [10.31.07 07:26 PM]

Part of the problem was mentioned earlier: "Seems like you can apply precisely the same logic to MS and Apple OS APIs."

Nat, you need to move away from the idea of value = intellectual property toward value = intellectual process. Those who own the process own the value. The property is just a snapshot, a fly in amber. Like Linux on a CD. Valuable today. Trash in a few weeks. And we're starting to see the dawn of an age where the day you have to go to court to make money is the day you've become irrelevant, incompetent and immaterial.

If I make a valuable service on a free API, then the maker of the API decides the free API just goes "poof"? Is that a real situation? No: the maker of the free API has two logical choices:

1. Make a deal with the one providing value (the one with the process)
2. Duplicate the value. If the provider of the free API is better than the original, s/he deserves to "own" it.

The six rules are so bad, they're not even wrong. They present a small facet of the real situation, which is that process, not property is where the value is.