被迫妥协：共同研发的 RunC 意味着什么？
Docker 一开始就一家独大，并且并不是一种开放的态姿态在做，所以很早之前 Google 就投资了 CoreOS 来做竞争的容器——Rocket.那时是三家鼎立：Docker/Rocket/Warden，为了避免惨烈的竞争，大家终于统一意见，决定成立 OCI 做统一的容器运行时——RunC，OCI 成立后加入了大约50家厂商。出于对 Docker 封闭化商业式发展的担心，OCI 商讨出这种方案：以 RunC 为核心重新构建生态圈，并且通过插件来弱化容器在 CaaS 生态圈的重要性。
OCI 负责的 RunC 是非常小的运行核，其目的在于提供一个干净简单的运行环境，他就是负责隔离 CPU、内存、网络等形成一个运行环境，可以看作一个小的操作系统：现在 OCI 只负责这些，尚未扩大到更大的范围，其实这样是小而美的，这样的是业界所最需要的。
当然， RunC 的生态发展就会局限在企业级别应用中，并因此具有不同的发展目标：RunC 不是要提供多少种工具，而是要非常稳定。 接下来需要做的是可能是添加完善一些功能，比如将 Docker 镜像导进来，与各种插件更好地结合（动态化即插即用），热启动和迁移。这些功能是企业需要的，但是对开发者没什么作用。以热迁移为例，从一台虚拟机迁移到另外一台虚拟机，但是开发者可能本来就一台机器并没有这个需要。
因为 RunC 是 Docker 的一个子集，所以单纯从代码量上来讲，RunC 只占 Docker 的百分之几。相比而言，Docker 有丰富工具，更贴近于开发者。这也是为什么很多个人开发者并不知道 RunC，因为RunC的使用者都是 Mesos、K8S 和 Cloud Foundry 这类 CaaS 厂商。
在 RunC 早期，Docker 是主要贡献者（在我看来，如果 Docker 不参与 RunC 的发展就意味着和容器生态圈决裂）；后来随着各大厂商对 RunC 大幅贡献代码，RunC 的代码贡献者越来越多样化，Docker 所占比例在持续下降。通过不断迭代，RunC 一定会越来越成熟，它已经在生产环境中开始积累技术了，Cloud Foundry 已经有不少全球重量级客户在用内置 RunC 容器，经历的很多坑的 bug 修补已经回馈到 RunC 源码中去了。
Docker 的运行内核虽然是从 1.11 支持 RunC 的，但是 Docker 的心态是很复杂的：一方面作为 OCI 成员必须支持 RunC，但是另一方面他会担心 RunC 对 Docker 的替代的威胁。
危机解读： 适合Docker公司的路在何方？
坦率而言，我认为 Docker 进军编排界并没有优势，因为他缺乏企业级基因。
Docker 更适合在容器本身的技术，今年 Docker 力推 Swarm，把资源花在了集群管理上，这其实并不是 Docker 技术的初心。当时 Docker 迅速流行是因为简单易用，而后来走却想把太多东西塞到 Docker 中。
在从目前适用场景选择来看，一般而言，使用 Docker Swarm 的都是小企业的小规模应用，而大企业采用的都是 Mesos、K8S 或 Cloud Foundry.（当然有极少的案例采用了 Docker 的 Swarm，但是从比例而言这并不具普遍性）。因为最初的设计来源就不一样，前者是从开发者角度设计，而 Mesos、K8S 和 Cloud Foundry 是从企业中来，有很多企业运维的实战积累。
Docker 也就是小几百人的公司，并不算巨头公司，做企业级市场比较吃力，而做中小企业或是个人用户市场这种思路更适合 Docker 的盈利模式。在我看来，不论国内国外，做企业级市场一定需要很多销售去和企业用户打交道聊需求，项目实施的时候往往要根据客户的需求做定制，要知道每个企业用户的需求是不一样的，没有办法进行完全统一的标准化，那定制化的需求就需要一定规模的人力投入，每个项目都需要一定的人员资源投入，小公司很难做这种投入。在我看来，小作坊做企业用户还是面临很大的挑战。
从企业级需求来看，比如企业一个考虑就是，一定要前后版本兼容，否则就无法升级。而这恰恰是 Docker 不 care，比如个人用户可以随时重启机器，开发者在遇到问题可以重启，在企业级的思路不是这样的。Docker 的思路并不是做企业级 IT 应用系统的思路，所以如果应用到企业级应用中一定会遇到问题。至于很多互联网公司在应用 Docker，很多互联网公司也是在摸索，包括自己做 Docker 集群管理的不少，但自己做 Docker 集群管理的基本都开始开始转向 K8s、Cloud Foundry、Mesos 这些专业的容器集群管理软件了，这是很明显的趋势，那么这些互联网企业当初花资源做的集群管理基本就是被废弃，即使现在没转的迟早要转型到 CF（Cloud Foundry） / K8s / Mesos.对于企业客户来说，这种试错是得不偿失的，因为企业客户没有这么多人去研究开发容器集群管理软件。但对互联网公司来说，这个试错是可以接受的，毕竟养这么多工程师其中有一部分就是通过不断的、或大或小的试错而优化技术的。