If you do the same math for a company with thousands, or tens of thousands, of developers, the answer looks different.
Large companies already have dedicated teams for stuff that is a lot less critical than the container runtime.
The companies that are too big to avoid paying, but too small to build a replacement, are the ones that are in a jam -- for now. But in a year or two, Podman or Rancher might might fully meet their needs. What should they do then? Continue to pay for Docker, or use a free and open source alternative that has feature parity?
$250k/yr/developer, so for 1 quarter, that's $62.5k, 3 developers for one quarter is $187.5k. Docker costs $10/mo, or $120/yr, so for 1000 developers, that's $120k/yr, or a payoff time of 1.5 years, assuming nobody ever has to touch anything ever again. Let's say our solution requires 1 developer-quarter per year to maintain - bugfixes, upgrades, deployments, etc. That's $62.5k/yr. That pushes our payoff time out to 2.5 years.
Let's say our solution causes a net decrease in developer productivity of 1% (our solution has a bug that means things are slow for a day, developers can't google for easy answers, developers have to port things into our system) - that's a minute of extra work for every ~2hrs. That's 1000*250k*.01, or a net drain to the company of $2.5M/yr, which effectively pushes our payback time out to "never".
Hell, we can even work the math the other way - for replacing Docker Desktop to be worthwhile, it's gotta cost less than $120/yr/developer. Developers cost $250k/yr, for call it 250 days of work per year, so $1000/day, or $125/hr, which means if the aggregate cost of our replacement to an individual user is even an hour per year, it wouldn't be worth doing for free. Add in the cost of actually having someone actually maintain our replacement product, and the math's even shittier.
A big mistake with this math is that globally developers are not paid anywhere close to 250k/yr even fully loaded for the company. In my country in Europe it's closer to 60k/yr fully loaded. There is cheaper. Also most companies aren't gonna build something from scratch, they are going to use something else that is also available. That being said this type of exercise is good to show because many managers do not do it.
Remember that Europe is quite large and not homogeneous. For sure wages are lower and less different between blue collar and white collar jobs, which is both good and bad.
We don’t know where the gp is posting from; btw in places like London or Berlin a dev can make 2x that figure.
On the other hand they do get free health care, free uni (if in the right country), a social safety net that you can actually live decently on and other services.
> Let's say our solution causes a net decrease in developer productivity of 1%
This is an extremely aggressive assumption, and affects the entire equation. What happens when you achieve parity in 1 month, because actually, docker isn't that important? nerdctl + containerd basically eliminate my need for docker in a work context. nerdctl only for my local development.
Tech companies with XX thousand employees already have dedicated infrastructure teams of all sorts. This math doesn't feel like it reflects reality of the marginal costs and payoff time.
The marginal costs of dedicated infrastructure teams is the legion of tickets that product teams want fixed first. The signup team hates that signups take seconds to process instead of milliseconds so there's desire to rebuild the batch job runner, the identity teams want you to make a richer capability-based authz system so that they can sell capabilities as a customer facing product, etc. These infra teams need to justify rebuilding infra like Docker against the marginal opportunities of creating new things for product teams.
I've had more productivity loss than that from docker's bugs and CPU/battery drain. We don't use docker in prod so why use it for dev? I need a container not this power hungry daemon and annoying UI.
As I type this my laptop is hot because docker needs to be reset and restarted.
This is what drove me away from docker in the first place - only to find there’s little alternative today. Honestly, the poor reliability of docker on any platform, for so many years, has tainted it in my mind and I will change in a heartbeat if something better comes along.
Interesting... My experience has been pretty much exactly the opposite, Docker just works flawlessly and it's the alternatives like podman and systemd that's caused me headaches and countless hours of wasted time.
I gave podman weeks of effort trying to get its “killer feature” to work properly (rootless containers). I couldn’t even justify the time for a hobby project. Instead, I just installed Docker and went on my way.
IMO they need to improve documentation and drop the facade that it’s 1:1 Docker.
Yep, I also spent a huge amount of time trying to get podman rootless containers working. It felt like what fusion progresses looks like, forever “just around the corner”, so I also decided to just stick with docker.
I did hit some kind of networking bug on a Linux server recently (in the past 2 weeks) which required a restart of the Docker daemon, and that is my classic personal experience. We went all-in on Docker Swarm several years ago, and we ended up having to do full server reboots on what seemed like a weekly basis. And I know I'm not alone in having loads of problems on MacOS - although I must admit it seems to have been a lot better recently.
That's strange, my developers run docker on quite old laptops and they are doing fine. Not mac's though, we running Manjaro Linux and no impact in performance.
But we uses docker engine, not desktop.
I had seen docker desktop runs in Qemu VM on non-linux os. That might be the problem and defeating the purpose of using containers at all.
One of the reasons I use Docker regardless of deployment is to verify it works on a machine that is not mine. Running it in Docker is a quick litmus test I have all made all the dependencies explicit. Also, a Dockerfile is potentially machine interpretable documentation on what you need to do to run the application. All of this has value before you even deploy anything.
There is not just cost to count. There is also value in having a custom solution that is well integrated into your other tools, and value in avoiding vendor lock-in. Large companies build a lot of their own internal tooling for those reasons.
Let's say there was no open source replacement (that's not true, or at least it's not going to be true when Podman and Rancher improve, but for the sake of argument...)
What would prevent Docker from doubling the subscription right now? Tripling it?
Assume 250k/employee ctc that’s $250M. Assume revenue is 2x labor cost and that’s 500M earnings. Typical revenue multiple nowadays is like 5, unless very high growth, so $2.5B valuation. Not exactly big but unicorn at least.
More users = greater need for dedicated support. A company that has tens of thousands of developers will need an entire team staffed up just to answer questions and troubleshoot issues with their homegrown Docker replacement, and the end result will be that the team gets laid off and the company just buys licenses because that is far cheaper.
Large companies already have dedicated teams for stuff that is a lot less critical than the container runtime.
The companies that are too big to avoid paying, but too small to build a replacement, are the ones that are in a jam -- for now. But in a year or two, Podman or Rancher might might fully meet their needs. What should they do then? Continue to pay for Docker, or use a free and open source alternative that has feature parity?