"The problem is that Docker the technology became so successful that Docker the company struggled to monetize it. When your core product becomes commoditized and open source, you need to find new ways to add value."

No, everything was already open source, other had done it before too, they just made it in a way a lot of "normal" users could start with it, then they waited too long and others created better/their own products.

"Docker Swarm was Docker’s attempt to compete with Kubernetes in the orchestration space."

No, it never was intended like that. That some people build infra/business around it is something completely different, but swarm was never intended to be a kubernetes contender.

"If you’re giving away your security features for free, what are you selling?"

This, is what actually is going to cost their business, I'm extremely grateful for what they have done for us. But they didn't gave themselves a chance. Their behaviour has been more akin to a non-profit. Great for us, not so great for them in the long run.

It didn't help them that they rejected the traditionally successful ways of monetizing open source software. Which is, selling support contracts to large corporate users.

Corporate customers didn't like the security implications of the Docker daemon running as root, they wanted better sandboxing and management (cgroups v2), wanted to be able to run their own internal registries, didn't want to have docker trying to fight with systemd, etc.

Docker was not interested (in the early years) in adopting cgroups v2 or daemonless / rootless operation, and they wanted everyone to pay to use Dockerhub on the public internet rather than running their own internal registries, so docker-cli didn't support alternate registries for a long long time. And it seemed like they disliked systemd for "ideological" reasons to an extent that they didn't make much effort to resolve the problems that would crop up between docker and systemd.

Because Docker didn't want to build the product that corporate customers wanted to use, and didn't accept patches when Red Hat tried to get them implemented those features themselves, eventually Red Hat just went out and built up Podman, Quay, and the entire ecosystem of tooling that those corporate customers wanted themselves (and sold it to them). That was a bit of an own goal.

I think what Docker should have done, is charge for Docker Desktop from the start... even $5/mo/user as a discount rate for non-open-source usage... similar for container storage, had a commercial offering for private containers from very early on.

The former felt like a rug pull when they did it later, and the latter should have been obvious from the start. But it wasn't there in the beginning and too many alternatives from every cloud provider popped in to fill that gap and it was too late.

There were a lot of cool ideas, and I think early on, they were more focused on the cool ideas and less on how to make it a successful, long lived business that didn't rely on VC funding and an exit strategy they didn't have to succeed.

> Their behaviour has been more akin to a non-profit. Great for us, not so great for them in the long run.

This is particularly amusing when considering they helped start the Open Container Initiative with others back in 2015.

What if Docker "the company" was just a long con to use VC bux to fund open source? I say mostly in jest.

> No, everything was already open source, other had done it before too, they just made it in a way a lot of "normal" users could start with it, then they waited too long and others created better/their own products.

Yes. It was a helpful UI abstraction for people uncomfortable with lower level tinkering. I think the big "innovations" were 1) the file format and 2) the (free!) registry hosting. This drove a lot of community adoption because it was so easy to share stuff and it was based on open source.

And while Docker the company isn't the behemoth the VCs might have wanted, those contributions live on. Even if I'm using a totally different tool to run things, I'm writing a Dockerfile, and the artifacts are likely stored in something that acts basically the same as Docker Hub.

Arrogance was what actually killed them. They picked fights with Google and RedHat and then showing up at conferences with shirts that said "we don't accept pull requests" tipped the scales so that RedHat and Google both went their own way and their technology was now pushed out of 2 of their biggest channels.

>> Docker Swarm was Docker’s attempt to compete with Kubernetes in the orchestration space."

> No, it never was intended like that.

It was certainly marketed as that though...

For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

> but swarm was never intended to be a kubernetes contender.

Your comment is accurate for the original Swarm project, but a bit misleading regarding Swarm mode (released later on and integrated into docker).

I have worked on the original Swarm project and Swarmkit (on the distributed store/raft backend), and the latter was intended to compete with Kubernetes.

It was certainly an ambitious and borderline delusional strategy (considering the competition), but the goal was to offer a streamlined and integrated experience so that users wouldn't move away from Docker and use Swarm mode instead of Kubernetes (with a simple API, secured by default, just docker to install, no etcd or external key value metadata store required).

You can only go so far with a team of 10 people versus the hundreds scattered across Google/RedHat/IBM/Amazon, etc. There were so many evangelists and tech influencers/speakers rooting for Kubernetes already, reversing that trend was extremely difficult, even after initiating sort of a revolution in how developers deployed their apps with docker. The narrative that cluster orchestration was Google's territory (since they designed Borg that was used at a massive scale) was too entrenched to be challenged.

Swarm failed for many reasons (it was released too soon with a buggy experience and at an incomplete state, lacking a lot of the features k8s had, but also too late in terms of timing with k8s adoption). However, the goal for "Docker Swarm mode" was to compete with Kubernetes.

I joined them after they were clearly in decline and half of the office was empty. Contrary to some of the comments here, there were enterprise products (Docker EE, private registry, orchestration) and a very large sales team.

There were also a lot of talented, well-paid engineers working on open source side projects with no business value. It just wasn't a very well-run company. You can't take on half a billion dollars in VC just to sell small enterprise support contracts.

My own mental model of swarm is "k8s but easier" - is that wrong?

> No, it never was intended like that. That some people build infra/business around it is something completely different, but swarm was never intended to be a kubernetes contender.

That would be news to the then Docker CTO, who reached out to my boss to try to get me in trouble, because I was tweeting away about [cloud company] and investing heavily in Kubernetes. The cognitive dissonance Docker had about Swarm was emblematic of the missteps they took during that era where Mesos, Kube and Swarm all looked like they could be The Winner.