## 7 Assessment of Maturity and Stability  
This section answers research questions RQ7-RQ10:  
_RQ7. What is the maturity of a CO framework with respect to a common feature or a functional (sub)-aspect?_  
For each of the 9 functional aspects, we have created a table that maps each common feature to a timeline that orders CO frameworks according to the time they have released the alpha version of the common feature. The timelines also show when feature update and feature removal or deprecation events have occurred in order to assess the stability property. Because these timelines contain a lot of details we present in this article only a high-level summary as part of addressing RQ8, but the detailed timelines and their analysis are available in the associated technical report [31], Section 5. _RQ8. Which functional sub-aspects are mature enough to consider them as part of the stable foundation of the overall domain? Which CO frameworks have pioneered a particular sub-aspect?_  
Figure 11 shows an overall timeline that ranks sub-aspects with respect to their maturity. For each sub-aspect, the figure shows which CO framework has pioneered in consolidating the sub-aspect. We define a sub-aspect as being consolidated when a coherent subset of the common features of that sub-aspect has been established by the pioneering framework. With respect to identifying those sub-aspects that are considered mature and well-understood, we are guided by the criteria that (i) the sub-aspect has been consolidated by the pioneering framework at least two traditional release cycles of 18 months [57] ago (these two release cycles are needed for letting other CO framework adopt and develop similar features. ), (ii) the corresponding feature implementation strategies of the pioneering framework have at least reached beta-stage in the meantime and (iii) there are no deprecation or removal events of important features in the latest traditional release cycle. This leads us to the observation that 15 out of 27 sub-aspects can be considered mature and well-understood (see green rectangle in Figure 11). Figure 10: Radar chart of Docker Swarm integrated mode, Kubernetes and DC/OS for common + unique features. Some sub-aspects that have been consolidated at least 36 months ago are not yet considered mature because they fail to meet one of the other two criteria:  
* The sub-aspect \"monitoring resource usage and health\" is still in flux as Kubernetes' monitoring service (Heapster) has recently been completely replaced by two new monitoring services. * Host port conflict management is expected to evolve due to the growing importance of supporting service networking in true host mode. * Improved security isolation support by Kubernetes has not been substantially adopted by other orchestration frameworks; instead, security isolation is becoming a customizable property of container runtimes themselves. * Logging support has remained very basic in all frameworks. Instead, many third-party companies have already offered commercial solutions for centralized log management. * The network plugin architecture of Kubernetes has remained in alpha-stage for a very long time and is therefore expected to evolve. Docker's network plugin architecture is also expected to evolve because Docker EE supports Kubernetes as an alternative orchestrator. * Inspection of cluster applications is expected to evolve towards a fully reflective interface so that it becomes possible to support application-specific instrumentation of different types of container orchestration functionality (see Section 8.3). * Cluster maintenance, especially cluster upgrades, remains poorly automated. Figure 11 also presents the creativity of CO frameworks by showing on the left of the timelines which CO frameworks have pioneered in consolidating a sub-aspect. Kubernetes has pioneered in 12 of the 27 sub-aspects. Mesos + Marathon in 10 of these sub-aspects, Docker Swarm in 4 sub-aspects, and Aurora in 1 sub-aspect.