For the past few years, developers and tech companies have tried to find the right balance in their partnership strategies. From completely open and free API to closed and carefully selected partnerships, the choice is not easy. So how does one find the right solution for a win-win deal between companies and developers?
Before going further, let’s go back to the basics. An Application Program Interface (API) is a piece of code that allows two applications to communicate and exchange data. Mostly, they are used to develop new applications using existing piece of software. The most commonly used example is Google Maps API that allows developers to integrate its basic features (maps, geolocalisation, Street View…) in their applications. A handful of applications, like the famous Uber, were developed thanks to this API.
So, is there a magical way to give access to your data and code to third party partners without harming your business?
This summer, the French transportation company, SNCF, announced a 5-year plan to kick off its digital transformation. Among other projects, it planned to revamp its APIs and unify its partnership program. Even though, the project was called “Open Data”, one of the major changes was to limit the access to its data by charging third party developers after a certain number of requests. What it means is that if you want to create an incremental business with SNCF’s data you need to pay your share. According to Yves Tyrode, head of digital at SNCF, this was implemented to highlight the value of their data and make sure that big comparison websites (Google, Kayak…) don’t take advantage of it.
While the French were working on a way to protect their data without killing innovation that could have economic fallout, the Google owned company, Nest was developing their brand new “Works with Nest” program. As a reminder, Nest is an IoT company that creates connected devices that help you manage your house.
What Nest released on October the 1rst, is a broader third party program that open its Weave communication protocol (used to make Nest products exchange information without Wi-Fi). This will allow the creation of a unique ecosystem with other IoT products. According to TheNextWeb, several companies are really interested in this new program, such as Phillips Hue and General Electric.
Behind these 2 different strategies, only one question lies: will my partnership program bring value to my business?
Indeed, put yourself in SNCF’s shoes, does giving big comparison websites like Kayak or Google free access to your data bring new users? Maybe not. They might as well get some money out of it. At the same time, by choosing a freemium economic model for their API, they support innovating startups by giving them a free access to the data. And these startups are the ones adding value to their services. Just like what Nest is trying to do with its API, the idea behind it, is to favor the creation of a virtuous ecosystem.
Building a healthy relationship with third party developers is essential, even for the developers themselves. The survival of their applications relies on the existence of the API. It is in their best interests that those partnership programs are favorable for both parties. TheNextWeb even gave them basic rules to ensure fruitful relationships:
“Thou shalt not freeload”
“Thou shalt not forego talking to a person”
“Thou shalt monitor everything”
Basically, if you want to use an API, be respectful and create a real relationship.
On a more serious note, completely opened APIs are going scarcer mainly because business is still business. In our data-driven world, your data is a treasure you must cherish and protect. And they tend to be more valuable than any software. Even Google is open sourcing TensorFlow, its state-of-the-art machine learning software for pictures.
We see a new trend arising from these strategies; the value is slowly shifting from software and pieces of code to the way you exploit them and the data we use to do so.
So now you know what you have to do, protect your data and open your protocols.