3 ms·
There's no need to worry. `Docker CE` is the exact same Docker as before - just renamed to clarify the relationship to Docker EE. Docker is still open-source;
by shykes 10y ago
There's no need to worry. `Docker CE` is the exact same Docker as before - just renamed to clarify the relationship to Docker EE.
Docker is still open-source; it still has all the same features; it has the same maintainers and contribution roles; it has the same roadmap of features. And we still welcome pull requests.
Meanwhile we have been breaking the components of Docker into standalone upstream projects: containerd, swarmkit, libnetwork etc. So there are more and more ways to use parts of Docker without being forced to use all of it. We will continue doing that.
Is there any detailed fear that you can describe? I will do my best to reassure you.
- ilovecaching 10y agoIt may be only a name change today, but relabeling the docker to 'CE' opens up a world of possibilities where 'enterprise features' get shipped in the 'EE' and the 'CE' turns into watered down freemiumware. Honestly I don't believe that this 'clarifies' an existing relationship. DDC was the product and the locked down engine was just a part of that product. This makes it excruciatingly clear that DDC failed to take off and now we're going another level down to making the engine itself a product, which comes with all sorts of questions about what will really be driving the roadmap in the future. What would have been wrong with focusing on monetizing Docker Hub and leaving the tool alone like Github and Git? Docker Hub doesn't look like it's been updated in ages... I also don't see why anyone should be thrilled that this split is being made when you can only offer a 1 year support window for 'EE'? How is anyone going to explain to their manager that what the cool tool they were sold on is now just the 'community version' and if they want support they can only get it for one year at a time? Do you know how long it takes to go through the upgrade process in a large enterprise? We'll be lucky if we get six months or less of support before we have to upgrade again. Also, I feel no urge to go and create pull requests for your community edition product. If Docker were still completely free and community driven I would feel compelled to do my part, but I'm not building software for you to sell.
- benmusch 10y agoSeems unlikely that there would be 'enterprise features'... the value of Docker is that you can send a Dockerfile somewhere and it will work identically on each system. If they changed the feature-set of Docker EE it'd undermine the reason people use their product
- majewsky 10y agoI'd guess that if enterprise features were to appear, it would be higher up in the stack then "sending a Dockerfile somewhere". Container runtimes are becoming (or have already become) a commodity, so people are now chasing to get a slice of the orchestration pie before everyone standardizes on Kubernetes.
- danudey 10y agoIf the Enterprise Edition is a superset of Community Edition functionality, then this could definitely still happen. EE people could run all CE Dockerfiles, containers, etc., but EE people could also (for their own uses, or from enterprise vendors) run Enterprise docker containers, Dockerfiles, etc. The situation could turn into something reminiscent of using non-RHEL/CentOS Linux in the enterprise before Ubuntu became popular. Using Debian and need drivers from a vendor? Here's an RPM! Convert it to a .deb, extract it yourself, hope it doesn't have scripts that'll break your install and that the paths work properly. Oh wait this is for a specific patched kernel that RHEL ships, now I have to go get the source and build it myself, but it only ships as patches to a kernel source tree of theirs. Ubuntu's widespread support helped, and then the advent of VMs made it so that you could hypervisor your hardware and then not have to worry about support in your various OSes. And then vendors started shipping VM images (e.g. AeroFS), but only if you're using a supported virtualization solution (we support both ESIx and HyperV!). Now we have containers, and we can ship customized environments, stripped down and devoid of anything the app doesn't need, but how long until vendors start shipping those containers with assumptions about either the host or the environment/tooling that only works for the people who pay extra?
- shykes 10y agoIt looks like containerd will be a better fit for you than Docker. It's the core container runtime extracted into a standalone upstream project. See https://containerd.tools https://containerd.tools and https://blog.docker.com/2017/02/containerd-summit-recap-slides-videos-meeting-notes/ https://blog.docker.com/2017/02/containerd-summit-recap-slid...
- kordless 10y agoI'll detail my fears. I'm afraid investment and corporate structure, specifically of infrastructure companies, directly affects the security, reliability and trust of the infrastructure on which all of this stuff runs. I am aware maintaining shareholder value for such a company may be difficult given infrastructure (or fractional infrastructure) may be asked to remain open, transparent and trustworthy for the user's benefit. To use a bit of a biased argument, I've been told by several infrastructure VCs that the infrastructure market is currently difficult to invest in because of the uncertainty the technology behind it has brought us. I don't trust that continued traditional investments behind producing those infrastructure offerings are a rational choice for users. However, at the end of the day, only the users can speak to that claim. I can only speak my mind on the matter. Unfortunately, it's difficult to trust a service or software built on closed technologies because seeing inside the service or software becomes difficult, expensive or impossible. The combination of desired outcomes (easy infrastructure) and risk bias (implied trust) presents itself as a dangerous one because leads to cognitive dissonance where the market must literally believe two things at once: We have to TRUST this service or software because We NEED this service or software. I'd prefer we all work together to solve these conflicted views with "enterprise" software offerings, especially those involved in building infrastructure, but my observations say that we are more likely to not work together because of existing investment structures. Perhaps this will change over time as new models emerge. For now, I remain sceptical at best about the way we're investing and growing the infrastructure market.