The Race to Zero

4 mins

Build System Background
Enterprise build systems are, by design and necessity, bespoke implementations. While many enterprises do indeed utilize the same core feature set - i.e. clone a repo & then iterate through a series of predefined tasks - this accounts for around 75% of the functionality that a build system has to possess.

The results delivered in that last 25% require enormous customization and thus ensure that no two build systems will ever be the same. Let’s take a look at what that means to the economics of the Builds as a Service (BaaS) business model.

Let me first say that I have designed, developed, implemented and supported somewhere on the order of 500 build systems over the past 20 years. I’ve created these from scratch, used Cruisecontrol, Jenkins (Hudson), Gitlab CI and in a few cases briefly supported & then replaced well-intentioned but poorly-designed & buggy home-grown stuff.

I even went so far as to create my own BaaS offering. I was initially convinced that this was an amazing opportunity to productize everything I knew about build systems, and if VCs were smart they’d invest 20 quadrillion dollars in it.

The reality turns out to be very different. Once I disconnected my emotions (“I love this stuff!”) from the concept and looked at it through the lens of simple economics, the entire business model collapses.

Let’s break it down point by point.

Cost for Basic Features
Virtually every1 enterprise producing & building a legacy application in-house is developing on the J2EE platform and uses Jenkins as the primary build system engine. Jenkins provides a good - some parts great, some parts just ok, but overall adequate - system that can perform build actions on a configurable schedule or trigger. It can process ant build files, maven project files and simple (though complex) shell scripts. If you have a series of steps that you can run at the keyboard, these can be placed in a Jenkins job. You can expect Jenkins to produce the same results as your command-line invoked process.

That covers the 75% functionality I mentioned earlier and Jenkins is free to use. There are no license fees to pay anyone. You can download & install it 1000 times on different servers - on-premise, in the cloud, at your home office - and not pay a dime to any vendor. This is why Jenkins is so widely used.

Cost for those Extra Features
That other 25% is where things get wild. It can also be obtained free of license costs.

No two organizations will have the same combination of networks, storage models, servers and source control needs. This is where & why Jenkins plugins emerged - they provide some of that remaining 25% functionality without the need to have a bunch of extra code in the core product. If you need a non-core feature, you download, install & configure the plugin. Managing that process can be initially cumbersome, but once you have the plugin set that works for your organization, you’re all set.

Plugins are almost universally free. There are a few that are pay-to-use, but not many. In general, there’s a free plugin to do almost anything you need to bridge the gap between 75% and 100%, providing you with a working solution that is fully customized to your needs.

Aside from the setup cost, all of this benefit acrues to your enterprise free of charge. A build engineer or team will still need to add jobs to the system as new projects emerge & existing projects evolve, but that’s an ongoing cost of development. You’re already paying for the headcount.

Service providers to this point have offered one of two flavors of BaaS: hosted Jenkins or hosted travis-ci variant. The pitch - I said this myself! - is that operating a build system is so complex that an enterprise doesn’t want to do it themselves or that there’s some extra value to be had in special plugins that the service provider itself offers. The inverse argument, which is interesting but still falls flat, is that build systems are simply undifferentiated heavy lifting. Why pay your engineers to do grunt work?

It’s in fact not undifferentiated. Recall that 25% customization? That still has to occur. The BaaS provider doesn’t know anything about your environment - your own engineers have to do that setup. It’s exactly the same work they’d do to setup a Jenkins system on your own hardware or EC2 instances.

There is simply no way for a commercial service to compete on cost. Companies that have tried to do this have reduced service plan subscription fees to effectively zero - lower than their own costs to provide the underlying infrastructure to service a customer account.

It’s a race to zero.

- jbminn

1 a very large empirical number such that I’m using ‘virtually every’ as notational shorthand