Live data from Hacker News

A new upstream project to break up Docker into independent components

github.com

271–280 of 321 posts

Re: A new upstream project to break up Docker into independent components

#271
post #229

Earlier quoted context omitted.

Many people really love the name Docker. Could you explain the reasoning behind the need for a new name? I ask this because would it not have been a better choice to name the other releases differently. For example: Docker (docker/docker) = open source development. Docker CE (docker/docker-community) = free product release Docker EE (docker/docker-enterprise) = commercial product release based on Docker CE (private).…

We're separating the upstream open-source project , and the downstream open-source product under 2 different names, because a lot of people in the open-source community asked us to. It's a common concern in the free software community that having an open-source project too tightly coupled to a single company's product is a bad thing. Moving the upstream open-source project into Moby, and keeping the downstream open-s…

> We're separating the upstream open-source project, and the downstream open-source product under 2 different names

I think a lot of the confusion comes from the downstream product split between Docker CE and Docker EE.

Many people are waiting for the other shoe to drop, because the point of releasing a separate binary version for 'CE' and 'EE' versions is very vague if the products are identical, with the extra EE functionality not really being necessary since it can be added via external services like DDC or plugins for LDAP authentication.

Is Docker EE also open-source?

Breaking out core Docker into components sourced in an external project like Moby makes it easier for you to replace the OSS components of Docker EE one piece at a time with your own private, closed-source versions where the paid development is focused.

So you get Docker CE which pulls all components entirely from Moby, then you get Docker EE which starts off identical. Then at some point you fork an individual Moby component, add some enterprise feature, and Docker EE now pulls from this. Docker EE is now a variant that's "mostly" open source with that one closed component. This component is focused and optimized for enterprise for a bit, then the same thing is done with a different component.

Rinse, repeat. "Docker EE" drifts away from its open source roots and over time loses resemblance to the original project while still taking advantage of the brand that's been built and maintained by thousands of contributors. Essentially, it's a way to co-opt an open-source product.

That's the source of my initial misgiving, anyway.

I get it, you're a business and you want to make money. Just stop being coy about Docker EE and Docker CE continuing to be identical except for the 'support and certification' mentioned in the Docker EE announcement.

Re: A new upstream project to break up Docker into independent components

#272

Earlier quoted context omitted.

It's gonna take more than a github announcement to refresh the memory of 1 million developers ;)

Pretty sure that's exactly what Docker is counting on. Otherwise what used to be called Docker would continue to be called Docker.

What used to be called Docker does, in fact, continue to be called Docker.

Re: A new upstream project to break up Docker into independent components

#273

Earlier quoted context omitted.

Do you know that keeping your users in a constant state of confusion is not the way to convince them that you're building a stable and secure product? Also, isn't it kind of ironic that you built your company on OSS and then invited a well known destroyer of OSS onto your main stage? Plus, I want my DockerCon money back. What exactly did you announce besides multi-stage builds at the general sessions that is actually…

Happily stopped using Docker when they began removing key features - even in the face of widespread user protest , https://github.com/moby/moby/pull/5001

I recently went through a Docker Pluralsight course that made extensive use of this removed feature. I can scarcely imagine the politics behind this but it makes things much more confusing and the third party open source tool people recommend to replace it is difficult to use and doesn't provide the same information.

Re: A new upstream project to break up Docker into independent components

#274
post #213
post #60

Earlier quoted context omitted.

Hi, I'm the founder of Docker. That is very surprising and absolutely not OK. I'm sorry that you experienced this. Could you contact me directly at solomon@docker.com to give me more details? There is no animosity towards kubernetes, quite the contrary. We are working with the kubernetes community to integrate the individual components of Docker, so that everyone can reuse each other's code and ideas. For example: -…

Hi Solomon, Thanks for responding. There really isn't many more details other than that. It was in DockerCon Seattle in the space needle. I don't remember who the employee was. I did generally get the feeling that Docker employees felt at least wary or worse about k8s. That was from more than just that once situation, but from multiple interactions I had over the conference with employees. I only pointed out that one…

>I did generally get the feeling that Docker employees felt at least wary or worse about k8s.

I'm no k8s fanboy (and I have the comment history full of replies from annoyed k8s contributors to prove it), but it's because they know that Kubernetes is going to end them. It relegates Docker to a swappable implementation detail.

Re: A new upstream project to break up Docker into independent components

#275
post #203

Earlier quoted context omitted.

I don;t think that is really what happened. :) As part of the runtime abstraction, kubernetes must necessarily decide how to handle stdout/stderr logs. Not having a decision for something at a given point in time is not exactly a bad thing.

Thanks, this seemed to be quite unusual decision to be made by the Kubernetes dev community, that's why I've asked.

Hi, I'm from sig-node. We just don't have enough time/people to cover all log management in 1.6, this is just a temp workaronud so we can ship CRI in time. Log mgmt, together with some other missing parts will be definitely picked up after CRI fully released.

Re: A new upstream project to break up Docker into independent components

#276
post #229

Earlier quoted context omitted.

We're separating the upstream open-source project , and the downstream open-source product under 2 different names, because a lot of people in the open-source community asked us to. It's a common concern in the free software community that having an open-source project too tightly coupled to a single company's product is a bad thing. Moving the upstream open-source project into Moby, and keeping the downstream open-s…

> We're separating the upstream open-source project, and the downstream open-source product under 2 different names I think a lot of the confusion comes from the downstream product split between Docker CE and Docker EE. Many people are waiting for the other shoe to drop, because the point of releasing a separate binary version for 'CE' and 'EE' versions is very vague if the products are identical, with the extra EE f…

Docker EE already works the way you describe. DDC is now part of Docker EE, which makes EE quite different from CE.

I want to address your concern but don't really understand what it is. What exactly are you worried will happen, and how does it affect you?

Re: A new upstream project to break up Docker into independent components

#277
post #194
post #75

Hi all, Docker founder here. It appears that the explanation in the pull request is not very clear. Sorry about that. We didn't expect the PR to be the first thing people read: there is a new website at mobyproject.org. Unfortunately Github is struggling under the load, and I can't update the PR text to clarify. Here is an updated version with some clarifications: Docker is transitioning all of its open source collab…

So all books about Docker are now outdated. What will happen with hub.docker.com? Is store.docker.com the replacement? Or will both coexist? Which one will be hosted on mobyproject.org ?

Books are for history, fiction and resume's.

Re: A new upstream project to break up Docker into independent components

#278

Earlier quoted context omitted.

The object "Docker" has been in dissonance for quite a while now, both by the company's perspective and the consumer's perspective. I think rationalizing it as a "brand" move is a bit simplistic. It is a FACT that individuals are unable to use the term "Docker" on anything they would like to create and share with others. This has been enforced with takedown notices and legal entities getting involved in "protecting"…

"I've seen the gleam in people's eyes when they talk about a ubiquitous computing infrastructure, of which it will run their code, without question, and never, ever breaks. " This seems to be a much higher level construct , like PaaS or Lambda, than what Docker provides. Docker was more of a bottom-up wake up call to those upper layers that lower layer technology usability still matters.

I never said otherwise. Again, the idea people hold about a technology, with a given tag, is moving in the direction of what they expect as users of said infrastructure. Please note that I did indicate this was an irrational belief. Whether or not Docker actually does this thing people understand it to be is another argument entirely.

Re: A new upstream project to break up Docker into independent components

#279
post #132
post #86

Earlier quoted context omitted.

That's just silly. Kubernetes is an open source project too, and I don't think Google is making a ton of money from it.

Smaller vendors are making money from turnkey k8s. There are at least two I won't mention. Docker is out on a limb with the dynamic mesh, nobody else is using the p2p gossip protocol that I know of and there are problems, and Docker paid-for support is just dropping tickets related to networking issues making this work. The service outages caused by mesh gossip problems are simply measureable by NewRelic free ping sy…

Consul is all p2p gossip, and it seems to be pretty popular.

Re: A new upstream project to break up Docker into independent components

#280

Earlier quoted context omitted.

Yup, and your's as well, by extension. I'd add that the rebrand needed to happen, given naming a company and a product the same thing is never a good idea.

Except the company and product still have the same name, it is just the open source project's name which is changing.

I suppose at this point we should ask ourselves why everyone keeps repeating the same thing over and over again. That's irrationality defined.

You appear to be disagreeing with something I said, so I have to assume it's based on the assertion that naming a company AND product the same thing is usually a bad idea, at least for marketing purposes. The confusion that has arisen with other products in the past is real, and it's clear that people are confused with this move. That's why I said it. I didn't say it to be completely precise about what happened, because people aren't precise in understanding how companies market to them. It's a common mistake in marketing, of which I am moderately skilled, or so I hear.

Anyway, I would say, in general terms, that reality is perceived differently from person to person. This means that some may conceptually map a concept to a word in a completely different way than another. That some are confused about this particular change in mapping is a good indication that my recommendation is a sound one, where the product, company, project and repo should be called different things to avoid branding confusion[1] when the consumer is making a decision.

I would also add that this behavior of companies "being confused" in return to people's confusion resulting from a change in branding of something is also an indication of irrationality. And, it's also blaming in tone to assume people should "just get it" when these things are executed on poorly, at least marketing-wise.

[1] https://hbr.org/2002/03/brand-confusion

Post reply on HN