[openstack-dev] [tc] persistently single-vendor projects
joehuang at huawei.com
Fri Aug 5 03:00:52 UTC 2016
I think all the problem is caused by the definition "official OpenStack project" for one big-tent project.
I understand that each OpenStack vendor wants some differentiation in their solution, while also would
like to collaborate with common core projects.
If we replace the title "official OpenStack project" to "OpenStack ecosystem player", and make "big-tent"
as "ecosystem play yard" ( no close roof ), TCs can put more focus on governance of core projects
(current non-big-tent projects), and provide a more open place to grow abundant ecosystem. The bigger the
ecosystem is, the more scenario and demand for cloud operators(public, private, hybrid) can be fulfilled
with different choices, and the competition will also help to grow the best one.
Chaoyi Huang (joehuang)
From: Erno Kuvaja [ekuvaja at redhat.com]
Sent: 05 August 2016 1:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
On Thu, Aug 4, 2016 at 9:56 AM, Duncan Thomas <duncan.thomas at gmail.com> wrote:
> On 1 August 2016 at 18:14, Adrian Otto <adrian.otto at rackspace.com> wrote:
>> I am struggling to understand why we would want to remove projects from
>> our big tent at all, as long as they are being actively developed under the
>> principles of "four opens". It seems to me that working to disqualify such
>> projects sends an alarming signal to our ecosystem. The reason we made the
>> big tent to begin with was to set a tone of inclusion. This whole discussion
>> seems like a step backward. What problem are we trying to solve, exactly?
> Any project existing in the big tent sets a significant barrier (policy,
> technical, mindshare) of entry to any competing project that might spring
> up. The cost of entry as an individual into a single-vendor project is much
> higher in general than a diverse one (back-channel communications,
> differences in vision, monoculture, commercial pressures, etc), and so
> having a non-diverse project in the big tent reduces the possibilities of a
> better replacement appearing.
Actually I couldn't disagree more. Since big tent and stackforge move
under the openstack name space the effect has been exactly the
opposite. Competitors have way less needs to collaborate with each
other to be part of OpenStack as anyone could just kick up their own
project and do it in their way still being part of the
We see projects splitting more when they do not share the core
concepts (which is good thing) but we do not see projects combining
their efforts when they do overlapping things. Maybe we do see this
lack of diversity just growing as long as we don't care about it (tag
here, another there is not going to slow the company behind the
project pushing it to their customers even there was more diverse or
better options, it's still part of OpenStack and it's "ours"). If we
start pushing the projects that are single vendor out of the big tent,
we give more pressure for multiple of those to combine their efforts
rather than continue competing for same thing and if they don't want
to play together I don't see anything wrong to send clear message that
we don't want to share the cost of it.
I personally see the proposed as not limiting the competition to
appear but rather the single-vendor competition might not stick around
when the competing projects would be under a threat to be thrown out.
If someone brings competing project into the ecosystem, 18 months is
also pretty decent time to see if that approach is superior enough (to
attract the diversity) and justify it's existence or if those people
just should try to play with others instead of doing their own thing.
I'm all for the selective inclusion based on meritocracy, not only on
person level, but on project level as well.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev