Hacker News new | comments | show | ask | jobs | submit login

Hi, I created Docker. I have exactly 3 things to say:

1) Competition is always good. Lxc brought competition to openvz and vserver. Docker brought competition to lxc. And now tools like lxd, rocket and nspawn are bringing competition to Docker. In response Docker is forced to up its game and earn its right to be the dominant tool. This is a good thing.

2) "disappointed" doesn't even begin to describe how I feel about the behavior and language in this post and in the accompanying press campaign. If you're going to compete, just compete! Slinging mud accomplishes nothing and will backfire in the end.

3) if anyone's interested, here is a recent exchange where I highlight Docker's philosophy and goals. Ironically the recipient of this exchange is the same person who posted this article. Spoiler alert: it tells a very different story from the above article.

https://twitter.com/solomonstre/status/530574130819923968 (this is principle 13/13, the rest should be visible via Twitter threading)

EDIT: here is the content of the above twitter thread:

1) interface to the app and developer should be standardized, and enforced ruthlessly to prevent fragmentation

2) infrastructure should be pluggable and composable to the extreme via drivers & plugins

3) batteries included but removable. Docker should ship a default, swappable implementation good enough for the 80% case

4) toolkit model. Whenever it doesn't hurt the user experience, allow using one piece of the platform without the others.

5) Developers and Ops are equally important users. It is possible and necessary to make both happy.

6) If you buy into Docker as a platform, we'll support and help you. If you don't, we'll support and help you :)

7) Protect the integrity of the project at all cost. No design decision in the project has EVER been driven by revenue.

8) Docker inc. in a nutshell: provide basic infrastructure, sell services which make the project more successful, not less.

9) Not everyone has a toaster, and not everyone gets power from a dam. But everyone has power outlets. Docker is the outlet

10) Docker follows the same hourglass architecture as the internet or unix. It's the opposite of "all things to all people"

11) Anyone is free to try "embrace, extend extinguish" on Docker. But incentives are designed to make that a stupid decision

12) Docker's scope and direction are constant. It's people's understanding of it, and execution speed, that are changing

13) If you USE Docker I should listen to your opinion on scope and design. If you SELL Docker, you should listen to mine.




I think you're reading too much - or too little - into this if you think they're "slinging mud". Any fork is going to list its reasons for the fork- if they didn't have issues with how Docker is heading, why would they be making the fork in the first place?

If they just quietly gave an ambiguous non-disparaging statement like "we're forking because we're unhappy with the direction Docker is taking", it would seem frivolous and ill-considered, and nobody would know on what points the fork would be aiming to distinguish itself.

This statement needs to be made, the way it was made, for the same reasons any project announcement is made: it needs to announce that it exists, and why it exists. It's the same as Docker's "debut" blog post(s).

Every schism needs its 95 Theses, and the odds favor the ones who can read them, understand them, and take them into consideration.

---

Disclaimer (re https://twitter.com/kenperkins/status/539528757711622145): I make edits to my comments after posting, usually posting a line or two then fleshing them out over time. If I make a change that conflicts with a statement in an earlier revision, I'll note it: otherwise I'm pretty much just composing live.


It's really bugging me people are using the word "fork". This is not a fork, it's a competing container format, there isn't any docker code in Rocket AFAIK. Even @shykes called it a fork in a comment, it's not somebody taking your code and doing something different with it, they are doing their own implementation. Ideas aren't "forked", code is.

As to everything else, I manage CoreOS clusters with docker for now, and while this came out of the blue (seems like for Docker folks as well) I'm happy to see what happens as a result. I'm not sure why there are hurt feelings over the announcement, didn't find anything particularly in bad taste and what exactly is wrong with promoting your new product?

The CoreOS team isn't under any obligation to docker to contribute however anyone on the docker team want's them too. Even if these issues have been discussed before they've clearly taken a different path and that's within their right, not sure where mud is being slung. Where this will lead who knows, but hopefully there will still be good collaboration between different groups as they pursue their own goals that align with their needs.

EDIT: I haven't actually looked at the code, so if somebody wants to prove what I'm saying wrong please do. I'm basing what I know off the announcement.


IMO rewriting something from scratch is like forking but worse because it's impossible to merge later. And Rocket is definitely forking the Docker community.


By this definition, linux is a fork of windows and is inferior because it cannot be merged back to windows.

Often, starting from scratch is better. This is especially true when the goals or philosophy of the two projects are fundamentally different and incompatible, even if they perform similar tasks. Again, linux vs windows example applies.


If it can't be merged, it's not a fork, that's the key part of forks (well, not entirely, but the lack of shared code means it's not a fork by my definition).

That said, you're on point: this is forking the community. A hard fork, too.


That's great, except forks can be merged later.


Yes, that's what I said.


I don't have a horse in this race, but from what I read this is the part that can be construed as "slinging mud". I've put some [read between the lines] comments in square brackets:

  "Unfortunately, a simple re-usable component is not how things are playing
   out. Docker [much to our dismay] now is building tools for launching cloud
   servers, systems for clustering, and a wide range of functions: building
   images, running images, uploading, downloading, and eventually even overlay
   networking, all compiled into one [big and nasty] monolithic binary running
   primarily as root [how insecure is that?] on your server. The standard
   container manifesto was removed [those flip-floppers!]. We should stop
   talking about Docker containers, and start talking about the Docker
   Platform [since we can focus attention on our efforts that way]. It is not
   becoming the simple composable building block we had envisioned [which puts
   our offerings at a disadvantage]."

  "We still believe in the original premise of containers that Docker
   introduced, so [unlike those silly Docker people] we are doing something
   about it."
Later on, they specifically say:

  "the Docker process model ... is fundamentally flawed"
  "We cannot in good faith continue to support Docker’s broken security model..."
All these may be valid criticisms, but even ignoring my potentially off-base annotations it's difficult to read their announcement as anything other than "Docker is broken and can't be fixed". It's reminiscent of political attack ads which focus on the shortcomings of your opponent rather than the strengths of your own platform.


"Docker is broken and can't be fixed"

Or, taking the announcement as intended, "We were interested in the direction Docker started in, they have since pivoted. We were more interested in the direction than Docker itself".

Yes, there is some mild-mannered disparagement in the announcement, but it's hard to characterise it as 'slinging mud', and it's not really fair to disparage it with the name-calling you're injecting.


I think they spent plenty of time talking about the advantages of their approach. The comment at the bottom there was only in response to an FAQ of "why not just work from the docker you already use?"


[deleted]


personally, I think the long term value of Rocket is not about Rocket -- its about the ACI specification for the formats of containers.

Right now I'm already taking a Dockerfile, exporting it to a tar, and then running systemd-nspawn -- I love Dockerfiles, I love being able to grab a postgres server and get it up quickly from Docker Hub, but I didn't need or want the rest of docker.

If both Docker and Rocket support ACI, then you have a composable image layer, and that means people aren't locked into either ecosystem just to build images of their applications.

ACI :: Docker-tar-format to me is like QCOW2 :: VMDK. Wouldn't it be cool if projects like Packer[1] didn't have to exist, because the image format of Virtual Machines was open and documented as an independent standard?

[1] - https://www.packer.io/


Now we're talking. Yes, I agree having a better spec for the underlying image format would be nice. In fact I also agree you should be able to use the Docker runtime without its packaging system, and vice-versa.

However I think it makes more sense to do this on the actual Docker format which everyone already uses... That way you get the benefit of increased openness without the drawback of fragmentation. I have the impression I've been pretty vocal in asking for help in making this happen, and wish these guys had stepped in to help instead of forking. I pretty distinctly remember pitching this to them in person.

So, I'll re-iterate my request for help here: I would like to improve the separation between the Docker runtime and packaging system, and am asking for help from the community. Ping me on irc if you are interested.


Looking back from the long-term future, though, what's the difference between the two approaches?

Whether the work on a standard container format happens inside or outside of Docker, it would result in a format presumably a bit different from how Docker containers are now (e.g. not overlay-layered by default, since most build tooling wants to just output an atomic fileset.) And either way, work would then occur to make Docker support that standard format.

The only real difference is that, in this approach, the ecosystem also gets a second viable runtime for these standard containers out of the deal, which doesn't seem like a bad thing. You can't have a "standard" that is useful in a generic sense without at least two major players pulling it in different directions; otherwise you get something like Microsoft's OpenDocument format.


> However I think it makes more sense to do this on the actual Docker format which everyone already uses... That way you get the benefit of increased openness without the drawback of fragmentation.

One could have just as easily said the same thing when the Docker format was introduced. The OpenVZ template format works well and is very similar to the proposed ACI format. The Docker format hasn't been without issue/problems.


I think it's called OVF[1]. It's just not as widely supported as it probably should be.

[1] - http://en.wikipedia.org/wiki/Open_Virtualization_Format


Yeah, just try using OVF with containers and you'll discover how much of a round peg/square hole fit you are describing. VM's and containers are surprisingly different.


> Wouldn't it be cool if projects like Packer[1] didn't have to exist, because the image format of Virtual Machines was open and documented as an independent standard?

Is what I should have quoted in my reply. Nobody was talking about using one instead of the other. Though, it'd be easy enough to run, for instance, CoreOS from an OVF image to run containers from. Though, I feel like you and I are just stating the obvious at this point. Wouldn't you agree?


I would.


Yes, it is always massively disappointing with every release of Parallels Desktop for Mac that OVFs and OVAs are not supported; they blindly continue to support just their own disk format whilst pushing their "enterprise" solution - surely OVF and OVA deployments are essential in that environment???

Sigh!

This'll be the last version of Parallels that I buy (thanks Yosemite)


In theory, OVF is the 'answer' for Virtual Machines -- but its failure has been in adoption -- if you can't get Amazon and OpenStack to adopt it, what's the point?

Before Rocket/ACI there wasn't even a contender for Containers. Now there is a published spec. Start there. Iterate.


I don't disagree, but OVF is an ANSI[1] & ISO[2] standard. Like you said, Amazon & OpenStack have chosen not to adopt it.

[1] http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS+469-20...

[2] http://www.iso.org/iso/home/store/catalogue_tc/catalogue_det...


Just goes to show that adopted+working is more important and useful than a published spec.


Might be worth mentioning that you are employed by Docker, if you're going to engage in this discussion.


The Docker team does this a lot, and it's part of their PR machine. They creep their way into and eventually try to steer every conversation regarding containers, especially when it can potentially be damaging to their "brand". (part of what has rubbed me the wrong way)

~~~

Frankly, shykes and other Docker employees shouldn't be commenting here. It only serves to make them look petty with any attempt of a "rebuttal" and, as shykes put it, "sling mud". CoreOS made a grand announcement, and yes it competes with Docker... but just let it play out.

Frankly, there is a lot of things Rocket aims to do that are more appealing to me. Security being one of them, and a standardized container specification is another. If anything, it will make Docker compete better.


Actually, I appreciate that shykes and others take the time and try to explain their side of things and engage in a dialog. There's a lot of people confused right now about what's going on.


I think it's a little less scary than you think. The person who commented was a dev. Like a very devvy dev, who spends lots of time devving on Docker. He's free to express an opinion, but he prob should have mentioned who he was (I recognised his name because he dev a lot on docker). But he's not part of the PR machine. He's a dev. A dev with a kinda ill thought out opinion, but a dev.


> The Docker team does this a lot, and it's part of their PR machine. They creep their way into and eventually try to steer every conversation regarding containers, especially when it can potentially be damaging to their "brand".

Can you give three examples of this happening?


If you must know, the opposite just happened. Someone who happens to work at Docker just voiced their individual opinion. He was then reminded by "the PR machine" that it is better to take the high road and refrain from answering, and let the company make an official answer. This is pretty standard communication practices, and a good way to avoid feeding trolls like you. I know this, because I myself will get in trouble for replying to you :)


> avoid feeding trolls like you.

Interesting to see you resort to calling your users "trolls" simply because they feel it's not good for you, the head of Docker, to respond off-the-cuff and angry about a PR announcement from a competitor.

> that it is better to take the high road and refrain from answering, and let the company make an official answer

Your company already released an official announcement 2+ hours ago (with much of the same rhetoric as your post here). Seems you didn't even follow your own advice.


I'm just calling you a troll, and it's for implying that a cabal of Docker employees somehow manipulates and suppresses the public conversation about containers for the profit of their employers.


    > I'm just calling you a troll, and it's for implying that 
    > a cabal of Docker employees somehow manipulates and 
    > suppresses the public conversation about containers for 
    > the profit of their employers.
Really? This strikes you as a good idea?


You came here with the explicit intent of disseminating your viewpoint that CoreOS is making a terrible decision and why your company and it's ideals are better. Your company already made an official PR response, leave it at that. (and you call me a troll?)

For the first time in Docker's short history, it's future and mission are being directly challenged. This is your response? (it won't be the last time Docker is directly challenged).

Imagine if Microsoft went around rattling the cage every time Apple released some product -- it would make them look pretty petty pretty quickly. Just get out there and compete. Produce a superior product and the market will speak.


> Imagine if Microsoft went around rattling the cage every time Apple released some product

You mean like this? https://www.youtube.com/watch?v=eywi0h_Y5_U FIVE HUNDRED DOLLARS FOR A PHONE?

In all seriousness, you made a few blaming statements early on in this thread which is the most likely reason got the reaction you did from Solomon. I'm not opposed to people making observations, but speaking for others really has no place here!

Specifically talking about the "PR machine" comment. Say what you mean!


Well, for the sake of the argument, it did make them look bad.


You're just digging a hole here. Better to take your own advice and take the high road.


> Hi, I created Docker. I have exactly 3 things to say:

In line of making lists of things to say. I got 2.

1) Don't use Twitter for having long conversations and public fights. Just don't. No good will come out of it. Engaging in that is feeding the trolls and slinging mud, which you accuse the other party of doing.

2) Vis-a-vis "just compete!". How do you see this "competing" happening without an announcement like this. "We have created X container thingy"? Ok, isn't it smart to compare to an existing container "thingy" right of the bat?

Imagine they didn't mention Docker. I can see you writing about "stealing of ideas", "lies", "not being straight-forward", "this is just a Docker clone by they don't mention Docker so they are being shady" and so on.


> 1) Don't use Twitter for having long conversations and public fights. Just don't. No good will come out of it.

I encourage you to read the twitter exchange I linked to. It predates all of this, and is not at all a fight. On the contrary it is a constructive exchange and I am using it to assert Docker's philosophy in a positive way

> Vis-a-vis "just compete!". How do you see this "competing" happening without an announcement like this. "We have created X container thingy"? Ok, isn't it smart to compare to an existing container "thingy" right of the bat?

Surely it's possible to launch a competing tool without resorting to a press campaign like this one: http://techcrunch.com/2014/12/01/coreos-calls-docker-fundame...

> Imagine they didn't mention Docker. I can see you writing about "stealing of ideas", "lies", "not being straight-forward", "this is just a Docker clone by they don't mention Docker so they are being shady" and so on.

No, I would definitely not say that.


> without resorting to a press campaign like this one

So, clearly stating their concerns about the direction your company has taken, and why they feel the need to create a competing solution is bad?

The only way that article can be considered "negative" is if your opinion is that Docker, Inc are the gods of containerisation and should be considered the be-all and end-all of solutions to container based software deployments etc.


If you were trying to make sure as many people as possible paid attention to Rocket as a serious alternative to Docker, which is the current de facto standard Linux containerization scheme, well done.


An article spreading fud on Docker's philosophy is at the top of HN. I added a comment describing the actual Docker philosophy.


You have to realize that commenting here, in this thread in particular is not helping things... Instead of keeping your head down, letting the buzz blow over, you just made the PR that much stronger for the CoreOS POV. You should have thought about posting an article in a few days/weeks that, while not directly refuting the CoreOS post, put the Docker vision front and center and made it seem like you were the leader of the market, not just a company that was blindly reacting.

I think it's safe to say that while your comments here made you feel better, they didn't help your position at all, regardless of how valid your points are.


This is a pretty cynical point of view.

Why can't we all work something out here?


It's not cynical, it's PR 101. You shouldn't respond publicly to something until you've calmed down. (It's actually good advice overall). No good can come from posting in the heat of the moment. Hell, you had the founder of Docker calling some of the people in this thread "trolls". That's not a win for anyone.

The problem for the Docker folks was that they were making things into a much bigger deal than they otherwise were. By attacking the CoreOS announcement, both here in comments and in their blog, they only amplified the issue. Consider it a corollary of the Streisand effect.

You even alluded to this earlier in the day when you told them to: Don't do PR, just build the better thing.

There isn't anything here to "work out", and if there is something, it needed to not happen in public. People from Docker just needed to stop talking for a while and take a time out. They weren't helping their situation and didn't seem to get that.


If these projects are using 'open design processes', then the conversations do need to happen in the public.

What I felt as cynical about your post were things like:

>and made it seem like you were the leader of the market

I feel this is cynical because it's advocating not for facts and technical solutions, but arguably, willful misleading of the public. Docker should be open and honest about its software and its positions, not trying to create narratives where it 'seems' like you are something that you might not be.

>you just made the PR that much stronger for the CoreOS POV

The reason I advocated for not 'doing PR' is that, in my book, PR is an exercise in charade. Tell us what you feel, what you're working on, and why these things are good. Don't try to 'manage' appearances. If you have a problem with something, let it be known.

I think there are some things that might be able to be worked out. Docker and CoreOS/Rocket may be able to co-exist. Rocket doesn't seem to have the tools to easily produce the ACI's. Dockerfiles are widely used and pretty decent. Docker could focus on tooling while CoreOS handles execution. Both companies have contributed useful technology and it's not exactly clear that one company can/should own the entire solution.


Docker wants to be the leader in the market for containerized deployments, right? This is largely a competition for mind-share and users. How you act in a matters. Messaging matters. If Docker wants to be perceived as the leader in containers, then they should act like it.

PR isn't just standing in front of a microphone and saying what you're working on or how awesome you are. It's how you act in public, how you treat customers and competitors. You want to be authentic, but you don't have to share everything about how you feel to the public. Similarly, overly managed responses can be just as bad. There are good and bad ways to make an argument. Sometimes, it doesn't matter if you're right or not, if the way you make your argument turns people off, you are going to lose.

I think that the whole Docker/Rocket thing was vastly blown out of proportion, and wasn't the big deal that they made it out to be. Let's see who can make the best solution. But it is a mistake to think that this was a technical issue - it wasn't. The way that the situation was handled clouded what could have been a technical discussion of the merits or need for Rocket. At the same time, don't think that the best technical solution always wins.


Your comments on this post have done more to damage my faith in Docker's philosophy than the Rocket announcement did.

Somebody highlighted concerns they have with the direction of your product. You may not agree with their opinions, but that doesn't make them FUD. They have every right to ship a product that adheres to their vision, just as you do.


Hey Solomon; honest question - skipping the tête-à-tête for a moment, the first tenant you outline:

> 1) interface to the app and developer should be standardized, and enforced ruthlessly to prevent fragmentation

Is one I've been pondering and asking myself about a bit - what does this mean?

Is the interface the API? The docker CLI? Interfaces to libcontainer?

Where does the line "enforced ruthlessly" fall exactly?

Does this mean wrapping the CLI or API in another convenience layer is a no-no if it doesn't expose the docker API directly?

I think the rest of the 13 make perfect sense, and I actually don't think the CoreOS guys we're going against any of those in practice or philosophy; more they wanted something small that did one thing very well.

Anyway, I love you guys and the coreos guys, so I'm only in it for the swag.


What's with all the drama? Did we read the same announcement?

What is it that we end users don't know?


Docker and CoreOS are in a pre-monetization land grab for a single market.

They've so far been approaching it from opposing corners, but CoreOS just made the first play at the opponent's territory, and it apparently rattled Docker a bit.

I am excited to have more viewpoints in play.


Yes and Pivotal (CloudFoundry) has posted a fairly supportive blog entry on Rocket. So it's not just CoreOS "making a play".

https://news.ycombinator.com/item?id=8683540


Cloud Foundry also quietly forked Docker with Warden/Diego (edit: I meant Garden, thanks kapilvt), although in that case they remained compatible with Docker images.


clearing up some facts.. warden predates docker, its a container impl. diego is something entirely different more like kubernetes or mesosphere (scheduling & health, etc). garden the go implementation of warden containers does add fs compatibility for docker.


Your edit is incomplete. Warden predates Docker and is an independent container system. Diego is a new controller/staging/allocating/health system for part of Cloud Foundry, which is a complete PaaS, of which Warden is a low-level component.


Yeah, I'm not saying it's just a cheap shot; Rocket does a good job of addressing some real issues with Docker.

I'm optimistic that the ecosystem as a whole will benefit a lot from this, no matter how much or how little market share Rocket manages to capture.


My +1 goes to Kelsey Hightower. He posted on 7 Nov some worries which many Docker users and contributors, already had since the past year, when you dropped off LXC containers, instead of working together with https://linuxcontainers.org/ project to get a better code. That seems already a strategic business decision to decouple your "product value" from his mother and generator: LXC. IMO, Docker's 'new' direction completely ignored the tremendous amount of support they had from the sysadmin and devops communities.


> IMO, Docker's 'new' direction completely ignored the tremendous amount of support they had from the sysadmin and devops communities.

Kind of weird that this line from your comment is identical to a line in this comment from another user: https://news.ycombinator.com/item?id=8682864

lgs 907 days ago [dupe]

Infact I just copy & past that ..., not the least, I didn't found better words to express that feeling, which I hope it will be wrong honestly because I'm on board with Docker since the early days and I'd like to see it more community driven that private business driven.


Hacker plagiarism.


@jsprogrammer yes,

cutting & pasting (hacking :) is faster, if you're not mother tongue but believe me, in Italian it won't sound so gentle & polite.

Moreover, ... we all hope that like a "plagiarism" it won't became a a common feeling, a meme.

So what about the other 75% of my worry? That's not a cut & past, is my worry, what do you think about:

> ... Kelsey Hightower ... posted on 7 Nov some worries which many Docker users and contributors, already had since the past year, when you dropped off LXC containers, instead of working together with https://linuxcontainers.org/ project to get a better code. That seems already a strategic business decision to decouple your "product value" from his mother and generator: LXC.


I only meant it as a statement of fact. When all we really get from each other is pieces of text, it is viewed as 'suspicious' when someone copies something verbatim without acknowledging that they have done so. Of course, the context plays a big part of whether it's viewed like that. In a forum like this, where we are supposedly typing our own 'comments' to the conversation, it's a little strange to see a sentence like that copied in two places with two different user names. It made me consider if the comment was made by a bot.

Is LXC upset about Docker? I'm not sure how much room is for strategic business decisions like that. The solution is going to be a technical one and it's probably going to go to the first one to get it 'right'. There might not be space for many companies to compete on small parts of the solution (like, how to package a container).


Thanks for clarifying @jsprogrammer. What I'd really like, would be an Open Source model able to be COOPERATIVE over COMPETITIVE, as it was at the beginning of the movement.

We all are here because of that disruptive vision and willing to cooperate beyond personal & corps interests, not to compete between startups to get funds and be quoted to the NASDAQ. No Linux or Docker or even Google, would be here without that enlightened vision.

That's way I don't agree with @shykes statement one too: "1)Competition is always good ...". No Sir, not always, it depends by what you are competing for and if you follow the competition rules too.

I'm really astonished seeing big CORPs like Microsoft, VMware and others, put their eyes on a relatively small but potentially disruptive projects like Docker, the pressure could be misleading, also for an Hacker like @shykes.

We already saw that traps so many times ..., anyway I think everything it's gonna be good at the end of the day and I saw @shykes on the right pathway already: https://news.ycombinator.com/item?id=8684119

I like Docker as a project, as well as a company. So many times I thought: "that's a company I'd really like to work for".

I'm sure that @shykes (Solomon Hykes), has the strength to find the balance between external Corps pressures and Project wellness to led this Open Source community the right path like he did until now.


That is difficult to achieve when you're embedded in a culture that often puts money above everything. Everyone (as in, those competing [often corporations]) are focused on the dollars and market share over the technical merits of the solutions.

There is a strong desire to own and control solutions. The facts are that image registries and container execution are lightweight abstractions over already existing protocols [DNS, HTTP] and technologies [Linux Containers]. There's not much to own in the space other than through having the 'best' technical solution.


Ops (particularly in Enterprise) doesn't want batteries included by default. Principle #3 and #5 are incompatible IMO. Do one thing and do it well...

Seems to me that post-Docker 1.2, the Docker team has taken Ops concerns much less seriously and is focused almost exclusively on iterating Dev-friendly features.

Hope things change.


This is all too common in my opinion.

It feels to me like a lot of startups, and even smaller tech companies focus completely on developers. I seriously think some people think "DevOps" literally means Developers doing what Operations/Infrastructure people/teams do (or should do).


It literally does mean that a lot of the time. It also means sysadmins bashing our horrible code and of course, the two working together which was the original concept.

Any term coined to remove barriers will always be co-opted by middle management to mean something else so they can put them back up. Otherwise, they'd be out of jobs and they can't have that now, can they?

;)


Sounds nice to work somewhere that developers actually recognise (even if its only because they're forced to by access rights, structure or what have you) that Ops actually have a clue what they're talking about,


I see a lot of words in your post, but for the life of me, I can't figure out what part of the linked story you feel is "mud slinging", nor what "langauge" or "behaviour" you're so disappointed about? AFAIK docker has had a crappy security story from the start, by design. Perhaps Docker is now, or proceeding to, leverage more of LXC/namespaces for "proper" security -- but the argument against a monolithic daemon makes perfect sense.

Security and convenience are always at odds: I don't see it as a problem that tools lean one way or the other: It does make me a bit worried if they lean one way or the other by accident -- which is what you seem to imply with your comment. I take it you're trying to "defend" docker -- but I don't know against what, nor do I understand your arguments.

Perhaps you could take a deep breath, and try again? I'm sure you really do have something to say on the matter, that is worth reading.


I like how 'exactly 3 things' turned into two lists, one with 13 items :)


Don't be unfair, clearly the 2nd list is nested :)


IMHO Docker should go Git way. I mean that the "core" binary provide minimum commands needed to work and any other command should be external executable that is discovered by running `docker-command-name`.


We compiled our (Codenvy's) thoughts on the Rocket vs. Docker perspectives and posted it on a blog post today. http://blog.codenvy.com/rocket-rocket-docker/

Our net conclusion is that this is good for the industry as competition induces everyone to work a little bit harder. We anticipate that the end game is that advancements and concepts suggested by Rocket are likely not to make it stand alone, or with very broad adoption, but that there will be enough interest & momentum that we eventually see some sort of alignment between Docker and Rocket. It's what would be in the best interests of all involved, in the end. Seems like the projects could eventually merge.

While some of the tone of the initial announcement had political overtures, which were further amplified by Pivotal (James Watters certainly didn't mind fanning flames), what this could indicate is that there were deep ideological divisions in thought within the Docker community. And instead of the parties finding common ground, the CoreOS team needed to create a new project with PR to gain attention to their ideas. That shows commitment and to a degree, high certainty, in their beliefs. Sometimes it requires one person taking on massive risks to fully convey the power of their position.

But there have been examples in the past of splinters that eventually get mended back into the fold. This wasn't a full fork, this was an entirely new approach. The foundations of what they are proposing are nice gap fills for Docker. So there are many more ways for alignment here than for division.


Two thoughts:

1. Competition? How can open source software be in competition with anything? It's free, its source code is there; if people want it they'll use it, if not they won't. Why would anyone care what other projects are doing or saying? Just build your tools how you want and go on with life. (Unless you're building your tools specifically to make money, in which case I guess PR and 'competition' does matter a lot)

2. On Twitter you suggested things should be 'composable to the extreme' ..... using plugins and drivers. https://www.youtube.com/watch?v=G2y8Sx4B2Sk


> How can open source software be in competition with anything?

Market share is power. Popular open-source projects can, and do, shape the industry. If you believe your trajectory is the right one for the industry, competition matters a lot.

As an example, Mozilla's Firefox was created to compete with Internet Explorer. It succeeded, and now Mozilla is working to defend the open web, so market share is still crucial for Mozilla even today.


I'm sorry but you're incorrect. Mozilla's Firefox was originally called Phoenix, and it was created because Mozilla the browser was a dog-slow encumbered monstrosity of Netscape's attempt to create an all-in-one solution for the web. Firefox was essentially competing with Mozilla Suite, but it wasn't so much "competing" as filling a necessary role: a browser that didn't suck.

Mozilla Suite was also not created to compete with Internet Explorer. In fact, Internet Explorer was created to compete with Netscape, which was the dominant browser for years until IE finally knocked it off its catbird seat. It never recovered because IE offered a simple, fast browsing experience, even if it sucked dick at actually rendering content.

In this vein, Phoenix was created in the model of Internet Explorer. So in a way you could say it competed, but in actual fact it was competing against its own progenitor.

Reflecting more on 'competition': the browser wars nearly destroyed the web as we know it as each browser introduced incompatible proprietary extensions which were then picked up (badly) by each other over time. The lack of standards, or good implementations of standards, severely hampered the adoption of more advanced technology. Firefox continues that tradition today by pushing more and more features that IE can't support; we're just lucky that Firefox is the dominant browser now, and that people are now used to upgrading their browser virtually every week.


It always makes me chuckle that Firefox adds more and more features and becomes more and more like the suite they replaced; I still miss the Composer for web pages!

I remember using it when it was called Firebird.


Huh. I was basing my comment on the knowledge that Mozilla feared IE would become the way to browse the web. I should have double checked.


Firefox founder here. You are correct and the reply comment is incorrect. Firefox was created to take on IE. Period.


I stand corrected, then. I definitely agree that by 2004 there was a huge effort to get as many people to the browser as possible, even comparing it as a better browser than IE. Still, it's interesting that IE was only ever mentioned two years after the initial release, and everyone who talked about the goals of the project were talking about the bloat of Mozilla and having a better user experience. I imagine it would have ended up much worse if the focus was competition alone.


You seem to narrow down (i.e. restrict) pretty heavily what competition can mean. Open source projects can compete even if no money is involved, e.g. on visibility and amount of help and traction they can get from the community. This is partly related to the concept of fragmentation (where some people argue that fragmentation dilutes efforts).


I don't read any mud-slinging in this post at all. What I read from it is someone (or a group of people) disappointed by Docker's current path and wanting to offer an alternative.

Docker's received a lot of funding, and so it has an interest in building a whole platform. I won't say whether that is "right" or "wrong," but it may pollute the original, simple container strategy. The goal of this seems to be to offer a pure alternative. No mud-slinging there - just a different goal than what Docker has become today.


Hey, shykes. Thanks for creating Docker (and your enthusiasm). I think HN is being extremely critical of you, but they have some valid points. Keep a thick skin -- it's tough not to look defensive even if you are right.

(i don't know enough about rocker to make a judgement either way).


And then?


Can't let the ecosystem fracture. Docker creates a set of standards that are badly needed. This creates value for everyone




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: