His argument doesn't appear to be "don't build", it appears to be "tread cautiously". If your business model depends on filling an obvious hole in someone else's product, you need to be wary of the idea that the first-party will fill that hole. Joel Spolsky outlines this well in the Stack Overflow podcast, though he's usually talking about plug-in ecosystems.
And yes, people making iPhone apps or Facebook apps need to be careful of this. If Facebook decided to build in a friend-ranking feature, the company that makes that Compare People app is hosed. If Apple decides it wants to add ebooks to the iTunes Store, then a lot of iPhone apps are in trouble.
Heck, any recent news about App Store shenanigans should make people nervous about their app existing only with Apple's permission. If Apple doesn't like your app (for any reason), it won't get approved. And if Apple decides to pull your app, you're paying for the refunds (and Apple's keeping it's cut of the sales).
i suppose my point is that building an application based on a website's provided APIs and services shouldn't be considered "filling and obvious hole". if you don't want your developers to do something, tell them not to or disallow them from doing it.
it is of course a company's prerogative to implement new functionality and features, but if you're essentially killing off a large swath of applications that you asked/allowed to be developed, its a bit of a dick move and worthy of at least a little whining. imo.
Using someone's APIs may not be considered "filling an obvious hole", but it's not unreasonable to assume that a website that focuses on extremely short messages is going to be looking into ways to make that limitation less burdensome, and lengthy hyperlinks are an obvious target.
Indeed, anyone using Twitter for more than like 4 tweets is going to realize, "Gee, it's a pain in the ass that the URL in my tweet takes up half the room, I wish I could shorten it". In that light, a URL shortener is an obvious feature for Twitter to implement, since it's so simple (like what, 2 SQL tables and 30 lines of code?). Similarly, something like cut-and-paste was a likely future iPhone feature, so someone spending months designing an app where cut-and-paste was a major feature was all but begging to get steamrollered by Apple.
By contrast, someone who does something like a Twitter match-making service (matching Twitter accounts based on the hashtags or links they tweet) isn't fulfilling an obvious future Twitter feature, and thus is probably safe from being squished by Twitter.
Yes, it is the third party developer's job. It's his job to look at the marketplace for the product he's creating before he spends too much time developing it, and analyze what the current and potential future competition look like. If it's likely you're going to be competing against someone with an insurmountable advantage (the first party), you need to think long and hard about investing resources into that product.
I don't think elegant and innovative is the line here. An idea can be elegant and innovative and something the first party never thought of, but unless it's patentable, you risk first party competition.
Again, I'm not saying first party competition is necessarily death, but it's definitely a challenge.
I kinda figured that you'd sort of shove date/time, link URL, browser info, and referrer in there to collect the data. So it's probably more like 50 lines of code. Whatever.
And yes, people making iPhone apps or Facebook apps need to be careful of this. If Facebook decided to build in a friend-ranking feature, the company that makes that Compare People app is hosed. If Apple decides it wants to add ebooks to the iTunes Store, then a lot of iPhone apps are in trouble.
Heck, any recent news about App Store shenanigans should make people nervous about their app existing only with Apple's permission. If Apple doesn't like your app (for any reason), it won't get approved. And if Apple decides to pull your app, you're paying for the refunds (and Apple's keeping it's cut of the sales).