伴随着Docker公司的容器技术生态在云计算市场中站稳了脚跟，围绕着Docker项目进行的各个层次的集成与创新产品，也如雨后春笋般出现在这个新兴市场当中。
而Docker公司，不失时机地发布了Docker Compose、Swarm和Machine“三件套”，在重定义PaaS走出了最关键的一步。
这段时间大量围绕着Docker项目的网络、存储、监控、CI/CD，甚至UI项目纷纷出台，涌现出如Rancher、Tutum这样在开源与商业上均取得了巨大成功的创业公司。
2014~2015年间，容器社区真是热闹非凡。
繁荣背后,更多担忧,即对Docker公司商业化战略的种种顾虑。
Docker项目此时已经成为Docker公司一个商业产品。而开源，只是Docker公司吸引开发者群体的一个重要手段。
不过这么多年来，开源社区的商业化其实都是类似的思路，无非是高不高调、心不心急的问题罢了。
真正令大多数人不满意的是Docker公司在Docker开源项目的发展上，始终保持绝对权威,并在多场合挑战其他玩家（CoreOS、RedHat，谷歌微软）的切身利益。
其实在Docker项目刚刚兴起时
Google也开源了一个在内部使用多年、经历过生产环境验证的Linux容器
1 lmctfy（Let Me Container That For You）
然而，面对Docker项目的强势崛起，这个对用户没那么友好的Google容器项目根本没有招架之力。所以，知难而退的Google公司，向Docker公司表示了合作的愿望：关停这个项目，和Docker公司共同推进一个中立的容器运行时（container runtime）库作为Docker项目的核心依赖。
不过，Docker公司并没有认同这个明显会削弱自己地位的提议，还在不久后，自己发布了一个容器运行时库
2 Libcontainer
这次匆忙的、由一家主导的、并带有战略性考量的重构，成了Libcontainer被社区长期诟病代码可读性差、可维护性不强的一个重要原因。
至此，Docker公司在容器运行时层面上的强硬态度，以及Docker项目在高速迭代中表现出来的不稳定和频繁变更的问题，开始让社区叫苦不迭。
这种情绪在2015年达到了一个小高潮，容器领域的其他几位玩家开始商议“切割”Docker项目的话语权 — 成立一个中立的基金会。
2015年6月22日，由Docker公司牵头，CoreOS、Google、RedHat等公司共同宣布，Docker公司将Libcontainer捐出，并改名为
3 runc
交由一个完全中立的基金会管理，然后以runc为依据，大家共同制定一套容器和镜像的标准和规范。
这套标准和规范，就是
4 OCI（ Open Container Initiative ）
OCI的提出，意在将容器运行时和镜像的实现从Docker项目中完全剥离出来
- 一方面可以改善Docker公司在容器技术上一家独大的现状
- 另一方面也为其他玩家不依赖于Docker项目构建各自的平台层能力提供了可能
OCI更多是高端玩家出于自身利益一个妥协结果
尽管Docker是OCI的发起者和创始成员，却很少在OCI的技术推进和标准制定等事务上扮演关键角色，也没动力推进这些所谓标准。
这也是OCI组织效率持续低下的根本原因。
眼看着OCI无力改变Docker公司容器领域一家独大现状，Google和RedHat等第二把武器摆上了台面。
Docker之所以不担心OCI威胁，就在于它的Docker项目是容器生态的事实标准，而它所维护的Docker社区也足够庞大。
可是，一旦这场斗争被转移到容器之上的平台层，或者说PaaS层，Docker公司的竞争优势捉襟见肘
在这个领域里，像Google和RedHat这样的成熟公司，都拥有着深厚的技术积累
而像CoreOS这样的创业公司，也拥有像Etcd这样被广泛使用的开源基础设施项目。
可是Docker公司呢？它却只有一个Swarm。
所以这次，Google、RedHat等开源基础设施领域玩家们，发起名为
