Open Stack

This message makes a bunch of salient, valid points, none of which I
wish to directly address.

However, on the whole, I think the analysis stops short of pushing through
to a root cause, and thus, the solution proposed is entirely focused on
symptoms.

The root cause of all of this until now has been not really knowing what
OpenStack is. The visioning recently done was a great step in the right
direction toward this. I would like to make sure that we acknowledge
this while we address symptoms of the past choices we made.

In particular, I wonder if landing the vision, pushing harder to fill
in any missing parts of the constellation concept, and getting actual
constellations defined _immediately_, would do just as much as drawing
these concerte lines around abstract bits of software.

So, I'm not saying any of this is wrong. I like the solution proposed,
and I think all of the problems stated are in fact problems. I just
wonder if we're bouncing off "visions are hard" and falling into a bit
of yak shaving around the easy problems when we as a community should
remain focused on the vision.

If nothing else, I'd like to see it clearly stated how this solution
fits in with the vision.

Excerpts from Thierry Carrez's message of 2017-06-28 16:50:01 +0200:
> Hi everyone,
> 
> Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup
> working on "better communicating what is openstack", I started a
> thread[1] about moving away from big tent terminology. The thread went
> in a lot of directions, including discussing GitHub mirroring strategy,
> what makes projects want to be official, the need for returning to a
> past when everything was (supposedly) simpler, and naming fun.
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html
> 
> Many agreed that the "Big Tent" name (as a synonym to "official
> openstack projects") is hurting more than it helps, and we should stop
> using it. The issue is, merely stopping using it won't be enough. We
> have tried, and the name sticks. You need to replace the name by
> something that sticks more, or address the root cause directly.
> 
> The central issue being discussed here is an issue of external
> perception. It's hard for newcomers to the OpenStack world to see what
> is a part of OpenStack and what's not. If you google "openstack machine
> learning", the first hits are Cognitive and Meteos, and it's impossible
> to tell that those are actually not OpenStack projects. One of those has
> been dead for 2 years -- having people think that those are official
> projects hurts all the OpenStack projects, by lowering expectations
> around what that means, in terms of quality, maintenance, or community.
> 
> The confusion mainly stems from the fact that OpenStack project
> infrastructure is open to any open source project (and it's nobody's job
> to clean up dead things). So you can find (on our wiki, on our
> mailing-list, on our cgit farm, on our gerrit, on our GitHub
> organization...) things that are actually not OpenStack, even with the
> expansive "are you one of us" definition. Arguably the most confusing
> aspect is the "openstack/" prefix in the git repository name, which
> indicates some kind of brand association.
> 
> I'd say we have two options. We can address the perception issue on the
> edges, or you can treat the root cause. Neither of those options is
> really an OpenStack  governance change (or "big tent" change) -- they
> are more about what to do with things that are actually *not* in our
> governance.
> 
> Addressing the perception on the edges means making it clearer when
> things are not official. The thread above discussed a lot of potential
> solutions. We could give unofficial things a catchy group name
> (Stackforge, Opium, Electrons...), and hope it sticks. We could find a
> way to tag all projects on GitHub that are not official, or mirror them
> to another organization, or stop mirroring them altogether. We could
> remove the openstack/ prefix from all the projects we host. We could
> actively mark all wiki pages that are not about an official project. We
> could set up a separate Gerrit or separate ML for hosted projects
> development discussions. The main issue with that approach is that it's
> a *lot* of work, and it never completely eliminates the confusion.
> 
> 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:
> 
> 1- it lets us set up code repositories and testing infrastructure before
> a project applies to be an official OpenStack project.
> 
> 2- it lets us host things that are not openstack but which we work on
> (like abandoned Python libraries or GPL-licensed things) in a familiar
> environment
> 
> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> 
> I would argue that we could handle (1) and (2) within our current
> governance.
> 
> For (1) we could have an "onboarding" project team that would help
> incoming projects through the initial steps of becoming an openstack
> project. The team would act as an umbrella team, an experimental area
> for projects that have some potential to become an OpenStack project one
> day. There would be a time limit -- if after one year(?) it looks like
> you won't become an openstack project after all, the onboarding team
> would clean you up. I actually think a bit more project mentoring would
> serve us better than our current hands-free approach.
> 
> For (2) we could also have some other official project team as an
> umbrella for those deps we depend on and have to continue maintaining.
> Or we could expand Oslo's team scope to cover it. It's just a couple of
> repositories anyway.
> 
> That leaves (3). I would argue that was a nice thing to have, but its
> impact was very limited (not so many successful/alive projects in that
> category). I guess if the need is still there and people really want to
> work on this, it could be (and actually has been) set up as a parallel
> infrastructure. The confusion that stems from running it on top of the
> very same infrastructure is just too costly for us at this point.
> 
> This radical solution still means work, but it's one-time governance
> work, rather than infra changes / continuous curation work. It *is*
> radical though, especially for the affected git repositories (for which
> we often don't have any contact email). It will also make removing
> projects a lot more difficult (as there will be consequences in terms of
> project hosting).
> 
> Thoughts on that ? Would you rather address the confusion at the edges,
> or remove the root cause ?
>