As we come upon the deadline for being in compliance or not with the new pricing and licensing scheme for Docker Desktop, we have to make sure we approach decisions like this considering costs and benefits of options over time, rather than rushing to a free thing that seems to be OK right now. In this piece, we’ll unpack what that means using Docker Desktop as an example.
The initial reaction from the infrastructure development community was a fairly unsurprising mix. It is indeed difficult for companies to move to charging for something that was once free, and so, anger at something that was free, which now needs money was rife. There were a flurry of posts and activity of folks picking up and trying alternatives, but in most cases this was “hey, there is also this other free thing, so I’ll try that”, but that is just nowhere near sufficient for us to build a good decision model.
As of February 1, 2022, Docker Desktop is not free for commercial use; that is the line in the sand for our decision. We no longer have the free Docker desktop; we have basically two choices;
- Pay Docker the licensing fee (regardless of plan level)
- Use an alternative open source tool (minikube, podman, rancher etc)
The first thing to think about is what features we are using right now. Docker Desktop already provides more than just running containers on your laptop. You definitely want to get a spread of integrations devs are using (e.g. Visual Studio Codes devcontainers) so, at a minimum you have a set of tests and evaluation points. How many developers need to get coverage here? Given the exposure from the licensing, it really is best to get a team or organization wide stance on this, and the number of people who have to be supported plays into the ongoing cost of picking up an alternative open source tool, but these two things together are your initial point and are the description of purpose, i.e. we need to deliver and support these features for X developers today.
Now let’s consider feature differences over time, Docker Desktop does have a roadmap that it shares, and so you have some idea of where they are taking this tool with new things and the utility that would be to you. Most open source tools have some notion of a plan that you can look at as well, and while we should never treat any roadmap as guaranteed. Between the features we are using now and the roadmap view we can build our view of benefits along with the timeline of realization.
Obviously costs can include licensing payments, and initial testing or deployment time for either a different tool or integrating docker desktop (eg SSO with something like Okta). We should definitely evaluate opportunity costs, this is where we look at the roadmap of benefits between choices, and estimate the loss of what we are giving up. If we do decide to switch, we’ll need an estimate of transition cost, and remember to include training and maybe removal costs in that piece.
The next thing to consider is the vendor relationship. Now, you may think that this would mean in this example evaluating Docker the company, but we really should think of open source communities as vendors as well. In both cases we’ll have an internal cost (legal, finance, compliance etc) which especially in large companies can be quite unwieldy. We also want to think about what will we get from working with the people involved; are they responsive to issues, feedback and contributions? The vendor can be thought of as a multiplier on the cost and benefit sides, but at different rates, and really you are just asking yourself if the vendor makes looking after this capability easier or harder.
Another thing to be really careful about is if managing tools like this fits well with other work and technology that as an organization you manage. In most companies today there are broadly DevOps/SRE folk looking after infrastructure and associated tooling, but if you are mostly doing this through vended services it likely is an ill fit to manage the intake and delivery of an open source tool.
One specific cost that drops out from the two points above is if you need to hire someone new (an engineer with appropriate domain knowledge to manage the vendor or tooling), you need to consider that extra cost over just the engineer assignment cost, and add the potential time delay as a cost and risk.
The final thing to talk about is time. Over time is a pretty broad and non-specific statement, and this part of the model is inherently less precise. The horizon of our decision will normally be measured in years regardless of up front investment, ie there aren’t many decision timelines of months, and engineering decisions that last longer than a decade are rare. This decision specifcally will probably have a horizon of 1-3 years. Once you have it selected you should ammortize the total of costs and benefits to come up with a yearly ratio, and at this point you are in position to make your call.
With all of the above we have a good list of things to build a cost benefit model for vendor and open source tooling alternatives, and while there are definite margins of error in some of these estimates we are more likely to pick out the cost effective decision. The approach to building this model is definitely replayable for technology that is in the early or late majority phases of its adoption. If you are looking at problems which require novel or early adopter stage solutions there is definitely some different calculus, but thats for a later post.