I’m Done Developing for Twitter(restrictionisexpression.com)
restrictionisexpression.com
I’m Done Developing for Twitter
http://restrictionisexpression.com/post/26144987502/im-done-developing-for-twitter
74 comments
Oh come on, that's bullshit. By offering an API, Twitter says "dev for us!". If they subsequently make actually developing for Twitter impossible, they're in the wrong.
Calling it the developers fault is just ridiculous.
Twitter should either own up to their current strategy and remove the API altogether (publicly), or keep the API and support it like it's a service that matters.
Calling it the developers fault is just ridiculous.
Twitter should either own up to their current strategy and remove the API altogether (publicly), or keep the API and support it like it's a service that matters.
>By offering an API, Twitter says "dev for us!"
That's true, but in no way is this invitation a binding contract.
It's a temporary bargain: The big player gets a cheap way to offer more functionality to his users, and the API-users profit from the big audience of the platform.
As soon as one player decides that the bargain isn't worth it anymore, the deal is off. It's no one's fault, just the nature of it.
That's true, but in no way is this invitation a binding contract.
It's a temporary bargain: The big player gets a cheap way to offer more functionality to his users, and the API-users profit from the big audience of the platform.
As soon as one player decides that the bargain isn't worth it anymore, the deal is off. It's no one's fault, just the nature of it.
The population turns over. And a high proportion of members need to be "burned" before they become "shy". And, there's a subset that never does learn.
It's what the con-man (/person) lives on, the old: "There's a sucker born every minute."
And even when individuals are not deliberate in forethought and intent, social systems tend to recreate these patterns. When your family needs to eat (metaphorically, when not literally), you'll restrict your API, too, if that's what it takes.
There's a reason that metaphors stick around. "Don't be a sharecropper." "Don't put all your eggs in one basket." "Time is money." Etc.
It's what the con-man (/person) lives on, the old: "There's a sucker born every minute."
And even when individuals are not deliberate in forethought and intent, social systems tend to recreate these patterns. When your family needs to eat (metaphorically, when not literally), you'll restrict your API, too, if that's what it takes.
There's a reason that metaphors stick around. "Don't be a sharecropper." "Don't put all your eggs in one basket." "Time is money." Etc.
Perhaps we'll reach the stage where developers react to third party APIs like an abused spouse does to their aggressor -- shying away from their spouse and doing their best to move on to greener pastures.
We may end up at the stage where the most successful third party APIs are those that provide strong bilateral agreements and service guarantees, so that the developer doesn't live in fear that the nerdy rug will be unpredictably pulled out from underneath them.
We may end up at the stage where the most successful third party APIs are those that provide strong bilateral agreements and service guarantees, so that the developer doesn't live in fear that the nerdy rug will be unpredictably pulled out from underneath them.
I wish it were so, but though I hate to be cynical, this has been going on (for me) since the early 90's (back then Microsoft was the one everyone connected to) so I doubt that anything is going to change.
Maybe it needs to get worse before the tipping point is reached though and API developers start genuinely caring for the wellbeing of their developers and acting with a greater deal of integrity and empathy.
Established businesses should feel less secure today as it seems far harder for one business to have a stranglehold on the market. Software distribution costs have been lowered by the internet. Development costs have also been lowered because we no need to push wheelbarrows of cash to Oracle, et al. We have better tools, better infrastructure, and shorter development cycles. Marketing is easier, cheaper, and more apt to give rapid feedback.
Established businesses should feel less secure today as it seems far harder for one business to have a stranglehold on the market. Software distribution costs have been lowered by the internet. Development costs have also been lowered because we no need to push wheelbarrows of cash to Oracle, et al. We have better tools, better infrastructure, and shorter development cycles. Marketing is easier, cheaper, and more apt to give rapid feedback.
Network effects are still horrible barriers to overcome on social networks or phone platforms. Once a company has large numbers of active users they tend to win, and once they start winning they have little incentive to care about the well being of individual third party developers. Once they have the eyeballs the third party developers want access to, they can treat most of them like dirt, and they can still count on more lining up to use their API.
If a company like Google struggles to launch a new social network with their existing huge user base, you know its hard. Yes social networks and platforms do die, like MySpace and RIMM, and new ones burst in to prominence like Pinterest or Android, but for every new network or platform that succeeds, hundreds or more probably thousands fail.
Small third party developers have strong incentives to put up with the risks involved in using API's provided by dangerous companies like Twitter, Facebook and Apple because they have to if they want to get access to all the users those companies own.
If a company like Google struggles to launch a new social network with their existing huge user base, you know its hard. Yes social networks and platforms do die, like MySpace and RIMM, and new ones burst in to prominence like Pinterest or Android, but for every new network or platform that succeeds, hundreds or more probably thousands fail.
Small third party developers have strong incentives to put up with the risks involved in using API's provided by dangerous companies like Twitter, Facebook and Apple because they have to if they want to get access to all the users those companies own.
We see turnover all the time. The network effect is interesting, but creative people can and do overcome it. reddit overcame it by faking user activity until they actually had a community. Facebook overtook MySpace with exclusivity combined with an exponential rollout. LiveJournal lived and died because of its community and the "network effect"; Tumblr has now achieved what LiveJournal had only dreamed about. The network effect is a difficult hurdle to overcome, but the best do and as a result we end up with a "new internet" ever 5-10 years or so. Craigslist might be the next giant to lose their golden star, and I wouldn't be especially surprised if they do.
Google failed in part because they never really communicated what Google+ is. I still don't really grok what it's for or why I should use it, and that's why I don't. They really just didn't produce a compelling product, brand it well, or market it effectively. For whatever reason, Google's marketers doesn't appear to be of the same caliber as their engineers.
Someone will pull Twitter's pants down and at the same time eat their lunch. I love Twitter, but I can't wait to see what cool thing replaces them.
Google failed in part because they never really communicated what Google+ is. I still don't really grok what it's for or why I should use it, and that's why I don't. They really just didn't produce a compelling product, brand it well, or market it effectively. For whatever reason, Google's marketers doesn't appear to be of the same caliber as their engineers.
Someone will pull Twitter's pants down and at the same time eat their lunch. I love Twitter, but I can't wait to see what cool thing replaces them.
"I still don't really grok what it's for or why I should use it, and that's why"
Uh, its for pretty much the same thing Facebook is for, except you can do lists and make them public or private, you seriously didn't get that?
Or did you just not use it because the people in your network weren't using it. If your friends are already on Facebook there is almost no reason for you to migrate to a new social network where your friends, or chosen thought leaders, aren't active. Maybe you will tack it on as a 3rd, 4th or 5th social network where it will mostly just consume more of your time.
As I said, yes network do rise and fall but it is enormously difficult to get that ball rolling and keep it rolling. FriendFeed was an awesome social network, with all star founders, but it never gained that critical mass, the founders gave up believing they could displace Facebook so they sold it down the river... to Facebook.
Uh, its for pretty much the same thing Facebook is for, except you can do lists and make them public or private, you seriously didn't get that?
Or did you just not use it because the people in your network weren't using it. If your friends are already on Facebook there is almost no reason for you to migrate to a new social network where your friends, or chosen thought leaders, aren't active. Maybe you will tack it on as a 3rd, 4th or 5th social network where it will mostly just consume more of your time.
As I said, yes network do rise and fall but it is enormously difficult to get that ball rolling and keep it rolling. FriendFeed was an awesome social network, with all star founders, but it never gained that critical mass, the founders gave up believing they could displace Facebook so they sold it down the river... to Facebook.
Don't count Google out yet. Just because it hasn't become hugely successful in it's first year doesn't mean it won't. How many users did Facebook have in 2005? Twitter in 2007? Google has put enormous resources behind Google+, and they don't show any sign of backing down. They're taking dozens of separate services that they provide and integrating them through Google+. In 5 years, that's going to be a very compelling platform.
I question whether a "stranglehold" is necessary for business security.
Your analogy is defective in that abused spouses usually still cling to their abusers, which is why domestic violence is so persistent and bad. If a random person assaults you on the street, you're very unlikely to lie in court to keep him from going to prison; battered spouses do that kind of thing all the time.
Of course my analogy is "defective" -- that's a feature of analogies, not a bug because all analogies break down rapidly. An analogy is a loose likeness between two things; one is not a wholly accurate representation of the other.
Humans have extremely high tolerance to abuse. Many businesses have this as their main pillar. Adobe famously continues to release worse and worse experiences with their products, and still have a popular costumer base. The masses simply have very low quality standards.
Perhaps the tolerance is only propped up because there's no viable alternative. GIMP is nice, but it's not Photoshop. Likewise, Inkscape is nice, but it too is not Illustrator.
Tolerance for BS decreases as the number of perceived choices increases. This seems to be true across the board, from software to relationships.
Tolerance for BS decreases as the number of perceived choices increases. This seems to be true across the board, from software to relationships.
Humans also have surprisingly high levels of trust. People expect businesses, which by definition exist solely to make money, to be reasonable about things, and then are shocked when they aren't. And people will often try to reason something is an "honest mistake" and not deliberate.
>Adobe famously continues to release worse and worse experiences with their products, and still have a popular costumer base.
Famously? Really? As in "some random non professional designers/adobe users complained on the intertubes".
Care to mention how, say, Photoshop, Premmiere or Lightroom CS6 are worse than previous versions? All have been praised as substantial updates.
Bonus points for not using non-technical catch-all words like "bloated".
I would aldo like to hear about the worthy replacement, with feature parity to those products.
Abode products, due to the custom UI, have some odd look&feel issues in some controls. They also have bugs like any program has (far less than most, though, especially considering scope and complexity).
That said, they are the industry leading products, with no substitution that has the same breadth for professional wokflows. So, no, its not about "tolerance", its about being the "best game in town".
People jumped ship from Quark to inDesign in a heartbeat, when the option emerged.
Famously? Really? As in "some random non professional designers/adobe users complained on the intertubes".
Care to mention how, say, Photoshop, Premmiere or Lightroom CS6 are worse than previous versions? All have been praised as substantial updates.
Bonus points for not using non-technical catch-all words like "bloated".
I would aldo like to hear about the worthy replacement, with feature parity to those products.
Abode products, due to the custom UI, have some odd look&feel issues in some controls. They also have bugs like any program has (far less than most, though, especially considering scope and complexity).
That said, they are the industry leading products, with no substitution that has the same breadth for professional wokflows. So, no, its not about "tolerance", its about being the "best game in town".
People jumped ship from Quark to inDesign in a heartbeat, when the option emerged.
Yeah. My wife uses Photoshop, Illustrator, InDesign, and is moving to Lightroom now, professionally, and loves Adobe's products. Oh, I'm sure she has her gripes about certain things, but they work great. There are other products. She used Aperture for a while (and still does, as I mentioned, she's moving to Lightroom), but if you heard her tell it, it wasn't because Aperture was better, it was just that she ended up learning that first. They are, in essence, the same.
And when they are basically the same, the one that fits in with the entire suite of applications she uses is one she will want to use more often.
Adobe does not begin with PDF's and end with Flash.
And when they are basically the same, the one that fits in with the entire suite of applications she uses is one she will want to use more often.
Adobe does not begin with PDF's and end with Flash.
Back in 2009, I was doing a lot of social network research with the Web Ecology Project (http://www.webecologyproject.org/).
Among other things, we captured a 100% set of tweets surrounding the election in Iran in 09, and released a paper on them. It was interesting, because it ended up all being a bit of a precursor to the Arab Spring and many current events in the middle east today.
I loved doing it. The API team was responsive, and although we were never able to get full Firehose (despite offerring large amount of money) we were able to easily play with and access a lot of data.
Much/all of that has changed. The API has gotten really complex to work with. The terms of service are no longer friendly. Getting whitelisted accounts for standard API calls is impossible, and overall feeling like we have any influence or use to Twitter is dwindling.
Whereas at one point I felt it was a joy to work with, now I feel its impossible. Getting the data to study is impossible (or expensive, since a few companies control the firehose), and there's the constant feeling of getting shut down at any moment. Plus, there's just too much data to grab given the clunky methods you have to use to do it. I'd kill for a hard drive of the 'network graph' with diffs over time. As-is, its impossible to answer certain academic questions.
To a certain degree, while Twitter is used far more now than in 2009, it feels boring, obvious and less important to me. So at the end of the day, nothing of value was lost, but I do miss it as it was interesting at one point.
Among other things, we captured a 100% set of tweets surrounding the election in Iran in 09, and released a paper on them. It was interesting, because it ended up all being a bit of a precursor to the Arab Spring and many current events in the middle east today.
I loved doing it. The API team was responsive, and although we were never able to get full Firehose (despite offerring large amount of money) we were able to easily play with and access a lot of data.
Much/all of that has changed. The API has gotten really complex to work with. The terms of service are no longer friendly. Getting whitelisted accounts for standard API calls is impossible, and overall feeling like we have any influence or use to Twitter is dwindling.
Whereas at one point I felt it was a joy to work with, now I feel its impossible. Getting the data to study is impossible (or expensive, since a few companies control the firehose), and there's the constant feeling of getting shut down at any moment. Plus, there's just too much data to grab given the clunky methods you have to use to do it. I'd kill for a hard drive of the 'network graph' with diffs over time. As-is, its impossible to answer certain academic questions.
To a certain degree, while Twitter is used far more now than in 2009, it feels boring, obvious and less important to me. So at the end of the day, nothing of value was lost, but I do miss it as it was interesting at one point.
I was kind of hoping Dorsey coming back to Twitter would have put an end to or at least subdued their hostility to their developer community, but it doesn't appear to be the case. Their new proprietary attachments are even more concerning than this.
Costolo and Ev are dickish enough you expect crap from them, but Dorsey used to have some hacker cool. I wonder if either Dorsey doesn't have enough power to swing Twitter back to being open and cool again, or if he's drunk the rich and famous Koolaid to the point he just wants to cash out in a big IPO and doesn't care about the things he used to care about.
Regrettably companies trying to squeeze enough revenue out of "free" Internet services to have a successful IPO are pretty much compelled to be complete dicks, so its probably gonna happen.
It just kind of sucks that Twitter is the absolute coolest news stream there is, there aren't any good replacements and you KNOW they are going to totally wreck it by the time they IPO or within a year of going public and we are going to all have to start over on some new "never heard of" clone. Then repeat cycle endlessly every few years. Dave Winer will keep shouting to use RSS but RSS completely sucks by comparison.
As an aside a few days ago I read New Yorker and some other mags were getting weary of letting Flipbook scrape their content and were going to just put a lead in and link users to their main web site through flipbook instead. I'm thinking, wow that's what Twitter was already doing. I totally never understood what Flipbook offered to justify the hype. A good Twitter stream in a good client is infinitely better.
Costolo and Ev are dickish enough you expect crap from them, but Dorsey used to have some hacker cool. I wonder if either Dorsey doesn't have enough power to swing Twitter back to being open and cool again, or if he's drunk the rich and famous Koolaid to the point he just wants to cash out in a big IPO and doesn't care about the things he used to care about.
Regrettably companies trying to squeeze enough revenue out of "free" Internet services to have a successful IPO are pretty much compelled to be complete dicks, so its probably gonna happen.
It just kind of sucks that Twitter is the absolute coolest news stream there is, there aren't any good replacements and you KNOW they are going to totally wreck it by the time they IPO or within a year of going public and we are going to all have to start over on some new "never heard of" clone. Then repeat cycle endlessly every few years. Dave Winer will keep shouting to use RSS but RSS completely sucks by comparison.
As an aside a few days ago I read New Yorker and some other mags were getting weary of letting Flipbook scrape their content and were going to just put a lead in and link users to their main web site through flipbook instead. I'm thinking, wow that's what Twitter was already doing. I totally never understood what Flipbook offered to justify the hype. A good Twitter stream in a good client is infinitely better.
You should try google+. I like it better than twitter and I use it primarily as a news stream.
The only reason I don't use it more regularly is that they don't have a proper API yet and therefore have no apps for my blackberry.
The only reason I don't use it more regularly is that they don't have a proper API yet and therefore have no apps for my blackberry.
Just to play devil's advocate for a moment...
The first app created a layer between twitter and its users which meant that stripping ads would be trivial & likely universal (they don't put ads in 3rd party app streams yet but should they chose to this would stop them) and you could be harvesting the analytics and user metainfo that twitter wants to sell for ad-targeting against what they probably consider "their" content. I can see how they would take exception to a service that allows users to fully control their interaction with twitter; it could seem too much like "handing the keys over" to a third party.
TweetFavor (ironically) seems that it would worsen the signal to noise ratio that Proxlet aimed to improve. Friends turning themselves into voluntary zombies in a twitter spam botnet? I know it's not actually that bad but I can see why twitter would want to cut this off.
None of this excuses the manner with which twitter did what they did, and like I said, "Devil's Advocate," neither of the apps were that bad, but it's not unfathomable to me why twitter would have a problem with them.
The first app created a layer between twitter and its users which meant that stripping ads would be trivial & likely universal (they don't put ads in 3rd party app streams yet but should they chose to this would stop them) and you could be harvesting the analytics and user metainfo that twitter wants to sell for ad-targeting against what they probably consider "their" content. I can see how they would take exception to a service that allows users to fully control their interaction with twitter; it could seem too much like "handing the keys over" to a third party.
TweetFavor (ironically) seems that it would worsen the signal to noise ratio that Proxlet aimed to improve. Friends turning themselves into voluntary zombies in a twitter spam botnet? I know it's not actually that bad but I can see why twitter would want to cut this off.
None of this excuses the manner with which twitter did what they did, and like I said, "Devil's Advocate," neither of the apps were that bad, but it's not unfathomable to me why twitter would have a problem with them.
Proxlet never made any attempt to block ads (they didn't even exist when we built it!) That said, it's really no different than a normal 3rd party app which could do the same thing. Again, my beef was the manner in which they shut it down abruptly stranding users.
TweetFavor just supports an existing pattern "hey dude, can you tweet this for me?" And permission had to be given per-tweet request, there was no mass zombification. You'd pledge individual tweets. Once again, no reason as to why it was shut down, and certainly no one used it before making the call.
TweetFavor just supports an existing pattern "hey dude, can you tweet this for me?" And permission had to be given per-tweet request, there was no mass zombification. You'd pledge individual tweets. Once again, no reason as to why it was shut down, and certainly no one used it before making the call.
Moral of the story: be-wary of developing applications with dependency to a platform
Yep. Or at least "be-wary of developing applications with dependency to a platform unless you control it, it's easily replicable, or you have a legally binding SLA in place with the provider."
We're seeing more and more of this kind of thing, and people need to realize that you can't build something sustainable by relying on the happenstance goodwill of some arbitrary API provider.
Yep. Or at least "be-wary of developing applications with dependency to a platform unless you control it, it's easily replicable, or you have a legally binding SLA in place with the provider."
We're seeing more and more of this kind of thing, and people need to realize that you can't build something sustainable by relying on the happenstance goodwill of some arbitrary API provider.
You know the old joke about being involved vs being committed, the punch line is that in a bacon and eggs breakfast the chicken is "involved" and the pig is "comitted." So it is with web service APIs.
If you have 'free' API access then you are providing some benefit to the web service (whether you know what the benefit is or not), when you have a 'paid' API access you are a customer of that web service.
If you're paying for a service as part of your product, you need to understand how your costs may change over time, and generally you put into the contract language under what conditions and time frames the price can change.
This is one of the essential differences between building products and building demos. Just like an engineer might build a circuit that works to prototype something, they will go back and do all the edge case and tolerance analysis prior to putting it 'into production.' If you've never shipped a product before it can sometimes be a painful learning experience to get these sorts of lessons the hard way.
If you have 'free' API access then you are providing some benefit to the web service (whether you know what the benefit is or not), when you have a 'paid' API access you are a customer of that web service.
If you're paying for a service as part of your product, you need to understand how your costs may change over time, and generally you put into the contract language under what conditions and time frames the price can change.
This is one of the essential differences between building products and building demos. Just like an engineer might build a circuit that works to prototype something, they will go back and do all the edge case and tolerance analysis prior to putting it 'into production.' If you've never shipped a product before it can sometimes be a painful learning experience to get these sorts of lessons the hard way.
Thank you for this. It's not anecdotal to simply say "don't rely on platforms". Be weary of platforms that are free. They do have risks. It's important to understand those risks before thinking you've just hit a gold mine.
Personally, I wonder if this sort of pushback will drive us towards a more standards-ish way of approaching platforms where it won't be enough to simply provide an API – to get use, you'll need to make it a more standardized API that provides a more standardized sort of data – because only when we have those sorts of standards can we hope of it being safe to develop based on someone else's free API – because I know if I need to, I can substitute in (or combine) some other data source.
Relatedly, Right now, what I think we're seeing is a lack of real competition of direct substitutes. There is nothing exactly substitutable for Twitter quite in the way that products ranging from Heinz Ketchup to the Chevy Malibu face real, direct substitutes, rather than a more abstracted category substitute (i.e. Facebook is similar to Twitter, but it's not a perfect substitute). As such, switching costs are higher and it makes development for a specific platform more risky.
Relatedly, Right now, what I think we're seeing is a lack of real competition of direct substitutes. There is nothing exactly substitutable for Twitter quite in the way that products ranging from Heinz Ketchup to the Chevy Malibu face real, direct substitutes, rather than a more abstracted category substitute (i.e. Facebook is similar to Twitter, but it's not a perfect substitute). As such, switching costs are higher and it makes development for a specific platform more risky.
I'd say avoid platforms that lock you in to that vendor, free or not. I've read of paid accounts being shut down just as unceremoniously. Or prices were increased 10X. Even when not locked in, one should be ready enough to move to another vendor without too much problem.
Well, if you're paying, you should at least have some sort of contractual protection. If you don't, you're just a wallet to them, not a valued customer.
I totally agree. There are no free lunches and there will be no free lunches. Piggy-backing is fine but it's unsustainable if you don't offer the part you're piggy-backing something in return.
Google Maps is a pretty good example of why you should be wary of all platforms, free or not.
[deleted]
A group of us developed an app for published research work that used the streaming API within academia. The amount of hoops we had to jump through for the necessary access was absurd. It's as if the attitude is "it's a privilege for you to use this API", as opposed to making it a viable platform.
They used to say this about Microsoft.
http://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePla...
Now it can apply to any company that provides developers an API.
Now it can apply to any company that provides developers an API.
Sadly, I don't think there's any kind of "social contract" with web services providing APIs. Just as the exploitation of crowdsourced data is now common practice (including personal data), most organizations provide APIs only as long as they find free access in their own interest. There's little loyalty or feeling that they owe users anything, at all.
In my most cynical moments, I think the business plan is to provide an API, let it boost your services usage via 3rd party labor, get successful, then buy what you want and lockout the rest.
That's not in any way cynical; that's business.
I don't think it is a good long term business plan. I believe you should "dance with the one that brought you".
If this is all about advertising or branding, it is just sad and it makes it harder for the people who actually care about their developers.
If this is all about advertising or branding, it is just sad and it makes it harder for the people who actually care about their developers.
Amateur question here. How does Twitter stop your app? Do they block your IP from accessing their API?
In order to interact with their API, you need a security token. They revoke the rights on that token, and the API rejects your requests.
And to put a finer point on it, tokenized APIs are basically whitelists.
and today they post this https://dev.twitter.com/blog/delivering-consistent-twitter-e...
from the link: "for example with branding, and in the coming weeks, we will be introducing stricter guidelines around how the Twitter API is used."
They have a vision and it doesn't include 3rd party developers. I think developers were hoping for a universal message bus / directory of users and Twitter wants to be something else.
They have a vision and it doesn't include 3rd party developers. I think developers were hoping for a universal message bus / directory of users and Twitter wants to be something else.
Yet you'll notice that the only features they mention that people might build upon are all features based upon contributions to Twitter itself, in the form of either content (posting proxies) or analytic data ('like' buttons, embeds). Consumption is left entirely out of the mix.
Yea, they want developers to develop content for them, and they want developers to develop traffic for them. They absolutely dont want developers to develop interesting clients and apps using for their message bus. Their guidelines on displaying tweets are getting so restrictive its pointless to develop anything resembling a client. Twitter has also proved to be spectacularly bad at building clients themselves. I haven't been able to stand any of the many iterations of their web site and their best client efforts were just bought from the 3rd party developer community and then mangled.
Twitter should seriously consider just shutting down their API to third party developers and restrict it entirely to their clients and widgets.
It would be a lot more intellectually honest thing to do versus just slowly and continuously stangling their developer community in their quest for revenue. If they just shut off the API then everyone would get the kick in the pants they need to move on to something new.
The Internet community desperately needs to figure out a way to build an open message bus + identity system + open API + server farm + spam killers using a foundation along the lines of Wikipedia.
Letting one for profit company control the Internet's message bus has proven to be a truly horrible idea. Going back to RSS and a totally decentralized system not good either.
Twitter should seriously consider just shutting down their API to third party developers and restrict it entirely to their clients and widgets.
It would be a lot more intellectually honest thing to do versus just slowly and continuously stangling their developer community in their quest for revenue. If they just shut off the API then everyone would get the kick in the pants they need to move on to something new.
The Internet community desperately needs to figure out a way to build an open message bus + identity system + open API + server farm + spam killers using a foundation along the lines of Wikipedia.
Letting one for profit company control the Internet's message bus has proven to be a truly horrible idea. Going back to RSS and a totally decentralized system not good either.
This is why open source triumphs in platform spaces: if your business relies on another company's intellectual property it can be destroyed at any time.
Sad and disheartening. As someone who also hacks together the occasional twitter app/hybrid, I wonder if this sentiment is widespread/growing?
What Twitter is doing is extremely damaging to developers and the perception of APIs. But let's not bundle all APIs as terrible. The Twilio's, Stripe's and other progressive APIs know how to treat devs and respect them. We just need to make sure we are equally vocal about the good and the bad in the space.
The difference between Twitter and Twilio or Stripe is that Twitter has a product that exists outside their API. In the case of Stripe or Twilio their API is their product, the dynamic between developers and the Twitter vs. Twilio is going to be far different.
Agreed, but this distinction isn't made when bashing API opportunities. The haters on this thread and others state developers are fools for depending on APIs...not just APIs who have products that exist outside their APIs.
If you base your app on 3rd party APIs, and charge users for using your app, don't you have any liability in case the API shuts you off?
Would a TOS clause with something like "We will not be held responsible if our service providers cease to function. Also no refunds." give any protection?
A company you did not pay and do not help generate revenue (doesn't one of them actually reduce ad impressions?) arbitrarily disconnected you from using their server resources? Crazy talk...
> do not help generate revenue
That isn't true. API apps drive engagement which helps retention to grow their platform.
That isn't true. API apps drive engagement which helps retention to grow their platform.
[deleted]
That is a horrible domain name. It's almost as bad as Experts Exchange before they hyphenated it...
While you're at it, never commit your data to any proprietary application.
There, that's what 40 years taught me.
There, that's what 40 years taught me.
Not to mention the insanely low rate limits...
Twitter gained a lot of popularity on the back of a vibrant third party ecosystem. Now that they're established, it seems that the have deemed those same third party developers a threat and have turned on them. Just another example of why basing your company on someone else's platform is a bad idea.
The problem is: will we have real APIs in the future? because these APIs are a kind of scam.
Perhaps they should be renamed to SPI - Service Programming Interface.
An API somewhat gives the impression of a programming interface that will execute valid instructions unconditionally and reliably. An SPI is different because it can fail, not because of a technical error, but because a human, for grins or otherwise, decided to cause the failure.
An API somewhat gives the impression of a programming interface that will execute valid instructions unconditionally and reliably. An SPI is different because it can fail, not because of a technical error, but because a human, for grins or otherwise, decided to cause the failure.
I think the definition of an "API" should be "can I, if necessary, replace it with my own implementation of the same thing?" If it isn't subject to the Liskov substitution principle it's something different.
And as a side note, I'm not berating the guy for doing it. It's just another cautionary tale.
No worries, I don't feel berated. These were hobby projects that people found useful, I have a full-time startup that gets the majority of my attention. So yes, making sure I share yet another cautionary tale. If you read Cappy's comment on my blog there's another excellent cautionary tale in there re FB
>Moral of the story: be-wary of developing applications with dependency to a platform.
I've come to the conclusion that this belongs in the category of "Make regular backups" and "Use unique passwords and a password manager".
Everyone knows they should, and yet so many people refuse to accept that it could happen to them. I don't know if it's hubris or arrogance. How many times has this lesson been displayed in the last week on HN, let alone the last 4 years. iOS, LinkedIn, Craigslist, Twitter, often Facebook.
Not me! My app is too {small, unique, creative} to be a problem.
I've come to the conclusion that this belongs in the category of "Make regular backups" and "Use unique passwords and a password manager".
Everyone knows they should, and yet so many people refuse to accept that it could happen to them. I don't know if it's hubris or arrogance. How many times has this lesson been displayed in the last week on HN, let alone the last 4 years. iOS, LinkedIn, Craigslist, Twitter, often Facebook.
Not me! My app is too {small, unique, creative} to be a problem.
Sort of. Writing a program is usually a fun endeavor. Having the platform owner come and stomp on you, regardless of how much right they have to do it, is still a pretty shitty thing to do.
To be fair, if your application revolves around producing a tweetspam-filtered copy of Twitter's stream of tweets, it's not really possible to make that twitter-independent. Competitors like facebook and google+ don't really have a spam problem.
You list Facebook as being an equal problem for developers. I remember seeing articles on the other four companies you list, but not Facebook. Did I miss something? Honest question: what did I miss?
Either people are stupid, or despite a few publicized cases of apps getting shut down, the benefit of being able to build on someone else's API outweighs the risk. It's probably a bit of both.
The problem is that good data is often tightly locked up.
Exactly the reason why I am so paranoid about third party APIs. I even asked this over a HN post here but did not get much response.
http://news.ycombinator.com/item?id=4162370
http://news.ycombinator.com/item?id=4162370
i'm done developing for SHINE
Seriously.
This isn't new eg [1].
Also, I don't really buy into the argument that these third-party providers is what made Twitter popular. IMHO Twitter made Twitter popular and the devs just followed the money.
[1]: http://gigaom.com/2011/06/07/fred-wilson-to-devs-expect-plat...