Comment by shykes
10 hours ago
This is incorrect.
Docker in its earlier incarnations was based on openvz, which predates lxc. The lxc project was initially a kernel development project: a collection of kernel patches to add container support. The userland tool was just a companion. When it became apparent that these patches would "win" the race to be upstreamed even though openvz was much more mature, we switched our tooling to lxc. The patches matured over time, but the userland tool (what we now know as "lxc") was finicky.
The original open-source release of Docker wrapped lxc for low-level container operations. But it was just too unreliable and we swapped it out for an in-house Go implementation called "libcontainer".
As for "commercializing": Docker was famously bad at commercializing anything, we open sourced so much (maybe too much) and still people complained that we were not open enough.
“Docker was famously bad at commercializing anything, we open sourced so much (maybe too much) and still people complained that we were not open enough”
Developers are a tough market to please, especially when your business revolves around open source software.
Unless you have an option to do private cloud hosting (like all these databases and other platforms do), it’s incredibly difficult to monetize.
In the case of docker, I think it’s in the nature of the product that it’s difficult to monetize. Best you can do is enterprise support contracts, but those aren’t good enough to justify all that VC funding.
I don't think it's necessarily that difficult to monetize, they just ignored a lot of the needs of enterprise users (rootless, not punching holes in the firewall, not fighting with systemd, private registries) for long enough that other projects (e.g. Podman, Quay) filled the void.
None of those things were obstacles to commercialization. None of them were common requests from enterprise customers except private registries, which Docker did build.
Podman has never been commercialized.
Docker's difficulties in commercializing were self-inflicted. Enterprise and open source teams were culturally siloed and as a result the enterprise products were not "native". There was a lack of focus and a "checkbox" approach to building product. There was no singular "dictator" who could enforce a coherent product design and vision, and it showed. etc.
> Docker was famously bad at commercializing anything
That's because there was never a proper sysadmin on your team to slap some sense in your decisions.
You've got too opinionated[0], too tied on yourself[1] monster which required too much resources what you can handle alone.
And your market is not the developers but the companies where whose developers have a daytime jobs: https://news.ycombinator.com/item?id=46739153
[1] Eg: the syntax to point the image to a specific registry is something... bad. So bad I just abandoned running my own registry, it wasn't worth it.
PS there is still (AFAIK) no support for a transaction-like image building in Compose. So instead of something like this:
people need to write these one-liner abominations:
EDIT: to add on [1]: https://news.ycombinator.com/item?id=35312087
> You've got too opinionated [0]
>>[0] 'Bridge' was and still is an established network term for joining two broadcast domains into one. Why the hell you decided to name your NAT'ed network layer a 'bridge'?
Like they told you 9 months ago, the terminology is exactly right. They're called "bridge" networks because they use Linux `bridge` devices to bridge `tap` adapters of all containers attached to the same Docker network.
There's nothing exotic about this terminology at all and complaining about it betrays your own lack of knowledge.
> PS there is still (AFAIK) no support for a transaction-like image building in Compose. So instead of something like this:
Do you mean Dockerfiles? RUN command has had heredoc support for 5 years now.
https://docs.docker.com/reference/dockerfile/#run
2 replies →
In the end, how were you able to monetize Docker?
[flagged]
Earlier incarnations of the project (2008-2011) were python based on openvz+aufs, with the very first prototypes (2007-08) wrapping vserver. We started the transition to lxc+aufs in 2011. Open-sourced the lxc wrapper in 2013. Replaced it with libcontainer in... 2014 I believe?