4 ms·

If it's an open/pluggable system why the need for these 'partnerships'? Any OSS project can just quickly hack in support for Docker, just as they've been doing

by 23david 12y ago

If it's an open/pluggable system why the need for these 'partnerships'? Any OSS project can just quickly hack in support for Docker, just as they've been doing for almost 2 years now. This is getting ridiculous.

tracker1 12y ago
Easy answer to the partnerships... Money to pay their employees... and influence from the partners on the future development of the project.
- nickstinemates 12y ago
  (disclaimer: I run technology / alliance partnerships for Docker) 1) Money is definitely not the case - docker is well capitalized. A special benefit of being in that situation is you don't have to do unnatural things like partner for money. 2) We welcome contributions from everyone, partners or not. Influence is gained by real contribution. The reason we build partnerships is to ensure a few main things #1 (and the biggest) Docker is made available on a wide variety of platforms, allowing developers and admins to work in native environments instead of fork-lifting to another just to try it out. #2 Enable a network of services, products, systems integrator, IT vendors, etc. to have support, training, and other necessary things as they offer docker features in their products. This allows those who do not make containers and container services the core of their business, and instead focus on making/solving different problems. I am more than happy to walk you or anyone else through partner strategy at any time. I'm easy to find.
  - 23david 12y ago
    would be great if the other Docker employees were as clear as you are about that. Are you willing to share the contract details involved in these partner agreements? What do partners have to agree to in order to be an official partner?
    - nickstinemates 12y ago
      > Are you willing to share the contract details involved in these partner agreements? Of course I can't do that, but I can talk about the different contract types thematically in an appropriate forum, absolutely. > What do partners have to agree to in order to be an official partner? 1) Not to fork the Docker project (in the negative context, i.e use Docker but call it something else) 2) To use the Docker API (and not a derivative implementation) As a general, official technology partner, that's pretty much it. And, most of the time, we're more than happy to promote (especially smaller partners) to that status in good faith without any paper work. > What about prioritization, you may ask? The list I provided above in terms of recruitment/opportunity criteria? That's prioritized. My team has to prioritize the tremendous interest from some of the largest as well as some of the smallest companies in the world A guiding principle is that special attention paid to those who make a commitment (and have shown ) to contribute their learning upstream - either via code contribution, proposal, activity on IRC, etc. I/we spend a tremendous amount of time on all of the feedback channels (like this one) to know who is active and from there form a relationship. If you follow my activity on any of these forums, you'll probably see a lot of "hey what you're doing is awesome. lets chat more" That's usually how it starts. I hope that helps, and my inbox/calendar/time is always open for a conversation. If this is interesting to you or others, I'm a pretty open book. Don't hesitate.
ABS 12y ago
we need to separate Docker the open source container runtime from Docker Inc: - the former is managed by the Docker Governance Advisory Board with people from many companies and individuals, see minute of the first meeting here for example: https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0DRKyZKxYQ1aursxNorg/edit https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0... - the latter is a company that naturally needs to be profitable. In fact I'm surprised so many people find Docker Inc. developing a "platform" around Docker a change of direction, let alone unexpected. It's nothing new and in fact I feel like Docker Inc choice is the "right" one: historically Commercial Open Source companies have had only a handful of choices to monetise: 1) selling support and services around the open source product, 2) going Open Core, 3) developing orthogonal, complementary commercial products around the main open source one and 4) be acquired :-D RedHat is really the only one that managed to make option 1 work at scale and it looks like a black swan the longer time goes by. Option 2 was a bad idea to begin with a few years ago and I'm still surprised there are companies going for it today (I experienced it on my own skin). Option 4 is what it is. So Option 3 is really the only reasonable way to go: keep the open source product really open source and make money with complementary products. I kind of expected this to be the way to go for Docker Inc all along, with a little niggle at the back of my mind fearing they would go for Open Core instead.
- jbeda 12y ago
  The advisory board is just that -- advisory. It has absolutely no teeth. The open source project is 100% owned by Docker, Inc. Solomon believes strongly in a "firewall" between OSS Docker and Docker, Inc -- but it breaks down in various places where it comes to any online service. Examples: * The docker hub gets special privileges in the image namespace. It isn't built on DNS but instead rooted in a namespace owned by Docker, Inc. * The newly announced swarm depends on a discovery endpoint that (as far as I've seen) is closed source and undocumented. I'd love to see the online parts of the OSS docker project have the same "firewall" as Solomon believe he holds for the OSS components.
  - jbeda 12y ago
    Update: the discovery endpoint is pretty simple and now documented: https://github.com/docker/swarm/blob/master/discovery/README.md https://github.com/docker/swarm/blob/master/discovery/README...

by 23david 12y ago

tracker1 12y ago

Easy answer to the partnerships... Money to pay their employees... and influence from the partners on the future development of the project.

nickstinemates 12y ago
(disclaimer: I run technology / alliance partnerships for Docker) 1) Money is definitely not the case - docker is well capitalized. A special benefit of being in that situation is you don't have to do unnatural things like partner for money. 2) We welcome contributions from everyone, partners or not. Influence is gained by real contribution. The reason we build partnerships is to ensure a few main things #1 (and the biggest) Docker is made available on a wide variety of platforms, allowing developers and admins to work in native environments instead of fork-lifting to another just to try it out. #2 Enable a network of services, products, systems integrator, IT vendors, etc. to have support, training, and other necessary things as they offer docker features in their products. This allows those who do not make containers and container services the core of their business, and instead focus on making/solving different problems. I am more than happy to walk you or anyone else through partner strategy at any time. I'm easy to find.
- 23david 12y ago
  would be great if the other Docker employees were as clear as you are about that. Are you willing to share the contract details involved in these partner agreements? What do partners have to agree to in order to be an official partner?
  - nickstinemates 12y ago
    > Are you willing to share the contract details involved in these partner agreements? Of course I can't do that, but I can talk about the different contract types thematically in an appropriate forum, absolutely. > What do partners have to agree to in order to be an official partner? 1) Not to fork the Docker project (in the negative context, i.e use Docker but call it something else) 2) To use the Docker API (and not a derivative implementation) As a general, official technology partner, that's pretty much it. And, most of the time, we're more than happy to promote (especially smaller partners) to that status in good faith without any paper work. > What about prioritization, you may ask? The list I provided above in terms of recruitment/opportunity criteria? That's prioritized. My team has to prioritize the tremendous interest from some of the largest as well as some of the smallest companies in the world A guiding principle is that special attention paid to those who make a commitment (and have shown ) to contribute their learning upstream - either via code contribution, proposal, activity on IRC, etc. I/we spend a tremendous amount of time on all of the feedback channels (like this one) to know who is active and from there form a relationship. If you follow my activity on any of these forums, you'll probably see a lot of "hey what you're doing is awesome. lets chat more" That's usually how it starts. I hope that helps, and my inbox/calendar/time is always open for a conversation. If this is interesting to you or others, I'm a pretty open book. Don't hesitate.

ABS 12y ago

we need to separate Docker the open source container runtime from Docker Inc: - the former is managed by the Docker Governance Advisory Board with people from many companies and individuals, see minute of the first meeting here for example: https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0DRKyZKxYQ1aursxNorg/edit https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0... - the latter is a company that naturally needs to be profitable. In fact I'm surprised so many people find Docker Inc. developing a "platform" around Docker a change of direction, let alone unexpected. It's nothing new and in fact I feel like Docker Inc choice is the "right" one: historically Commercial Open Source companies have had only a handful of choices to monetise: 1) selling support and services around the open source product, 2) going Open Core, 3) developing orthogonal, complementary commercial products around the main open source one and 4) be acquired :-D RedHat is really the only one that managed to make option 1 work at scale and it looks like a black swan the longer time goes by. Option 2 was a bad idea to begin with a few years ago and I'm still surprised there are companies going for it today (I experienced it on my own skin). Option 4 is what it is. So Option 3 is really the only reasonable way to go: keep the open source product really open source and make money with complementary products. I kind of expected this to be the way to go for Docker Inc all along, with a little niggle at the back of my mind fearing they would go for Open Core instead.

jbeda 12y ago
The advisory board is just that -- advisory. It has absolutely no teeth. The open source project is 100% owned by Docker, Inc. Solomon believes strongly in a "firewall" between OSS Docker and Docker, Inc -- but it breaks down in various places where it comes to any online service. Examples: * The docker hub gets special privileges in the image namespace. It isn't built on DNS but instead rooted in a namespace owned by Docker, Inc. * The newly announced swarm depends on a discovery endpoint that (as far as I've seen) is closed source and undocumented. I'd love to see the online parts of the OSS docker project have the same "firewall" as Solomon believe he holds for the OSS components.
- jbeda 12y ago
  Update: the discovery endpoint is pretty simple and now documented: https://github.com/docker/swarm/blob/master/discovery/README.md https://github.com/docker/swarm/blob/master/discovery/README...