6 Ways Vendors Sell WebRTC Developer Tools

How can you make a living from WebRTC? You offer WebRTC developer tools.

One of the interesting questions is around monetizing WebRTC. The truth is, it is hard to monetize a concept, or a piece of technology. Kranky said it well over 3 years ago – WebRTC Market Size (is 0).

What does this mean? That you can either make money by selling tools to developers who need WebRTC. Or you make money by offering a service that makes use of WebRTC, but we can now debate if that’s WebRTC or not.

Anything that isn’t WebRTC developer tools talls into other market niches – healthcare, education, gaming, … all these compete and create business far from the WebRTC core itself.

WebRTC developer tools though – that’s where a small WebRTC market niche exist. And there are several ways to make money in this market. Here are 6 different types of services you can offer to sell WebRTC to developers – some will offer multiple services.

#1 – Sell a Managed Service (SaaS)

You can sell a managed service.

Find something that developers need.

Create a service that offers that solution.

Sell it in XaaS model.

• We do it at testRTC for testing and monitoring WebRTC services.
• Callstats.io does that for monitoring.
• XirSys and a few others offer a managed service for NAT Traversal (=someone else hosts the TURN and STUN servers that your application uses)
• Others offer a customized hosted offering
• And then there are CPaaS vendors. Many of them offering WebRTC as well (check out this report on WebRTC CPaaS)

This market is rather challenging, as the name of the game is scale, and getting there is hard. For some reason, this is also where most customers end up penny pinchin.

#2 – License Software

You can develop a product that others need and offer it under a commercial license.

There are those who want or need to run their own service, not relying on managed services. And at times, they are happy to pay for a commercial license that comes with an SLA and someone you can shout at and threaten.

The best thing about most commercially licensed software is that the people behind it work on that software. And once they have paying customers, they are bound by contracts to support and maintain it, usually for long periods of time.

In this category, you can find companies such as Dialogic, Frozen Mountain and SwitchRTC.

#3 – Support and Customization of Open Source

Open Source doesn’t mean free.

People need to be able to make money out of their work – even if they are idealists who are just contributing to the community as a whole.

The way to go about doing that is by writing software that then gets distributed freely under an open source license. This allows anyone to take that software, use it, modify it and even try and contribute back to it and improve upon it.

For popular open source projects, this creates a nice feedback loop that everyone enjoys. For the most obscure projects, it remains the work of a single maintainer.

So how can someone make a living out of open source? By offering one of three different alternatives (usually a mix of them):

1. Support contracts – if you’re the owner and main maintainer of the open source, then you can sell support contracts. Those who use your open source project may have questions, and giving them priority support can be an income source. For companies, having support available on the open source projects they use can be an important aspect of choosing one open source project over another
2. Customization work – copmanies who adopt open source projects sometimes need modifications to these projects. They can attempt to do it on their own, or they can just have the main maintainer of the project do it for them at a price
3. Commercial license – LGPL, GPL, AGPL and other open source licenses are often considered as cancerous licenses for commercial products. The reason for that is that they “contaminate” the code written around them forcing their license terms on that code as well. There are other open source licenses that are more tolerable to companies (more about it here). Which is why in many cases, a company would prefer paying to get a commercial license instead of using the free open source licenses of a project. Dual licensing is another way of making a living

Jitsi, for example, was distributed under an LGPL license. This allowed the team behind it to make a living through all 3 approaches: support contracts, customization work and offering commercial licenses. After its acquisition by Atlassian, it switched from LGPL to a more lenient APL license. The main reason? Atlassian had other objectives for Jitsi and they weren’t about deriving direct monetary value from it. The Jitsi team no longer offers paid support or customization – it doesn’t mean they don’t support the code base, it just means that you can’t pay them for priority support.

Kurento got acquired by Twilio. Naevatec, the company behind Kurento made most of its direct revenue from Kurento by offering support and customization work. After the acquisition, Naevatec was left without its engineers that were experienced with Kurento and has since been struggling to maintain the Kurento codebase.

Janus is still an open source project. The company behind it offers support and customization work if someone needs it.

To be able to make a living out of an open source project, it needs to be one that is mission critical to the companies who use it, and it needs to be popular enough. If you plan on taking that route, remember that maintaining such a project can make you proud at the number of companies that end up adopting it, but may well frustrate you if you look at how many of these companies won’t be willing to pay for it at all.

#4 – Conduct Analysis

This is something I wasn’t aware of up until several months ago.

There’s this interesting market niche in WebRTC, and I am not sure how prevalent it is with other technologies.

It is of companies and enterpreneurs who set out building a product with not enough knowledge and experience in WebRTC. They try to learn as they go along, floundering while at it. Many reasons why this happens:

• They are doing it with an itnernal team that doesn’t have the skill set
• They outsourced the project to an open source vendor who knows nothing about WebRTC, but knows how to build a mobile app, a website or even a VoIP service
• They outsource the project but don’t scope it properly, getting a product that isn’t what they really wanted – and then blaming the outsourcing company about it

When this happens, companies start looking for alternatives. And there really are only 4 things to do here:

1. Close shop and go home. Consider this a failure and just move on to other projects
2. Reboot. Look at all of it as sunk costs and start from scratch
3. Fix. Get your team or pay the outsourcing vendor (or other outsourcing vendors) to continue working on the project until it is working
4. Salvage. Get an expert to look at the existing codebase, analyse it, offer his advice and even let him do the fixing

Salvage is somewhat different from fixing, as it focuses on analyzing the whole architecture along with the implementation instead of just diving right in and continuing with the same approach that brought you to where you are in the first place.

And there are companies who offer such packaged services. Look at Blacc Spot Media and WebRTC.ventures for that if this is what you’re after.

#5 – Outsource Your R&D Skills

You’re good with coding and know WebRTC?

Great.

Outsource it to others.

Many of the people who contact me are after developers with WebRTC experience. Some of them want to have these developers work as freelancers. Others want to outsource to a company. Others still are looking to recruit skilled workers, but understand they may end up outsourcing anyway.

There are quite a few companies and individuals who offer their outsourcing services around WebRTC.

The known freelancers who do WebRTC work are usually fully booked. It is hard to get their attention and time for new projects, but it is worth a try.

The outsourcing companies come in different shapes and sizes. Many don’t have the relevant skillset. Some will place inexperienced developers on your project. Some will do the best work for you.

Quality here varies greatly, so you should take the time to pick the right outsourcing vendor to work with.

In many cases, my role in such projects is to assist in deciding on the exact requirements, selecting the outsourcing vendor and “translating” the requirements between the company and the outsourcing vendor.

#6 – Consult

There are those who simply offer consulting (I do that by the way).

Their role is to assist in the thought processes – be it the initial phases of helping in fleshing out the product’s roadmap and differentiation, assisting in the competitive analysis, in writing down the RFPs (or the response to an RFP), selecting vendors, suggesting architecture, etc.

Many of the experienced outsourcing vendors will usually add a consulting component into their service, and their customers will usually benefit from that consulting.

What’s Next?

Looking to start a WebRTC project? Trying to understand how to get that done? Know that the market is dynamic and always changes.

Which is why I am in the process of updating two resources on my site:

1. Choosing a WebRTC API Platform report
   1. If you think a vendor that isn’t in the report needs to be added to it – tell me
   2. If you plan on purchasing this report, then the best time would be from now until the publication of the update (see below)
2. WebRTC Developer Tools Landscape will be updated soon – if you miss vendors here – tell me