Overly Restrictive API Policies Kill Innovation

In recent years, there has been a growing trend of companies initially providing public APIs and an open platform, only to enact API restrictions or even close access to the platform later on. This pattern has become rather commonplace among social networking service providers. Facebook, Google, Twitter and LinkedIn have all made changes to their API terms of service in recent years, limiting access to their platforms in varying degrees.

This trend of closing platforms and restricting API access has led to the monoculture of the predominant social networking platforms where innovation has begun to decline or perhaps has even disappeared. The lack of innovation among the major social networking platforms has become increasingly apparent; breakout applications are few and far between, and the platforms have begun to look almost exactly the same.

View Interactive Timeline on CodePen: Timeline highlights Twitter company milestones, some of the events surrounding Twitter API changes, and responses to those changes from developers and leaders in the API industry. Powered by Knight Lab TimelineJS.

While Facebook was the first company to go from an open platform to a not-so-open platform, the other social networking companies have followed suit. The Facebook platform was launched back in May 2007 as an open platform, allowing developers to build Facebook-driven third-party apps. Within a year of the launch, the company began restricting access to the platform and reducing the use of Facebook APIs by developers.

Google has retired quite a few web services and APIs in recent years, beginning with the "spring cleaning" for some of its APIs in June 2011 and followed by "a second spring of cleaning" in March 2013. In addition, Google has recently announced that it will shut down Orkut on Sept. 30.

Twitter launched the Twitter API in September 2006, opening the platform to developers, which helped to build a large ecosystem of innovative third-party, Twitter-driven applications. In March 2011, the company began to restrict the types of applications that developers could build with the Twitter platform. In August 2012, Twitter announced that changes would be coming with the Twitter API version 1.1, which included new strict API terms of use, display requirements and API tokens limits.

In July 2013, LinkedIn followed in Twitter's footsteps and began to restrict access to the LinkedIn API. On Nov. 4, LinkedIn announced that it would implement "vetted API access." New applications that would like access to the LinkedIn People Search and Jobs APIs need to submit an application requesting access and must pass review by LinkedIn. Sarah Perez wrote about the changes in a TechCrunch article published last year:

The API changes LinkedIn is implementing speak to a larger trend among today’s Internet players — services offer open APIs to third-party developers as they grow, and later start clamping down after achieving significant scale. We’ve seen this same story play out time and time again, with companies like Facebook and Twitter, and now LinkedIn.

While there can be many reasons for a company deciding to restrict or even close programmatic access to its platform, there are very few cases where the decision is not based on monetization. Back in August 2012, Bottlenose CEO and co-founder Nova Spivack wrote an article about the "Changes coming in Version 1.1 of the Twitter API" announcement. The article describes two monetization models for an open Twitter API, making the case that opening an API allows for greater monetization than closing an API. In the article, Spivack writes:

Forget about what’s right for developers or whether Twitter is evil or not. It also doesn’t really matter whether Twitter’s apps are better or worse than third-party apps. “All that matters is the money” (to quote Shark Tank). And the money says, closing the APIs is sub-optimal. You can make more money by opening them with a good monetization model.

There seems to be a notion that by reducing or eliminating third-party applications, the number of users of official clients and third-party applications will increase by default, allowing for increased monetization. However, the opposite is true. An open platform with APIs allowing developers to build third-party applications will allow for greater monetization. An open platform means more users, more advertising and more money. Spivack writes in the article that:

... what worries me is that they [Twitter] might be missing the value of the long tail here. Instead of shutting down third-party clients and trying to own all the consumer eyeballs, Twitter can make far more money leveraging them into a larger surface area that they control and monetize.

Last month, ProgrammableWeb published an article about how to build engaging applications with social networking APIs. The article features APIs and tools provided by Facebook, Foursquare, Google+, LinkedIn, Pinterest and Twitter. The article also features examples of websites and third-party applications built using those social networking APIs.

While researching the article, it became clear that the number of innovative applications built with social networking APIs has been drastically reduced. Social networking APIs can still be used to create engaging applications. However, many of the applications built with social networking APIs incorporate the same functionality and features. Developers must adhere to each social networking company's API rules, terms of use and display requirements. In some cases, the API terms of use are so restrictive that lack of innovation when it comes to platform-driven applications is all but ensured.

Without a robust ecosystem of third-party application developers, the monoculture of social networking platforms will continue, fostering a lack of innovation and user choice.

About the author:Janet Wagner
is a data journalist and full stack developer based in Toledo, Ohio. Her focus revolves around APIs, data visualization, machine learning, and data-driven journalism. Follow her on Twitter: @webcodepro, Google+, or send her an email.