Per Aaron’s Comments:

…
... <https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/BEBH4XXRVEP54F5VR5TGXXVUEA5YEPPK/#>
*Long Answer: *I agree that BOSH can be better, as can all software ;-). However, the certification process for offerings isn't about experimentation in the ecosystem. It's about consistency across the distributions. Requiring BOSH as the deployment method gives us two key things: (1) much more consistency for operators of the platform and (2) a consistent target (really a least common denominator) for ISV's packaging software for backing services. The value of consistency year over year doesn't diminish the value of experimentation outside of the certified distributions.
The consistent target from an Engineering perspective should always be the contract or interface, but should never degrade to the point of being a particular implementation. This has been damaging in many open source projects. Where competition has always fostered excellence in these projects. Look at gcc and clang, or vim and neovim where the original projects were in states of decay, but a competitor emerging kicked them back into gear. Settling on BOSH as a lowest common denominator will make BOSH stagnate. With only one deployment mechanism and no clean interface to separate Cloud Foundry components and releases from BOSH implementation details, it's possible that the lines become so blurred that BOSH becomes impossible to remove. Even if at some point it becomes desirable because the community has reason to move away from BOSH (ie. rewrite time, or perhaps a better mechanism has been discovered or even leveraging a new open source project to do the same) it will be harder to do so, and hamper the evolution of the project. I'd propose keeping BOSH out of the CF certification, and instead start work on describing the BOSH <-> CF interface more cleanly, and work to improve that so that various deployment mechanisms can be used all the while retaining the consistency which seems to be the real goal we're trying to strive for here. …

It worries me that we are strengthening the how, specific implementation, as a higher goal than what can be innovated and accomplished within the project. The comment that this will make BOSH stagnant is worthy of concern. It also assumes that BOSH’s implementation needs to be raised in importance which somewhat removes it from needing to compete with alternatives. Competition is good for the project. Specifically, with alternative deployment options on the market that are both garnering good healthy attention and innovating at a rapid rate, elevating BOSH implementation to this level seems limiting. Case in point, to think that a decision for a certification like this can stop innovations like what Stackato has just brought to market as a currently certified product exemplifies the issue. To put innovations like this at risk to strengthen operator consistency or to simplify how to evaluate talent is risky.