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?

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.

Topics:

  • http://twitter.com/qriz Christian Nord

    This reminds me of the model that most operators are still using. If you build a service on top of SMS the operator always gets a cut based on the fact that you as a user will have to cover the basic transmission cost for the text message. At the same time. API:s are important and companies will have to think hard about how they want the economics to function around their API and what type of eco-system they are looking to build.

  • http://www.tagbento.com/ @stephenhau

    “What if Twitter took a flat 30% of that channel? You could probably live with that and structure your company around it.”Like offering a magazine through AppStore…”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?”…then seliing subscriptions that bypass Apple's payment mechanism (& their 30% cut), leading to Apple banning the app…”It’s certainly negotiable, but the boundaries are not clear.”… And that's what they did – not great PR for Apple because once again, they threw their toys out of the pram, but being such a darling baby, we'll overlook that incident.I think it all stems from a fledgling symbiotic relationship where both parties need each other to grow, and they don't know at the outset what amazing (or otherwise) things the other party might come up with. It's lean growth – it avoids wasting time drawing up exhaustive terms and conditions for what *might* happen, and instead focuses on what matters: product development.The grief comes when the host starts to formulate T&Cs based on what clients are doing, and likely they're reasonable measures taken to prevent abuse of the host and to maintain service levels.In a co-dependent relationship like that, there's no easy way to introduce change – be prepared to deal with change, or stay out of dependency in the first place.

  • http://borasky-research.net/2011/01/13/project-kipling-alpha-test-is-now-in-suse-studio-ddj-datajourno/ znmeb

    I don't see a dilemma here that's unique to Twitter. You build a business upon some assumptions. If the assumptions change, you either change to respond to them or you shut your business down. It's a bit like trading – you cut your losses *fast* and you let your winners run as long as possible.Business is about forging win-win partnerships. If there isn't a win for the developer *and* a win for Twitter, there is no partnership. Do I think Twitter is making the right choices? In some cases, no. For example, I think their decision to partner with third parties like Gnip and Datasift to “mark up” data / analytics is wrong – I think they could and should build those capabilities in-house and sell them directly. But in the “Twitter client” space, I think they've made the correct decision – use vigorous enforcement of trademarks and standards to guarantee a quality user experience for millions of end users. They *must* protect their brand or they will die a horrible and painful death, much like MySpace.

  • http://twitter.com/kullar pardeep kullar

    I agree that it is not just unique to Twitter and, as I stated, every developing and established startup has to think through the same issues. That said, there is something unique to technology companies and API's that requires different rules. You mentioned 'trading' and cutting losses but with technology companies, we are not talking about cutting losses on a bet you made a week ago but potentially dropping up to 18 months work put in by an entire team of people. Twitter did not discourage the use of its API and many startups grew rapidly using it, therefore giving the green light to many others. What happens now that they've backtracked on this? What is every other startup building on the Foursquare, Gowalla or a dozen other API's thinking? It is very difficult to go 'all in' on a project where in 18 months, the owner of the API could change the rules because you have no relationship beyond hope.

blog comments powered by Disqus