The dilemma that Twitter has given new startups

A fundamental problem between third-party Twitter clients and Twitter itself is that the client owns its own interface and Twitter has to negotiate with that client to make money from its own users. This is a difficult situation for Twitter to find itself in, especially when it so badly needs those third parties, who help it to retain existing users and bring new ones in.

The situation could be worse. What if a third-party client was also capturing user email addresses on the side and porting users over to its own service over time under its own brand? It’s possible the third party could redefine that product as something new and different from the original and take that user base away. 160 characters anyone?

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":254921,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,mobile,social,","session":"C"}']

This may be why Twitter has stopped third-party developers creating new full-service clients and wants them to build helpful add-ons instead. However, what if you, as a third party, then build a helpful add-on that becomes lucrative and Twitter decides it wants that revenue channel? Do you hope that Twitter does a deal with you? What if Twitter took a flat 30% of that channel? You could probably live with that and structure your company around it. But what happens if you develop an additional source of revenue that is a bi-product of your relationship with the Twitterverse but can be defined as a separate product? Does Twitter also get 30% of that? It’s certainly negotiable, but the boundaries are not clear. Many questions arise, and I haven’t even mentioned the potential for financial wizardry in seemingly reducing profits by defining them as expenses.

This isn’t just a problem for Twitter-related startups but for all established and developing startups. Even within Facebook and Zynga’s successful union there have been troubled times, as entrepreneur and investor Chris Dixon described in a recent blog post. Entrepreneur Steve Klabnik, one of the people impacted by Twitter’s decision to put a stop to full-service clients, stated, “Any software that’s owned by one entity, corporate or not, is open to the possibility of being abused.” Steve and friends have had to pivot their business and instead create http://rstat.us/, which clones the basic functionality of Twitter.

As a new startup looking at this situation, you wonder what to do. Twitter was the lantern bearer for API development, and everybody jumped in. Many have now got burned. We take a risk building on someone else’s API, but we also need to define the rules for our own services. No-one wants to turn around to a developer in the future and say, “We are going to build a competing service to you. Thanks for bringing us lots of users and giving us a great interface to copy but … you are not one of us, bye. P.S. we are also cutting your API calls per user from 100 to 1.”

The API game has only just begun, the rules are not well defined and we are likely to see a great deal of evolution and maybe even a re-defining or merging of company balance sheets. Twitter as a larger organization cannot match the zeal of entrepreneurial third-party developers, but it could define the relationship however it wants. For example, by default, everyone building on its API has to be in joint venture agreement with open accounting. Twitter then also has the right to sit on the board of that company if it chooses and can include special buy-out clauses.

Other companies, such as Apple, have chosen to impose a flat 30% fee on API users. It has an established model of commoditized apps with a built-in payment system; however, this not yet a standard model across all companies and, for some, this is not yet possible.

The relationship when it comes to software, between a third-party developer and the API owner is unusual and the answer to the problem may also be unusual. Either way, any such answer would make things a lot more comfortable for both sides to get on with their work.

Pardeep Kullar is co-founder of LikeOurselves.com. He graduated from the London School of Economics to pursue a career in technology. He has worked as a developer, an analyst and finally gave up such comfortable roles to go on the startup warpath with LikeOurselves in 2009, to his everlasting regret.