The most interesting and alarming acquisition in the WebRTC space yet?
It seems like The Verge spilled the beans: AddLive got acquired by Snapchat. Not many details are provided, but we can assume that AddLive made money out of this transaction.
Today, AddLive’s blog added the following entry:
We are very happy to announce that AddLive is joining Snapchat.
While we have no immediate plans to add new customers to the platform, we intend to continue providing our ongoing video chat services to some of the most innovative companies in the world.
Our special thanks go out to all our early customers and everyone who has helped us along the way. We look forward to continuing our journey with Snapchat.
So… Snapchat snapped AddLive and now all I can do is chat about it?
If you don’t know AddLive, it is one of the WebRTC API Platforms. Developers go to AddLive to build their service, and AddLive provides them the tools they need. I did an interview with Kavan Seggie, CEO of AddLive, about a year ago. It will give you some idea what AddLive is all about.
While The Verge talks about a silent acquisition made months ago, it doesn’t fit with the realities of AddLive’s business and actions. The more likely story is that Snapchat was a customer of AddLive, and now that it released its own video chat feature, it decided to acquire the service outright – something that was concluded as recent as last week.
What’s interesting here is that this is a service company (ephemeral messaging in a way) purchasing a WebRTC API Platform. Snapchat isn’t just using it, or taking out of the market another service. It decided on an outright acquisition, preferring to own the technology and the people behind it, than to use them as a supplier.
Some things to note:
- While WebRTC is challenging, AddLive were able to build a VERY successful platform with a team of 8
- AddLive isn’t taking in new customers, but continues to support the existing ones. This is probably due to ongoing contracts and obligations it has – ones it will probably not renew when the time comes
- If AddLive continues working independently of Snapchat for other customers, will it still be as attractive to new customers as it were just two weeks ago?
- Unrelated but equally interesting – Snapchat is using AddLive and its WebRTC video calling service in its recently introduced real-time video capabilities. WebRTC is real and it is here now
This acquisition has me worried and happy at the same time.
Happy because AddLive deserve this. They have a top notch platform – talking to their existing customers in the past as well as researching them for my WebRTC API Platform report made that clear.
That said, this is a talent and infrastructure acquisition. Snapchat has no need for AddLive’s customer base and business models – these are not going to last.
I am worried because this places the WebRTC API Platform niche as well as the whole WebRTC ecosystem in turmoil. It might indicate we are taking the route of the BaaS platforms. When StackMob, a BaaS player, was acquired by PayPal, Nancy Gohring wrote this post titled PayPal’s StackMob acquisition should serve as a warning signal on CITEworld:
PayPal became the latest big name to get into backend-as-a-service with its announcement that it has acquired StackMob. While these acquisitions lend legitimacy to the BaaS market, they should also make BaaS customers think hard about which provider they choose.
PayPal didn’t take long to take StackMob off the market – 2 months:
This morning, StackMob’s founder Ty Amell announced that the backend as a service offering will be shut down. PayPal acquired StackMob in mid December. It’s one of several backend-as-a-service (BaaS) offerings, which help companies develop mobile apps more quickly and cheaply by providing certain services in the cloud.
The move should encourage BaaS customers to think about their choice of providers, because it’s clear consolidation is underway in this market. That means some services are bound to shut down. While most providers will offer a way for users to export their data, the process of moving an app to another service won’t be easy.
My gut feeling? AddLive will go the same route. Once existing contracts are over, AddLive’s won’t renew them and the service will be closed. This will leave customers with the need to select another WebRTC API Platform to use.
This turmoil will definitely affect the selection process developers will be making when selecting a WebRTC API Platform.
For a more positive note, check out Chris Kranky’s take on Snapchat’s acquisition.
Why is this important?
This has ramifications beyond Snapchat, AddLive and AddLive’s immediate customers.
- The large WebRTC API Platform players, such as Twilio and TokBox should be happy: a new customer will likely opt for an established and deep-pocketed platform vendor instead of a small player that might be acquired and taken off the grid in a heartbeat
- The smaller WebRTC API Platform players, those focusing on growing and attracting customers: they are going to find it harder now to onboard new customers, as these will think twice before using a platform that is up for sale
- At the same time, the smaller vendors who have proven technology with known customer wins: they can prep themselves to get acquired. Snapchat probably isn’t the only one shopping around for such a technology
Note: If you have purchased a copy of my Choosing a WebrRTC API Platform report, you will receive a longer form document explaining the ramifications of this latest development on this space.
Hi Tsahi, another thought provoking article. It is great to see Kavan and the team win.
I disagree that Twillio and TokBox should automatically be the next choice. They hold the same risks as AddLive. They are API companies. Even very large companies choose to shut down programs or services that aren’t profitable or no longer fit their world view.
Using a PaaS, an API or closed source software, involves a risk. You are trading off lower cost, convenience and time to market against an increased risk that a critical piece of your system becomes unavailable. If your project is important you should not take this risk. Period.
As a developer, to control and properly protect your projects, you need to be more responsible and ensure you control the critical software components.
EasyRTC, our open source WebRTC platform, includes a lightweight signalling server and you can use the RFC 5766 TURN server (also open source) as well as the EasyRTC client side APIs.
Use EasyRTC or any other open source WebRTC platform and you will control of the code base your system is dependant on. You will be able to continue to operate in case of corporate shutdown, buyout or outage.
Doug,
While I understand this way of thinking, I can’t say that everyone will agree with it. Using hosted API based platform can be good for many. This is why Twilio is so big these days and AWS is a lot bigger still.
These platforms has a major role to play in our small industry and the WebRTC space – it is now just a little bit harder to make a decision.
I get the growth of APIs. We programmers tend to be lazy…
Doing a prototype or proof of concept with a WebRTC API is fine, but you should be aware of the inherent risk of this slippery slope. There is vendor lock-in with APIs, they may say open this or that but they are really portals to a closed source service. Once you go down the path with writing to an API you have to rewrite that code to retreat. Since coding is where the bulk of the time and money will be spent on software projects why not make a choice to spend an extra half hour up front to protect your project in the long run by using open source.
I do think using AWS or any other hosting service is different than using an API. Your application code doesn’t have to change to switch to another hosting service.
Doug,
Using AWS to its fullest means using AWS APIs.
Just using it for hosting still has its own perks that can be considered as vendor lock-in – it just tends to be “nicer” to those who need to approve it in management levels.
I’ve had my share of decisions this past year in my part time employer where vendor lock-in was raised. It happens with proprietary solutions, APIs, virtualization, cloud services and open source. The flavor is different – the result is similar.
Cloud is here to stay. Smart companies will know how to make use of it properly, which at times will mean using a 3rd party API and at other times will mean relying on open source and self development only.
Hi Doug and Tsahi
My point of view is that it raises rather the question of contracts, terms of use, etc. when going to a cloud API.
With some exceptions, most of the API vendors you mention in your report are either startups or small sized companies. We all struggle to get customers and evangelize around WebRTC, to have customers to understand how it will bring them competitive advantages on their activities.
Addlive, although it had a nice client list, was not in a dominant position on the market, so there will be no “industrial disaster” harming the whole API providers because some customers are “stuck” with their choice.
Also, entering into business with any startup in any technology takes always some risk. And choosing the best technology isn’t always the only factor.
When negotiating contracts with larger customer companies, these startups are not really in a dominant position. This means that procurement can perfectly include terms like holding in escrow code in case the startup goes bust, or in case it’s acquired, a certain amount of money to move to another vendor, or the obligation of continuing the service for a certain period of time.
I agree with your analysis on most points, but I think it’s rather good news for Addlive customers (other than Snapchat) that their vendor grows. They can either stay for some time or as you write, there is no vacuum in tech, they will move elsewhere to another vendor. Which will be good news for other vendors.
As a conclusion, I would say, that choosing a technology holds always risk. But for me the biggest one is that the technology offer of the chosen company doesn’t evolve. Legal aspects can always be solved 🙂
Luis,
As much as I like to disagree and get a conversation going with people, you make great points. And it is true – it all boils down to risks we take as customers and developers, and balancing them out with our objectives.
It’s important to note that the offering from Addlive was head-and-shoulders above WebRTC default. There are no competitors that offered their smooth baked-in support for non-webrtc browsers, firewall and proxy bypass capabilities and OpenTok has only relatively recently provided a multiplexer/relay.
If this analysis is correct and Addlive cease to provide their services to customers, it’s a serious loss – there’s no replacement for what they do, certainly not from the bulk of the WebRTC players who seem to think signalling is all you need.
Richard,
The great thing about tech is that there is no vacuum. Other vendors will come to fill in the gap. I’d also say that there are a few who offer comparative service, though they are less familiar. My report covers these players and what they provide – something I found surprising myself when I researched the topic.