Open Source Competitive Moats

6 mins

I’ve recently been thinking about how companies that both produce and consume open source software (OSS) behave in the markets that develop around them. This post examines the incentives on both sides - and considers multiple third sides - to gain advantage from use of OSS in enterprises.

The obvious first order case of advantage is using OSS because it’s free of ongoing license costs. This is true for SMB but less so for enterprises that purchase licenses for versions of the OSS that contain proprietary features. Everyone is familiar with this model - I was one of the first to implement a freemium model in 2001 for Freepository.

Hosted source control is a zero-sum game. That’s apparent as soon as you look at the costs associated with switching between alternatives. For this discussion, I’m going to stick with the two primary git-based repository hosting providers, Github and Gitlab.

There is increasingly feature parity between the offerings - arguably Gitlab is now better suited for enterprises, as the application has been installable on-premise since its inception. Features important to the enterprise emerged early as enterprises began rapidly adopting git and implementing Gitlab onsite. To be fair to Github, the awareness that they provided in the marketplace was substantial. Gitlab was initially a clone of Github. But Github’s enterprise offering was expensive and - according to a lot of posts - was difficult to implement and buggy. This is not in dispute.

A day-one advantage that Gitlab had was that it could be installed on-premise for free. The enormous vaue of this cannot be overstated: Gitlab was behind the firewall and it was free of license costs. It was by definition more secure and less costly than the alternative it was replacing. Paid licenses emerged soon after, but the freely installable Community Edition (CE) was wildly successful. Gitlab’s footprint inside the enterprise grew rapidly.

Fast forward several years and here we are. Github has been acquired by Microsoft and Gitlab is still a venture-backed quasi-startup valued at over a billion dollars. Gitlab’s penetration into the enterprise has fueled growth in the same way that free accounts fueled Github’s earlier growth. Legacy build systems inside enterprises - I lived in the space for 15 years, recall - is now almost entirely on-premise implementations of Jenkins, another OSS application. Yes, of course there’s some stuff using other CI/CD tooling, but the bread & butter legacy applications are far & away still Java and they’re built in Jenkins.

Jenkins uses project configuration files that contain the repo URLs of the sources involved in a build operation. This is super straight-forward and every single config file uses the same notation. I can - and have - changed the repo URLs for hundreds of projects using a simple script that walks across the config files using a regex to substitute the new URL for the old. It’s as easy to accomplish as it sounds. A competent sysadmin can do this in 15 minutes.

The technological switching costs are near-zero with respect to repo URLs, so long as basic git functionality as consumed by Jenkins is what’s in play. Please don’t @ me with a bunch of esoteric “but what about [x]?” I know about [x]. It’s a one-off that will carry exactly zero importance in the scenario I’m about to describe.

I’ll point out now that Gitlab is OSS while Github is not. Github is widely associated with open source because many of the projects hosted there are OSS, but the service itself is proprietary. It’s one of the more clever jedi mind-tricks used in recent memory. This allows Github to enjoy the positive reputational benefits of OSS without any of the actual open source.

This leads into a second order advantage - and disadvantage - for enterprises using either of these tools. We’ll need some background here.

I’ll dig into this in great detail in another post, but for now it’s important to grasp that enterprises are rapidly adopting Infrastructure as a Service (IaaS) and that there are five major providers:

  • AWS
  • Microsoft
  • Google
  • IBM
  • Alibaba

and everybody else. With 48% market share, AWS is the 500 lb gorilla. With just under 16% market share, Microsoft is #2. That 30%+ gap creates incentives for both Microsoft as well as AWS. When Microsoft acquired Github, it went out of its way to state that Github would continue to operate as it had before, but that there would be tighter integration with other tooling, such as the incredibly popular - and open source, free to use - IDE Visual Studio Code, commonly just called Code. So far, so good.

But what happens when Microsoft decisively acts to increase their share of the lucrative - and dollar-wise growing - IaaS market? They’ll by design need to offer something that draws customers, both new and existing, away from AWS. This will likely come in the form of some type of developer tooling tie-in that increases cost or friction when used with AWS. It could be as simple as requiring a paid Code plugin to use non-Github repos or layering in some great new features that only work with Azure. Any enterprises using Gitlab will have to absorb the additional cost or lack of functionality - or switch to Azure.

Will some switch? Of course. Economic incentives are powerful. That’s why they’re used.

Here’s where things get really interesting, though. Enterprises that currently use AWS - that 48% market share - as well as Github - are suddenly facing a disincentive. Continued use of Github means they’re adding costs or friction.

If a large part of your infra is currently in AWS & you’re deploying new stuff on a daily basis, the inertia behind continued use of AWS is very, very strong. It’s one thing to academically argue that “all provisoned resources are ultimately the same no matter the cloud provider”, it’s quite another entirely to be faced with porting a few thousand Cloudformation templates into Azure Resource Manager. That’s exactly the pain point that Hashicorp’s Terraform is meant to avoid. No great surprise that Terraform also employs a freemium model.

There are multi-year, multi-million dollar commited spend contracts keeping enterprises in AWS. Enterprises aren’t going to break those contracts & take on all that new tech debt, at least not when there’s a clear alternative.

That clear alternative, as discussed above, is Gitlab.

I see Gitlab as an AWS acquistion target for a number of reasons, with this being #1. Adding Gitlab into the AWS services mix adds yet another layer to their competitive moat, further incentivizing existing enterprise customers who use Gitlab to stick with AWS. This would likely come in the form of enhanced interoperability between Gitlab and other AWS services & integration into the dashboard. That’s powerful.

This wouldn’t require any reduction of existing compatibility between AWS and Github. It would all be on the ‘advantage Gitlab’ side and it’s almost certainly the same strategy that Microsoft is putting into place with Github.

As a bonus, new customers could implement Gitlab CE at no cost. Don’t let that shock you - lots of enterprises still use CE.

There wouldn’t be any credible anti-competitive claims to assert. It would simply be AWS - Amazon - being Amazon.

- jbminn