Docker Community Edition is the Docker you've always heard about, now with an Enterprise big brother (Docker EE).
Moby is a set of standardizable tools that underly that product which might be shared with OS suppliers, Kubernetes, or other virtualization solutions.
If you want containers for your apps, you want Docker. If you're bundling containerization components into your Linux distro/orchestration platform/custom hybrid cloud solution then Moby will be your swiss army knife :)
Docker is a brand and a product, that product does a bunch of stuff beyond the simplest levels of letting download or build images and run containers - such as SDN, physical clustering, hardware provisioning, and service orchestration with load balancing and automatic management.
A lot of the community understands that "docker" has gained a lot of features, but they may not understand it is because Docker is the name of an integrated product suite a company wants to sell.
These features are added because Docker, Inc. wants to have commercial offering containing a full technology stack around containerization, a community offering to attract people to their stack, and open source backing the community offering so that enterprises don't get fearful of vendor lock-in.
But other companies want to use containerization. And Docker doesn't mean anything in their context, because they only want to use a few pieces and swap the rest for their own. In fact, they are resistant against using Docker because
1. It is iffy whether they could use the trademark, even if they were ok marketing a competing product
2. They don't have the same voice in the technical decisions of the open source project
Moby is an attempt to solve these issues:
- It is a project with a vendor neutral name
- Presumably, it will be managed in a way that gives vendors somewhat equal footing
- It makes it clearer that the pieces are containers, etc, the project that develops all the open-source pieces is moby, and one of the products that integrates all the pieces is docker.
It is similar to how RedHat split out Fedora, except that RedHat didn't see the value in having a RedHat-branded community edition.
> 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?
You are better off looking at Oracle, the difference between (say) MySQL Community Edition and MySQL Enterprise Edition, and the relationships between MySQL and MariaDB and Percona.
Except that you claim Docker will continue to have Docker CE (Fedora equivalent) and Docker EE (RHEL equivalent). These products will continue to be issued by Docker Inc., will they not? Will "Docker CE" be released as "Moby" in the future? If so, how will it be distinguished from the "Moby Project", which is just a bunch of "building blocks"?
If Moby is the name of a collection of subsystems that are drawn upon to build user-ready container platforms like Docker, isn't GNU userland/Linux kernel->(Fedora/Red Hat)->Red Hat Inc. as Moby->(Docker CE/EE)->Docker Inc.?
Perhaps a better way to explain it is that Moby is a "containerization kernel/core" a la Linux or an "open containerland" a la GNU. The term "framework" may be a little more accessible at the cost of diminishing street cred by appealing more to web devs than old-school system devs. These fancy words probably shouldn't be a problem since it seems only developers would be interested in Moby anyway (instead of end users who would want to use a Moby distribution).
With a little bit of finesse, this could've probably been construed as the boon for the open-source community that it seems you originally intended. "Docker Inc. donates its core technology to the open-source community and invites competitors to use it as the base of their own products." Too late to right the ship?
> Will "Docker CE" be released as "Moby" in the future? If so, how will it be distinguished from the "Moby Project", which is just a bunch of "building blocks"?
Docker CE will remain Docker CE. In the Fedora/RHEL analogy, think of Docker CE as the recently introduced "RHEL free developer edition". It's still a commercial product - it's just free and open-source.
> With a little bit of finesse, this could've probably been construed as the boon for the open-source community that it seems you originally intended. "Docker Inc. donates its core technology to the open-source community and invites competitors to use it as the base of their own products." Too late to right the ship?
Outside of the Hacker News bubble, this is a non-issue. 500 people read the title of a pull request, didn't even read the contents of the change, and clicked on the "thumbs down" emoji. Meanwhile the vast majority of Docker users don't scan the repository for pull requests. And the majority of those who do actually take the time to read the code, and usually have enough context to understand why we are doing this: modularization, openness etc. In between these two groups, you have Hacker News basically.
That pull request was confusing, yes. And we clarified it. But it's an implementation detail and definitely not representative of how the Moby launch was understood by the community.
Terrible timing for Docker to do this. It may not be much of an underlying change, but the simple fact that https://github.com/docker/docker redirects to https://github.com/moby/moby is a product-destroying move, as Docker is now just managing to spread to a wider audience.
This move is going to confuse many users, and could entirely derail their growth. What the hell were they thinking, to execute this decision at such a critical point in time? Docker was already confusing enough to get started with, and now there's an additional barrier to entry just to understand what it all means? People right now at least understand what "Docker" is; now people are going to be redirected to something called "Moby", and many will give up out of confusion.
Really bad timing for such a move.
tldr; Am I even supposed to call it "Docker" now? Years of growing recognition of that name, thrown out the window.
Users shouldn't be confused as they are able to continue using docker as they have in the past. The Moby project doesn't affect their consumption and use of docker.
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?
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.
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.
I'm sure you'll clean up your phrasing (since you're getting downvoted for some reason) but could I ask, is this something you really first thought of when you heard the name? Is it UK slang? I've never heard it. I don't think you should be downvoted for the info (even though it doesn't actually apply, they will keep the name for their commercial stuff) as it's news to me.
but you're not my parent poster...and you didn't actually answer the question about whether it had negative connotations. (specifically, the term "docker" doesn't appear on that page in that form.) I am asking whether it's the first thing my parent poster, or anyone, would first think of, for example if the project were named "wanker".
Of course it was the first thing I thought of when I originally heard the name -- what else could it possibly mean? I assume they changed the name because somebody finally pointed out the first definition of docker on urbandictionary. But what was so dirty about my phrasing, other than saying the name of the project itself? (And it's only a myth that it's dirty, unless you never bathe.) Shouldn't any mention of that name be flagged, not just my message? Leave it to the prudes to shoot the messenger... ;)
The phrasing (as of when I write this comment, still within OP's edit window) can use work, but how's it off-topic? This article is about a name change and nothing but a name change.
But OP is Dutch - nobody, even from the general gay community (not specifically Holland), replied saying it's the first thing they thought of.
OP, you really made it sound like it's something as well-known as the word wanker - whereas it's extremely obscure.
If I'm in charge of the docker project, the gay dutch community is much too obscure for me to change the name because of.
-
EDIT:
jacquesm, I read your reply to this comment and we simply disagree. Their phrasing can use work, but the information is clearly 100% on-topic if it's genuinely the first thing they thought of when they heard it, and if they phrased it more neutrally. If a project were called "wanker" would you call it off-topic to discuss the UD definition on an article about its name? in reply to the call for speculation phrased "Why change the name? All the books and posts reference the name Docker."?
EDIT2:
this thread is becoming boring but as for the opposite of sarcasm,the opposite of /s are the three letters "srs", maybe in parentheses.
Off-topic: something that does not have to do anything with the subject at hand, in this case, Docker, the company producing software, software in general and so on as well as rebranding or changing the name of open source companies. What GP's associations with the name are doesn't really matter and as far as I can see did not have any influence because they are keeping the name so that is certainly not why they are changing their open source projects to be moved under a new brand.
I'm not Dutch, and it's definitely not just a Dutch thing. And it's the first definition on urbandictionary, so it's not that obscure.
But speaking of which, the Dutch gay community was also quite enamoured with the name of the photo sharing site "Flickr", i.e. https://nl.wikipedia.org/wiki/Flikker
How was my phrasing inappropriate? I never said they should change the name -- just the opposite! At least it's not a demeaning insult, like gimp, git or mongo.
Is there an html markup for non-sarcasm I should use, like the opposite of <s>? Or if I just nest two <s> tags do they cancel out?
Pro tip: always check urbandictionary before naming a project.
I'm familiar with it, but somehow jumping to it whenever hearing about "Docker" is akin to thinking of AIDS when one hears about "hearing aids" or anal in Google Analytics - it doesn't seem like a problem unless someone decides to over-read.
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.
This is why I hate SW business and I am very picky about services / software I use.
I really dislike companies undercutting competition with practices like this.
Hi, I'm the founder of Docker. That is very surprising and absolutely not OK. I'm sorry that you experienced this. Could you contact me directly at solomon@docker.com to give me more details?
There is no animosity towards kubernetes, quite the contrary. We are working with the kubernetes community to integrate the individual components of Docker, so that everyone can reuse each other's code and ideas.
For example:
- we're actively working on a containerd+CRI integration.
- there's great technical discussions about supporting CNI in SwarmKit
- we are participating in the early CSI (common storage interface) discussions along with the Mesos and Kubernetes communities.
- we are discussing the possibility of participating in the Kubernetes secrets implementation work, since we invested a lot in SwarmKit secrets and some of that work could be reused, or at least discussed for reference.
In short: no animosity. Not sure what happened to you at Dockercon but we will look into it.
Thanks for responding. There really isn't many more details other than that. It was in DockerCon Seattle in the space needle. I don't remember who the employee was. I did generally get the feeling that Docker employees felt at least wary or worse about k8s. That was from more than just that once situation, but from multiple interactions I had over the conference with employees. I only pointed out that one interaction because it made me certain that at least that employee was more than wary.
I'm happily using Docker and it was a good conference otherwise.
>I did generally get the feeling that Docker employees felt at least wary or worse about k8s.
I'm no k8s fanboy (and I have the comment history full of replies from annoyed k8s contributors to prove it), but it's because they know that Kubernetes is going to end them. It relegates Docker to a swappable implementation detail.
I'm surprised we still haven't seen a K8s solution from AWS yet. Their container engine looks OK, but K8s handles setting up internal LBs and has minikube for local development. The AWS app LB seems far behind.
I'm looking forward to them accepting defeat on this one and just natively supporting K8s like Google.
There are companies like CoreOS, Heptio trying to provide good Kubernetes support for AWS. Personally, I don't think all cloud providers _have to_ provide native Kubernetes support as it’s designed to be something users can roll out on their own regardless of the environment, or purchase services from companies in the ecosystem (like those I mentioned earlier). Today, there are many tools like kops that integrate well with AWS ecosystem and make it easier to install Kubernetes on AWS, which makes me think that users are happy enough without an official support from AWS. And that shows the strength of the community.
That doesn't make it non-annoying. I am personally annoyed at the current state of the open source ecosystem where all the top open source projects are dominated by large tech co's.
These large companies are developing open source as a strategic asset but most people have no idea and just think they're being altruistic.
The reason this really sucks is because as a result, all the large projects backed by large companies kill of the alternatives which have very pure motivation. Just like react is replacing a pure open standards based way of web development. Sure, it's "open source", but this is not right.
> I am personally annoyed at the current state of the open source ecosystem where all the top open source projects are dominated by large tech co's.
It's fascinating how far we have come in the past 20 years. First the introduction of using opensource at work, then businesses starting to opensource things themselves, and here we are complaining that the top opensource projects are in fact backed by companies.
I understand your point, but it's also a luxury to be able to complain about this.
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.
I admit to being a little surprised to hear that too. Certainly it's a polarizing topic, I'm sure, but I also went to a talk either by a Docker Captain or employee that spent five minutes talking about K8s, and not in a denigrating or discouraging way whatsoever.
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.
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!
> 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?
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.
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"?
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 :)
This idea isn't cynical, it's branding. The whole point of creating a brand like Moby is to trigger conversations about what level of service you're getting when you say you're using "Moby" vs. "Docker". The CTO hears they're using "Moby", which for the first time may make the CTO realize that some of the infrastructure for his business is relying on unsupported technology (or maybe he intuitively realized it but now it's obvious).
It's not a "cheap shot", and it's not for "upvotes", it's just an observation about the nature of this change being non-technical, related to messaging.
Why do we keep equating OSS to "unsupported"? Some of the OSS I use is far better supported than licensed software. Drop an issue on GitHub and it gets fixed in a few weeks.
Because without a legal contract to cover support, you don't have someone that contractually has to answer your call.
You might not care about this, and many don't. You're running the risk that the maintainers won't pack up shop and stop maintaining the project, and that you & your team will need to inherit the project.
Other way of looking at it, is that if you're a business, you always should pay for your software, even if it's open source. Because you will one way or another: through your team, or through the risk that free riding brings.
The object "Docker" has been in dissonance for quite a while now, both by the company's perspective and the consumer's perspective. I think rationalizing it as a "brand" move is a bit simplistic.
It is a FACT that individuals are unable to use the term "Docker" on anything they would like to create and share with others. This has been enforced with takedown notices and legal entities getting involved in "protecting" the Docker brand, on Docker's behalf. This, in and of itself makes sense, given Docker is a private company with a significant amount of private investment behind it, with expected returns on protecting that investment. It has used that investment well to further build the brand, as you indicate here.
However. Docker is also an idea which is one of taking a "software container" and starting it somewhere, running it for a bit, twiddling on it in a variety of ways, then moving it somewhere else where someone else can do that too, without too much operations headache as you do so. Again, it's the IDEA of this that matters, not whether it is technically true or not. The idea simply leverages the concepts of writing, deploying and running code and smears them across a the vast resources of which the Internet is comprised.
I've seen the gleam in people's eyes when they talk about a ubiquitous computing infrastructure, of which it will run their code, without question, and never, ever breaks. Irrational beliefs are still beliefs, and sometimes it is necessary to also believe they are rational ones in order to get things done. We're all busy, and the Internet requires a lot of us to get more done in the future. People need the idea of Docker to get project's interest raised, approved, and put into production to get more things done.
This is where Docker's dissonance comes in, and does so fairly heavily handed. Docker is here to make money. They will do that at the expense of all other things, given their purpose is to preserve shareholder value first. That includes changing the idea that everyone holds about ubiquitous computing. That's not to say that shareholder value isn't tied to consumer value and completely rational, but it can also become a vicious circle very quickly when company values are prioritized over consumer values at any expense, or vice versa even.
Personally, this is why I'm not a big of traditional investments in infrastructure technologies. While I do think that traditional investments have been a great help to the growth of technology in the past, it is my belief we are going to continue to run into increasing challenges attempting to rationalize arguments for shareholder value vs. user's best interests when it comes to infrastructure. And, to make it even more challenging, I think most times the users don't realize they are trusting these offerings in an implicit way, which makes their view on matters highly irrational. That is to say, irrationality indicates additional work must be done to resolve the truths of who and what to trust. This is made difficult by applying that irrationality to the very systems on which we base trust.
I don't want to live in a reality where we are having to constantly question the trustworthiness, or irrationality, of our infrastructure.
I don't have a great suggestion for how to fix these types of issues other than proposing a radical change in infrastructure business models. I do have a suggestion on how to do that, but it will make it completely irrational for traditional investors to consider, which would limit the adoption of it, even if it got going. A catch 22, if there ever was one.
"I've seen the gleam in people's eyes when they talk about a ubiquitous computing infrastructure, of which it will run their code, without question, and never, ever breaks. "
This seems to be a much higher level construct , like PaaS or Lambda, than what Docker provides.
Docker was more of a bottom-up wake up call to those upper layers that lower layer technology usability still matters.
I never said otherwise. Again, the idea people hold about a technology, with a given tag, is moving in the direction of what they expect as users of said infrastructure. Please note that I did indicate this was an irrational belief. Whether or not Docker actually does this thing people understand it to be is another argument entirely.
It probably depends on each of our anecdotal experiences. I've worked with and met some higher ups in companies and government organizations that would actually react like this and I met some that were very well educated. Unfortunately I've worked with far more of the former than the latter.
So to me it seems fair but depending on your experience I could see it as a cheap shot for upvotes as well.
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.
Here is an old saying: "Nobody ever got fired for buying IBM" - neatly illustrating the issue. I have met _many_ senior people that don't understand these naming differences. They tend to be the bosses of the CEO and CTO's
When you tell your boss you adopted moby, he's like "WTF is that?!".
If you were already migrating to Docker, now you have to explain that the project name changed overnight without explanation, and it's hurting your credibility pretty bad. It's also gonna bring a lot of confusion onto everyone for a very long time.
Use the tried and true engineer response. Docker does many things because it has to be all things to all people. Docker is composed entirely from Moby, we're only composing the parts that matter to our organization. It'll be faster, use less resources. Even better, it reduces our attack surface because we're removing all that stuff less experienced teams need to muddle through their deployments.
The three points seem to be, cheaper, more secure, and the other guys are dumb.
> Enterprise IT and development teams looking for a ready-to-use, commercially supported container platform. We recommend Docker EE instead.
I'm sure they do. If I were involved in a situation like that I would definitely check this out, just to make sure that their recommendation is not just a way to protect their income stream. 'Don't look there' is the forbidden fruit theory at work, of course everybody will look there.
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.
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.
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.
Yes, that's a pretty good analogy. Except our "chromium" (Moby) actively encourages and facilitates creating completely different types of "browsers", not just Docker.
thank you, makes sense now. why do they think we think that you can take an open source thing and make it closed source? All you can do is force them to buy commercial licenses by using a GPL on Moby. That is common use of GPL after the fact (see ExtJS history), but I'm not sure how they get around the viral aspect of GPL when they are using source from GPL project in their commercial offering. They'd have to be completely separate. If tomorrow the free "CE" product went away, what would happen? Imagine if we had to pay for the Java runtime or JDK.
There's nothing viral about using GPL code. Your docker containers are probably running on Linux, which is also GPL, and that has neither infected nor affected you, has it?
I wonder how you could say such a patently (and copyright-ly) false thing, especially considering you replied to a comment explicitly mentioning Linux.
Would you not think all these huge companies would think twice before using Linux if it meant being dependent on the good will of everyone who ever contributed to any of thousands of packages that come with a typical distribution?
"I predict that the term "micro" will be replaced by the term "modular", and that docker will create a replacement for the microcontainer named the modular loader/container."
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.
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.
It's quite clever actually. First you get half the world behind your open source project and then with a little sleight of hand that suddenly becomes a valuable commercial brand.
Because the commercial entity will keep the name so all the docker mindshare suddenly 'points' to a thing that people would have to pay for.
If they had renamed the commercial stuff to Moby they'd have to start from scratch, now there are thousands of articles and links that say 'go get docker' intending to point you to the open source stuff, instead directing you to the commercial stuff.
What, exactly, is the bait in this case? The name? Because it sure seems as if I could still get everything as I could before. Do you really think there are people who reads a tutorial and ends up buying Docker Enterprise Edition for 9,950$ because they failed to see the "Docker Community Edition" link, which by the way, will still be available?
That's correct. There is no change to Docker CE or Docker EE. We are adding a 3d thing, upstream from both of them: Moby. We use Moby to assemble all the pieces of Docker. You can also use it to assemble all the pieces of other things like Docker, and maybe in the process collaborate with Docker on the common parts.
> Plently of people run successful OSS under the same name. Disappointing.
But those projects aren't true OSS in the way that something like Docker / Moby needs to be. Your Vagrant example is one of them; Vagrant is a useful tool but ultimately too narrowly-focused. Docker's biggest coup was seamlessly integrating orchestration tools with deployment tools -- and now they're separating the two (which is completely fine, because they need to be separate tools anyway to support complex use cases).
Docker has built a lot of valuable IP that they want to protect (branding, UI, API, etc.) That makes a lot of sense. It also makes sense that they want to open source a big chunk of the "glue" between everything because 1) it's generally useful to lots of people / projects and 2) it gets other companies to kick in dollars for maintenance.
You're not going to get non-customers to fund the maintenance of an open source project that is wholly run and owned by Docker. They know that, and hence they're creating a governance board. But once you do that, you lose full control of your brand (which is attached to the project), and thus you have to divorce the two.
Docker is still going to drive the development of Moby. But over time, other companies will enter the fold to build other complex system orchestration projects on top of Moby.
On the contrary. If you understand enterprise FOSS, then you understand that one of the primary benefits of FOSS for the enterprise contributing customer is the ability to to make the software more relevant for the enterprise through the enterprise's contributions to the FOSS project, at a rate which is typically unfeasible, if even possible, for closed commercial products.
By splitting up the open-source Docker CE codebase into smaller projects, each smaller project is more approachable to outside potential contributors. If Docker can succeed in increasing the number of contributors to the Moby projects, compared to the Docker CE project, then they'll have succeeded in increasing the relevance of their product in their target market, which translates to more customers, sales, and profits in the long-term.
Of course they run the business risk of a fork taking off, but in the real world, forks are arms races. They're easily won against dead or severely mismanaged projects, but against a project with a well-funded corporate sponsor? Few, if any, will have the resources to put into making a better fork than the original.
And like they said, for the vast majority of their customers, nothing is changing. Their customers bought a Docker product yesterday, and they're buying a Docker product tomorrow. That branding isn't changing.
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 :)
Dunno about SEO, but the SO/other questions shouldn't be too big a problem I imagine - the end-use related questions will still be in the right namespace.
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.
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.
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.
> 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.
- 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."
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.
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.
- Decision maker: "Also, do you really think I'm some sort of walking caricature of doofus management? And if so–what, exactly, is, in your estimation, the overlap of 'has absolutely no clue' and 'has heard of Docker'. Because sure as hell the CEO doesn't know anything about Docker. And while I'm the CTO, it happens that I, like quite a few of these decision-makers, came through the technical ranks. I compiled kernels when you weren't even born! So just once, I would wish you wouldn't attack some ridiculous straw-man of an argument, but the strongest possible argument which I could make. That's what I try to do, and it's why I'm the CTO, and yes, playing golf right now. Cheerio!"
Brilliant! Brilliant! I was just searching for "Docker" after reading a tutorial, and now I spent my inheritance on Docker Enterprise Edition, even though there's also a Community Edition, on the same website, which will continue to exists, and this theory is obviously insane, and nothing of this makes any sense, but why start with goodwill, when conspiracy-fuelled hate will do, and when literally the future of the free world is at stake.
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?
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.
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.
Yup, and your's as well, by extension. I'd add that the rebrand needed to happen, given naming a company and a product the same thing is never a good idea.
I suppose at this point we should ask ourselves why everyone keeps repeating the same thing over and over again. That's irrationality defined.
You appear to be disagreeing with something I said, so I have to assume it's based on the assertion that naming a company AND product the same thing is usually a bad idea, at least for marketing purposes. The confusion that has arisen with other products in the past is real, and it's clear that people are confused with this move. That's why I said it. I didn't say it to be completely precise about what happened, because people aren't precise in understanding how companies market to them. It's a common mistake in marketing, of which I am moderately skilled, or so I hear.
Anyway, I would say, in general terms, that reality is perceived differently from person to person. This means that some may conceptually map a concept to a word in a completely different way than another. That some are confused about this particular change in mapping is a good indication that my recommendation is a sound one, where the product, company, project and repo should be called different things to avoid branding confusion[1] when the consumer is making a decision.
I would also add that this behavior of companies "being confused" in return to people's confusion resulting from a change in branding of something is also an indication of irrationality. And, it's also blaming in tone to assume people should "just get it" when these things are executed on poorly, at least marketing-wise.
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.
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.
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 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 shel...
320 comments
[ 2.9 ms ] story [ 287 ms ] threadMoby = open source development Docker CE = free product release based on Moby Docker EE = commercial product release based on Docker CE.
Moby is a set of standardizable tools that underly that product which might be shared with OS suppliers, Kubernetes, or other virtualization solutions.
If you want containers for your apps, you want Docker. If you're bundling containerization components into your Linux distro/orchestration platform/custom hybrid cloud solution then Moby will be your swiss army knife :)
A lot of the community understands that "docker" has gained a lot of features, but they may not understand it is because Docker is the name of an integrated product suite a company wants to sell.
These features are added because Docker, Inc. wants to have commercial offering containing a full technology stack around containerization, a community offering to attract people to their stack, and open source backing the community offering so that enterprises don't get fearful of vendor lock-in.
But other companies want to use containerization. And Docker doesn't mean anything in their context, because they only want to use a few pieces and swap the rest for their own. In fact, they are resistant against using Docker because 1. It is iffy whether they could use the trademark, even if they were ok marketing a competing product 2. They don't have the same voice in the technical decisions of the open source project
Moby is an attempt to solve these issues: - It is a project with a vendor neutral name - Presumably, it will be managed in a way that gives vendors somewhat equal footing - It makes it clearer that the pieces are containers, etc, the project that develops all the open-source pieces is moby, and one of the products that integrates all the pieces is docker.
It is similar to how RedHat split out Fedora, except that RedHat didn't see the value in having a RedHat-branded community edition.
> 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?
> defining an open, community-centric governance inspired by the Fedora project
I don't think the same applies to Docker Inc. so my initial reaction is step on the brakes here.
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.
The difference between them is like
Redhat Enterprise Linux (Costs Money, Enterprise Supported)
vs
CentOS (Community managed, community supported, Libre Free)
https://www.redhat.com/archives/fedora-list/2003-September/m...
If Moby is the name of a collection of subsystems that are drawn upon to build user-ready container platforms like Docker, isn't GNU userland/Linux kernel->(Fedora/Red Hat)->Red Hat Inc. as Moby->(Docker CE/EE)->Docker Inc.?
Perhaps a better way to explain it is that Moby is a "containerization kernel/core" a la Linux or an "open containerland" a la GNU. The term "framework" may be a little more accessible at the cost of diminishing street cred by appealing more to web devs than old-school system devs. These fancy words probably shouldn't be a problem since it seems only developers would be interested in Moby anyway (instead of end users who would want to use a Moby distribution).
With a little bit of finesse, this could've probably been construed as the boon for the open-source community that it seems you originally intended. "Docker Inc. donates its core technology to the open-source community and invites competitors to use it as the base of their own products." Too late to right the ship?
Docker CE will remain Docker CE. In the Fedora/RHEL analogy, think of Docker CE as the recently introduced "RHEL free developer edition". It's still a commercial product - it's just free and open-source.
> With a little bit of finesse, this could've probably been construed as the boon for the open-source community that it seems you originally intended. "Docker Inc. donates its core technology to the open-source community and invites competitors to use it as the base of their own products." Too late to right the ship?
You mean like this? :)
https://blog.docker.com/2017/04/introducing-the-moby-project...
http://www.cio.com/article/3191344/linux/why-docker-created-...
http://windowsitpro.com/cloud/docker-brings-open-collaborati...
https://jaxenter.com/docker-containers-moby-project-133404.h...
Outside of the Hacker News bubble, this is a non-issue. 500 people read the title of a pull request, didn't even read the contents of the change, and clicked on the "thumbs down" emoji. Meanwhile the vast majority of Docker users don't scan the repository for pull requests. And the majority of those who do actually take the time to read the code, and usually have enough context to understand why we are doing this: modularization, openness etc. In between these two groups, you have Hacker News basically.
That pull request was confusing, yes. And we clarified it. But it's an implementation detail and definitely not representative of how the Moby launch was understood by the community.
This move is going to confuse many users, and could entirely derail their growth. What the hell were they thinking, to execute this decision at such a critical point in time? Docker was already confusing enough to get started with, and now there's an additional barrier to entry just to understand what it all means? People right now at least understand what "Docker" is; now people are going to be redirected to something called "Moby", and many will give up out of confusion.
Really bad timing for such a move.
tldr; Am I even supposed to call it "Docker" now? Years of growing recognition of that name, thrown out the window.
quite to the contrary I'd say. Docker will be their commercial enterprise offering and moby will be the open source project.
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.
http://www.urbandictionary.com/define.php?term=docker
Anyway that is pretty obscure. Thanks for the info, I guess.
- nonce (infosec) - paedophile
- gyp (node) - offensive nickname for gypsies.
Now they have to deal with the even more obvious connotations of "moby".
Out of the frying pan and into the fire!
Well, at least "docker" isn't transitioning to "scissorer".
https://en.wikipedia.org/wiki/Mongolian_idiocy
https://en.wikipedia.org/wiki/Mongo#Other_uses
https://jira.mongodb.org/browse/SERVER-22286
Or maybe just because it is off-topic?
But OP is Dutch - nobody, even from the general gay community (not specifically Holland), replied saying it's the first thing they thought of.
OP, you really made it sound like it's something as well-known as the word wanker - whereas it's extremely obscure.
If I'm in charge of the docker project, the gay dutch community is much too obscure for me to change the name because of.
-
EDIT:
jacquesm, I read your reply to this comment and we simply disagree. Their phrasing can use work, but the information is clearly 100% on-topic if it's genuinely the first thing they thought of when they heard it, and if they phrased it more neutrally. If a project were called "wanker" would you call it off-topic to discuss the UD definition on an article about its name? in reply to the call for speculation phrased "Why change the name? All the books and posts reference the name Docker."?
EDIT2:
this thread is becoming boring but as for the opposite of sarcasm,the opposite of /s are the three letters "srs", maybe in parentheses.
But speaking of which, the Dutch gay community was also quite enamoured with the name of the photo sharing site "Flickr", i.e. https://nl.wikipedia.org/wiki/Flikker
How was my phrasing inappropriate? I never said they should change the name -- just the opposite! At least it's not a demeaning insult, like gimp, git or mongo.
Is there an html markup for non-sarcasm I should use, like the opposite of <s>? Or if I just nest two <s> tags do they cancel out?
Pro tip: always check urbandictionary before naming a project.
This is not nice.
There is no animosity towards kubernetes, quite the contrary. We are working with the kubernetes community to integrate the individual components of Docker, so that everyone can reuse each other's code and ideas.
For example:
- we're actively working on a containerd+CRI integration.
- there's great technical discussions about supporting CNI in SwarmKit
- we are participating in the early CSI (common storage interface) discussions along with the Mesos and Kubernetes communities.
- we are discussing the possibility of participating in the Kubernetes secrets implementation work, since we invested a lot in SwarmKit secrets and some of that work could be reused, or at least discussed for reference.
In short: no animosity. Not sure what happened to you at Dockercon but we will look into it.
Thanks for responding. There really isn't many more details other than that. It was in DockerCon Seattle in the space needle. I don't remember who the employee was. I did generally get the feeling that Docker employees felt at least wary or worse about k8s. That was from more than just that once situation, but from multiple interactions I had over the conference with employees. I only pointed out that one interaction because it made me certain that at least that employee was more than wary.
I'm happily using Docker and it was a good conference otherwise.
I'm no k8s fanboy (and I have the comment history full of replies from annoyed k8s contributors to prove it), but it's because they know that Kubernetes is going to end them. It relegates Docker to a swappable implementation detail.
Docker, on the other hand........
If they can drive adoption, it makes it much easier to move customers away from AWS and on to GCE.
I'm looking forward to them accepting defeat on this one and just natively supporting K8s like Google.
These large companies are developing open source as a strategic asset but most people have no idea and just think they're being altruistic.
The reason this really sucks is because as a result, all the large projects backed by large companies kill of the alternatives which have very pure motivation. Just like react is replacing a pure open standards based way of web development. Sure, it's "open source", but this is not right.
It's fascinating how far we have come in the past 20 years. First the introduction of using opensource at work, then businesses starting to opensource things themselves, and here we are complaining that the top opensource projects are in fact backed by companies.
I understand your point, but it's also a luxury to be able to complain about this.
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.
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.
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?
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.
It's not a "cheap shot", and it's not for "upvotes", it's just an observation about the nature of this change being non-technical, related to messaging.
- a CIO
Platinum support means you can get C-level executives on the line.
Reputation and counter party risk all factor into evaluation and cost of support as well
That's "on the _premises_".
You might not care about this, and many don't. You're running the risk that the maintainers won't pack up shop and stop maintaining the project, and that you & your team will need to inherit the project.
Other way of looking at it, is that if you're a business, you always should pay for your software, even if it's open source. Because you will one way or another: through your team, or through the risk that free riding brings.
It is a FACT that individuals are unable to use the term "Docker" on anything they would like to create and share with others. This has been enforced with takedown notices and legal entities getting involved in "protecting" the Docker brand, on Docker's behalf. This, in and of itself makes sense, given Docker is a private company with a significant amount of private investment behind it, with expected returns on protecting that investment. It has used that investment well to further build the brand, as you indicate here.
However. Docker is also an idea which is one of taking a "software container" and starting it somewhere, running it for a bit, twiddling on it in a variety of ways, then moving it somewhere else where someone else can do that too, without too much operations headache as you do so. Again, it's the IDEA of this that matters, not whether it is technically true or not. The idea simply leverages the concepts of writing, deploying and running code and smears them across a the vast resources of which the Internet is comprised.
I've seen the gleam in people's eyes when they talk about a ubiquitous computing infrastructure, of which it will run their code, without question, and never, ever breaks. Irrational beliefs are still beliefs, and sometimes it is necessary to also believe they are rational ones in order to get things done. We're all busy, and the Internet requires a lot of us to get more done in the future. People need the idea of Docker to get project's interest raised, approved, and put into production to get more things done.
This is where Docker's dissonance comes in, and does so fairly heavily handed. Docker is here to make money. They will do that at the expense of all other things, given their purpose is to preserve shareholder value first. That includes changing the idea that everyone holds about ubiquitous computing. That's not to say that shareholder value isn't tied to consumer value and completely rational, but it can also become a vicious circle very quickly when company values are prioritized over consumer values at any expense, or vice versa even.
Personally, this is why I'm not a big of traditional investments in infrastructure technologies. While I do think that traditional investments have been a great help to the growth of technology in the past, it is my belief we are going to continue to run into increasing challenges attempting to rationalize arguments for shareholder value vs. user's best interests when it comes to infrastructure. And, to make it even more challenging, I think most times the users don't realize they are trusting these offerings in an implicit way, which makes their view on matters highly irrational. That is to say, irrationality indicates additional work must be done to resolve the truths of who and what to trust. This is made difficult by applying that irrationality to the very systems on which we base trust.
I don't want to live in a reality where we are having to constantly question the trustworthiness, or irrationality, of our infrastructure.
I don't have a great suggestion for how to fix these types of issues other than proposing a radical change in infrastructure business models. I do have a suggestion on how to do that, but it will make it completely irrational for traditional investors to consider, which would limit the adoption of it, even if it got going. A catch 22, if there ever was one.
This seems to be a much higher level construct , like PaaS or Lambda, than what Docker provides.
Docker was more of a bottom-up wake up call to those upper layers that lower layer technology usability still matters.
Basically I wouldn't ignore it.
So to me it seems fair but depending on your experience I could see it as a cheap shot for upvotes as well.
Here is an old saying: "Nobody ever got fired for buying IBM" - neatly illustrating the issue. I have met _many_ senior people that don't understand these naming differences. They tend to be the bosses of the CEO and CTO's
If you were already migrating to Docker, now you have to explain that the project name changed overnight without explanation, and it's hurting your credibility pretty bad. It's also gonna bring a lot of confusion onto everyone for a very long time.
The three points seem to be, cheaper, more secure, and the other guys are dumb.
I'm sure they do. If I were involved in a situation like that I would definitely check this out, just to make sure that their recommendation is not just a way to protect their income stream. 'Don't look there' is the forbidden fruit theory at work, of course everybody will look there.
Good thing it's all OSS. Don't try to solve problems with a pitchfork, when a simple fork will do.
There's nothing viral about using GPL code. Your docker containers are probably running on Linux, which is also GPL, and that has neither infected nor affected you, has it?
It's viral, any connection whatsoever, not sure where they draw the line. GPL is just not enforced except when it comes to selling software licenses.
Would you not think all these huge companies would think twice before using Linux if it meant being dependent on the good will of everyone who ever contributed to any of thousands of packages that come with a typical distribution?
"I predict that the term "micro" will be replaced by the term "modular", and that docker will create a replacement for the microcontainer named the modular loader/container."
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.
Not the first time this is done either.
If they had renamed the commercial stuff to Moby they'd have to start from scratch, now there are thousands of articles and links that say 'go get docker' intending to point you to the open source stuff, instead directing you to the commercial stuff.
A very effective bait-and-switch.
That's not Docker. That's Moby.
That happens ALL the time. Except they (managers) don't read tutorials, they read trade magazines saying that X is the new hotness.
So off they go and buy X Enterprise Edition.
This happens in the corporate world, not everywhere, but that's where a company gets the big contracts.
Not picking on Docker here, it's a great product and good luck to them; just a commentary on corporate fashion driven IT culture.
But those projects aren't true OSS in the way that something like Docker / Moby needs to be. Your Vagrant example is one of them; Vagrant is a useful tool but ultimately too narrowly-focused. Docker's biggest coup was seamlessly integrating orchestration tools with deployment tools -- and now they're separating the two (which is completely fine, because they need to be separate tools anyway to support complex use cases).
Docker has built a lot of valuable IP that they want to protect (branding, UI, API, etc.) That makes a lot of sense. It also makes sense that they want to open source a big chunk of the "glue" between everything because 1) it's generally useful to lots of people / projects and 2) it gets other companies to kick in dollars for maintenance.
You're not going to get non-customers to fund the maintenance of an open source project that is wholly run and owned by Docker. They know that, and hence they're creating a governance board. But once you do that, you lose full control of your brand (which is attached to the project), and thus you have to divorce the two.
Docker is still going to drive the development of Moby. But over time, other companies will enter the fold to build other complex system orchestration projects on top of Moby.
By splitting up the open-source Docker CE codebase into smaller projects, each smaller project is more approachable to outside potential contributors. If Docker can succeed in increasing the number of contributors to the Moby projects, compared to the Docker CE project, then they'll have succeeded in increasing the relevance of their product in their target market, which translates to more customers, sales, and profits in the long-term.
Of course they run the business risk of a fork taking off, but in the real world, forks are arms races. They're easily won against dead or severely mismanaged projects, but against a project with a well-funded corporate sponsor? Few, if any, will have the resources to put into making a better fork than the original.
And like they said, for the vast majority of their customers, nothing is changing. Their customers bought a Docker product yesterday, and they're buying a Docker product tomorrow. That branding isn't changing.
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 :)
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.
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.
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.
- 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"
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.
:thumbsup:
- Boss: here's the business-level problem I want solved
- Engineers: here's what we think it'll take to do it, and the technical path forward
- Boss: either (1) cool, what can I can do to help you get started? or (2) yikes, that's a bigger problem than I thought. What's the 80% solution?
Brilliant! Brilliant! Bravo!
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.
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.
They'd lose 40k+ GitHub stars, I guess.
You appear to be disagreeing with something I said, so I have to assume it's based on the assertion that naming a company AND product the same thing is usually a bad idea, at least for marketing purposes. The confusion that has arisen with other products in the past is real, and it's clear that people are confused with this move. That's why I said it. I didn't say it to be completely precise about what happened, because people aren't precise in understanding how companies market to them. It's a common mistake in marketing, of which I am moderately skilled, or so I hear.
Anyway, I would say, in general terms, that reality is perceived differently from person to person. This means that some may conceptually map a concept to a word in a completely different way than another. That some are confused about this particular change in mapping is a good indication that my recommendation is a sound one, where the product, company, project and repo should be called different things to avoid branding confusion[1] when the consumer is making a decision.
I would also add that this behavior of companies "being confused" in return to people's confusion resulting from a change in branding of something is also an indication of irrationality. And, it's also blaming in tone to assume people should "just get it" when these things are executed on poorly, at least marketing-wise.
[1] https://hbr.org/2002/03/brand-confusion
And, their competition at the higher level is starting to abstract away from their runtime. Like this: https://github.com/kubernetes-incubator/cri-o
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 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 shel...
I'm 36, and have seen most of what your described and more.
Any language, as it grows and takes on larger tasks, its dependencies will also grow.
Build time dependency management, distribution, and run time dependency management are different phases that would still need to be managed