## 7 Assessment of Maturity and Stability
As such, the Kubernetes project has been the most creative in terms of pioneering new features despite being a younger project than Mesos, Marathon and Aurora. _RQ9. What are the relevant standardization initiatives and which CO frameworks align with these initiatives?_  
Figure 11: Timeline of when support for a sub-aspect have been consolidated by a CO framework. The stability of a CO framework software depends among other factors on its alignment with standardization initiatives. Increased openness to such standardization initiatives also creates more potential for researchers and entrepreneurs to contribute innovating technology that can be integrated in multiple CO frameworks. In Section 4, we have identified several standardization initiatives towards common specifications to improve the plug-ability of various components including container runtimes, container networking services and storage drivers for external persistent volumes. Table 7 gives an overview of these standardization initiatives and which CO frameworks have aligned with these initiatives. The OCI specification for pluggable container runtimes has been accepted by Docker EE and Kubernetes, while Mesos has announced to add support for OCI soon. Different standards for container networking (CNI, libnetwork) and persistent storage (CSI, Docker volumes) are not compatible across respectively Kubernetes and Docker Swarm. In opposition, DC/OS, provides encompassing support for all initiatives: DC/OS supports both CNI-based network plugins and Docker's libnetwork architecture. Moreover, it supports both Docker volumes as well as the CSI specification for persistent volumes. As such, with respect to networking and storage plugins, DC/OS and other Mesos-based frameworks are the most open frameworks. With respect to container runtimes, Kubernetes and Docker Swarm are the most open frameworks. In general, we can state that DC/OS is the most interesting platform for prototyping novel techniques for container networking and persistent volumes because DC/OS' adherence to all relevant specifications in these two areas maximizes the potential to deploy these techniques in Docker Swarm and Kubernetes as well. Docker or Kubernetes are best fit for prototyping innovating container runtimes. However, a widespread adoption of Kubernetes by cloud providers and cloud orchestration platforms has also occurred after the Cloud Native Computing Foundation has pushed Kubernetes as the de-facto standard in container orchestration and launched a certification programme for production-grade commercial Kubernetes offerings [23]. As a result, Docker volumes and Docker's libnetwork architecture, which are not supported by Kubernetes, may face the risk of not being further developed or halted. We estimate this risk to be low however because Docker offers its volume and networking architecture as separate building blocks that are relatively loosely coupled from its orchestrator layer. Therefore, we believe that Docker's volume and networking architectures will remain important alternatives to the existing standardization initiatives. _RQ10. What is the risk that common or unique features might become deprecated in the future?_  
If a particular CO framework halts the development of a particular feature or even deprecates the feature without offering a replacing feature update, then the risk arises that the development of company products or research prototypes that heavily rely on those features might also get compromised. In this section, we will assess that risk but for the future.