Hacker News Reader

Comment by curun1r | Hacker News Reader

Again, that's a relatively-recent branding decision on your part. It's pretty meaningless to people that have spent more than a year trying to explain to people what Docker is and why we should use it. Trying to go back to those people now to switch terminology is, at best a massive headache and, at worst, going to get containerization efforts canceled.

View on HN

I'm not sure I understand the problem. Whatever containerization project you were building on top of Docker, it is just as viable today as yesterday. No option has been removed - if anything there are now more options available to you. All new versions of Docker remain backwards-compatible with previous versions. And components of Docker which were previously not available standalone, now are.

What exactly would you like Docker to do, that we're not currently doing?

What you're missing is the ecosystem vs platform distinction. A platform is yours to control and an ecosystem has a life of its own. You're right that everything that was possible still is. But docker, as a term, developed in ways not controlled by you. It took on a meaning that's probably more limited than you'd like. And it developed momentum that can't be stopped or diverted by a marketing strategy and a press release from Docker, Inc.

You're not the first company that's had to deal with this. To me, it's similar to Google's failed attempts to keep people from using their name as a verb. You're both companies that has a wildly successful initial product that got associated with your company's name and that hindered attempts to branch out from that initial offering. But the more you try to repurpose the term to refer to your broader offering rather than the narrower base layer that it started out as, the more you create problems for those of us that have spent a lot of time and effort selling your approach within our organizations. Not everyone is sold on containerization and we (your advocates) have people that will pounce on any confusion as a way to push back.

Decision-makers in organizations are often surprisingly non-technical. Imagine if there were a company behind email. And that company wanted to make money selling add-on services like encryption and mailing list management. So it decided to call the base email layer libsmtpd and repurpose the term email to mean the broader platform offering. Now imagine you've got to explain this change to your elderly mother who's just gotten over the hump and gotten comfortable with sending email and referring to email correctly.

That's kinda the position you're putting us in.

Very well said!

I understand what you're saying. And you would be 100% correct if everyone shared your definition of Docker as a tiny container runtime and nothing else. But that is not at all the case. There are conflicting narratives of what Docker is and isn't. And where you see the mystical forces of brand destiny deciding which narrative will win - I have seen the kitchen where the branding sausage is made. And believe me there is nothing magical about it. Some vendors want you to believe Docker is a component, so they spend money in marketing programs and suddenly you're hearing through various channels that Docker is a component. We in turn want you to know that Docker is a product, we invest in telling you that story, and here we are.

The difference is that we invented Docker. We understand its future potential and control its design and trademark. Our competitors don't.

So I'm sorry that you have a different definition of Docker than the people who invented Docker. But just like Google decides what Google is - Docker decides what Docker is.

If Google decided to pivot to a lunch delivery service and shut their search offerings, people would still 'google' things.

I'm sorry you feel that way.

For what it's worth, my notion of what Docker is comes from having run it in production since before the transition away from LXC. I ran a small team inside a relatively large company (8000 employees, $25B mkt cap) and we largely had control over our own ops. We ran into a lot of early adopter pains, but the benefits definitely outweighed the pain.

I was also in various architecture groups that made decisions for the larger products at the company. I was always honest about the drawbacks, but I pushed for limited exploratory projects using Docker to try to slowly move ops in that direction. I had a lot of opposition from ops folks that never felt the pain of the developer experience and worried that Docker was an encroachment on their fiefdom (GoT had nothing on our internal politics :-)

Slowly, we (I wasn't the only Docker supporter at the company) made progress. We set up a Quay private registry server so that, at least, teams could begin to experiment. And when I met your team at re:invent and heard that you were developing your own offering for private registry, I convinced them to switch. The first-party argument was easy to make and the company didn't really quibble about sub-7-figure software purchases.

I ended up leaving that company last year, so your current direction isn't really making my life harder, but had I stayed,it would be. If you want to be explicit in your targeting of a different market segment from the kind of early adopter that I am/was, that's fine. But don't accuse me of having my view shaped by competitors' marketing. That's a highly revisionist view of your own history. Because when I got on the Docker bandwagon, the reality absolutely matched what I'm describing. Docker was the base layer and a prefix added to related product offerings. But it wasn't a platform like you're describing. That seems like it's changed now, which would've really screwed me in trying to push Docker at my previous employer.

None of that has changed. Docker is still targeted explicitly at your use case. I believe your project would have been just fine. Docker EE was shaped by requirements very similar to your own. But I can't seem to convince you of that... Sorry if I'm not being clear. Maybe we can discuss in person one of these days :)

@curun1r

Maybe you should face and accept the fact that Docker is not going in the direction you need it to, and its future plans are not aligned with your interest.

These are perfectly reasonable reasons for a company to cancel the efforts and avoid the headache.

A comment on a news will not put it back on the "right" track. Don't invest in risky and uncertain products.

We are going in the direction he wants us to. We're just doing it under the name "containerd" and he's unhappy that we're not calling it "Docker". If he were to simply accept our choice of naming, 100% of his issues would go away.

>> accept our choice of naming,

Therefore you are not going in the direction he wants you to.

The name for that is "Docker" and it has been for many years already. You can't just rename things to fit your new marketing strategy and pretend that your users won't get hurt.

If you could simply erase the memory of all inhabitants of Earth and rename all books and articles even written, then yes, there would be no issues in renaming.

I don't understand this level of outrage. In any case being outraged doesn't make you right, and it doesn't authorize you to twist the facts. So let's compare your claim that Docker was "just a container runtime" for years, and we are suddenly changing that to "fit our marketing strategy", whatever that means. For reference here is the changelog of Docker: https://github.com/docker/docker/blob/master/CHANGELOG.md

- Docker has included a container build system since version 0.3 in May 2013. https://github.com/docker/docker/blob/master/CHANGELOG.md#03...

- Docker has included image storage and distribution since the version 0.1 in March 2013. https://github.com/docker/docker/blob/master/CHANGELOG.md#01...

- The official website has said "Docker is a platform to build, ship and run distributed applications" since 2014, and clearly featuring the collection of multiple tools forming that platform. https://web.archive.org/web/20141216011043/https://www.docke...

- Docker has included a distributed key-value store and optional multi-host networking since version 1.7 in June 2015. https://github.com/docker/docker/blob/master/CHANGELOG.md#17...

- Docker has included orchestration since 1.12 in June 2016.

- Docker has included cryptographic content trust since version 1.8 in August 2015. https://blog.docker.com/2015/08/content-trust-docker-1-8/

- Docker has included secrets management since 1.13 in February 2017. https://blog.docker.com/2017/02/docker-secrets-management/

- Docker for Mac and Windows have included a built-in hypervisor and OS since March 2016. https://blog.docker.com/2016/03/docker-for-mac-windows-beta/

- Docker for AWS and Azure have also included a built-in OS since June 2016. https://blog.docker.com/2016/06/azure-aws-beta/

- Docker started gradually factoring out its container runtime in 2013. First with libcontainer; then with runc/OCI; and most recently with containerd. https://containerd.tools

- containerd in particular exists since 2015; and it's been over a year since Docker doesn't perform any container runtime task itself - it's all handed off to containerd.

I could go on. Docker has said clearly and consistently, for several years now, that it is building a platform made of a collection of tools, including but not limited to a core container runtime. You just didn't want to hear that explanation, either because you didn't like it, or because someone other than Docker (perhaps a competitor) gave you an incorrect explanation of what Docker is.

And now that the dissonance is becoming hard to ignore, you're forced to reconcile your incorrect definition of Docker with the real definition, and it makes you angry. But, like I said, being angry doesn't make you right. And it doesn't put you above having to provide evidence of your claims. So, can you provide concrete evidence that we are "hurting our users"?

I think Solomon has hit the nail on the head here, but I'll call it out even more starkly.

Assuming containerd is successful, and that higher-order systems like Kubernetes and Mesos use containerd directly, we will see one of two things in 12-18 months time: 1) There are hundreds of thousands of DOCKER users 2) There are hundreds of thousands of CONTAINERD users

The split is forcing stratification (in a good way) where there previously was none. Users have to identify whether they think "docker" means "a container runtime" or "a full stack".

Of course, the pie is growing, so maybe we get both results. The real problems over the next 12-18 months are MESSAGING and DISENTANGLING. How do you get this message across to people, and can you actually change the words in the common vernacular?

As owners of the word "Docker" Solomon can define it how he likes, but that doesn't mean he can actually stop people from using it to mean something else. That's going to be a process.

c.f. "literally". Even Webster's Dictionary has given up the fight on that.

Reply on news.ycombinator.com