Open infrastructure is hard to monetize. Old school robotics players have a playbook for this. You may or may not agree DBs are infra but Oracle has done well by capitalistic standards.
The reality is in our economy exploitation is a basic requirement. Nothing says a company providing porcelain for Linux kernel capabilities has a right to exist. What has turned into OCI is great. Docker desktop lost on Mac to Orb stack and friends (but I guess they have caught back up?) the article does make it clear they have tried hard to find a place to leverage rent and it probably is making enough for a 10-100 person company to be very comfortable but 500-1000 seems very over grown at this point.
Really should not have given up on Swarm just to come back to it. Kubernetes is over kill for so many people using it for a convenient deployment story.
But not impossible. Terraform seems to have paid its creator quite well.
Imagine if Docker the company could charge AWS and Google for their use of their technology.
Imagine if Redis, Elastic, and so many other technologies could.
Modern database companies will typically dual license their work so they don't have their lunch eaten. I've done it for some of my own work [3].
You want your customers to have freedom, but you don't want massive companies coming in and ripping you off. You'd also like to provide a "easy path" for payments that sustain the engineering, but not require your users to be bound to you.
"OSI-approved" Open Source is an industry co-opt of labor. Amazon and Google benefit immensely with an ecosystem of things they can offer, but they in turn give you zero of the AWS/GCP code base.
Hyperscalers are miles of crust around an open source interior. They charge and make millions off of the free labor of open source.
I think we need a new type of license that requires that the companies using the license must make their entire operational codebases available.
[3] https://github.com/storytold/artcraft/blob/main/LICENSE.md
Big tech companies saw this as an opportunity to build proprietary value-add systems around open source, but not make those systems in turn open. As they scaled, it became impossible to compete. You're not paying Redis for Redis. You're paying AWS or Google.
Part of that was that the platform churn costs were a new thing for developers that needed to be priced in now. In the "old world" aka Windows, application developers didn't need to do much, if any at all, work to keep their applications working with new OS versions. DOS applications could be run up until and including Windows 7 x32 - that meant in the most ridiculous case about 42 years of life time (first release of DOS was 1981, end of life for Win 7 ESU was 2023). As an application developer, you could get away with selling a piece of software once and then just provide bug fixes if needed, and it's reasonably possible to maintain extremely old software even on modern Windows - AFAIK (but never tried it), Visual Basic 6 (!!!) still runs on Windows 11 and can be used to compile old software.
In contrast to this, with both major mobile platforms (Android and iOS) as an app developer you have to deal with constant churn that the OS developer forces upon you, and application stores make it impossible to even release bugfixes for platforms older than the OS developer deems worthy to support - for Google Play Store, that's Android 12 (released in 2021) [1], for iOS the situation is a bit better but still a PITA [2].
[1] https://developer.android.com/google/play/requirements/targe...
To compete at offering infrastructure maybe, but what I would like is more capability to build solutions.
And I think that today one has much more open-source technologies that one can deploy with modest efforts, so I see progress, even if some big players take advantage of people that don't want or are not capable to make even modest efforts.
I can't imagine. Tell me one software project used in AWS/GCP that Amazon/Google pay for. Not donations (like for Linux), but PAID for.
Docker started as a wrapper over LXC, Amazon has enough developers to implement that in a month.
An "issue" is that Docker these days mostly builds on open standards and has well documented APIs. Open infrastructure like this has only limited vendor lock-in.
Building a docker daemon compatible service is not trivial but was already mostly done with podman. It is compatible to the extent that the official docker cli mostly works with it oob (having implemented the basic Docker HTTP API endpoints too). AWS/GCP could almost certainly afford to build a "podman" too, instead of licensing Docked.
This is not meant to defend the hyperscalers themselves but should maybe out approaches like this in perspective. Docker got among other things large because it was free, monetizing after that is hard (see also Elasticsearch/Redis and the immediate forks).
If I wrote the best word processor in the world, I could probably sell it for a decent money to quite a few people.
However if I expressed my revenue expectations as a percentage of revenue from the world's bestselling novels, I would be very quickly disappointed.
I worked in engineering software for a long time and because of who we sell to, there's always been a very hard cost-benefit analysis for customers of SaaS in that space. If customers didn't see a saving equal to more than the cost of the software in Y1 they could and would typically cancel.
- take advantage of the current agentic wave and announce a Docker Sandbox runner product that lets you run agents inside cloud sandboxes
But the actual experience with developing on VSCode with Dev Containers is not great. It's laggy and slow.
I have also used them remotely (ssh and using tailscale) and noticed a little lag, but nothing really distracting.
There is a lot more than a simple chroot to Docker though - with FreeBSD Jails being a stepping stone along the way. It's real innovation and why it won over alternatives was the tooling and infrastructure around the containers - particularly distributing them.
What is the edge that docker provides these days?
I'll add that needing to be on the "right" Linux system is another strike against Podman. Last I checked if I wasn't on a RedHat derivative I was in the wilderness.
That you are not the average developer
Are you suggesting that docker provides an (unspecified) edge to developers who are better than average? Or to those who are mediocre? Or...
I tried to substitute docker-compose with Podman and Quadlets on a test server the other day, but was shocked how badly described the overall concept is. Most materials I found glimpsed through ability to run it as root/user and how different that is in configuration, and repeated the same 4-6 commands mantra.
Spent a few hours on it and just... failed to run a single container. systemctl never noticed my qualdet definitions, even if podman considered my .container file registered.
A bit.. frustrating, I expected smoother sailing.
Then you can just create a few line systemd unit definition, and it integrates as a normal systemd unit, with logs visible via journalctl etc.
systemctl --user daemon-reload
I agree that the documentation needs a good tutorial to show the complete concept as a starting point. There are multiple ones though on the internet.
The gap with Podman is closing though, and most users don't need any of these in the first place.
"Deploying" one is as simple as `nixos-rebuild switch --flake .#hostName`
He'd always try to get us into various technologies, Docker was one of them. It wasn't really relevant for the job, but I could see its uses.
Now that I think about it, I don't think anything they did on the tech discovery front was useful. Got stuck on Confulence which required us to save as a .pdf for our users to view lmao. Credit for being super smart with coding, he was a wiz on code reviews.
You have to be root to set it up, but after that you don't need any special privileges. With Docker the only option is to basically give everyone root access.
It's true that it requires root for some setup though. Unclear if op was complaining about that.
Yeah, I mean what do you expect or is the alternative? If you have a process that needs access to something only root typically can do, and the solution been to give that process root so it can do it's job, you usually need root to be able to give that process permission to do that thing without becoming root. Doesn't that make sense? What alternative are you suggesting?
Sure you cannot install docker or podman as a non-root user. But take your argument a bit further: what if the kernel is compiled without cgroups support? Then you will need root to replace the kernel and reboot. The root user can do arbitrarily many things to prevent you from installing any number of software. The root user can prevent you from using arbitrary already installed software. The root user can even prevent you from logging in.
It is astounding to me that someone would complain that a non-root user cannot install software. A much more reasonable complaint is that a non-root user can become root while using docker. This complaint has been resolved by podman.
At two places I worked their reps reached out to essentially ensnare the company in a sort of “gotcha” scheme where if we were running the version of Docker Desktop after the commercial licensing requirement change, they sent a 30 day notice to license the product or they’d sue. Due to the usual “mid size software company not micromanaging the developers” standard, we had a few people on a new enough version that it would trigger the new license terms and we were in violation. They didn’t seem to do much outreach other than threatening us.
So in each case we switched to Rancher Desktop.
The licensing cost wasn’t that high, but it was hard to take them in good faith after their approach.
Due to the usual “mid size software company not micromanaging the developers”
standard
At my midsize company, our engineers could absolutely say something like “we don’t like Terraform Cloud, we want to switch to OpenTofu and env0” and our management would be okay with it and make it happen as long as we justify the change.
We wouldn’t even really have to ask permission if the change was no cost.
If they never changed that licensing, nobody would have had an incentive to put big effort into an alternative.
I think the hosted Docker registry should have been their first revenue source and then they should have created more closed source enterprise workflow solutions and hosted services that complement the docker tooling that remained truly open source, including desktop.
Strongly disagree. The core Docker technology was an excellent product and as the article says, had a massive impact on the industry. But they never found a market for that technology at any price point that wasn't ~free, so they didn't have PMF. That technology also only took off in the way it did because it was free and open source.
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.
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 it 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 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.
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.
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.
Gordon is the character from Half Life.
Docker a piece of software. Don't anthropomorphize it.
Just a note, I am working for the org, that sells enterprise software shipped as container images, publishes on Docker Hub and RedHat. No issues migrating to apple/container.
FYI- If I was docker, I'd stand up some bare metal hosting (i.e., a Docker Cloud) designed around making it easier for novice developers to take containers and turn them into web applications, with a product similar to Supabase built around this cloud to let novice developers quickly prototype and launch apps without learning how to do deployments in more sophisticated clouds. Supabase and AI vibe coders pair well, but the hole in the market is vibe coders who want to launch a web app vibe coded but don't know how to deploy containers to the cloud without a steep learning curve. It keeps many vibe coders trapped in AIO vibe coding platforms like Lovable and AI Studio.
Is it really a hole? I'm not the target user, but I keep coming across "Build & deploy your own platform/service/application with VibeCodingLikeThereIsNoTomorrow" and similar, maybe new one every week or so.
The tech is open source and free forever - thats somehow a problem? The company monitised enterprise features, while keeping core and hub free - also a problem? Is exploring AI tools, like everyone else is? should they not? should they just stay stagnant? Has made hardened images free instead of making that a premium feature only for people in banks? - and monitising SLAs, how is that a problem?
Docker is still maintaining the runtime on which orbstack, podman etc are all using, and all the cloud providers are using, but apparently at the same time Docker is deeply irrelevant and should not make money - while all of us on HN with well paid tech jobs get to have high thoughts on their every move to pay their employees and investors...
Podman? Podman appears to have reimplemented basically everything. What runtime are you talking about?
Early 2017 was peak Docker and Docker Inc. Those were the days. Container hype was everywhere. Before moby. Before all the pivots.
Microsoft was embracing open source and the cloud. They were acquiring dev tools.
It was a missed opportunity for both companies.
gregoryl•1h ago
reedf1•1h ago
hu3•1h ago
It has been a year without problems since I enabled WSL2 engine for Docker.
Honestly they should make the WSL2 Docker engine mandatory because otherwise things barely work.
tuananh•1h ago
bonesss•55m ago
throw20251220•1h ago
breakingcups•1h ago