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.
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.