One of the wonderful things about starting your own company is the freedom that it gives you. The freedom to set your own policies about flexible working hours and limitless holiday. The freedom to build a remote-first business with staff around the globe. The freedom to bury your head in code all day, every day, if you so choose.
And then you go and hire a marketing director. She makes you write blog posts. She makes you host events. Suddenly, before you know quite how it happened, you’re standing on a stage in Singapore, in front of a roomful of conference delegates, talking to them about APIs.
So you’d better be able to come up with something interesting. Thankfully, in the API world, there’s a tale of theft and intrigue that will chill your very bones. It’s called…
The great API robbery
Once upon a time, companies began creating open source software. Their motivations were noble and communities across the globe benefitted from their efforts. Developers set out along a well-trodden path, with the ultimate goal of creating systems that benefitted people:
In the API world, a ‘winner takes all’ mentality developed. Those with high adoption (and therefore success) rates became the ‘ones to beat,’ setting the standards and the tone of the conversation.
High adoption and success rates deliver plenty of power, but they also hamstring developers in terms of their ability to make changes. As soon as organisations begin adopting your product, your design flexibility tanks. You can’t experiment. You can’t change things. You’re successful, but you have too many third-party dependencies to do much more than tweak things. Suddenly you’re into versioning and expanded teams, with pressure on you to perform and deliver a standardised, stable API, as that’s what your customers are paying for.
When it comes to open source, the same applies in that the leading API is the one that sets the standard. However, it’s also in the public domain. Hence… the great API heist!
The dual-edged sword of success
Let’s look at Redis. Redis is a very popular in-memory store that loads of people use. Redis worked hard to bring their product to the enterprise world, but then along came AWS. AWS forked Redis’ code, built AWS ElastiCache and began selling it to their users as compatible with Redis drivers. Redis’ success essentially led AWS to cut them out of the loop.
Then there’s mongo – and this is where the heist gets really daring. mongoDB is a document store that suffered massively from its own success. Amazon and Azure came along and implemented mongo’s API (its driver protocol), put it in front of their services and began selling those services. They created their own document stores, with global availability and all the other lovely advantages that come with being a tech giant. They launched them as compatible with mongo drivers, but without them running mongoDB – they bypassed mongo entirely.
It gets worse. Let’s look at Oracle America. Oracle America bought Sun Microsystems, who developed the hugely successful Java. Java itself is open source, but Sun owned all the patents around its implementation. Now, it occurred to Oracle that Android was built on Java, but that at no point had anyone paid them for doing that. So Oracle took Google to court, filing for $9 billion in damages. As you do.
The case has now escalated to the Supreme Court, after two District Courts found in favour of Google, then the Federal Circuit Court reversed those decisions. Google’s argument is that it created a clean room implementation of Java. It looked at the Java API and that parts that were patented, then created its own version of the patentable bits. They built and copied an API on top of a proprietary engine, stuck Android on top of it and created a massive infrastructure. What a heist!
Industry implications
The Oracle versus Google case, fundamentally, is about whether you can copyright and patent an API. If the Supreme Court rules in favour of Google, it means that APIs are fair game – that tech giants can swoop in, copy your code and nab your customers. Which sucks.
So, how can you protect your product from interface theft? Well, the key is to ensure that the value proposition of your product doesn’t sit close to the API level. Your API is not your competitive edge – the value you provide to your customers is.
Let’s face it, we’re not all in a position to take Google to court. So your options are:
- Use the data: use the data model of the thing that you create and couple it strongly with what you produce, so if someone does copy it, the interface theft is blatant (providing you with a good legal case).
- Don’t build a skinner box: figure out how to not make your API the product. Build a value proposition on top of that API that is intrinsic to your company. The API is there to deliver value to your customers not because of the API itself but because of what it gives your customers.
The solution? Consider where you’re putting your value. That is how to protect yourself from becoming the next victim in the tale of the great API heist!
