Hi! Thanks for offering an AMA here. I don't have a specific question, but I am interested in hearing about the general story of what it was like developing Docker, what the experience was like trying to build a business around it, and what you're up to these days in post-Docker life. Thanks in advance!
I also recently discovered a trove of my old presentations, retracing my early obsession with the same problem, and my repeated failed attempts to get people to care. I shared some of them in a talk a few weeks ago: https://www.youtube.com/watch?v=huRfsLMK5sA
Imitation is the highest form of flattery! Obviously there was demand for an alternative to Docker that was native to the Red Hat platform. We couldn't offer that (although we tried in the early days) so it made sense that they would.
In the early days we tried very hard to accommodate their needs, for example by implementing support for devicemapper as an alternative to aufs. I remember spending many hours in their Boston office whiteboarding solutions. But we soon realized our priorities were fundamentally at odds: they cared most about platform lock-in, and we cared most about platform independence. There was also a cultural issue: when Red Hat contributes to open source it's always from a position of strength. If a project is important to them, they need merge authority - they simply don't know how to meaningfully contribute to an upstream project when they're not in charge. Because of the diverging design priorities, they never earned true merge rights on the repo: they had to argue for their pull requests like everyone else, and input from maintainers was not optional. Many pull requests were never merged because of fundamental design issues, like breaking compatibility with non-Red Hat platforms. Others because of subjective architecture disagreements. They really didn't like that, which led to all sorts of drama and bad behavior. In the process I lost respect for a company I once admired.
I also think they made a mistake marketing podman as a drop-in replacement to Docker. This promise of compatibility limited their design freedom and I'm sure caused the maintainers a lot of headaches- compatibility is hard!
Ultimately the true priority of podman - native integration with the Red Hat platform - makes it impossible for it to overtake Docker. I'm sure some of the podman authors would like to jettison that constraint, but I don't think that's structurally possible. Red Hat will never invest in a project that doesn't contribute to their platform lock-in. Back when RH was a dominant platform, that was a strength. Nowadays it is a hindrance.
There was probably a lot going on behind closed doors, but from the outside, it appeared that RedHat was trying to improve the security and technical details of containers, but Docker was just refusing pull requests and not playing nice. This eventually drove RedHat to make their own implementation (i.e. Podman), so it was a self created enemy and not necessarily one that was built-in/inevitable.
I'm definitely not a fan of RedHat's moves since being acquired, but at least from the outside, this looked like Docker being arrogant and problematic and not a "RedHat problem".
We heard the feedback that we should pick a lane between CI and AI agents. We're refocusing on CI.
We're making Dagger faster, simpler to adopt.
We're also building a complete CI stack that is native to Dagger. The end-to-end integration allows us to do very magical things that traditional CI products cannot match.
We're looking for beta testers! Email me at solomon@dagger.io
Dagger has been a godsend in helping me cope with the unending misery that is GitHub Actions. A big thanks to you and the whole team at Dagger for making this possible.
Yes, I am the co-founder of Docker and also of Dagger. The other two co-founders of Dagger, Sam Alba and Andrea Luzzardi, were early employees of Docker.
The companies themselves are not related beyond that.
Only listen to your users and customers, ignore everyone else.
Don't hire an external CEO unless you're ready to leave. Hiring a CEO will not fix the loneliness of not having a co-founder.
Having haters is part of success. Accept it, and try to not let it get to you.
Don't partner with Red Hat. They are competitors even though they're not honest about it.
Not everyone hates you even though it may seem that way on hacker news and twitter. People actually appreciate your work and it will get better. Keep going.
'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'?
As far as I know, Docker uses the term "bridge" in the standard way, to designate the use of Linux bridge interfaces (basically virtual ethernet switches) to interconnect containers. Containers connect to each other via a layer 2 bridge, not NAT.
It has as much sense as calling all the car roads in the world 'bridges'. They are interconnecting some areas via a physical connection, not some 5th dimension magik, after all.
It's even more egregious with 'ipvlan' and 'macvlan' drivers:
> ipvlan Connect containers to external VLANs.
Duh, that's a 'routed network' and nobody cares if it's on a separate vlan or not.
> macvlan Containers appear as devices on the host's network.
Which reminds me that BuildKit does not have support for specifying a network which is crazy given how you can configure the daemon to not attach one by-default.
Yes, of course. I was also an avid user of vserver and openvz on Linux, back when they required patching the kernel, and lxc didn't exist yet.
When we open sourced Docker, we had considerable experience running openvz in production, as well as migrating to lxc - a miserable experience in the early days because the paint was still so fresh. To my knowledge we were the very first production deployment of managed databases and multi-tenant application servers on lxc, back in 2010.
It's a common misconception that Docker was a naive reinvention of, or a thin wrapper around, pre-existing technology like solaris zones or lxc. In reality that is not the case. Those technologies were always intended as alternative forms of virtualization: a new way to slice up a machine. Docker was the first to use container and copy-on-write tech for the purpose of packaging and distributing applications, rather than provisioning machines. Before Docker, nobody would ever consider running a linux container or solaris zone on top of a VM: that would be nonsensical because they were considered to be at the same layer of the stack. Sun invented a lot of things, but they did not everything :)
Hi! Thanks for offering an AMA here. I don't have a specific question, but I am interested in hearing about the general story of what it was like developing Docker, what the experience was like trying to build a business around it, and what you're up to these days in post-Docker life. Thanks in advance!
It's difficult to tell the whole story in a HN comment, but if you're interested, I did share my experience in a few podcasts over the years. Here are a few that I could find on youtuve: https://www.youtube.com/watch?v=UVED44sb7zg https://www.youtube.com/watch?v=MSlHvz57RKs
I also recently discovered a trove of my old presentations, retracing my early obsession with the same problem, and my repeated failed attempts to get people to care. I shared some of them in a talk a few weeks ago: https://www.youtube.com/watch?v=huRfsLMK5sA
What's the most important thing for Docker, Inc. to do right now?
I would say: listen to your customers. Listen to your engineers. Don't overhire. Pick your battles carefully. Don't tolerate mediocre VPs.
All generic advice since I don't have inside information.
What are your thoughts on Podman?
Imitation is the highest form of flattery! Obviously there was demand for an alternative to Docker that was native to the Red Hat platform. We couldn't offer that (although we tried in the early days) so it made sense that they would.
In the early days we tried very hard to accommodate their needs, for example by implementing support for devicemapper as an alternative to aufs. I remember spending many hours in their Boston office whiteboarding solutions. But we soon realized our priorities were fundamentally at odds: they cared most about platform lock-in, and we cared most about platform independence. There was also a cultural issue: when Red Hat contributes to open source it's always from a position of strength. If a project is important to them, they need merge authority - they simply don't know how to meaningfully contribute to an upstream project when they're not in charge. Because of the diverging design priorities, they never earned true merge rights on the repo: they had to argue for their pull requests like everyone else, and input from maintainers was not optional. Many pull requests were never merged because of fundamental design issues, like breaking compatibility with non-Red Hat platforms. Others because of subjective architecture disagreements. They really didn't like that, which led to all sorts of drama and bad behavior. In the process I lost respect for a company I once admired.
I also think they made a mistake marketing podman as a drop-in replacement to Docker. This promise of compatibility limited their design freedom and I'm sure caused the maintainers a lot of headaches- compatibility is hard!
Ultimately the true priority of podman - native integration with the Red Hat platform - makes it impossible for it to overtake Docker. I'm sure some of the podman authors would like to jettison that constraint, but I don't think that's structurally possible. Red Hat will never invest in a project that doesn't contribute to their platform lock-in. Back when RH was a dominant platform, that was a strength. Nowadays it is a hindrance.
There was probably a lot going on behind closed doors, but from the outside, it appeared that RedHat was trying to improve the security and technical details of containers, but Docker was just refusing pull requests and not playing nice. This eventually drove RedHat to make their own implementation (i.e. Podman), so it was a self created enemy and not necessarily one that was built-in/inevitable. I'm definitely not a fan of RedHat's moves since being acquired, but at least from the outside, this looked like Docker being arrogant and problematic and not a "RedHat problem".
5 replies →
> They really didn't like that, which led to all sorts of drama and bad behavior.
Which stand out? Any particular mailing list or github issue discussions?
What's next for Dagger? Any upcoming features?
Yes :)
We heard the feedback that we should pick a lane between CI and AI agents. We're refocusing on CI.
We're making Dagger faster, simpler to adopt.
We're also building a complete CI stack that is native to Dagger. The end-to-end integration allows us to do very magical things that traditional CI products cannot match.
We're looking for beta testers! Email me at solomon@dagger.io
Dagger has been a godsend in helping me cope with the unending misery that is GitHub Actions. A big thanks to you and the whole team at Dagger for making this possible.
1 reply →
Really happy to hear this. I was tinkering with Dagger soon before the pivot to AI, and assumed this would not be solving my CI woes anytime soon.
Focusing on CI would still enable the AI stuff too! But my use case is CI, no AI.
1 reply →
This is the way
Wait Dagger and Docker are related?
Yes, I am the co-founder of Docker and also of Dagger. The other two co-founders of Dagger, Sam Alba and Andrea Luzzardi, were early employees of Docker.
The companies themselves are not related beyond that.
What would you have done differently in retrospect?
What I would tell my younger self:
Only listen to your users and customers, ignore everyone else.
Don't hire an external CEO unless you're ready to leave. Hiring a CEO will not fix the loneliness of not having a co-founder.
Having haters is part of success. Accept it, and try to not let it get to you.
Don't partner with Red Hat. They are competitors even though they're not honest about it.
Not everyone hates you even though it may seem that way on hacker news and twitter. People actually appreciate your work and it will get better. Keep going.
How did it feel the first time you or someone on your team built a container and ran it?
'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'?
As far as I know, Docker uses the term "bridge" in the standard way, to designate the use of Linux bridge interfaces (basically virtual ethernet switches) to interconnect containers. Containers connect to each other via a layer 2 bridge, not NAT.
It has as much sense as calling all the car roads in the world 'bridges'. They are interconnecting some areas via a physical connection, not some 5th dimension magik, after all.
It's even more egregious with 'ipvlan' and 'macvlan' drivers:
> ipvlan Connect containers to external VLANs.
Duh, that's a 'routed network' and nobody cares if it's on a separate vlan or not.
> macvlan Containers appear as devices on the host's network.
And this is a bridge!
Which reminds me that BuildKit does not have support for specifying a network which is crazy given how you can configure the daemon to not attach one by-default.
Did you know Solaris zones at all before creating Docker?
Yes, of course. I was also an avid user of vserver and openvz on Linux, back when they required patching the kernel, and lxc didn't exist yet.
When we open sourced Docker, we had considerable experience running openvz in production, as well as migrating to lxc - a miserable experience in the early days because the paint was still so fresh. To my knowledge we were the very first production deployment of managed databases and multi-tenant application servers on lxc, back in 2010.
It's a common misconception that Docker was a naive reinvention of, or a thin wrapper around, pre-existing technology like solaris zones or lxc. In reality that is not the case. Those technologies were always intended as alternative forms of virtualization: a new way to slice up a machine. Docker was the first to use container and copy-on-write tech for the purpose of packaging and distributing applications, rather than provisioning machines. Before Docker, nobody would ever consider running a linux container or solaris zone on top of a VM: that would be nonsensical because they were considered to be at the same layer of the stack. Sun invented a lot of things, but they did not everything :)
[flagged]
Not interested, sorry.
Sure thing! Thank you for the reply.