"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.
Absolutely none of this is true. Docker had support contracts (Docker EE... and trying to remember, docker-cs before that naming pivot?).
Corporate customers do not care about any of the things you mentioned. I mean, maybe some, but in general no. That's not what corps think about.
There was never "no interest" at Docker in cgv2 or rootless. Never. cgv2 early on was not useable. It lacked so much functionality that v1 had. It also didn't buy much, particularly because most Docker users aren't manually managing cgroups themselves.
Docker literally sold a private registry product. It was the first thing Docker built and sold (and no, it was not late, it was very early on).
I mean you can say that, but on the topic of rootless, regardless of "interest" at Docker, they did nothing about it. I was at Red Hat at the time, a PM in the BU that created podman, and Docker's intransigence on rootless was probably the core issue that led to podman's creation.
I've really appreciated RH's work both on podman/buildah and in the supporting infrastructure like the kernel that enables nesting, like using buildah to build an image inside a containerized CI runner.
That said, I've been really surprised to not see more first class CI support for a repo supplying its own Dockerfile and being like "stage 1 is to rebuild the container", "stage two is a bunch of parallel tests running in instances of the container". In modern Dockerfiles it's pretty easy to avoid manual cache-busting by keying everything to a package manager lockfile, so it's annoying that the default CI paradigm is still "separate job somewhere that rebuilds a static base container on a timer".
When Docker was new I had a really bad ADSL connection (2Mbps) and couldn't ever stack up a containerized system properly because Dockerhub would time out.
I did large downloads all the time, I used to download 25GB games for my game consoles for instance. I just had to use schedule them and use tools that could resume downloads.
If I'd had a local docker hub I might have used docker but because I didn't it was dead to me.
Unfortunately even podman etc.. are still limited by OCIs decision to copy the Docker model.
Crun just stamp couples security profiles as an example, so everything in the shared kernel that is namespace incompatible is enabled.
This is why it is trivial to get in-auditable communication between pods on a host etc…
yes; its really notable that corporates and other support companies (e.g. redhat) don't want to start down the path of NIH, and will go to significant efforts to avoid it. However, once they have done it, it is very hard to make them come back.
I think the Star Wars problem was that instead of making the movies at a steady cadence they stretched it out too long.
I can't help but see a parallel with some of the entertainment franchises in recent years (Star Wars, etc.) -- where a company seems to be allergic to taking money by giving people what they want, and instead insists on telling people what they should want and blaming them when they don't
> 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.
> 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.
Only because with Google open sourcing Kubernetes, it was a decision on still be able to play the game, or be left completely out, helping with OCI was a survival decision.
As proven later when Kubernetes became container runtime agnostic.
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.
I truly do sometimes detest the open source community's often outright hostility towards monetization of software. People gotta eat.
One thing that really hurt them from my PoV was how they acted when they changed their licensing structure with respect to revenue generating companies. I’m fine with the idea that licensing Docker and Docker Desktop is a good thing to do. However, I think they just made people distrust their motives with their approached to this.
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.
> 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.
What exactly are you objecting to? Since you say “I’m fine with the idea that licensing Docker and Docker Desktop is a good thing to do” it’s not the change, so what is it? The 30 days, them saying they would sue after that, or the tone?
I haven’t seen the messages so I cannot comment on that, but if you accept that the licensing can be changed, whats wrong with writing offenders to remind them to either stop using the product or start paying? And what’s wrong with giving them 30 days, since, in my memory, they announced the licensing change months in advance?
> they sent a 30 day notice to license the product or they’d sue
This tracks with what I saw, one day there was an email sent out to make sure you don’t have docker desktop installed.
It was wild because we were on the heels of containerize-all-th-things push and now we’re winding down docker?? Sure whatever you say boss.
So they have become Oracle...
They basically made the case for podman existing, and I see podman gaining steam and being easier and easier to drop in as a replacement for Docker.
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.
Due to the usual “mid size software company not micromanaging the developers”
standard
I believe you’re using royal-you but just to be clear I didn’t run these companies.
At one place there wasn’t and at the other it wasn’t well managed. I agree from a compliance point of view and have advocated for this but I was not on the IT/Ops side of the business so I could only use soft power.
The CTO at the first company had a “zero hindrances for the developers” mindset and the latter was reeling from being the merger of five different companies. The latter did a better job of trying to say the least but wasn’t great about it. Outcome was the same none the less.
I mainly consult but we have a few managed clients that are dev houses too. We do their employee onboarding, wrangle their licensing, keep them updated, give them a self service storefront for commercial software that they pay for, add SSO integrations for them etc. Basically they wanted to do NoOps but also didnt want to have to procure or configure their equipment.
But outside of 'make sure the oracle lawyers never contact us' they dont want us policing them and they are admins on their own devices. For a lot of businesses their computer network has separate production and business zones and the production zone is a YOLO type situation.
Amazon has device management but still allows developers to install software via `brew`. Windows is slightly more locked down in that user's don't have admin by default, but there's a very low bar to clear to get it temporarily.
Brew also has workbrew which gives the admin control of the repository. There's also JAMF on macos. None of these systems must give developers free reign to violate software licenses.
Device management != micromanaging developer workflow.
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.
-> and make it happen.
I think OPs point is they failed on this part. "Making it happen" should have been ensuring a compliant and approved version of the software was the one made available to the developers. At a large scale that is done via device management, but even at a medium sized enterprise that should have been done via a source management portal of some sort.
> Docker’s journey reads like a startup trying to find product-market fit, except Docker already had product-market fit
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.
The entire technology is a wrapper on setns().
And Dropbox is just curlftpfs
Seems like (according to the author) whatever docker is doing it is a sign of their immediate demise and everyone on HN is cheering for the company to go down in flames no matter what.
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...
> Docker is still maintaining the runtime on which orbstack, podman
Podman? Podman appears to have reimplemented basically everything. What runtime are you talking about?
I agree with a lot of the above, but then there's:
> Docker is still maintaining the runtime on which orbstack, podman etc are all using, and all the cloud providers are using
I need to fact check that one. runc was donated by Docker to OCI a while back. And containerd was created under the CNCF from a lot of Docker code and ideas. podman is sitting on the RedHat containers stack, which has their own code base. Docker itself uses runc and containerd, and so do most Kubernetes deployments. Many of these tools go to containerd directly without deploying the Docker engine.
> containerd was created under the CNCF from a lot of Docker code and ideas
No. containerd was created by Docker, as part of a refactoring of dockerd, then later donated to cncf. Over time it gained a healthy base of maintainers from various companies. It is the most successful of Docker's cncf contributions. But it was not created under the CNCF.
to the respondants above - you are right - that lacked nuance
Look at the maintainer lists of containerd and moby, which are used by loads of others, several docker employees on those lists - I didn't check what their amount of involvement is compared to other companies, nor whether they are even sanctioned by docker to do the work, but afaik those projects came out of OCI with Docker as one of the primary backers.
OP is wrong. Docker created containerd, then donated to cncf, then other contributors joined.
Not really, rancher, containerd, podman don't depend on Docker other than offering a compatibility layer for tools that expect talking to the real Docker.
Hi, I'm the founder of Docker. I started it in 2008 (under the name Dotcloud) and left in 2018.
AMA.
- well time to announce DockerVM, a super fast under 100ms boot time competitor to firecracker and gvisor and try selling this to some of the cloud providers out there
- take advantage of the current agentic wave and announce a Docker Sandbox runner product that lets you run agents inside cloud sandboxes
Someone explain why a company should make money selling what is a essentially a thin layer of convenience over kernel features?
What I hate about docker and other such solutions is that I cannot install it as nonroot user, and that it keeps images between users in a database. I want to move things around using mv and cp, and not have another management layer that I need to be aware of and that can end up in an inconsistent state.
> What I hate about docker and other such solutions is that I cannot install it as nonroot user
There's a rootless [0] option, but that does require some sysadmin setup on the host to make it possible. That's a Linux kernel limitation on all container tooling, not a limitation of Docker.
> and that it keeps images between users in a database.
Not a traditional database, but content addressable filesystem layers, commonly mounted as an overlay filesystem. Each of those layers are read-only and reusable between multiple images, allowing faster updates (when only a few layers change), and conserving disk space (when multiple images share a common base image).
> I want to move things around using mv and cp, and not have another management layer that I need to be aware of and that can end up in an inconsistent state.
You can mount volumes from the host into a container, though this is often an anti-pattern. What you don't want to do is modify the image layers directly, since they are shared between images. That introduces a lot of security issues.
It's hilarious. Your 'solution' to use docker without root is to make some system changes as root and then use/build docker LOL.
> is to make some system changes as root
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?
Uhm no. Podman is a different product that is pretty much a drop-in replacement for Docker but lets you run as non-root.
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.
Docker can run rootless the same way podman does.
Now. I was at Red Hat at the time, in the BU that built podman, and Docker was just largely refusing any of Red Hat's patches around rootless operation, and this was one of the top 3, if not the top motivation for Red Hat spinning up podman.
> I cannot install it as nonroot user
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.
> It is astounding to me that someone would complain that a non-root user cannot install software.
Depends on what you mean by "install software".
If your definition is "put an executable in a directory that is in every other user's standard $PATH", then yes, this is an absurd complaint. Of course only root should be able to do this.
If your definition is "make an executable available to run as my user", then no, this is not absurd. You absolutely should not need root to be able to run software that doesn't require root privileges. If the software requires root, it's either doing something privileged, or it's doing it wrong.
I don’t think you understood my comment.
> You absolutely should not need root to be able to run software that doesn't require root privileges.
But root can approve or disapprove you running that software. Have you heard of SELinux or AppArmor? The root user can easily and simply preventing you from running an executable even as your own user.
A malware can run as your own user and exfiltrate files you have access to. The malware does not need root privileges. Should root have the capability to prevent the malware from being installed? Regardless of what your definition of “install” is, the answer is unequivocally yes.
If you're not into rootless Docker, but still want to improve sandboxing capabilities, consider alternative runtimes such as runsc (also known as gVisor)
If somebody missed it, apple/container is a good replacement for Docker for Mac on macOS. I have been using it for the last 6 months, there are issues, but also team is actively developing it.
I haven't personally used it, but containerd also has "nerdbox": http://github.com/containerd/nerdbox
Does that let you build images on a macOS host that works on Windows and Linux too? It doesn't seem to talk about what platform the images support, only where you could run containers.
Not sure about Windows, but yes to Linux. It runs linux containers (not darwin), plus can have rosetta. And I build multi arch images (arm64/amd64). It uses buildkit, the same Docker uses, so I am sure you can build Windows containers with it as well.
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.
How is the performance overhead of this compared to docker on MacOS?
I used to be very enthusiastic about docker compose, but I've been playing around with nix + process-compose lately and its pretty great. I can have k3s and tilt in there only when it's necessary--which it's usually not.
Nix is wonderful for reproducible and declarative infrastructure, but how do you manage multiple server instances with it? I have a handful of projects active at any time, and am currently running four web servers, three mysql instances, two postgres, and a partridge in a pear tree. Should I run Nix in Docker, Docker from Nix, or is there a nix-only solution for this?
There are tools such as deploy-rs, colmena, and morph that let you deploy nixOs configs using nix. I can't speak to how good they are personally, I use ansible to push my nix configs.
I may misunderstand your problem, but I just have a configuration repository for various "hosts". There are a couple of settings I share between them, and then just specify the differences.
"Deploying" one is as simple as `nixos-rebuild switch --flake .#hostName`
These are all dev environments running at the same time. I wasn't sure if Nix had some kind of port mapping or proxy config for this sort of thing. I'm still partial to having containers as self-contained build artifacts, I just like to have options as dev environments go, and "Docker from Nix" looks like the best option so far. But it's a vast ecosystem, and there's plenty I might be missing.
cool,, i have to check out process-compose.
Another year, another story written about the demise of Docker. This has been happening since before Kubernetes took off. My own take:
Docker had a choice of markets to go after, the enterprise market was being dominated by the hyperscalers pushing their own Kubernetes offerings. So they pivoted to focus on the developer tooling market. This is a hard market to make work, particularly since developers are very famous for not paying for tooling, but they appear to making a profit.
With Docker Hub, it's always been a challenge to limit how much that costs to run. And with more stuff being thrown in larger images, I don't want to see that monthly bill. The limits they added hurt, but also made a lot of people realize they should have been running their own mirror on-prem, if not only to better handle an upstream outage when us-east-1 has a bad day.
Everything else has been pushing into each of the various popular development markets, from AI, to offloading builds to the cloud, to Hardened Images. They release things for free when they need to keep up with the competition, and charge when enterprises will pay for it.
They've shifted their focus a lot over the years. My fear would be if they stayed stagnant, trying to extract rents without pushing into new offerings. So I'm not worried they'll fail this year, just like I wasn't worried any of the previous years when similar posts were made.
Reminds me a bit of stuff like curl - the importance of it and the monetization opportunities are out of sync. Tricky
I’m currently building a micro transaction version of `ls`
Not a charity - they’re going to want to see a viable eventual monetization path too
An AI version of ls and fzf bringing your file system to the AI age
I switched to Podman on Windows and found it less laggy, and it works fine for local development. I'm sure I'm missing some features, but as Docker continues to struggle to generate revenue, the open-source option will be important to an increasingly large part of the industry.
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.
> 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
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.
Seems like its a hole in the market if new services are cropping up. If there wasn't a hole then established clouds would have this. I don't have to think if I want a virtual machine booted with Ubuntu. I can do that in any cloud. How many have vibe coding support to launch containers that work locally in a cloud so they are accessible as a website? How many of those have a build process that does security checks and helps patch the code and automates building browser tests to verify the functionality keeps working (or kicks it back to the coding agent to fix)? Basically, the last 10% of the vibe coding a web app locally that isn't automated. This is a big opportunity for a semi established vendor like Docker that a startup would need users and capital (for bare metal) to fix. Two things that a Docker has at their disposal.
Those seems like such basic and tablestake features of such a platform, that I've assumed they all do something like that already. Is that not the case? Is it vibecoders who aren't programmers who are building these services or what's going on?
Sorry off topic question but has Docker come up with a easy to use dev solution. I always end up with using Devcontainer: it solves the sandboxed, ready to use dev env.
But the actual experience with developing on VSCode with Dev Containers is not great. It's laggy and slow.
Devcontainers are great for me on windows and macos. What stack are you using?
Really? I work across multiple vscode projects (locally), some use dev-containers and others don't. I have never noticed any difference in experience across the two.
I have also used them remotely (ssh and using tailscale) and noticed a little lag, but nothing really distracting.
Most likely a Windows or MacOS user, where docker runs in a linux VM. Optimized as much as possible and lightweight, but still a VM.
Windows is a bit "yes but" kind of situation.
First of all it supports containers natively, Windows own ones, and Linux on WSL.
Secondly, because Microsoft did not want to invent their own thing, the OS APIs are exposed the same way as Docker daemon would expect them.
Finally, with the goal to improving Kubernetes support and the ongoing changes for container runtimes in the industry, nowadays it exposes several touch points.
https://learn.microsoft.com/en-us/virtualization/windowscont...
No, on Windows it is very quick too. On WSL2 compiling Rust programs are almost as fast as Linux on bare metal. However the files need to live inside the Linux filesystem. Sharing with Windows drives actually compiles slower than native Windows.
You can use dev drives instead, I guess.
I just want to disable "Ask Gordon" in the sidebar. I don't want to see it. My brain works in weird ways. Whenever I see a name for the first time I attach that person to it.
Gordon is the character from Half Life.
Docker a piece of software. Don't anthropomorphize it.
Eventually there will be enough anthropomorphized pieces of software for everybody to have their "Alexa" moment. Mine came last year (thanks, Docker).
Gordon was the office pet tortoise if I recall, and might still be around given they may live a very long time. Thus it became the default user in parts of their software. =3
Gordon unfortunately passed away in 2023: https://x.com/solomonstre/status/1637537983988629504
In a way, it is fun the memory still affects design choices. =3
A few times I've wondered, where would Docker Inc be today if Microsoft acquired them back in 2017?
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.
I don't want Microsoft's fingers all over docker -- if anything that would have accelerated the rise of e.g. podman
> Docker created a standard so successful that it became infrastructure, and infrastructure is hard to monetize
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.
Imo the problem with SaaS products is that their revenue expectations are priced accordingly to the market they serve, not the money it takes recreating them.
If I wrote the best word processor in the world, I could probably sell it for a decent sum 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.
This is a great way of framing it that I'd never thought of before.
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.
> Open infrastructure is hard to monetize.
But not impossible. Terraform seems to have paid its creator quite well.
I think Hashicorp got out just in time. They are declining in recent years.
They are stagnant and their dev experience is very poor.
They're IBM now, I think they just consider you and me beneath their notice. I guess some things never change.
The "Fair Source" [1] and "Fair Code" [2] licenses are sustainable and user-friendly.
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
Charging companies for software is as old as computers itself. We don't have to imagine.
The idea of not compensating for software took hold in the 2000s, both with engineers and consumers (remember when users scoffed at 99 cent apps?)
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.
> As they scaled, it became impossible to compete.
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.
> The idea of not compensating for software took hold in the 2000s, both with engineers and consumers (remember when users scoffed at 99 cent apps?)
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...
> Imagine if Docker the company could charge AWS and Google for their use of their technology.
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).
> Imagine if Docker the company could charge AWS and Google for their use of their technology.
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.
I think this deserves a reframing: Docker is perhaps the greatest success story involving a massively invested tech company.
We got an amazing durable essential piece of software from someone investing billions of dollars.
Now, the fact that they didn't get their money back, well, who cares? Not me, it wasn't my money.
Sucks for them, maybe -- but that's far better than enshittification for everyone.
For a while, Docker seemed to focus on developer experience.
It is honestly incredible that such an important part of the Windows dev process is nearly unusable. It is easily the most fickle and opaque bit of software that I am required to depend upon.
Yep. I used to have a ton of problems with Docker in Windows.
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.
Docker on Windows issues, back before WSL had matured enough, gave a pretty compelling argument for doing windows development on OSX inside a VM.
at work, i opted for remote development workspace because of this problem. Windows & Docker ain't meant to be together :(
Windows is the problem, not Docker. Just try wsl2 and you’ll see…
That's a very naive take. The issue is Docker Desktop, a buggy mess. I have plenty of well-functioning, complex Windows applications with detailed troubleshooting utilities.
My favorite thing about Docker is that it spawned Podman.
Honestly I reach for podman or `nix develop` any chance I get. What is the edge that docker provides these days?
Docker, or rather containerd, still has better plugin ecosystem around it. Unregistry https://github.com/psviderski/unregistry, Nydus https://github.com/dragonflyoss/nydus, all the different "snapshotters" (storage formats), or the utils for sharing NVIDIA GPUs with containers, etc.
The gap with Podman is closing though, and most users don't need any of these in the first place.
How do you manage your containers in podman declaratively?
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.
The podman kube support? It provides similar functionality as docker-compose, using a yaml file which is a subset of the Kubernetes pod definition syntax.
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.
Podman supports Compose files, so there's that. I've only glimpsed at Quadlets and I agree they seem very esoteric, especially if you're not very well versed in systemd service definitions.
quadlets fully depend on systemd doing its work. So, assuming you are running rootless, if you change your quadlets, you will need
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.
Yeah I think Quadlet just has bad docs. They document the whole API but iirc there is no: ok this is the hello world for running cowsay as a systemd unit
What is the edge that docker provides these days?
> [...] without being on a Linux system.
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.
Huh. I tried docker. Didn’t like the odor of enshittification, and so switched to podman (desktop). I use it on macOS, and deploy on Ubuntu. It’s been smooth sailing.
I found the signal to noise ratio better in Podland. As a newb to docker space, I was overwhelmed with should I swarm, should I compose, what’s this register my thing? And people are freaking about root stuff. I’m sure I still only use and understand about 10% of the pod(man) space, buts way better than how I felt in the docker space.
I miss when software engineering put a high value on simplicity.
Fair! I haven’t done any container related activities on Windows.
> What is the edge that docker provides these days?
That you are not the average developer
Not very clear what you mean... well you haven't actually given them an answer to their question.
Are you suggesting that docker provides an (unspecified) edge to developers who are better than average? Or to those who are mediocre? Or...
I mean that the average developer will follow/use what has the most traction already and in the containers space, like it or not, it's still Docker.
Switched to OrbStack in one prompt using Claude. It’s a night and day difference
What's better about it?
Who wants to pay for chroot?
Ah - the old magic.
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.
You're missing image distribution, namespaces (networking, pids, mount, users), seccomp (to limit root powers), cgroups (to limit cpu and memory usage), and so much more. There's also Docker Hub with the official images they maintain. And the Desktop tooling makes an embedded Linux VM much easier to work with than spinning up your own VM, copying files around, and forwarding networking ports.
They enshittified/Dropboxified their core Docker Desktop app so much that OrbStack — I believe a single person initially — managed to build a better product. I love this outcome.
I was a contractor code money at a place automating $3M/yr in labor. We reported to a senior that did little programming if at all. He was older than me but newer than myself to the company, I was happy to avoid meetings and code.
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.