
A new upstream project to break up Docker into independent components - lclarkmichalek
https://github.com/moby/moby/pull/32691
======
shykes
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 collaborations to the Moby
project going forward. During the transition, all open source activity should
continue as usual.

IMPORTANT NOTE: if you are a Docker user, this does not change anything.
Docker CE continues to exist as a downstream open-source product, with exactly
the same interface, packages and release cycle. This change is about the
upstream development of the components of Docker, and making that process more
open and modular. Moby is not a replacement for Docker: it's a framework to
help system engineers build platforms like Docker out of many components. We
use Moby to build Docker, but you can use it to build specialized systems
other than Docker.

You can learn more at [http://mobyproject.org](http://mobyproject.org)

We are proposing the following list of changes:

\- splitting up the engine into more open components \- removing the docker
UI, SDK etc to keep them in the Docker org \- clarifying that the project is
not limited to the engine, but to the assembly of all the individual
components of the Docker platform \- open-source new tools & components which
we currently use to assemble the Docker product, but could benefit the
community \- defining an open, community-centric governance inspired by the
Fedora project (a very successful example of balancing the needs of the
community with the constraints of the primary corporate sponsor)

>>>

EDIT: I'm happy to answer any follow-up questions here, if it helps clarify.

~~~
ilovecaching
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 benefiting Docker
users? I don't care about your plumbing and constant rebranding, other than
finding it very discouraging, I want to know what you're actually doing with
your product this year. I guess nothing.

~~~
BinaryIdiot
> 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?

I think I missed this; who are you referring to? I scrolled through the list
and didn't recognize anyone that I would consider a "destroyer of OSS" so I'm
not sure if I missed something, if you're just exaggerating or a little bit of
both.

~~~
ilovecaching
I'm not going to name names, if it's not obvious go watch the last general
session keynote.

Edit: See my response below

~~~
ThrowawayR2
Well, guess I'll do the detective work. Here's a link to the Docker blog that
has the two keynotes:

[https://blog.docker.com/2016/06/dockercon-general-session-
vi...](https://blog.docker.com/2016/06/dockercon-general-session-video/)

Guest speakers for the last (second) general keynote were:

 _-Guest speaker #1: Docker and Microsoft demo by Mark Russinovich, CTO
Microsoft Azure

-Guest speaker #2: Docker at ADP by Keith Fulton, CTO, ADP_

And just somehow I sense that the parent poster isn't objecting to the CTO of
ADP. /s

(What makes the objection doubly silly is that Mark Russinovich isn't the
usual corporate drone one might expect. He's the guy who did the Sysinternals
tools and several editions of the "Windows Internals" reference on the
architecture of the Windows OS.)

~~~
problems
> (What makes the objection doubly silly is that Mark Russinovich isn't the
> usual corporate drone one might expect. He's the guy who did the
> Sysinternals tools and several editions of the "Windows Internals" reference
> on the architecture of the Windows OS.)

From Sysinternals to the Azure CTO... what a weird transition. That guy has
had an interesting career.

~~~
616c
And most entertainingly those Sysinternals were open source originally and
were immediately close sourced after he was hired during fierce negotiations
by Microshaft and many angry at him for thumbing them publicly, especially for
the NT SKU registry change debacle.

[https://en.m.wikipedia.org/wiki/Sysinternals](https://en.m.wikipedia.org/wiki/Sysinternals)

(Interestingly citation needed; people still circulate the code on BitTorrent
of very old copies.)

Ironically a MSer told me he was famous for his infamous condition he be a
Senior Engineer with an unorthodox, exceptional contractual or understood
conditions: no painful managing other MS people. This only changed when made
the CTO of Azure.

No idea if that's rumor's true. He's a personal hero and I'm yet to read his
novel about cyber war (yes, you heard me).

------
glitcher
Excerpts from mobyproject.org give a much better explanation:

Moby is an open framework created by Docker to assemble specialized container
systems without reinventing the wheel. It provides a “lego set” of dozens of
standard components and a framework for assembling them into custom platforms.

Audience

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.

~~~
ernestbro
Moby is the fedora like oss project and docker is the RHEL like commercial
product. Purely a clever rebranding job. Timing is perfect - now that
enterprise is adopting the technology, when you tell your boss you adopted
moby he/she will say- but the CTO wants to be seen as being innovative for
adopting this new technology and ita called docker not moby!

~~~
vosper
> but the CTO wants to be seen as being innovative for adopting this new
> technology and ita called docker not moby!

I see this kind of cynicism / snark all the time on HN (especially when it
comes to Docker) but is it really warranted? Surely it's the rare exception?
I've never met senior people who couldn't understand the naming difference
between the open source version of a thing and the enterprise-branded version.
Or a CEO or President. They're not morons.

This seems like cheap shots for upvotes. Or am I wrong?

~~~
jetsnoc
I don't think your wrong. Someone being that entitled and ignorant must be the
rare exception in 2017. Maybe I'm in a bubble too.

The conversation usually goes like this with my folk:

I get it, Moby is the OSS version and can be easily stood up and you don't see
the need for extra cost. I'm glad you're trying to reduce expenses, but I
don't mind paying for 24x7 Enterprise Support and it gives me piece of mind
and priority escalation support.

Basically, I don't mind paying extra for a get out of jail free card if a
whole swarm is offline.... I can tell the CEO we have the vendor partner
engaged with a critical ticket and she can have piece of mind too. So, let's
quote out the Enterprise version of Docker and evaluate the TCO of both
solutions.

~~~
atgreen
By calling Moby the "OSS version" you are implying that Docker EE isn't open
source. Honest question... is it true that Docker EE contains proprietary
code, or did you mean to say "community version"?

~~~
jetsnoc
I probably should have written that as Community Version. I'm very uninformed
when it comes to all of this and the Docker, Inc. ecosystem. Sorry about that
:)

------
sandGorgon
@shykes - so im one of the lonely few that love Docker Swarmkit (not Swarm -
cos, that would be too confusing right !). I have spent a lot of time in the
Kubernetes ecosystem (including several SIG) and value the batteries-included
setup that Docker Swarm brings.

More recently, I was part of a discussion where Kubernetes has decided to roll
its own logging infrastructure, while leaving important parts like log
rotation still undecided.... driving me even closer to the Docker ecosystem.

However, it seems that Swarmkit is a big casualty of the whole CE/EE (and now
Moby) split. Docker EE ([https://www.docker.com/enterprise-
edition](https://www.docker.com/enterprise-edition)) still does not mention
Swarmkit anywhere. In fact, there is NO top-level page on Docker's own site
that actually mentions Swarmkit [1] and even Docker "Swarm-mode" is part of
some second level documentation and help pages.

It makes me really worried about how you are seeing Swarm-mode/Swarmkit as
part of the long term future of Docker Inc. You guys really dont talk about it
- not even on twitter.

I'm assuming this is your handle as well
([https://twitter.com/dockerswarm](https://twitter.com/dockerswarm)), which
has not seen a tweet since Jan 2017. However, you guys do tweet a lot about
"Docker Datacenter".

What's going on ?

[1] [https://www.google.co.in/webhp?sourceid=chrome-
instant&ion=1...](https://www.google.co.in/webhp?sourceid=chrome-
instant&ion=1&espv=2&ie=UTF-8#q=site:docker.com+swarmkit)

~~~
alexk
> More recently, I was part of a discussion where Kubernetes has decided to
> roll its own logging infrastructure, while leaving important parts like log
> rotation still undecided.... driving me even closer to the Docker ecosystem.

Can you please refer to this particular discussion and link to it here, I
would like to make sure that this indeed is what happened.

~~~
thockingoog
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.

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

~~~
resouer
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.

~~~
JdeBP
I recommend that you learn from the world around you. This is a long since
addressed problem. This is the way that the daemontools world has been
addressing logging since the middle 1990s, and there is a lot of design and
implementation experience to draw upon and learn from.

The ideas of decoupling logs from lifetimes of the the things being logged,
desynchronized log-watcher services that ship logs to central off-machine log
stores, logging chains, shims for things that talk to syslog over AF_LOCAL or
UDP sockets, shims for things that talk to the systemd journal using its
idiosyncratic logging protocol, compartmentalized logging services that are
protected by the operating system from compromises to the logged services, and
persistent log pipes that do not lose log data; have all been designed and
implemented.

* [http://jdebp.eu./FGA/daemontools-family.html#Logging](http://jdebp.eu./FGA/daemontools-family.html#Logging)

* [http://jdebp.eu./FGA/do-not-use-logrotate.html](http://jdebp.eu./FGA/do-not-use-logrotate.html)

* [http://jdebp.eu./Softwares/nosh/guide/logging.html](http://jdebp.eu./Softwares/nosh/guide/logging.html)

* [http://skarnet.org/software/s6/s6-log.html#diesyslogdiedie](http://skarnet.org/software/s6/s6-log.html#diesyslogdiedie)

* [http://skarnet.org/software/s6/s6-log.html#loggingchain](http://skarnet.org/software/s6/s6-log.html#loggingchain)

* [http://tinydns.org/#ContributedLogging](http://tinydns.org/#ContributedLogging)

------
bru
More information can be found there:
[https://github.com/moby/moby/pull/32691](https://github.com/moby/moby/pull/32691)

> Docker is transitioning all of its open source collaborations to the Moby
> project going forward.

Should I understand that the core team wants to keep the brand "Docker" but
use it in a commercial way, while Moby will be the underlying open source
code?

Is it Docker/Moby = RHEL/Fedora ? or Docker/Moby = Mongodb.com/Mongodb.org?

~~~
Jabbermonkey
Also from that thread:

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.

~~~
zamalek
So essentially the difference between Chromium and Chrome?

~~~
unixhero
No, that would not be accurate.

The difference between them is like

Redhat Enterprise Linux (Costs Money, Enterprise Supported)

vs

CentOS (Community managed, community supported, Libre Free)

~~~
bonzini
CentOS comes from RHEL, while Docker comes from Moby. So the correct parallel
is Fedora-RHEL or Wildfly-JBoss.

------
pi-rat
From comment by @stykes on the pull request:

    
    
      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.

~~~
bandrami
The pre-emptive defensiveness of that comment says a lot...

~~~
CGamesPlay
Maybe. The defensiveness could likely be that in many rebrands things tend to
get lost in the scuffle (e.g. documentation not fully up to date; difficult to
find references to some subproject's new name; checkbox for feature still
listed on the enterprise version's landing page; assumption that it was made
closed-source). The devs just want to get ahead of that as much as possible.

~~~
grey-area
There is absolutely no need for this rebrand, because they're not actually
getting rid of the old brand, they're trying to reuse it for something
different, which is insane. Hence the defensiveness. They know this will cause
problems and complaints. They can't get ahead of the complaints without
actually fixing them, by reversing the decision.

------
holydude
Why am I having the feeling that Docker Inc is being pissed about everyone
making money off docker except Docker Inc. themselves ?

This is not nice.

~~~
kentt
Oh, because it's true. Their employees were fairly outspoken about it at
Dockercon. I had one just dramatically and rudely turn and walk away from me
mid-sentence when I mentioned I was using Kubernetes.

~~~
markbnj
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.

~~~
ohdrat
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 synthetic monitors. Docker is getting paid--
they are falling down on support.

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

------
kibwen
Indeed, it seems that github.com/docker/docker now redirects to this. From a
technological perspective it's irrelevant, but from a brand management
perspective it's baffling. Did they perceive the Docker brand as tainted in
some way?

~~~
bonesss
The Docker brand is "tainted" in the eyes of their commercial competitors who
don't want to use shared tools/libraries.

By creating an independent project commercial actors in the Enterprise space
can share resources, components, and standards without having to explain why
they`re better than Docker even though they`re built on top of Docker.

This is a great move towards industry and container infrastructure
orchestration standardization. Common APIs will go a long way to widespread
container adoption.

~~~
tcrews
It's not the brand that is tainted. People simply cannot trust their projects
on someone else's commercial objectives. There is no indication this is
changing.

~~~
matt4077
Yeah, good luck with finding a technology stack that doesn't rely on any
products developed by companies...

------
yeukhon
This is the one of the worst kind of business decision one can make. But I am
not theirCTO and CEO. While not the same as Vagrant being replaced (and then
revived because the alternate project was a burden), feels the same shitty
decision IMO. Plently of people run successful OSS under the same name.
Disappointing.

~~~
bonesss
I believe you might be reading the situation backwards...

Dockers underlying components are quite usable for many solutions in other
projects and platforms. Now, instead of having "Docker TM" components in their
stack, OSS projects can connect the tools without seeming to support a
specific commercial provider.

Presently there is a lot of confusion and OSS projects are hesitant to use
Docker components because of the perception of a closed eco-system. Now the
project has clearer commercial branding and a more appealing package set for
OSS consumers.

Remember: many of the most important actors we need to collaborate in this
space are direct commercial competitors to Docker Inc.

------
wesleytodd
I do not understand the amount of negative feedback on this. It seems logical
to me to move the underlying open source components to a separate org from the
proprietary stuff. Why the hate?

~~~
BinaryIdiot
Honestly I think it makes sense as well but the way it was announced it was so
incredibly confusing that I find myself agreeing with some of the negative and
positive comments here depending on what my state of understanding was at the
time.

------
stephenr
What is it with tech companies and fucking terrible name/branding analogies?

Docker. Ok, works with containers I get... wait. Your logo is a WHALE with a
bunch of shipping containers on it. You know that whales DISAPPEAR underwater
for hours at a time, and shipping containers are NOT MEANT TO DO THAT?

Ok ok maybe it was an honest mistake hey whats this new thing moby.. wait.
Whales. Moby. Moby dick? Your project is named after a mythical white whale
that sank boats, the very thing that _actually_ carry CONTAINERS.

Having said all that, based on this [1] summary of Docker's usefulness in
production from February, maybe both names are absolutely on-point for the
reality of this abysmal 'product'.

1\. [https://thehftguy.com/2017/02/23/docker-in-production-an-
upd...](https://thehftguy.com/2017/02/23/docker-in-production-an-update/)

~~~
Khao
A+ post.

Funny rambling backed up by a crazy well detailed article and you get
downvoted by the HN hive mind. Docker is the ...ahem... whale in the room that
you shouldn't criticize ever!

~~~
user5994461
Author of the article here!

Just updated the titles to include moby.

Maybe I should change the links as well, then it can get reposted on HN and
reach the first page along the announcement :D

~~~
mdekkers
Love your articles. Thanks for taking the time and effort to write it up and
put it online.

------
tmaly
Why change the name? All the books and posts reference the name Docker.

~~~
e1ven
It looks like they want to rename the OSS version, to differentiate it from
their commercial version. They're using the analogy of Fedora->RHEL.

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

~~~
JumpCrisscross
Why doesn't the open-source predecessor have precedence?

~~~
jazzyb
Because people are more likely to pay for the more recognized name.

------
amouat
Personally, I think this a great move for the community, but the reasoning and
implications could have been made a little clearer.

The intention is to have a clearer split between the Open Source community
project - which is and will always be the heart of Docker (or now Moby) and
the "product" pieces. The Docker product itself is not changing at all from an
external perspective - you will still call "docker run" as before. However,
Docker will be an "assembly" of pieces from the moby project plus some under
the docker namespace, probably including "docker/docker-cli". Going forward,
this will allow the docker-cli to make more product-centric moves like further
Hub integration that would be too controversial for the community moby
project. It also allows other organisations to take the moby code and
reassemble it in different ways without offending the Docker "product".
Furthermore, the intention is that in the long run, various Moby pieces will
move to community foundations such as the CNCF and OCI.

------
bauerd
If I read this correctly they split up the Docker repository into several
components. The moby repo pulls these together and spits out a build (or many
builds?). So for instance one might choose an alternative container runtime to
containerd? Then there's an officially supported set of components from which
they build Docker CE. But why is Docker now called moby? Doesn't make sense to
me.

------
_jezell_
Please rename to Moby Dock instead.

~~~
rmoriz
Docker Failwhale Edition

------
wnevets
This certainly won't cause any confusion going forward.

~~~
bonesss
If you`ve hit the wall in between multiple container infrastructure
orchestration platforms I think the potential this provides is pretty big, and
will have a lot to say for Enterprise adoption.

Separating out the shared commodity container stack points towards plug-and-
play cross-vendor container stacks based on standardized APIs. Puppet, Chef,
Ansible, Azure, AWS, VmWare, Kubernetes, etc etc: todays market is a divergent
mess. Being able to mix-and-match configuration tools, clustering tools, and
management interfaces will get us to best-of-breed solutions. It should enable
plug-and-play components that today, amidst a dizzying array of
incompatibility, generally force you onto wholesale stacks.

Props to Docker for investing in the shared eco-system and risking the brand
confusion to push the industry towards the next step.

This doesn`t impact users of Docker or containerized app devs, people won`t be
setting up a Moby stackexchange site any time soon. This is big news for the
devs of container platforms though :)

------
alanfranzoni
Bad title. That's not what's happening. Moby is the name of the open source
project.

------
munin
They should have just re-branded to qwikster.

------
api
So devops conferences will no longer sound like "Docker docker Docker? Docker.
Docker docker docker docker? Ahh, Docker docker Docker docker docker." Now
they'll sound like "Moby moby moby...?"

This seems absurd from a branding point of view.

I personally find this a little bit vindicating. I'm 39, which is like 120 in
programmer years. I feel like one of the advantages of being an "old" (in
quotes!) programmer is that I'm pretty good at spotting a fad. Unfortunately
whenever I point one out I get mocked and down voted to oblivion, so I've
learned to just sit on the sidelines and watch the fads go past and just work
to avoid them in my own projects.

Programming is very faddish, and I've seen fads come and go. Here's a few of
the ones I've seen in my tenure:

\- "Design patterns" heavy "enterprise" programming, such as commonly seen in
the older work in the Java and .NET ecosystem.

\- XML for everything.

\- Agile. Oh god, agile.

\- Test driven development.

\- Dynamic languages (as productivity magic pixie dust).

\- Service oriented architecture (SOA).

... I could go on.

Not everything in these fads is bad. Fads often contain good ideas and some
fads contain non-fad elements that stick around. But they're fads insofar as
they are over-hyped as magic cure-alls.

The key characteristic of a fad is this:

It's heavily hyped as a cure to some set of very hard problems in programming
or system administration, but all it _really_ does is move the problem
somewhere else or hack around it in some trivial gimmicky way. There is no
real innovation. Meanwhile the fad often introduces new problems that nobody
thinks about until the shine wears off.

My simple heuristic for recognizing a fad is to ask "where's the innovation?"
A real innovation is a conceptual leap forward. It has a certain "meaty" feel
to it and seems worthy of at least one solid CS paper. It often _reduces_
complexity, since when deployed you can now dispense with all the mountains of
hacks you used to work around the problem prior to the innovation.

Here's some current things that I very strongly think are fads:

\- Microservices, which is just a reboot of SOA. The idea is not inherently
bad and often results in more scalable systems, but the faddish part is the
idea that replacing local API calls with RPC API calls or event queues is
going to make some major class of programming problems go away. No, and you've
also just introduced a new set of problems around network unreliability.

\- "Serverless" cloud, a.k.a. total lock-in to a proprietary mainframe.
Everyone doing this is going to regret it in 5-10 years except Amazon's
shareholders. It's a roach motel. Compute will get another order of magnitude
cheaper and prices for everything else will drop accordingly, but these prices
will not since you drank the kool-aid haha.

\- Containers.

... yes, containers.

Like most fads, containers are a response to a real set of problems. These are
mainly:

\- System/VM configuration drift and variability.

\- Dependency and DLL hell.

\- The fact that Linux/Unix has devolved into a single-tenant operating system
where it's hard to deploy more than one thing on one "server." (This debacle
is deserving of a whole very long blog post.)

Containers are a fad because they don't address any of those problems with
real innovation.

System configuration drift, dependencies, and DLL hell are are addressed by
the gimmicky hack of basically tar'ing up whole Linux images and _treating
them like gigantic statically linked binaries_.

If you're going to do that, why do you need Docker/moby/whatever? Just use a
static Linux distribution like [http://sta.li](http://sta.li) and run every
service in its own home or chroot. Keep your service trees in git and manage
systems with Chef, Puppet, or f'ing shell scripts.

I fail to see why orchestration (a.k.a. provisioning) systems like Kubernetes
could not work in such an environment without the container cruft.

Containers don't solve multi-tenancy much in practice. Their security profile
is not good enough for true multi-tenancy, and if you try to run too many on
one server you're going to run into stability problems that derive from all
the bugs that exist in all that extra complexity they add.

Real solutions to these problems would... you know... really solve them. A
real solution would make it possible to deploy stuff easily and forget about
DLL and dependency hell. A real solution would restore true multi-tenancy to
Unix, allowing _users_ (not root) to install and run services on commodity
identically-configured Unix systems. A real solution would reduce complexity.

Edit:

I do wonder a little if the idea of throwing out dynamic linking, which both
containers and some newer compilers like Go do, is not a bad idea. Maybe it's
obsolete. Maybe the tiny memory savings of dynamic linking are no longer
justified by the complexity overhead of dependency management.

~~~
quickben
Because it's cheaper to "snapshot" and roll back, than to pay somebody capable
to fix the thing.

I'm 36, and have seen most of what your described and more.

~~~
api
Yes I get that, but you can do that with "git".

------
detaro
previously: discussion of the announcement
[https://news.ycombinator.com/item?id=14139691](https://news.ycombinator.com/item?id=14139691)

------
thedangler
Not to be rude or anything but the people in charge of such changes need to
take a class in change management.

------
akerro
Wow, so much documentation, blogs, keywords, adsesnse and stackoverflow to
update! Better hurry!

------
pbreit
Can this piece of the puzzle really support a venture funded company? I get
RedHat, that's a complete operating system. And Mongo, the database is a huge
chunk of a system. But Docker seems definitionally a tiny sliver of the
overall ball of wax.

~~~
tyingq
I think that's the problem they are trying to solve. They want people to be
buying their higher level stuff, container management, orchestration, etc. But
all the attention is on the lower-level container runtime.

And, their competition at the higher level is starting to abstract away from
their runtime. Like this: [https://github.com/kubernetes-
incubator/cri-o](https://github.com/kubernetes-incubator/cri-o)

------
omidraha
Is there any wiki page of moby project on the WikiPedia? This is not related:
[https://en.wikipedia.org/wiki/Moby_Project](https://en.wikipedia.org/wiki/Moby_Project)

------
Chris2048
Moby dock?

------
SadWebDeveloper
So Docker is now called Moby or Moby is the OSS version of what i believe it
will be the "enterprise" version of Docker. Like RedHat is to Fedora, Docker
is to Moby right?

~~~
dwaite
Think how RedHat is the name of a company and an operating system product
(RHEL) assembled from the pieces in Fedora.

Docker is the name of a company and a container management product (Enterprise
and Community Editions) assembled from the pieces in Moby.

------
colept
What about all the SEO, Stack overflow questions, and the differentiation
between the two(?) platforms?

~~~
user5994461
The SEO is not a problem.

1) It's not conflicting with anything major (Unless it does, short 4 letters
names are way too common).

2) It will transfer along the URL redirections

3) Docker has enough credit and following to gather SEO on any new domain and
product name that comes out

The new pages will be top links on google very quickly. No worries about that,
machines are fine!

The trouble is with humans, they can't keep up. All the existing content
-documentation, community, articles- will stay under the Docker name, forever
splitting the knowledge and bringing confusion onto mankind.

------
amq
Seems to be done hastily - why?

------
tcrews
It's time for a foundation if they are serious about this.

------
w8rbt
Bargey or Tanky may have been a better name.

------
valarauca1
Are we getting ishmaeld now?

~~~
api
They could have ishmaeld to monitor mobyd and ahabd to kill mobyd if it
misbehaves.

------
breerly
Searched "runc" on this page - 0 found :(

------
xaduha
This isn't April 1st, is it?

~~~
DonHopkins
No, but it's 4:20.

------
nikcub
What a horrible title.

Docker isn't being renamed to Moby, but rather all of the open source
components are being spun out into a new umbrella OSS org called Moby.

No need to s/docker/moby anywhere.

This is going to end up being a case study in how not to make announcements,
because the news is otherwise big/interesting.

~~~
grey-area
This url is redirecting so that has changed (a rather important url):

[https://github.com/docker/docker](https://github.com/docker/docker)

This all seems so unnecessary. Why didn't they just keep docker docker and
have docker-xxx for whatever other brands they want to introduce? Reminds me
of CoreOS rebranding as Container Linux.

~~~
prashnts
> Why didn't they just keep docker docker

They'd lose 40k+ GitHub stars, I guess.

------
heeey
This is a bait and switch of whale proportions.

Docker used to be the open source part. Now that's being moved out of the way
so when you search for Docker you get the paid offerings. The goal is to
confuse the people who haven't been following this into thinking Docker is a
thing you pay Docker (the company) for.

It's brilliant.

~~~
stephenr
> The goal is to confuse the people who haven't been following this into
> thinking Docker is a thing you pay Docker (the company) for

Following the first thing they google without actually understanding what's
involved, all the way to handing over money sounds about what I expect from
someone who thinks Docker is a viable platform to use for anything worth
handing over money for.

~~~
heeey
That's not quite how it works.

\- Decision maker googles and finds there's this Docker company that will
solve their problems. Heard good buzz about Docker in the news, how open it
is, and how many companies use it.

\- Decision maker to engineer: "Hey can we use Docker software to solve
problem X"

\- Engineer: "Sure, the software is actually called Moby now though"

\- Decision maker: "Meh, I don't care what it's called, I just want problem X
solved. Docker solves it?"

\- Engineer: "Yeah I guess"

\- Decision maker: "Ok here's your budget. Pay Docker to solve problem X."

\- Engineer: "Alright"

~~~
stephenr
Is that how VC companies "work" ? "Decision makers" make unilateral decisions
about technology and "engineers" just say "yeah I guess" when asked about
using new tech?

What fucking problem does Docker solve that a "decision maker" can understand
it enough to get a result telling them to use Docker, yet s/he can't
understand the concept of "open core" software.

Docker's status seems entirely driven by me-too cool kids cargo-culting the
bejeezus out of it because they heard it can run their nodejs react app
better.

If you work for a company where your described situation could happen, fucking
leave.

~~~
sotojuan
A lot of devs seem completely fine with being pushovers and yes-men to the
MBAs.

~~~
HankB99
I'm between jobs at the moment at least partly becaue I pushed back.

------
horsecaptin
Sharpen the Spears?

------
kelsus
Shoulda called it d suite.

