On Platforms, Twitter and the value of a Contract

Twitter’s new rate limit updates this week have again fueled concern and anger amongst developers (and in some cases even twitter users). The reactions pretty much fall into two categories:

  • “What do people expect – they got a free ride and now the gravy is running out”.

  • “Twitter is evil – nobody should trust it in the first place”.

On that in particular stands out is Andrew Phelps’ post at Niemanlab (A good read – go check it out) which points out the real impact the changes could have. You know things are serious (or at least seriously confused) when Twitter has issue assurances like this:

Reading the Twitter post the update may actually make life better for some applications – but this is somewhat lost in communication (Anil Dash has a great take). As Andrew points out – the really worrying thing is above all the changes still create uncertainty – the rate limits are clear, but which apps fall into which category? who should be worried?

In our view however what is really missing here is blindingly obvious:

A Contract

For all the APIs we manage at 3scale, we encourage customers to set up terms and service which define when and how the service can be used as well as make statements about availability (you can find some things we commonly see in API ToS in this programmableweb post – but there are other good resources out there). For any business that wants third parties to invest in building on it’s platform (since this is truly what it is), a contract those third parties can believe in is crucial – that goes for any service delivered anywhere, not just APIs.

For many APIs, there is a very real business agreement which is created when a third party (or customer) engages with the API and this sets the foundation for future use – the rules of the game. This is the essence of a viable platform (and a viable API).

In Twitter’s case, the “contract” is the Terms of Service page developers click through on joining the program – this sets the rules and as is the case for many “public” free services they contain a line:

Twitter may also terminate any licenses hereunder for any reason

and other disclaimers allow Twitter to discontinue the service at any time, for any reason. This is standard practice for public open properties and clearly means there is no legal recourse for changes which might affect businesses building on the platform. Most company laywers would demand the same in a similar situation.

Much of the public angst stems arguably though, not from the contract captured in the terms of service, but a another implicit “contract for the social good” – which is people’s perception of twitter as a public utility for “fair use” of certain types by anybody. This clearly creates a conflict with the need for Twitter to figure out how to support its service. The implicit social contract is part of Twitter’s brand image – but it is not legal fact.

The lessons in this are:

  • If you are building a platform on which you wish to support 3rd parties – make your commitments to those third parties clear. The more guarantees you can give, the more confident your partners will be in building on your infrastructure.

  • If you are unwilling to give those guarantees you should probably make this repeatedly and loudly visible – implying stability without actually delivering it is very likely to lead to problems later on down the line.

  • Occasional blog posts about what “might be ok” are likely to cause mistrust and confusion – be clear, offer a “contract” or not. Also, if public perception of your service is out of sync with what you actually are willing to guarantee – which is arguably what has happened to Twitter even if through no fault of its own.

Arguably the idea of giving guarantees applies to public free platforms like Twitter also, it would seem highly beneficial for Twitter to actually split service access into multiple tiers with clear rules:

  • Public use with low limits and no guarantees longer than a 6 month time frame.

  • Higher limits, stronger guarantees and a much longer time frame of guaranteed validity of terms for higher volume approved apps.

  • Perhaps these higher levels of services could even have a cost – and hence offer a revenue stream.

To an extent it seems Twitter is moving this way with its requirement that high volume apps register – this creates the ability to actually create a real business relationship. Rather than complain about this (which some people have) it is arguably a step in the same direction for more dialogue with the ecosystem. This stability will likely be critical for apps like Storify etc. al. – without these guarantees their founders will likely go elsewhere or not bother to build at all.

Dalton Caldwell’s much discussed App.net initiative is partly in direct reaction to the Twitter API changes – arguing that Twitter’s free monetisation model means it will never offer enough stability of service. However, it seems that these choices are in fact orthogonal – better guarantees offer more confidence in the platform, traded off against future flexibility – those choices simply need to be made and the rules of the game written clearly.

A proper service contract makes all the difference.