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

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.

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.

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

Wait Dagger and Docker are related?

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.

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 :)

Not interested, sorry.