Open Stack

On 06/29/2017 03:00 AM, Thierry Carrez wrote:
> Monty Taylor wrote:
>> On 06/28/2017 09:50 AM, Thierry Carrez wrote:
>>> [...] Removing the root cause would be a more radical move: stop offering
>>> hosting to non-OpenStack projects on OpenStack infrastructure
>>> altogether. We originally did that for a reason, though. The benefits of
>>> offering that service are:
>>
>> I disagree that this is removing the root cause.
>>
>> I believe this is reacting to a misunderstanding by hiding from it. I do
>> not believe that doing this provides any value to us as a community.
>>
>> Even though we do not actually use github for development, we have
>> implicitly accepted the false premise that github is a requirement. It
>> is suggested that the existence of git repos in the openstack/ github
>> org is confusing to people. And our reaction to that is to cut off
>> access to our Open Source tools that we set up to collaboratively
>> develop cloud software and tell people to go use the thing that people
>> suggest is one of the causes of people being confused?
> 
> I don't think I agree. GitHub is just one area where confusion spreads.
> Going back to my example, searching for "openstack machine learning" on
> Google will give you links to GitHub, but also the OpenStack wiki, and
> our cgit farm. All of them corroborate that the two projects returned
> are, by all means, official (while they aren't).
> 
> So the suggestion (to cut off access to openstack project infrastructure
> for things that are not openstack and will never be) is not in reaction
> to GitHub, it's in reaction to the confusion that having them on the
> very same project infrastructure creates (on all of our online
> presence), *and* how hard it is to address that confusion at the edge.

Sure - but:

* wikis are wikis - people can literally put anything there they want to.
* The number of official projects is much larger than the number of 
unofficial. Removing unofficial projects will not solve any confusion.

>> * People are not 'confused' by what OpenStack is.
>>
>> Being "confused" is a passive-aggressive way of expressing that they
>> DISAGREE with what OpenStack is. We still have _plenty_ of people who
>> express that they think we should only be IaaS - so they're still going
>> to be unhappy with cloudkitty, congress and karbor.
>>
>> Such people are under the misguided impression that kicking cloudkitty
>> out of OpenStack will somehow cause Nova features to land quicker. I
>> can't even begin to express all of the ways in which it's wrong. We
>> aren't a top-down corporate structure and we can't 'reassign' humans -
>> but even if we WERE - this flawed thinking runs afoul of the Mythical
>> Man Month.
> 
> Sure, but you are missing my point. I totally agree that a lot of people
> involved in OpenStack pretend to be confused, despite us being very
> clear as to what's officially in OpenStack and what's not, and that's
> their own way of complaining about how things turned out.
> 
> The confusion I'm talking about is not the passive-aggressive from
> people involved in openstack. It's from our prospective new users, who
> have no idea about our governance, making random searches on Google.
> It's from people getting hit by marketing message from projects claiming
> to be official OpenStack projects, while they are not. It's extremely
> difficult for those to see clearly, especially with all our online
> presence reinforcing the confusion.

I understand the confusion you're talking about. Removing unofficial 
projects will not solve it.

>> * Kicking non-official things out will not help
>>
>> If I'm wrong about the above and it really is all just about not being
>> able to navigate a set of repositories that are prefixed with the string
>> 'openstack/', it STILL WON'T HELP.
>>
>> There are 1049 official repos. There are only 1676 repos in gerrit.
>>
>> Do we honestly think that people who are confused are going to be less
>> confused by the number of repos in the sacred 'openstack/' namespace
>> going from 1676 to 1049? Do we next tell projects they can only have
>> their primary service managed? Kick out chef, puppet, juju and ansible,
>> as well as the deb- repos? Because maybe the existence of
>> openstack/deb-python-oslo.privsep is confusing someone?
> 
> Again, I agree, but I think you're missing my point. Kicking
> non-official things is not about cutting the number of repositories, or
> somehow making the git.openstack.org/cgit front page more navigable. We
> are indeed past that.
> 
> Kicking non-official things is about stopping blurring the line between
> what's "in" openstack and what's "out". It's about someone googling for
> machine learning on openstack, finding Cognitive on git.openstack.org
> and wiki.openstack.org, assuming it's an official openstack project
> based on those domain names, trying to check it out, realizing it's only
> 4 commits and dead for two years, and assuming OpenStack has pretty low
> standards and is a bunch of dead crap. How do you propose we address
> *that* ?

I'm not missing your point - I'm disagreeing with your premise and your 
conclusions.

We are already WELL past where we can solve the problem you are 
describing. Pandora's box has been opened - we have defined ourselves as 
an Open community. Our only requirement to be official is that you 
behave as one of us. There is nothing stopping those machine learning 
projects from becoming official. If they did become official but were 
still bad software - what would we have solved?

We have a long-time official project that currently has staffing 
problems. If someone Googles for OpenStack DBaaS and finds Trove and 
then looks to see that the contribution rate has fallen off recently 
they could get the impression that OpenStack is a bunch of dead crap.

Inclusion as an Official Project in OpenStack is not an indication that 
anyone thinks the project is good quality. That's a decision we actively 
made. This is the result.

If we would like to change the current fundamental basis of our 
technical governance to be oriented on a curated product that has a 
cohesive and prescriptive design and that has project inclusion based on 
technical merits from some sort of central oversight body - that would 
be a way to address the concerns you are describing. I believe that 
would be a massive undertaking at this point and that we would not 
achieve it because we've designed literally EVERYTHING about how we 
operate to be the exact opposite of that.

We have the ability to make that choice, should we desire.

>> [...]
>>> Thoughts on that ? Would you rather address the confusion at the edges,
>>> or remove the root cause ?
>>
>> The only reasonable action is actually addressing the confusion.
>>
>> the confusion isn't just at the edges - the confusion is actually THE
>> ONLY PROBLEM. There is no other problem that needs to be solved _other_
>> than confusion in this area. The number of projects in gerrit is not a
>> technical problem. It's not overwhelming our governance. It's not a
>> problem for anyone who isn't confused (or saying they're confused when
>> they just disagree)
>>
>> If we create problems for any our developers because there are people
>> who are confused rather than addressing the confusion, we will have
>> abdicated our responsibilities wholesale.
> 
> That would be the first option. We continue to communicate about how
> things really are, and find technical ways to drop markers on unofficial
> projects so that people don't assume too much from the project hosting.
> It's just a lot of maintenance work, and it's not been very successful
> so far. With less and less resources on the infra team to implement
> technical workarounds, I'm just not convinced that's a sustainable solution.

I am 100% convinced that the second thing will produce no positive 
result and there are no circumstances where I can support

As I said in response to Steve Dake's email, we had this problem before 
the Big Tent. We, in fact, had this problem before the Integrated 
Release. Even if we not only kicked out the unofficial projects, but 
when completely crazy and kicked out everything that isn't in the six 
"core" projects - we'd STILL have this problem. We had this problem, 
have this problem and will continue to have this problem because we have 
never defined OpenStack in terms of a set of capabilities or shape of a 
thing we deliver - only by process and community.

This is FUNDAMENTAL to how we have defined ourselves.

Our foundation membership is completely unrestricted. Literally anyone 
who is interested can join. All of those people can vote for 
representatives to our Board of Directors.

The defining feature of OpenStack is our inclusivity and that we value 
everyone's input and everyone's voice.

Closing our borders will not magically solve any of the issues that 
pre-exist inside them, nor will it solve any of the issues that pre-date 
the existence of the borders in the first place.