“Open Source” SDK for SaaS and CPaaS are… Meh

26/02/2018

Open Source SDKs from SaaS vendors aren’t interesting.

Every once in awhile, I see a SaaS vendor boasting to have open source SDKs. The assumption is that if you say “open source” on something you are doing it immediately makes the thing free and open. The truth is far from it.

Planning on selecting a CPaaS vendor? Check out this shortlist of CPaaS vendor selection metrics:

Open Source Today

I want to start with an explanation of open source today.

Open source is a way for a vendor or a single developer to share his code with the “community” at large. There are many reasons why a vendor would do such a thing:

  1. To get others in the industry to assist in the effort of building and maintaining that code base (in most cases, such initiatives fail to meet their objective)
  2. To show technical savviness as a company. This is good for the brand’s name and when a company wants to attract top notch developers
  3. To showcase one’s technical abilities. An individual developer can use his github account to attract potential employers and projects
  4. To offer a reference implementation or a helper library for integrating with the company’s application

The above reasons are related to companies with proprietary software that they want protected. What they end up doing, is share modules or parts of their codebase as open source. Usually ones they assume won’t help a competitor copy and compete with them directly.

The other approach, is to use open source as a full fledged business model:

  1. Releasing a project as open source, then offering a non-open source license
  2. Or offering support and an SLA to it
  3. Or offering a hosted version of it
  4. Or offering customization work around it

A good example here is FreeSWITCH. They are offering support and customization work around this popular open source project. And now, there’s SignalWire, an upcoming hosted version of FreeSWITCH.

You see, for a company to employ open source, there needs to be an upside. Philanthropy isn’t a business model for most.

Cloud versus On-premise when Consuming Open Source

SaaS changes the equation a bit.

I tried placing different open source licenses on a kind of a graph, alongside different deployment models. Here’s what I got:

(if you’re interested here’s where to learn more about open source licenses)

CPaaS and SaaS in general are cloud deployments. They enable the company more leeway in the type of open source licenses it can consume. An on-premise type of business better beware of using GPL, whereas a cloud deployment one is just fine using GPL.

This isn’t to say that GPL can’t be used by on premise deployments – just that it complicates things to a point that oftentimes the risks of doing so outweighs the potential reward.

CPaaS / SaaS vendors and Interfaces

On the other end of the equation you’ll find how customers interact with CPaaS vendors.

Towards that goal, the main approach today is by way of an API. And APIs today are almost always defined using REST.

In the illustration above, we have a SaaS or CPaaS vendor exposing a REST API. On top of that API, customers can build their own applications. The vendor wants to make life easier for them, to increase adoption, so he ends up implementing helper libraries. The helper libraries can be official ones or unofficial ones, either created by third parties or the vendor himself. They can just be reference implementations on top of the API, offered as starting points to customers with no real documentation or interface of their own.

For the most part, helper libraries are something I’d expect customers to deploy and run on their servers, to make it easier for them to connect from whatever language and framework they want to use to the vendor’s service.

On a client device, we have SDKs. In some ways, SDKs are just like helper libraries. They connect to the backend REST API, though sometimes they may have a more direct/optimized connection to the platform (proprietary, undocumented WebSocket connection for example).

SDKs is something you’ll find with most of the services where a state machine needs to be maintained on the client side. In the context of most of the things I write here, this includes CPaaS platforms deciding to offer VoIP calling (voice or video) by way of WebRTC or by other means over non-browser implementations. In many of these cases, the developers never actually implement REST calls – they just use the SDK’s interface to get things done.

Which is where the notion of open source SDKs sometimes comes up.

The Open Source SDK

If we’re talking about a SaaS platform, then having the source code of the SDK has its benefits, but none of them relate to “open source”. There’s no ecosystem or adoption at play for the open source code.

The reasons why we’d like to have the source code of an SDK are varied:

  1. Reading the code can give us better understanding of how the service works
  2. Being able to run the code step by step in a debugger makes it easier to troubleshoot stuff
  3. Stack traces are more meaningful in crashes

Here’s the thing though –

Trying to market the SDK as open source is kinda misleading as to what you’re getting out of your end of the deal.

When it comes to CPaaS and WebRTC, there’s this added complexity: vendors will “open source” or give the source code of their JS SDK (because there’s no real alternative today, at least not until WebAssembly becomes commonplace). As for the Android and iOS SDKs, I don’t remember seeing one that is offered in source code form – probably because all vendors are tweaking and modifying the baseline WebRTC code.

SaaS and Open Source

In a way, SaaS has changed the models and uses of open source. When it was first introduced to the world, software was executed on premise only. There was no cloud, and SDKs and frameworks were commercially licensed. If you wanted something done, you either had to license it or build it yourself.

Open source came and changed all that by enabling vendors to build on top of open source code. Vendors came out with business models around dual licensing of code as well as support and customization models.

SaaS vendors today use open source in three different ways:

  1. They use it to build their platform. Due to their model, they are less restricted as to the type of open source licenses they can live with
  2. They open source code modules. Either by forking and sharing modified open source modules they use or by open sourcing specific modules
    1. Mostly because their developers push towards that goal
    2. And because they believe these modules won’t give away any of their competitive advantages
    3. Or to attract potential customers
  3. They may open source their whole platform. Not common, but it does happen. Idea here is to make revenue out of hosting the service at scale and giving away the baseline service for free (think WordPress for example)

 

Planning on selecting a CPaaS vendor? Check out this shortlist of CPaaS vendor selection metrics:

Responses

Gavin Henry says:
February 26, 2018

I’m unsure of your point here?

Reply
    Tsahi Levent-Levi says:
    February 27, 2018

    I am not sure either. I admit the punchline or takeaware here is somewhat hard to find 🙂

    This one is more what my thoughts are around open source these days, and where open source meets businesses and marketers.

    Reply
Anthony Minessale says:
September 21, 2018

Thanks for mentioning FreeSWITCH and SignalWire! We actually agree with this a lot. It part of our core thesis. We think FreeSWITCH is very powerful yet hard to reach for many so we want to make that easier but also, a lot of people are happy digging and C and we love them too. We obviously love open source as we’ve been doing it for over a decade! One of our goals for SignalWire is to balance exposing the power of FreeSWITCH in a scalable way and embrace open source for FreeSWITCH itself and also make open source tools to connect to our cloud hosted offering and bring things all together. I’ve been saying for a while now, stop living in the CPaaST. We think there are cooler more exciting things we can make available with APIs besides triggering boring stuff like SMS and PSTN calls. Balancing open source with business is an essential component so you can support the amazing team it takes to build an amazing product and service!

Reply
    Tsahi Levent-Levi says:
    September 21, 2018

    Anthony,

    I don’t really understand your point here. The end result is similar – isn’t it? To a large extent, SignalWire is CPaaS(T) 🙂

    It might be different in the features and functionality it offers. It might be more complex or simpler. But at the end of the day, it exposes communication APIs in a hosted/managed/aaS manner.

    Am I missing anything?

    Reply
      Anthony Minessale says:
      September 21, 2018

      My point was to thank you for mentioning us, and to agree with you as I feel I have a lot of experience on this topic.

      To answer your new questions:

      You mentioned in your earlier comment you were looking at how open source meets business. Being in a position to comment on this subject, I was pointing out that one of the places where it becomes necessary is the professional simplification and mainstreaming of complex technology.

      Communications has been in the cloud since SIP and H323 made it possible on a grand scale at the turn of the century. No matter where you deploy it, it has to be reachable over the Internet to be of any use especially commercially.

      The current notion of “Cloud Communications” is more about simplification and ease of access than anything else. Current solutions offer a gateway to send communications but not a true infrastructure to develop more meaningful products and services. You still have to do a lot of hard work yourself, not everyone wants that.

      As for differences with SignalWire, that’s subjective but since you asked.

      One of your opening points was said that some vendors offer open source clients and that’s not really a big deal in terms of open source. That’s a fact. Since we provide an open source core communications technology stack I think that’s a significant difference right away.

      I would agree that yes, we expose Communications APIs and that’s a commonality in all SaaS models but if the features and functionality differ I think that’s actually a more significant factor.

      API companies are supposed to be about developers and enabling them to be successful. I feel our history gives us an edge in this category when it comes to providing developers with not only communications APIs but infrastructure and solutions to problems.

      Also as you well know being deep into WebRTC there is a whole new wave of ways to communicate and it will go well beyond making phone calls over PSTN.

      Reply

Comment