The Api Paradox
jacquesmattheij.com
jacquesmattheij.com
You are safe to build on top of something like Twilio because the service is the API and API consumers are the customers. Consumers of Twitter's API are not customers of Twitter and should not be surprised Teotter does not treat them as such.
You are either the customer or the product. If you are neither you are in a precarious position.
This in fact is one of the red-flags he suggests: "[Be leery if] the API offers no (or very little) prospect for being monetized in the future"
This is also true about data. Startups are not about the data. A dozen companies did what Dropbox did, but there was only one Dropbox. Everybody did search, but there is only one Google, and so forth. Yes, people consume the data, and yes, if you ask them they'll say that's why they're using your app, but that's confirmation bias. They already use your app and enjoy it. When you ask them, they just look at what the app does and repeat it in a way that makes them sound the smartest.
So, presto chango, adding those two things together along with Jacques' essay and we end up in a really weird spot: your startup may be about providing some kind of massaged data to end users. So you find an API to do that. But the guys providing the data, the heart of your app, have the least amount of reward in the entire equation! Hell, in many cases they're providing data willy-nilly out to just about everybody for free. To them, the data is worthless, yet you're building your business off them! Crazy world.
I have a personal news aggregator I wrote a couple of years ago, http://newspaper23.com Nothing fancy, just rips some headlines, then rips the plain text, then puts the plain text in json and makes a client-based detached reader.
To provide the plaintext, I was using ViewText. Great folks. Put in an URL and it'll give you a readable version of what's there.
But guess what? The ViewText guys didn't like my app ripping 50-60 articles a day. So I lost this huge amount of functionality when they decided to start rate-limiting. Now when you click an article, I bring up a frame and load it. I wanted plain text, this was the entire reason for the app, and now the critical thing I wanted is the exact thing that isn't working.
No big deal for my newspaper23 app, but it would be a freaking red alert if this was something I was selling. API use, like walled gardens, are high-risk.
EDIT: Fixed possessive version of "Jacques"
Tiny, irrelevant nitpick.
Assuming that Jacques Mattheij is using the French pronounciation of his first name, the possessive version of Jacques is Jacques's.
This is because in French the final letter of most words is silent, and in English the possessive form of spoken nouns not ending in an audible "s" is rendered in text as <singular>'s.
Phoenetically:
zhahk -> zhahks
Not: zhahks -> zhahks.
Regards,another Jacques.
Thank you. I changed it to the Americanized form of possessive for words ending in s (pronounced or not) I think this could go either way, but I screwed it up no matter which choice an author might take.
edit:
> Jacqueses! (Jacuqi?)
Jacqueses would be closest (-ii is a Latin pluralisation, Jacques comes from Jacob which is Hebrew).
There's an impedance mismatch here: English stores plurality in the word, French stores it in the sentence.
There is no fully agreed upon means make words ending s (x or z) into possessive - the below site gives example of Dumas' and Dumas's as valid.
My general response has been if it looks ok with just an ' leave it and move on. I can open my own shop with the left over apostrophes.
http://en.wikipedia.org/wiki/Apostrophe#Nouns_ending_with_si...
Still, I prefer my rendition. The problem here is the incompatibility between the rules of pronounciation -- French permits silent letters to end a word, English in general does not. In translating to English you must choose either to honour the French or the English rules of pluralisation and possession.
Because I don't write many English sentences with de la, du or d', I figure that sticking to the English rule is the best move.
Maybe I'm missing something, but DropBox was just a very well-implemented GUI for backing up files - there was no "special sauce data".
As for Google, one could argue that their data (or their index) was one of their competitive advantages. They started crawling pages back in 1998. They basically have a 15 year head start over any new competitors that want to enter the field today. And their index is vastly superior to Bing's/Yahoo's.
So I would disagree that startups are not about the data. For a lot of them, without the data, they'd just be a fancy, useless CRUD GUI.
Because I get annoyed every time someone uses "APIs" to make general statements while assuming that specific narrow meaning.
So hard to invent catchy new terms... Trying here but they all sound like business buzzwords...
Business Proxy, Business Delegate, Business Front, Business Agent, Company Blackbox, Business Interface, Company Platform, Company Rube Goldberg, Company Socket, Partner Interface?
s/Api\'s/APIs/g
s/Api/API/g
I know it's nitpicky, but the error makes it painful to read the article. Obviously I'm blaming nobody, and to judge from his name the author is probably fluent in more languages than me. But it's a user-friendliness thing. It would help.Ok, fixed. Have an upvote :) & thanks again!
I see this on your main page: --- The Api Paradox APR 11TH, 2013 – layout: post title: The API Paradox date: 2013-04-11 11:00 comments: true categories: api development startups programming
permalink: /api-paradox
---And the page at http://jacquesmattheij.com/api-paradox still says "Api", not "API"?
Fixing, regenerating, deploying. eta 10 minutes, thank you very much!
Thanks!
Props to the author for fixing it so quickly.
typo: "If you do not heed that than chances..." than => then
It always comes to my mind operating system API when I read such titles.
Maybe WSI would be a better moniker? (Web Service Interface)?