Problem statement

The moby repository is the home for the Moby Project, an open framework to assemble specialized container systems. It was started in the context of separating the Docker product from the Project itself to allow more innovation.

However, the transition to Moby is not yet complete and this is causing confusion. There are still things to change in this repo to complete that transition and we'd like to make sure we cover it all in this issue. We would like to resolve this issue in a short period.

Success Criteria

• The purpose and function of the Moby project is well understood as a modular base for building container systems
• The contents of the moby/moby repo is clearly consistent with the purpose and function of the project
• The word “Moby” can be used standalone without ambiguity
• Moby is organised as a collection of tools
• Some Moby tools implement common container system functionality, such as the engine API, container init, etc
• Other Moby tools facilitate the development and packaging of a container system, such as build and assembly of containerized components into systems
• It’s easy to contribute to Moby
• It’s easy for downstream packagers to distribute Moby
• People mistakenly looking for Docker products or support can easily be redirected
• Go developers have clear guidelines for reusing code from Moby - which packages are stable, how to avoid breaking when Moby is updated, versioning and releases
• The repository makes it easy to maintain and distribute Moby based systems, both forks and platforms using the Moby components. This includes trademark policy.

Tasks

To complete the Moby transition, the following tasks must be completed:

• Update README (Update README for Moby Project #35141)
• Update CONTRIBUTING (First pass updating CONTRIBUTING #35168)
• Update ROADMAP (Update the Roadmap #35171)
• Update mobyproject.org website
• Rename dockerd to moby-engine (Rename binaries to moby-* #34226)
• Rename the other docker- prefixed tools to moby-. (Rename binaries to moby-* #34226)
• Remove other places where the word "docker" is used over time, taking care to allow existing applications to transition. This includes names of environment variables, sockets etc.
• organize the code in a clear way that reflects the new architecture, with each component and tool in a top level directory, and documented import paths for libraries.
• Replace the old Go import path github.com/docker/docker/... with github.com/moby/moby/... in as clean a way as possible, and help the community make this transition.
• rename "Docker Engine API" to "Moby Engine API", making the short format "Engine API" still hold.
• Merge github.com/moby/tool into github.com/moby/moby, and rename the moby tool to moby-assemble
• Bring the registry binary and libraries now in github.com/docker/distribution into the Moby project and rename the binary moby-registry.
• Bring other components of the platform into the project.
• Define a release cadence and document stability guarantees
• Set a new version and versioning scheme (eg semver) and apply across the entire repo. We propose to resume the original open-source engine versioning (starting at 2.0 for smooth transition) and cadence (Linux-style loosely time-based release trains, every 4 to 8 weeks, with an always-releasable master)
• Restart source and binary releases and document them clearly
• Complete issue transition so issues are relevant to this repo.

Criteria for inclusion into Moby

• Inclusion of a tool in github.com/moby/moby
  • If code has a direct dependency or tight coupling to other moby tools, it should be in moby/moby
  • If code implements part of the APIs of the Docker project, so it is a core part of a container runtime, it should be moved into moby/moby
• Spin-out of a fully standalone project to its own organization
  • If a project is fully standalone in API, functionality and community, it should be moved to its own github org.
  • These projects may be donated external organizations as they mature, eg OCI, CNCF
• Incubation of a standalone project in the github.com/moby organization
  • If a project is on track to becoming fully standalone, but not completely there yet, it should be incubated as a separate repo in the moby org.

Let us know if you want to help or have questions!