Should Docker Move To a Non-Profit Foundation? 47
darthcamaro writes "Docker has become the new hotness in virtualization technology — but it is still a project that is led by the backing of a single vendor — Docker Inc. Is that a problem? Should there be an open-source Foundation to manage the governance and operation of the Docker project? In a video interview — Docker founder and Benevolent Dictator for Life Solomon Hykes says — No."
It's a very complex issue. (Score:4, Funny)
I will wait to see what Bennett Haselton has to say about it.
Assuming it's open source, who cares. (Score:2)
If it gets mismanaged by an individual, you'll get dozens of non-profits as well as corporations that are welcome to fork it and try to convince people to use their own forks
If it gets mismanaged by a non-profit, you'll get dozens of commercial companies and individuals that are welcome to fork it and try to convince people to use their own forks.
In the end, the best managed fork will win; regardless of how it's t
a foundation? surely a product should be first. (Score:4, Insightful)
Foundations are used when an established product has such a broad userbase that representing it well requires an independent group of people.
A foundation for a thing which is as of now just a tool to assist in using other tools seems overkill. Unless your point is to hype the company.
I understand that this company just got another round of financing ... (according to wikipedia).
Perhaps someone out there wants their stock to go up by discussing it.
Rest assured, this company will fail or succeed on its own and will LIKELY BE REPLACED BY SOMETHING BETTER if the company starts acting like dicks...
Or if their investors do.
I hope it annoys you I didn't use the company name once in here.
See OP.
M
Re: (Score:2)
Rest assured, this company will fail or succeed on its own and will LIKELY BE REPLACED BY SOMETHING BETTER if the company starts acting like dicks...
I agree... Another factor to consider is the fact the codebase is fairly small... I have first hand dived into because of lacking docs...
Compared to a product like LibreOffice/OpenOffice, apache, Firefox, Linux, docker is very small project. So launching a competing product isn't that hard...
I thought... (Score:1)
Node.js was the problem, and Docker was just shifting that problem to another place in the pipeline.
So, my product goes viral... (Score:2)
...and you now expect me to give it away?
I really need to get to Starbucks and find out just what in the hell all the hipsters are sucking down. Apparently it's a Venti Capitalism with a New Math chaser that doesn't add up for shit.
Re: (Score:2)
Re: (Score:3)
No one cares enough to build a competitor. (Score:5, Informative)
Hype Shmype...
LXC is the core technology, and the part that's actually revolutionary (for linux). Docker is a cool, well thought out, popular, easy-to-use (etc. ad nauseum) front end to LXC. Yes, I know there some interesting features, but I remain unimpressed. It's still a FRONT END to containers. Honestly I don't know why there aren't several competing front-ends like what happened with cd burning software. Maybe because the people competent to make one just don't care -they are still using LXC directly. It -is- drop dead simple.
I know I for one don't want application containers anyway, what's it save me a few hundred MB of disk space? Whatever, I'm still using LXC extensively every day, and I still haven't gone past the front page of Dockers website.
Re: (Score:2)
LXC is the core technology, and the part that's actually revolutionary (for linux).
LXC is not really revolutionary, OpenVZ and Linux-VServer provided linux containerization for many many years.
I expect someone to come along any minute now and say that Docker no longer uses LXC anyway, now it uses libcontainer. This isn't true, libcontainer is just another frontend to LXC, libvirt being the first project to run a LXC without using the LXC userland.
http://linux-vserver.org/ [linux-vserver.org]
http://openvz.org/ [openvz.org]
Re: (Score:1)
Re: (Score:3)
LXC existed for some years so far, and the same for containers and similar technologies in other platforms. What Docker added over lxc is adding the use of an unionfs for reusing/improving containers, a simple way to share them, and a simple but powerful command line utility and api to manage them.
There is nothing so special in sulphur, charcoal and salt peter, but do the right mix with them and you get something explosive (and used in revolutions, too)
Re:No one cares enough to build a competitor. (Score:4, Interesting)
Before docker, as a (not necessarily web) developer I used vagrant to create reproducible environments and build artefacts from a very small set of files. The goal being: I should be able to git clone a very tiny repo tracking a few KiB of scripts and declartiive stuff/config, which - when run - pulls down dependencies, reproduces a build toolchain/environment, performs the build, and delivers substantially identical artefacts regardless of which machine I run it from. I should be able look at an artefact in 2-3 years time, look it up in our version history and reproduce it easily.
Achieving this isn't so easy. Even if I had been using LXC all along I still wouldn't have had the main thing from Dockerfiles that I enjoy: cached build steps. I've been cornered due to time pressures in the past where I can't afford to tweak everything nicely so I've had to release build artefacts from a process which isn't captured in the automation (i.e. I manually babysat the build to meet a requirement on time). This is because hour-long builds make for maybe 3-4 iterations per day, so you have one thread of work where you're hacking interactively while you wait to see if the automation was able to deliver the result you were up to an hour or two ago. I still have this to an extent with Docker (adjust build step and re-run, or step in interactively to explore what's needed) but because Dockerfile steps are cached these iterations are massively accelerated and there's only a handful of occasions where I had to bypass this process now.
I can't speak for using Docker to actually containerize running applications (that's not how I use it), but just this narrow usage of Docker has helped my productivity enormously.
Re: (Score:2)
I've never used Docker and I've always had cached build steps. It takes less than a second create a handful of [new] containers, making reusable containers basically useless.
Re: (Score:2)
Docker's transparent caching of RUN/ADD/etc Dockerfile steps has nothing to do with reusable containers. That "it takes less than a second [to] create a handful of [new] containers" is just as true for docker as it is for plain old LXC.
There are two sentences here but I'm not sure how they relate to each other, or the docker feature I'm discussing.
Re: (Score:2)
Docker is a cool, well thought out, popular, easy-to-use (etc. ad nauseum) front end to LXC
The front end is where open source tends to fail. Falls flat on its face. Have you ever wondered why?
Re:No one cares enough to build a competitor. (Score:5, Informative)
Docker does not use LXC anymore by default, fwiw.
Re: (Score:1)
Docker defines an abstraction for these machine-specific settings, so that the exact same Docker container can run - unchanged - on many different machines, with many different configurations.
So a newer, spiffier version of Java. Great!
I know people who spend all this time "docker-ing" a web app, and I ask them why and they say "I can deploy it to any machine in like no time." Ok, so how many servers do you have. "One"
Re: (Score:2)
AC, your inability to see below the surface abstraction layers is your defining characteristic.
Portable deployment across machines. -- LXC templates accomplish this quite nicely, Docker is not needed.
Application-centric. -- "Minimal image" vs "Strictly what's needed by the app" saves 1 or 2 hundred MB? Don't care.
Automatic build. -- Anyone is free to use a state machine with LXC.
Versioning. -- State machine + Git!
Component re-use. -- You can cache with plain old LXC as well. Woot!
Sharing. -- Put your tem
Re: (Score:2)
Yes, people can always roll their own solution ... if they want to.
Re: (Score:2)
2) You claim you can roll your very own solution to every single one of these "things Docker adds on top of LXC".
No dumbass. The solutions already exist. Man you're dense. Go back to your bandwagon junior.
Re: (Score:2)
What got me is that he admitted that he hadn't even tried the thing he's poo-pooing.
Re: (Score:2)
^^THIS! is the entire point of my original post, glad you understand that Docker just doesn't bring anything new or compelling to the world.
Let the man make his money (Score:3)
Re: (Score:2)
Non profit, bah, design by committee, ... (Score:2)
One of the reasons that OpenStack is such a mess is because it is a conglomeration of 1000 vested interests pulling it in a 1000 different directions. The same goes for numerous high profit non profits out there. The good thing about Docker Inc. running Docker is that it is a small team with a vision and one that knows what it wants.
There's also the thing that 'non profits' that are established at an early stage to run a project aren't really non profits, because they are funded and consequently influenced
Re: (Score:2)
s,high profit non profits,high profile non profits ...although the mistyped version has some amusement and juice to it...
Why should he listen? (Score:2)