How Open-Source is Reshaping our Business

Being in the software business for 20+ years, I’ve both feared and admired open-source.  On the one hand, we’ve benefited from it so thoroughly that it’s easy to overlook that we’re standing on ‘shoulders of giants’ every morning from the moment we boot up a Linux VM, to whatever PERL or Python module we’ll download or upgrade during the day.  We’ve made modest contributions along the way, but we’ve never taken the plunge of actually open-sourcing our own wares -- even though, economically and technically, our own customers have benefited from indirectly from them. After all, building our apps around open source has - over the long-term - kept our own customer’s total cost of ownership down, and kept openness and reliability up.  In this post, I’d like to explore an often-overlooked aspect of open-source:  it’s ability to help you close more sales by including an ‘infrastructure call option’ for your prospects.

We’ve never gone “full open-source” ourselves, though, and here are some reasons why:

1. Our software tends to be highly customized to those who use it, namely the large Telco & Cable companies.
2. We have a hard time imagining what a ‘one-size-fits-all’ implementation would look like, even if we did push all the code to Github.  In other words, could we even support an open-source distribution of our (often customized) code?
3. If we could solve #2, we’d still wonder how to make this profitable to us and whether a Dropbox-like “freemium” model would improve our lot in life.

But, here’s the thing we’re finding out.  Embracing open-source doesn’t have to mean doing a ‘git push’ on all your proprietary code, in our case code that deserializes, stores and analyzes Binary Call Detail Records for the telecom industry.   It can also mean embracing this new world where setting up job-based-infrastructure-on-public-clouds becomes an extra line or two of code.  In the old days, a developer would write a ‘source file’ command at script-start to set up environment variables and so on. Today, the first thing you do is spin up a Hadoop, Spark or Apache-Beam cluster, and move on from there.  When you’re done, you terminate the cluster, and move on with your day, often having included the ‘setup and cleanup’ cluster commands within your code itself.

And guess what?  Those tools you’ll use on big-3 cloud providers ?? Most of them are open-source, already pushed out by AWS, Microsoft or, especially, Google Cloud Platform.  We’ve been heavy users of Apache Beam for the past couple of years, and it’s fantastic.  That we choose to run it on GCP’s Dataflow service is almost incidental, since we could (if we were gluttons for punishment) run it on our own servers.  (We’re not in it for the pain, and we decided some time ago that we’d make our mark developing software not installing, cooling and patching servers.)

About a year ago, I had the pleasure of meeting Sam Ramji, who until recently ran GCP’s open-source strategy.  Along with being a really nice guy, I came away a bit amazed at Google’s commitment to open-source. After all, Beam - so much more powerful than anything from the Hadoop-Map-Reduce-world, would still be awesome even if, like BigQuery, it remained a “Google Proprietary” thing.  But, lo and behold, there it is out in the wild -- like Tensorflow -- to be run wherever you want: in your datacenter, on AWS, or - in our case - even in our customers’ datacenter. Their bet is this: More people using the right technology early on benefits everyone and they’re content enough to win ‘infrastructure dollars’ by competing on that.  You’ll still have to run open-source-software somewhere that’s reliable and safe and, like all the cloud vendors, they feel your infrastructure dollars are best spent there.

A smart-software-as-a-service company (a SSASS!) -- even closed source ones like us -- will see the benefit of this approach early on in the sales process:  After all, you can spin up resources to demonstrate your wares without long-term-hardware investments. But, as your opportunities move through the sales funnel, the particulars of your design choices air themselves, and one of a couple things will happen.  

First, it’s possible that your client will only care about the security of their data and the economics afforded them by using whichever cloud-provider you’re already up and running on.  Second, and perhaps more importantly, they’ll want to understand the degree to which they’re signing on to ‘vendor lock-in’ with you. At this stage of the game, they’re wondering things like:

• “If I start to send you a lot of my data, how would I ever ‘unwind’ my relationship with you, if I decide to switch vendors?”
• “If I need enhancements in the future, will these be easy to add?  Will you charge me ludicrous fees for simple things? Could my own staff ever build onto what you’re about to deliver or is technical collaboration out of the question?”
• “Can I start with this in the cloud, and move the whole thing in-house later on?”

At this point, it should be clear that your prospect is not expecting to hear: “No, we sell our closed-source software, run it where we want, and it’s so closed that your tech team will never figure it out, let alone be able to enhance it.”.    And, that’s where the magic of open-source can help even closed-source companies differentiate themselves: by separating out the infrastructure (open-source ‘runners’ in Beam’s case) from their closed-source code.  In our experience, buyers are beginning to think of ‘runners’ the way traders think of a ‘call option’ they may or may not exercise in the future.

To sum up, even if your bread and butter is ‘closed source’, you’ll likely benefit by developing around open-source runners, since the optionality of switching infrastructure later on is valuable to your prospects today. 

Feel free to follow me on Twitter...