You're reasoning by analogy, but the analogy between CORBA and OpenStack is flawed.
CORBA is mainly a standard. A standard only succeeds if most people adopt it.
OpenStack is mainly a set of open source software. Users can pick and choose the pieces to use in their system. If "OpenStack Governance" decides that Software X should be used for job Y, but something better (and open source) comes along, people can just switch to the better software. In other words, competition can happen at the component level and it can come from the grassroots (without permission from the big wigs). It's much different from everyone having to agree on one standard.
I don't need to tell you that there are many thriving open source software ecosystems. Make an analogy with one of them and OpenStack makes much more sense (e.g. Linux and its packages, Python and its packages, WordPress and its themes/plugins).
The analogy is not 1:1, but consider a few observations.
Firstly, OpenStack is not a thriving open source community in the usual sense. It has succeeded in creating a vendor ecosystem, it has not succeeded in creating a large volume of customer successes. An OpenStack deployment is notoriously hard to get right in practice and hundreds of millions of dollars have been squandered to date on failed projects. In this way it has a lot of similarity to CORBA, which was a vendor love fest far before customer adoption, which took years of failures before the initial successes.
Secondly, you may want to look into how the OMG operated (and still operates), which not as a top-down standards body, it is more of a community facilitation organization. OMG set out RFI/RFPs for set of component/facility/service-level specifications with competition in the form of RFP responses that are voted on by the membership and then consolidated. The OMG would have been much better served by having an open source reference implementation for the various specs (avoiding many of the design flaws and ratholes the OMG ran into).
That said, once the OMG picked a recommendation for an area, customers or vendors tended to use that or implement that, and ignore alternatives. This is not much different from the OpenStack Foundation, which can and will control the direction of the OpenStack software for the (debatable) benefits of its leadership and members. The startup community is risk tolerant enough to just "try something else" that's open source without a support contract, sure, but in my experience most enterprises won't mix and match things that aren't "approved" or "recommended" by the mothership and supported by the likes of EMC, VMware, HP or IBM.
Third, consider the popularity of RedHat Linux. It is a billion dollar company because they are the de facto go-to vendor for a Linux distribution, patch network, and support contract. They curate what packages and kernel patches are included in the distribution, but generally rely on Linus' governance for the kernel and do not deviate strongly from it. If Linus doesn't want it in the main kernel, it's an uphill climb to expect to see it eventually in RHEL.
I expect a similar pattern with OpenStack, with the caveat the governance itself is not user-centered, it is vendor-centered, which is not a good sign.
Comments
You're reasoning by analogy, but the analogy between CORBA and OpenStack is flawed.
CORBA is mainly a standard. A standard only succeeds if most people adopt it.
OpenStack is mainly a set of open source software. Users can pick and choose the pieces to use in their system. If "OpenStack Governance" decides that Software X should be used for job Y, but something better (and open source) comes along, people can just switch to the better software. In other words, competition can happen at the component level and it can come from the grassroots (without permission from the big wigs). It's much different from everyone having to agree on one standard.
I don't need to tell you that there are many thriving open source software ecosystems. Make an analogy with one of them and OpenStack makes much more sense (e.g. Linux and its packages, Python and its packages, WordPress and its themes/plugins).
The analogy is not 1:1, but consider a few observations.
Firstly, OpenStack is not a thriving open source community in the usual sense. It has succeeded in creating a vendor ecosystem, it has not succeeded in creating a large volume of customer successes. An OpenStack deployment is notoriously hard to get right in practice and hundreds of millions of dollars have been squandered to date on failed projects. In this way it has a lot of similarity to CORBA, which was a vendor love fest far before customer adoption, which took years of failures before the initial successes.
Secondly, you may want to look into how the OMG operated (and still operates), which not as a top-down standards body, it is more of a community facilitation organization. OMG set out RFI/RFPs for set of component/facility/service-level specifications with competition in the form of RFP responses that are voted on by the membership and then consolidated. The OMG would have been much better served by having an open source reference implementation for the various specs (avoiding many of the design flaws and ratholes the OMG ran into).
That said, once the OMG picked a recommendation for an area, customers or vendors tended to use that or implement that, and ignore alternatives. This is not much different from the OpenStack Foundation, which can and will control the direction of the OpenStack software for the (debatable) benefits of its leadership and members. The startup community is risk tolerant enough to just "try something else" that's open source without a support contract, sure, but in my experience most enterprises won't mix and match things that aren't "approved" or "recommended" by the mothership and supported by the likes of EMC, VMware, HP or IBM.
Third, consider the popularity of RedHat Linux. It is a billion dollar company because they are the de facto go-to vendor for a Linux distribution, patch network, and support contract. They curate what packages and kernel patches are included in the distribution, but generally rely on Linus' governance for the kernel and do not deviate strongly from it. If Linus doesn't want it in the main kernel, it's an uphill climb to expect to see it eventually in RHEL.
I expect a similar pattern with OpenStack, with the caveat the governance itself is not user-centered, it is vendor-centered, which is not a good sign.