A new upstream project to break up Docker into independent components

[shykes]

Work has been ongoing to break Docker into modular components for some time, with runc and containerd as examples. Containerd for example has been donated to the CNCF. We are now completing this work with the goal being that the monolithic docker repo eventually ceases to exist, instead being assembled from a set of components.

Docker is, and will remain, a open source product that lets you build, ship and run containers. It is staying exactly the same from a user’s perspective. Users can download Docker from the docker.com website.

Moby is a project which provides a “Lego set” of dozens of components, the framework for assembling them into custom container-based systems, and a place for all container enthusiasts to experiment and exchange ideas. You can learn more at http://mobyproject.org

Docker the product will be assembled from components that are packaged by the Moby project.

The Moby project provides a command-line tool called moby which assembles components. Currently it assembles bootable OS images, but soon it will also be used by Docker for assembling Docker out of components, many of which will be independent projects.

As the Docker Engine continues to be split up into more components the Moby project will also be the home for those components until a more appropriate location is found.

Docker is transitioning all of its open source collaborations to the Moby project going forward.
During the transition, all open source activity should continue as usual.

This pull request changes the README and kicks off the process of breaking up the engine under Moby. Again: if you are a Docker user, nothing changes.

[AkihiroSuda]

Docker -> Moby?

[fsouza]

Is updating the import paths within the moby project part of the scope of this change?

Right now if I do go get -d github.com/moby/moby/... this repo will get cloned twice because moby's source is still using the import path github.com/docker/docker. And since go get doesn't do shallow clones, cloning this repo twice can take a lot of time, specially if you're using some conference's wifi :)

Thanks!

[fsouza]

Is updating the import paths within the moby project part of the scope of this change?

Right now if I do go get -d github.com/moby/moby/... this repo will get cloned twice because moby's source is still using the import path github.com/docker/docker. And since go get doesn't do shallow clones, cloning this repo twice can take a lot of time, specially if you're using some conference's wifi :)

Thanks!

[netroby]

Did that means docker will all to moby

docker run   =>  moby run 
docker build => moby build

Am i right?

[netroby]

Did that means docker will all to moby

docker run   =>  moby run 
docker build => moby build

Am i right?

[mwarkentin]

@netroby I think docker CE / EE will continue to exist, and the CLI will remain the same - however they'll be built out of these moby components.

[mwarkentin]

@netroby I think docker CE / EE will continue to exist, and the CLI will remain the same - however they'll be built out of these moby components.

[omeid]

This is not gonna work nice for all the projects that depend on github.com/docker/docker. No notice, nothing, and just breaking everything. Not cool.

[omeid]

This is not gonna work nice for all the projects that depend on github.com/docker/docker. No notice, nothing, and just breaking everything. Not cool.

[netroby]

The docker/docker repository does not exists. only moby/moby..

Where is the docker ce code? inside the moby project?

[netroby]

The docker/docker repository does not exists. only moby/moby..

Where is the docker ce code? inside the moby project?

[shykes]

@omeid nothing should break. We have moved the repo before (from the dotcloud org) and your go get should handle the redirect gracefully.

In parallel we are setting up a facade URL for go packages (which we should have done long ago) to separate package names from git hosting.

[shykes]

@omeid nothing should break. We have moved the repo before (from the dotcloud org) and your go get should handle the redirect gracefully.

In parallel we are setting up a facade URL for go packages (which we should have done long ago) to separate package names from git hosting.

[shykes]

@netroby the Docker CE code is spread out in dozens of repos: containerd, libnetwork, swarmkit etc. Some of it is in moby/moby, and is being spun out into new components until moby/moby only includes the tooling to assemble Docker CE from the components (or your custom alternative to Docker CE).

[shykes]

@netroby the Docker CE code is spread out in dozens of repos: containerd, libnetwork, swarmkit etc. Some of it is in moby/moby, and is being spun out into new components until moby/moby only includes the tooling to assemble Docker CE from the components (or your custom alternative to Docker CE).

[kunalkushwaha]

What are the plans for Infrakit and Swarmkit? Will they be part of docker.org or may come to Moby project, considering they are vital part of docker container platform.

[kunalkushwaha]

What are the plans for Infrakit and Swarmkit? Will they be part of docker.org or may come to Moby project, considering they are vital part of docker container platform.

[frekele]

It no makes sense to change the name of the project already widespread in the community, many projects will be broken because of this, change without any warning.
I think there is a lack of common sense with a community.

I'm very confused by this change.
Moby = Open Source Development?
Docker CE = Open Source Release to Production? Or commercial now? or Dead?
Docker EE = Commercial Release to Production? or Dead?

Where is the Docker CE now?

Sorry, but it's not clear to me. Could you explain the structure of the project better and how will the licenses stay?

[frekele]

It no makes sense to change the name of the project already widespread in the community, many projects will be broken because of this, change without any warning.
I think there is a lack of common sense with a community.

I'm very confused by this change.
Moby = Open Source Development?
Docker CE = Open Source Release to Production? Or commercial now? or Dead?
Docker EE = Commercial Release to Production? or Dead?

Where is the Docker CE now?

Sorry, but it's not clear to me. Could you explain the structure of the project better and how will the licenses stay?

[shykes]

@frekele

Moby = open source development
Docker CE = free product release based on Moby
Docker EE = commercial product release based on Docker CE.

Nothing is dead; and everything that was open-source remains open-source. In fact we are open-sourcing new things.

[shykes]

@frekele

Moby = open source development
Docker CE = free product release based on Moby
Docker EE = commercial product release based on Docker CE.

Nothing is dead; and everything that was open-source remains open-source. In fact we are open-sourcing new things.

[frekele]

Thank you @shykes for the feedback.

It would be interesting to create a migration guide from docker to moby, so we can better understand what it affects, before the next release.

[frekele]

Thank you @shykes for the feedback.

It would be interesting to create a migration guide from docker to moby, so we can better understand what it affects, before the next release.

[duffn]

Moby = open source development
Docker CE = free product release based on Moby
Docker EE = commercial product release based on Docker EE.

Nothing is dead; and everything that was open-source remains open-source. In fact we are open- sourcing new things.

@shykes This should be made markedly clearer then. A few line GitHub issue without additional reference is not enough for your many, many users.

[duffn]

Moby = open source development
Docker CE = free product release based on Moby
Docker EE = commercial product release based on Docker EE.

Nothing is dead; and everything that was open-source remains open-source. In fact we are open- sourcing new things.

@shykes This should be made markedly clearer then. A few line GitHub issue without additional reference is not enough for your many, many users.

[shykes]

@duffn understood we will refine the explanation. We wanted to get things started in the open as early as possible, so that we can prepare the transition in the open woth all the contributors and maintainers.

Note: for the huge majority of Docker users nothing changes at all: the binary packages remain exactly the same. The github repo is used by thousands of people - the binary packages by millions.

[shykes]

@duffn understood we will refine the explanation. We wanted to get things started in the open as early as possible, so that we can prepare the transition in the open woth all the contributors and maintainers.

Note: for the huge majority of Docker users nothing changes at all: the binary packages remain exactly the same. The github repo is used by thousands of people - the binary packages by millions.

[shykes]

@frekele good idea. the short version is that Docker CE and EE users are not affected at all. The binary releases remain exactly the same.

Moby will get its own release process - probably source releases instead of binary. We need to discuss with the maintainers what it will be. We have a summit thursday to get things started.

[shykes]

@frekele good idea. the short version is that Docker CE and EE users are not affected at all. The binary releases remain exactly the same.

Moby will get its own release process - probably source releases instead of binary. We need to discuss with the maintainers what it will be. We have a summit thursday to get things started.

[shykes]

@kunalkishwaha SwarmKit and InfraKit will remain standalone like today and will not be affected. We would like to move them into separate standalone github orgs to clarify that we want them to be open and not dependent on Docker. We will discuss that move with the maintainers first. We will use Moby to develop and integrate SwarmKit and InfraKit, but they will not be "owned" by Moby.

[shykes]

@kunalkishwaha SwarmKit and InfraKit will remain standalone like today and will not be affected. We would like to move them into separate standalone github orgs to clarify that we want them to be open and not dependent on Docker. We will discuss that move with the maintainers first. We will use Moby to develop and integrate SwarmKit and InfraKit, but they will not be "owned" by Moby.

[panuhorsmalahti]

Will Docker CE be in part proprietary in the future? (Maybe it already is and I missed the news).

[panuhorsmalahti]

Will Docker CE be in part proprietary in the future? (Maybe it already is and I missed the news).

[Vanuan]

@panuhorsemalahti AFAIK there was never a way to build Docker CE from sources. Now it seams there is.

I think it will be like Chrome vs Chromium.

[Vanuan]

@panuhorsemalahti AFAIK there was never a way to build Docker CE from sources. Now it seams there is.

I think it will be like Chrome vs Chromium.

[krasi-georgiev]

It took me a while and a bit of reading, but I think now I understand the idea and really like it.

The "docker" idea just goes a level deeper by using the Moby project to build the base OS on which to run the containers.

I think container oriented kernel changes would be one of good the side effects for this transition.

[krasi-georgiev]

It took me a while and a bit of reading, but I think now I understand the idea and really like it.

The "docker" idea just goes a level deeper by using the Moby project to build the base OS on which to run the containers.

I think container oriented kernel changes would be one of good the side effects for this transition.

[gaocegege]

Since moby and docker focus on different aspects, why not keep two repos 🤔

And, could moby build the unikernel, instead of minimal linux distribution?

Anyway, congratulations 🎉

[gaocegege]

Since moby and docker focus on different aspects, why not keep two repos 🤔

And, could moby build the unikernel, instead of minimal linux distribution?

Anyway, congratulations 🎉

[krasi-georgiev]

@gaocegege if I understand it correctly moby will use linuxkit as the moby base cli #32693 and looking at the linuxkit repo there is already support for unikernels.

https://github.com/linuxkit/linuxkit/tree/master/projects/miragesdk

[krasi-georgiev]

@gaocegege if I understand it correctly moby will use linuxkit as the moby base cli #32693 and looking at the linuxkit repo there is already support for unikernels.

https://github.com/linuxkit/linuxkit/tree/master/projects/miragesdk

[catap]

@shykes

Moby = open source development
Docker CE = free product release based on Moby
Docker EE = commercial product release based on Docker EE.

Am I right that Docker EE will be something not related to Docker CE/Moby?

[catap]

@shykes

Moby = open source development
Docker CE = free product release based on Moby
Docker EE = commercial product release based on Docker EE.

Am I right that Docker EE will be something not related to Docker CE/Moby?

[thaJeztah]

Am I right that Docker EE will be something not related to Docker CE/Moby?

The last line should probably be;

Docker EE = commercial product release based on Docker CE.

Docker EE is on the same code base as Docker CE, so also built from Moby, with commercial components added, such as "docker data center / universal control plane"

[thaJeztah]

Am I right that Docker EE will be something not related to Docker CE/Moby?

The last line should probably be;

Docker EE = commercial product release based on Docker CE.

Docker EE is on the same code base as Docker CE, so also built from Moby, with commercial components added, such as "docker data center / universal control plane"

[zaquestion]

classic

[zaquestion]

classic

[shykes]

@gaocegege we moved the repository because the first task of the Moby project is to break up the engine monolith into smaller components, and spin them out into separate repos. Once that is complete, Moby will be an integration repository, with the tools necessary to combine upstream components into a complete system.

What we want to do (and clearly we need to communicate this better) is ask for the contributor's help in making this happen. Let's finish breaking up the monolith together - and then let's make Moby the best place to assemble the components in many different ways, so that everyone can do whatever they want with them.

[shykes]

@gaocegege we moved the repository because the first task of the Moby project is to break up the engine monolith into smaller components, and spin them out into separate repos. Once that is complete, Moby will be an integration repository, with the tools necessary to combine upstream components into a complete system.

What we want to do (and clearly we need to communicate this better) is ask for the contributor's help in making this happen. Let's finish breaking up the monolith together - and then let's make Moby the best place to assemble the components in many different ways, so that everyone can do whatever they want with them.

[shykes]

To clarify the "production chain", from upstream to downstream:

upstream components (containerd, linuxkit etc) -> Moby -> Docker CE -> Docker EE.

[shykes]

To clarify the "production chain", from upstream to downstream:

upstream components (containerd, linuxkit etc) -> Moby -> Docker CE -> Docker EE.

[AkihiroSuda]

+1 for technical modularization of current engine, but I fear separating GitHub repo can cause vendoring hell.
How about creating multiple "module" directories on single repo so as to avoid vendor hell?

[AkihiroSuda]

+1 for technical modularization of current engine, but I fear separating GitHub repo can cause vendoring hell.
How about creating multiple "module" directories on single repo so as to avoid vendor hell?

[ghost]

I think under the target audience section at mobyproject.org gives a bit more clarification to whom the Moby project is recommended for or not:

Moby is recommended for anyone who wants to assemble a container-based system, this includes:

• Hackers who want to customize or patch their Docker build
• System engineers or integrators building a container system
• Infrastructure providers looking to adapt existing container systems to their environment
• Container enthusiasts who want to experiment with the latest container tech
• Open-source developers looking to test their project in a variety of different systems
• Anyone curious about Docker internals and how it’s built

Moby is NOT recommended for:

• Application developers looking for an easy way to run their applications in containers. We recommend Docker CE instead.
• Enterprise IT and development teams looking for a ready-to-use, commercially supported container platform. We recommend Docker EE instead.
• Anyone curious about containers and looking for an easy way to learn. We recommend the docker.com website instead.

[ghost]

I think under the target audience section at mobyproject.org gives a bit more clarification to whom the Moby project is recommended for or not:

Moby is recommended for anyone who wants to assemble a container-based system, this includes:

• Hackers who want to customize or patch their Docker build
• System engineers or integrators building a container system
• Infrastructure providers looking to adapt existing container systems to their environment
• Container enthusiasts who want to experiment with the latest container tech
• Open-source developers looking to test their project in a variety of different systems
• Anyone curious about Docker internals and how it’s built

Moby is NOT recommended for:

• Application developers looking for an easy way to run their applications in containers. We recommend Docker CE instead.
• Enterprise IT and development teams looking for a ready-to-use, commercially supported container platform. We recommend Docker EE instead.
• Anyone curious about containers and looking for an easy way to learn. We recommend the docker.com website instead.

[rseymour]

this is a qwiksterious decision

[rseymour]

this is a qwiksterious decision

[zachdaniel]

EDIT: I guess this isn't the first place that my coworkers and I were supposed to hear about this (was just told there were some blog posts?) so take my below comment with a grain of salt

To be honest, even after reading this issue, lots of people are freaking out like they won't be able to say docker build . any more and how thats going to break all of their deployments. This seems like relatively poor communication. I would advise making this more clear, because from what I can tell this is a positive organizational change that shouldn't have any backwards compatibility issues for the vast majority of users.

[zachdaniel]

EDIT: I guess this isn't the first place that my coworkers and I were supposed to hear about this (was just told there were some blog posts?) so take my below comment with a grain of salt

To be honest, even after reading this issue, lots of people are freaking out like they won't be able to say docker build . any more and how thats going to break all of their deployments. This seems like relatively poor communication. I would advise making this more clear, because from what I can tell this is a positive organizational change that shouldn't have any backwards compatibility issues for the vast majority of users.

[naglalakk]

I agree. Docker or Moby or whatever you are called now. This is very poor management. Loads of users rely on your products and it's worrying to see that you keep making spontant decisions like this. It's not the first one, your take on versioning was also very weird and the communication around that was very bad. It's worrying to the point that I'm reconsidering if I should continue using your products at all. I have no idea what you will do tomorrow. Maybe you will rename this project to moby/dick or something. If you could give a clear explanation on why this name change is so important that would be great.

[naglalakk]

I agree. Docker or Moby or whatever you are called now. This is very poor management. Loads of users rely on your products and it's worrying to see that you keep making spontant decisions like this. It's not the first one, your take on versioning was also very weird and the communication around that was very bad. It's worrying to the point that I'm reconsidering if I should continue using your products at all. I have no idea what you will do tomorrow. Maybe you will rename this project to moby/dick or something. If you could give a clear explanation on why this name change is so important that would be great.

[k-s-dean]

Can we have a referendum on the name, how about, boaty mcboat face. and it looks like they did choose the name based on moby-dick...... poor choices "everywhere".

[k-s-dean]

Can we have a referendum on the name, how about, boaty mcboat face. and it looks like they did choose the name based on moby-dick...... poor choices "everywhere".

[vdemeester]

Because the sources changed place (with redirection and all so it really shouldn't break anybody but it's computer science, you never know 👼), doesn't mean the binaries and documentation of docker changes or will ever change. Same goes for backward compatibility, it's priority number 1 to not break compatibility during this move !

@zachdaniel definitely we need to make a better README and a better coverage on what is really happening, how and when it is/will happens. We're working on that 😉

[vdemeester]

Because the sources changed place (with redirection and all so it really shouldn't break anybody but it's computer science, you never know 👼), doesn't mean the binaries and documentation of docker changes or will ever change. Same goes for backward compatibility, it's priority number 1 to not break compatibility during this move !

@zachdaniel definitely we need to make a better README and a better coverage on what is really happening, how and when it is/will happens. We're working on that 😉

[saurfangg]

Moby = open source development
Docker CE = free product release based on Moby
Docker EE = commercial product release based on Docker CE.

It would have made more sense to call your new, commercial product the new name (moby) and not retroactively go back and freak your users out, but just my 2 cents.

[saurfangg]

Moby = open source development
Docker CE = free product release based on Moby
Docker EE = commercial product release based on Docker CE.

It would have made more sense to call your new, commercial product the new name (moby) and not retroactively go back and freak your users out, but just my 2 cents.

[joshuatalb]

I agree - there's been poor communication surrounding the name change etc. However, I'm sure this is a positive split that will help advance the Docker/Moby/container eco-system. I'm looking forward to seeing what this brings, but please, better comms next time!

[joshuatalb]

I agree - there's been poor communication surrounding the name change etc. However, I'm sure this is a positive split that will help advance the Docker/Moby/container eco-system. I'm looking forward to seeing what this brings, but please, better comms next time!

[tharanga-abeyseela]

this will be a huge mess..

[tharanga-abeyseela]

this will be a huge mess..

[JonasT]

@Vanuan based on the large amount of downvotes I am guessing that probably a lot of people misunderstood what is going on here based on early conclusions drawn just from the post description without actually reading the change in-depth.

(Edit: I could be wrong of course. I was just explaining why I think even more clarity and big arrows towards the full explanation might not hurt)

[JonasT]

@Vanuan based on the large amount of downvotes I am guessing that probably a lot of people misunderstood what is going on here based on early conclusions drawn just from the post description without actually reading the change in-depth.

(Edit: I could be wrong of course. I was just explaining why I think even more clarity and big arrows towards the full explanation might not hurt)

[omeid]

If Moby is going to be the upstream for Docker CE/EE why was the move necessary? Couldn't just docker/docker start using components from moby/moby?

[omeid]

If Moby is going to be the upstream for Docker CE/EE why was the move necessary? Couldn't just docker/docker start using components from moby/moby?

[cten]

@thaJeztah I would suggest closing this to comments, nothing constructive is coming from this comment section.

[cten]

@thaJeztah I would suggest closing this to comments, nothing constructive is coming from this comment section.

[Vanuan]

@omeid I think the motivation is that it's easier to move Docker CLI/Engine out of the docker repo than to move the build infrastructure and make Docker CLI/Engine use it.

See it yourself: you have the following components: docker/cli, docker/api, docker/engine, docker/moby
There's no way you can keep docker/docker because there's no such thing.

Also, GitHub issues should be in the larger-scope project.

[Vanuan]

@omeid I think the motivation is that it's easier to move Docker CLI/Engine out of the docker repo than to move the build infrastructure and make Docker CLI/Engine use it.

See it yourself: you have the following components: docker/cli, docker/api, docker/engine, docker/moby
There's no way you can keep docker/docker because there's no such thing.

Also, GitHub issues should be in the larger-scope project.

[omeid]

@Vanuan My understanding is, as per @shykes comments here and elsewhere, that Docker CE as distribution will continue to exist, that means there is going to be a docker product somewhere that pulls the engine, cli, et al to effectively give you what docker/docker is today.

Please correct me if I am wrong.

[omeid]

@Vanuan My understanding is, as per @shykes comments here and elsewhere, that Docker CE as distribution will continue to exist, that means there is going to be a docker product somewhere that pulls the engine, cli, et al to effectively give you what docker/docker is today.

Please correct me if I am wrong.

[Vanuan]

@omeid I don't think it's true. Take Fedora for example. There's no git repository that pulls Fedora. There are hundreds of repos and none of them is called Fedora.

Similar situation in the android community: there's a script that pulls android components and it isn't called android. Nonetheless multiple smartphone producers can build custom-made android distributions. There are also AOSP builds available for multiple devices.

[Vanuan]

@omeid I don't think it's true. Take Fedora for example. There's no git repository that pulls Fedora. There are hundreds of repos and none of them is called Fedora.

Similar situation in the android community: there's a script that pulls android components and it isn't called android. Nonetheless multiple smartphone producers can build custom-made android distributions. There are also AOSP builds available for multiple devices.

[omeid]

So where does the Docker CE fits in here? Is Docker CE gone?

[omeid]

So where does the Docker CE fits in here? Is Docker CE gone?

[Vanuan]

I believe there would be a script or a tool in this repository that will allow to build Docker CE. There's this new moby tool which supposed to be used to build multiple docker distributions.

[Vanuan]

I believe there would be a script or a tool in this repository that will allow to build Docker CE. There's this new moby tool which supposed to be used to build multiple docker distributions.

[JonasT]

What about making a text files only docker/docker-ce repo which lists the components that are used and points any confused readers to the actual build scripts (possibly in other repos) that are used to obtain the docker-ce package as we all know it? That would also explain better to anyone confused by the moby change where all of it went, and how all of moby is put together for the actual docker-ce.

[JonasT]

What about making a text files only docker/docker-ce repo which lists the components that are used and points any confused readers to the actual build scripts (possibly in other repos) that are used to obtain the docker-ce package as we all know it? That would also explain better to anyone confused by the moby change where all of it went, and how all of moby is put together for the actual docker-ce.

[Vanuan]

@JonasT That would be great. I think it'll be that way eventually.

[Vanuan]

@JonasT That would be great. I think it'll be that way eventually.

[Fonger]

So it means that repository names starting with moby is not allowed either? LOL

[Fonger]

So it means that repository names starting with moby is not allowed either? LOL

[shykes]

@JonasT yes good idea, we will create a repo that can build "Docker CE for Linux".

[shykes]

@JonasT yes good idea, we will create a repo that can build "Docker CE for Linux".

[shykes]

@omeid you are correct Docker CE continues to exist as you describe. It will expand in scope to fit the equivalent of Docker for Mac, Docker for AWS... which today have more components built-in than "Docker for Linux".

[shykes]

@omeid you are correct Docker CE continues to exist as you describe. It will expand in scope to fit the equivalent of Docker for Mac, Docker for AWS... which today have more components built-in than "Docker for Linux".

[ravibhure]

@shykes How this meant for current docker which is in production or heavily on dev infrastructure ?

[ravibhure]

@shykes How this meant for current docker which is in production or heavily on dev infrastructure ?

[shykes]

@ravibhure current Docker users are not affected, Docker remains exactly the same. You can get the latest Docker CE package for your package on docker.com, the same way as before.

[shykes]

@ravibhure current Docker users are not affected, Docker remains exactly the same. You can get the latest Docker CE package for your package on docker.com, the same way as before.

[omeid]

Let me ask it like it is, I depend on docker (the current standard distribution) both as a Go package and as a running daemon for a lot of my projects and my clients. What should I plan ahead? How much work should I expect to put in?

[omeid]

Let me ask it like it is, I depend on docker (the current standard distribution) both as a Go package and as a running daemon for a lot of my projects and my clients. What should I plan ahead? How much work should I expect to put in?

[Wirone]

Isn't Moby too busy with making music so he won't be able to handle all the building stuff? How this guy will do this single handedly.. All tech people, all the companies will rely on one bald guy with glasses.. I guess at some point he will say "I just cannot contain this" (pun intended).

[Wirone]

Isn't Moby too busy with making music so he won't be able to handle all the building stuff? How this guy will do this single handedly.. All tech people, all the companies will rely on one bald guy with glasses.. I guess at some point he will say "I just cannot contain this" (pun intended).

[apakhomov]

Did you try to use google when choosing new name? Now everybody will have to filter a lot of search rubbish about musician, moby dick, moby explorer, mobile applications etc when searching moby-related issues? Awesome

[apakhomov]

Did you try to use google when choosing new name? Now everybody will have to filter a lot of search rubbish about musician, moby dick, moby explorer, mobile applications etc when searching moby-related issues? Awesome

[shykes]

@omeid no work to plan. Nothing will change for you. Just keep installing Docker from the docker.com packages as usual. Same for the Go packages.

[shykes]

@omeid no work to plan. Nothing will change for you. Just keep installing Docker from the docker.com packages as usual. Same for the Go packages.

[brettdh]

For further clarification on the respective roles of Docker and Moby, please see this link.

@shykes did you mean to include a link there? 🙂 Maybe this one?

[brettdh]

For further clarification on the respective roles of Docker and Moby, please see this link.

@shykes did you mean to include a link there? 🙂 Maybe this one?

[JonET]

Appropriate:
https://www.youtube.com/watch?v=5Og42ldefVc

[JonET]

Appropriate:
https://www.youtube.com/watch?v=5Og42ldefVc

[lukemarsden]

@brettdh yes that's the right link

[lukemarsden]

@brettdh yes that's the right link

[frekele]

As the thread was unfolding with community input and comments from @shykes I began to understand the real purpose of this change. And I truly fully agree that the moby project only brings more advantages to the open source community.

This will bring more Collaboration of the community, and each time we will have a more incredible tool beyond what it already is.

An interesting post about this.
https://thenewstack.io/docker-seeds-two-new-projects-building-containerized-infrastructure/

I believe this image says a lot about docker/moby changes.

*Thus far, Docker already has a library of more than 80 containerized components, including Swarm, containerd, Docker Build and even LinuxKit. Many third-party components are now hard-wired into Linux distributions. Docker is welcoming more contributions from the community.here

Now with moby we can also have a third-party Moby projects.
With moby, now many components that were previously attached to the docker, will be linked to the moby, thereby generating more feedback, issues, PR of the community.

I think it's going to be this way now.

Correct me if I'm wrong. Please. 🙏 😄

[frekele]

As the thread was unfolding with community input and comments from @shykes I began to understand the real purpose of this change. And I truly fully agree that the moby project only brings more advantages to the open source community.

This will bring more Collaboration of the community, and each time we will have a more incredible tool beyond what it already is.

An interesting post about this.
https://thenewstack.io/docker-seeds-two-new-projects-building-containerized-infrastructure/

I believe this image says a lot about docker/moby changes.

*Thus far, Docker already has a library of more than 80 containerized components, including Swarm, containerd, Docker Build and even LinuxKit. Many third-party components are now hard-wired into Linux distributions. Docker is welcoming more contributions from the community.here

Now with moby we can also have a third-party Moby projects.
With moby, now many components that were previously attached to the docker, will be linked to the moby, thereby generating more feedback, issues, PR of the community.

I think it's going to be this way now.

Correct me if I'm wrong. Please. 🙏 😄

[fatherlinux]

@frekele while, I really want to believe this is a good move for the community, there is one critical component missing. In the drawings referenced, there is no mention of the docker command, docker daemon, and Dockerfile. There is no mention of whether they stay in the Moby project/repo or are separated out into another repository.

Either way, if they remain named docker daemon, docker command, and Dockerfile, it prevents any other company from extracting any value from their contributions to these projects because only Docker Inc. retains the rights to use the docker name.

As somebody who has targeted and refined my career over the last 4 years based on Docker/Containers, I can no longer extract value from that participation directly without becoming a Docker EE reseller of some kind. I can't build a company doing consulting on the docker daemon, Dockerfiles because that would be a breach Docker Inc's usage policy.

In fact, nobody can build anything downstream from Moby that includes the docker daemon, command or Dockerfile and talk about it in any sane way. The docker daemon absolutely needs renamed or Docker Inc is the only company that can extract value.

Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to extract downstream value. If the goal is openness, then I ask Docker Inc. to rename the docker daemon to mobyd, the command to moby, and the Dockerfile to Mobyfile. Then, anybody can build downstream value. I personally, am very upset. (opinions here my own, not those of my employer Red Hat).

[fatherlinux]

@frekele while, I really want to believe this is a good move for the community, there is one critical component missing. In the drawings referenced, there is no mention of the docker command, docker daemon, and Dockerfile. There is no mention of whether they stay in the Moby project/repo or are separated out into another repository.

Either way, if they remain named docker daemon, docker command, and Dockerfile, it prevents any other company from extracting any value from their contributions to these projects because only Docker Inc. retains the rights to use the docker name.

As somebody who has targeted and refined my career over the last 4 years based on Docker/Containers, I can no longer extract value from that participation directly without becoming a Docker EE reseller of some kind. I can't build a company doing consulting on the docker daemon, Dockerfiles because that would be a breach Docker Inc's usage policy.

In fact, nobody can build anything downstream from Moby that includes the docker daemon, command or Dockerfile and talk about it in any sane way. The docker daemon absolutely needs renamed or Docker Inc is the only company that can extract value.

Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to extract downstream value. If the goal is openness, then I ask Docker Inc. to rename the docker daemon to mobyd, the command to moby, and the Dockerfile to Mobyfile. Then, anybody can build downstream value. I personally, am very upset. (opinions here my own, not those of my employer Red Hat).

[shykes]

@frekele that's exactly right! Thank you for the extended drawing, and for taking the time to write this.

[shykes]

@frekele that's exactly right! Thank you for the extended drawing, and for taking the time to write this.

[shykes]

On Saturday, April 22, 2017, Scott McCarty ***@***.***> wrote: @frekele <https://github.com/frekele> while, I really want to believe this is a good move for the community, there is one critical component missing. In the drawings referenced, there is no mention of the docker command, docker daemon, and Dockerfile. There is no mention of whether they stay in the Moby project/repo or are separated out into another repository.

This is clearly explained in the proposed new README. Take the time to read the contents of this PR, it says that: - The docker daemon will be split into independent components, so will be replaced by multiple daemons. - The docker CLI and sdk will remain open-source in the docker organization. - The Dockerfile support is tied into the daemon, so will remain in the moby repo until it's spun out into an independent component. At that point we will have to work out together if Dockerfile and its syntax should be built-in, or more of an optional frontend, with the possibility for anyone to create their own custom build frontend. For example @ibuildthecloud has made a compelling argument for the latter. You're welcome to join that design discussion of course.

Either way, if they remain named docker daemon, docker command, and Dockerfile, it prevents any other company from extracting any value from their contributions to these projects because only Docker Inc. retains the rights to use the docker name. As somebody who has targeted and refined my career over the last 4 years based on Docker/Containers, I can no longer extract value from that participation directly without becoming a Docker EE reseller of some kind. I can't build a company doing consulting on the docker daemon, Dockerfiles because that would be a breach Docker Inc's usage policy. In fact, nobody can build anything downstream from Moby that includes the docker daemon, command or Dockerfile and talk about it in any sane way. The docker daemon absolutely needs renamed or Docker Inc is the only company that can extract value. Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to extract downstream value. If the goal is openness, then I ask Docker Inc. to rename the docker daemon to mobyd, the command to moby, and the Dockerfile to Mobyfile. Then, anybody can build downstream value. I personally, am very upset. (opinions here my own, not those of my employer Red Hat).

It's good to clarify that you are upset personally as an open-source contributor, not as the marketing manager for the Red Hat containers commercial offering. That would have been a shame since I remember spending several months explaining the upcoming change to Red Hat leadership, incorporating their feedback, and making sure they understood the change and agreed with it - after all, they did the same thing with Fedora back in the day. Then your employer agreed to publically support the change since it was clearly better for the community. If hypothetically you were speaking as a marketing manager at Red Hat, then that would lower my esteem for your employer quite a bit: breaking a commitment to me and not even having the courage to make it their official position - instead sending you to "be concerned". Fortunately like you said, you are *not* speaking as a marketing manager at Red Hat, so it's all good. You are of course entitled to be concerned, I hope my answer above helps address your concerns as an individual open-source contributor. I believe that Moby will make it easier, not harder, to extract value from your open-source contributions.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32691 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABzfQFZ_MHI2oD_WamJ10-LVLEFb6gVks5ryhyOgaJpZM4NAdPR> .

[shykes]

On Saturday, April 22, 2017, Scott McCarty ***@***.***> wrote: @frekele <https://github.com/frekele> while, I really want to believe this is a good move for the community, there is one critical component missing. In the drawings referenced, there is no mention of the docker command, docker daemon, and Dockerfile. There is no mention of whether they stay in the Moby project/repo or are separated out into another repository.

This is clearly explained in the proposed new README. Take the time to read the contents of this PR, it says that: - The docker daemon will be split into independent components, so will be replaced by multiple daemons. - The docker CLI and sdk will remain open-source in the docker organization. - The Dockerfile support is tied into the daemon, so will remain in the moby repo until it's spun out into an independent component. At that point we will have to work out together if Dockerfile and its syntax should be built-in, or more of an optional frontend, with the possibility for anyone to create their own custom build frontend. For example @ibuildthecloud has made a compelling argument for the latter. You're welcome to join that design discussion of course.

Either way, if they remain named docker daemon, docker command, and Dockerfile, it prevents any other company from extracting any value from their contributions to these projects because only Docker Inc. retains the rights to use the docker name. As somebody who has targeted and refined my career over the last 4 years based on Docker/Containers, I can no longer extract value from that participation directly without becoming a Docker EE reseller of some kind. I can't build a company doing consulting on the docker daemon, Dockerfiles because that would be a breach Docker Inc's usage policy. In fact, nobody can build anything downstream from Moby that includes the docker daemon, command or Dockerfile and talk about it in any sane way. The docker daemon absolutely needs renamed or Docker Inc is the only company that can extract value. Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to extract downstream value. If the goal is openness, then I ask Docker Inc. to rename the docker daemon to mobyd, the command to moby, and the Dockerfile to Mobyfile. Then, anybody can build downstream value. I personally, am very upset. (opinions here my own, not those of my employer Red Hat).

It's good to clarify that you are upset personally as an open-source contributor, not as the marketing manager for the Red Hat containers commercial offering. That would have been a shame since I remember spending several months explaining the upcoming change to Red Hat leadership, incorporating their feedback, and making sure they understood the change and agreed with it - after all, they did the same thing with Fedora back in the day. Then your employer agreed to publically support the change since it was clearly better for the community. If hypothetically you were speaking as a marketing manager at Red Hat, then that would lower my esteem for your employer quite a bit: breaking a commitment to me and not even having the courage to make it their official position - instead sending you to "be concerned". Fortunately like you said, you are *not* speaking as a marketing manager at Red Hat, so it's all good. You are of course entitled to be concerned, I hope my answer above helps address your concerns as an individual open-source contributor. I believe that Moby will make it easier, not harder, to extract value from your open-source contributions.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32691 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABzfQFZ_MHI2oD_WamJ10-LVLEFb6gVks5ryhyOgaJpZM4NAdPR> .

[fatherlinux]

On 04/22/2017 12:57 PM, Solomon Hykes wrote: On Saturday, April 22, 2017, Scott McCarty ***@***.***> wrote: > @frekele <https://github.com/frekele> while, I really want to believe > this is a good move for the community, there is one critical component > missing. In the drawings referenced, there is no mention of the docker > command, docker daemon, and Dockerfile. There is no mention of whether they > stay in the Moby project/repo or are separated out into another repository. > This is clearly explained in the proposed new README. Take the time to read the contents of this PR, it says that:

Clearly, there is some kind of disconnect. I read this [1] and there is no mention of dockerd. [1]: https://github.com/moby/moby/blob/master/README.md

- The docker daemon will be split into independent components, so will be replaced by multiple daemons. - The docker CLI and sdk will remain open-source in the docker organization.

This will essentially make Docker CE, the only place where all of these components come together and AFAIK, per the EULA, this is not Open Source. So, this is effectively a dissolution of the original docker project.

- The Dockerfile support is tied into the daemon, so will remain in the moby repo until it's spun out into an independent component. At that point we will have to work out together if Dockerfile and its syntax should be built-in, or more of an optional frontend, with the possibility for anyone to create their own custom build frontend. For example @ibuildthecloud has made a compelling argument for the latter. You're welcome to join that design discussion of course.

I am excited to join the discussion.

> Either way, if they remain named docker daemon, docker command, and > Dockerfile, it prevents any other company from extracting any value from > their contributions to these projects because only Docker Inc. retains the > rights to use the docker name. > > As somebody who has targeted and refined my career over the last 4 years > based on Docker/Containers, I can no longer extract value from that > participation directly without becoming a Docker EE reseller of some kind. > I can't build a company doing consulting on the docker daemon, Dockerfiles > because that would be a breach Docker Inc's usage policy. > > In fact, nobody can build anything downstream from Moby that includes the > docker daemon, command or Dockerfile and talk about it in any sane way. The > docker daemon absolutely needs renamed or Docker Inc is the only company > that can extract value. > > Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to > extract downstream value. If the goal is openness, then I ask Docker Inc. > to rename the docker daemon to mobyd, the command to moby, and the > Dockerfile to Mobyfile. Then, anybody can build downstream value. > > I personally, am very upset. (opinions here my own, not those of my > employer Red Hat). > It's good to clarify that you are upset personally as an open-source contributor, not as the marketing manager for the Red Hat containers commercial offering. That would have been a shame since I remember spending several months explaining the upcoming change to Red Hat leadership, incorporating their feedback, and making sure they understood the change and agreed with it - after all, they did the same thing with Fedora back in the day. Then your employer agreed to publically support the change since it was clearly better for the community. If hypothetically you were speaking as a marketing manager at Red Hat, then that would lower my esteem for your employer quite a bit: breaking a commitment to me and not even having the courage to make it their official position - instead sending you to "be concerned". Fortunately like you said, you are *not* speaking as a marketing manager at Red Hat, so it's all good. You are of course entitled to be concerned, I hope my answer above helps address your concerns as an individual open-source contributor. I believe that Moby will make it easier, not harder, to extract value from your open-source contributions.

Since, you were involved in those discussions, you are already aware that I was not involved in any of those conversations, nor any decisions contributing to this move to Moby. You are correct, as a Technical Marketing Manager, I have been evangelizing the docker project and technology for the last 3 years of my life. I have written countless blog entries, done countless demos, taught countless classes/tutorials, and literally convinced hundreds if not thousands of individuals to use or think about using docker containers. I contributed to the CIS Bechmark work, answered hundreds if not thousands of technical questions in the community, and have spoken all over the world about docker. So, with all of that said, forgive me if I have a personal reaction to the change in the project. I hope your above comment is your personal opinion, because if your condescending attitude was the official position of Docker Inc. it would lower my esteem for that organization as well. And, at the end of of all of this, no matter what happens, I don't get to cash out, my stake is merely emotional...

…

> — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#32691 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AABzfQFZ_MHI2oD_WamJ10-LVLEFb6gVks5ryhyOgaJpZM4NAdPR> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32691 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHLZXfi6KVBnFcEYtadEGGD-wpmgv8Sks5ryjGTgaJpZM4NAdPR>.

-- Scott McCarty scott.mccarty@gmail.com http://crunchtools.com @fatherlinux

[fatherlinux]

On 04/22/2017 12:57 PM, Solomon Hykes wrote: On Saturday, April 22, 2017, Scott McCarty ***@***.***> wrote: > @frekele <https://github.com/frekele> while, I really want to believe > this is a good move for the community, there is one critical component > missing. In the drawings referenced, there is no mention of the docker > command, docker daemon, and Dockerfile. There is no mention of whether they > stay in the Moby project/repo or are separated out into another repository. > This is clearly explained in the proposed new README. Take the time to read the contents of this PR, it says that:

Clearly, there is some kind of disconnect. I read this [1] and there is no mention of dockerd. [1]: https://github.com/moby/moby/blob/master/README.md

- The docker daemon will be split into independent components, so will be replaced by multiple daemons. - The docker CLI and sdk will remain open-source in the docker organization.

This will essentially make Docker CE, the only place where all of these components come together and AFAIK, per the EULA, this is not Open Source. So, this is effectively a dissolution of the original docker project.

- The Dockerfile support is tied into the daemon, so will remain in the moby repo until it's spun out into an independent component. At that point we will have to work out together if Dockerfile and its syntax should be built-in, or more of an optional frontend, with the possibility for anyone to create their own custom build frontend. For example @ibuildthecloud has made a compelling argument for the latter. You're welcome to join that design discussion of course.

I am excited to join the discussion.

> Either way, if they remain named docker daemon, docker command, and > Dockerfile, it prevents any other company from extracting any value from > their contributions to these projects because only Docker Inc. retains the > rights to use the docker name. > > As somebody who has targeted and refined my career over the last 4 years > based on Docker/Containers, I can no longer extract value from that > participation directly without becoming a Docker EE reseller of some kind. > I can't build a company doing consulting on the docker daemon, Dockerfiles > because that would be a breach Docker Inc's usage policy. > > In fact, nobody can build anything downstream from Moby that includes the > docker daemon, command or Dockerfile and talk about it in any sane way. The > docker daemon absolutely needs renamed or Docker Inc is the only company > that can extract value. > > Open source projects like Linux, Apache, KDE, etcd, etc allow ANYBODY to > extract downstream value. If the goal is openness, then I ask Docker Inc. > to rename the docker daemon to mobyd, the command to moby, and the > Dockerfile to Mobyfile. Then, anybody can build downstream value. > > I personally, am very upset. (opinions here my own, not those of my > employer Red Hat). > It's good to clarify that you are upset personally as an open-source contributor, not as the marketing manager for the Red Hat containers commercial offering. That would have been a shame since I remember spending several months explaining the upcoming change to Red Hat leadership, incorporating their feedback, and making sure they understood the change and agreed with it - after all, they did the same thing with Fedora back in the day. Then your employer agreed to publically support the change since it was clearly better for the community. If hypothetically you were speaking as a marketing manager at Red Hat, then that would lower my esteem for your employer quite a bit: breaking a commitment to me and not even having the courage to make it their official position - instead sending you to "be concerned". Fortunately like you said, you are *not* speaking as a marketing manager at Red Hat, so it's all good. You are of course entitled to be concerned, I hope my answer above helps address your concerns as an individual open-source contributor. I believe that Moby will make it easier, not harder, to extract value from your open-source contributions.

Since, you were involved in those discussions, you are already aware that I was not involved in any of those conversations, nor any decisions contributing to this move to Moby. You are correct, as a Technical Marketing Manager, I have been evangelizing the docker project and technology for the last 3 years of my life. I have written countless blog entries, done countless demos, taught countless classes/tutorials, and literally convinced hundreds if not thousands of individuals to use or think about using docker containers. I contributed to the CIS Bechmark work, answered hundreds if not thousands of technical questions in the community, and have spoken all over the world about docker. So, with all of that said, forgive me if I have a personal reaction to the change in the project. I hope your above comment is your personal opinion, because if your condescending attitude was the official position of Docker Inc. it would lower my esteem for that organization as well. And, at the end of of all of this, no matter what happens, I don't get to cash out, my stake is merely emotional...

…

> — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#32691 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AABzfQFZ_MHI2oD_WamJ10-LVLEFb6gVks5ryhyOgaJpZM4NAdPR> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32691 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHLZXfi6KVBnFcEYtadEGGD-wpmgv8Sks5ryjGTgaJpZM4NAdPR>.

-- Scott McCarty scott.mccarty@gmail.com http://crunchtools.com @fatherlinux

[zouyee]

Moby Dick

[zouyee]

Moby Dick

[ozbillwang]

our model is closer to the Red Hat model: we do everything in the open, in a fast-moving project where everyone can participate. Then we integrate, test and harden downstream into a supported enterprise product.

so docker as Red Hat, moby as centos?

[ozbillwang]

our model is closer to the Red Hat model: we do everything in the open, in a fast-moving project where everyone can participate. Then we integrate, test and harden downstream into a supported enterprise product.

so docker as Red Hat, moby as centos?

[Vanuan]

so docker as Red Hat, moby as centos?

I would think it's more like this:

Docker EE = RHEL
Docker CE = CentOS
Moby project = Fedora project

[Vanuan]

so docker as Red Hat, moby as centos?

I would think it's more like this:

Docker EE = RHEL
Docker CE = CentOS
Moby project = Fedora project

[fatherlinux]

Docker CE can't be CentOS because CentOS is a downstream build of Red Hat Enterprise Linux. The Red Hat relationship is below, each step is a selection, packaging and/or hardening process of the upstream because they are ALL open source:

Linux & Community Projects-> Fedora -> Red Hat -> CentOS

With Docker it's more like:

Community Projects (Containerd, Dockerd (maybe), Runc) -> Moby -> Docker CE -> Docker EE -> Dead End (because Docker EE is not made of all open source components. Docker EE adds proprietary components, RHEL does not).

[fatherlinux]

Docker CE can't be CentOS because CentOS is a downstream build of Red Hat Enterprise Linux. The Red Hat relationship is below, each step is a selection, packaging and/or hardening process of the upstream because they are ALL open source:

Linux & Community Projects-> Fedora -> Red Hat -> CentOS

With Docker it's more like:

Community Projects (Containerd, Dockerd (maybe), Runc) -> Moby -> Docker CE -> Docker EE -> Dead End (because Docker EE is not made of all open source components. Docker EE adds proprietary components, RHEL does not).

[jberkus]

@fatherlinux although to be fair, years ago, Red Hat used to have proprietary components (I'm talking about 2002 here).

We don't know that Docker EE will have proprietary components; @shykes has said they'll be open-sourcing some of the things which are currently proprietary. Let's give them a chance, eh?

For my part, a complete Moby kit will make it easier to release the version of Docker (or Moby) we want in Fedora. At least, theoretically. Some of us have been after Docker for the last year and more to "break up the monolith", and now they're doing it, so I think at least a bit of cheering them on is in order.

[jberkus]

@fatherlinux although to be fair, years ago, Red Hat used to have proprietary components (I'm talking about 2002 here).

We don't know that Docker EE will have proprietary components; @shykes has said they'll be open-sourcing some of the things which are currently proprietary. Let's give them a chance, eh?

For my part, a complete Moby kit will make it easier to release the version of Docker (or Moby) we want in Fedora. At least, theoretically. Some of us have been after Docker for the last year and more to "break up the monolith", and now they're doing it, so I think at least a bit of cheering them on is in order.

[jberkus]

BTW, @shykes, we have a bunch of community experts in Fedora-land, happy to discuss the new setup if we can help!

[jberkus]

BTW, @shykes, we have a bunch of community experts in Fedora-land, happy to discuss the new setup if we can help!

[shykes]

@jberkus I would love that, thank you for offering. I will contact you on your profile email to pick your brains, if that's OK.

[shykes]

@jberkus I would love that, thank you for offering. I will contact you on your profile email to pick your brains, if that's OK.