settingsLogin | Registersettings

[openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

0 votes

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 ?

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 15, 2017 in openstack-dev by Thierry_Carrez (57,480 points)   3 8 13

62 Responses

0 votes

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 ?

As much as I like the idea of offering our hosting for anyone to
use, I agree that it is at least related to the confusion about
what is and is not part of OpenStack. Clarifying that communication
issue is not necessarily going to be solved just with new names for
things like "big tent" or "official project".

The onboarding project team (SIG?) and time limit for joining
governance address any concerns I have about how we would continue
to allow new project teams to join.

For (2), I think I prefer a dedicated team or adding repos to
existing teams that need (or want to adopt) the tool, rather than
dumping everything on Oslo automatically.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Doug_Hellmann (87,520 points)   3 4 10
0 votes

On Wed, Jun 28, 2017 at 3:50 PM Thierry Carrez thierry@openstack.org
wrote:

Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. [...]

I think this is the right solution for OpenStack. In particular, I think
it will clarify external perception, and will promote internal focus on
developing integration between the remaining projects that are OpenStack.

I say that even as maintainer of one of the hosted non-official projects
(networking-calico) that would be booted out under this proposal. I will
have a bit of work to do to set up equivalent CI that I currently get from
the OpenStack infrastructure - but that will have fringe benefits too, in
terms of my team's ability to change things more rapidly. I'm grateful for
the experience and mentoring that I've had while using the OpenStack
infrastructure - that makes me feel confident that I can now set up what
networking-calico needs myself.

Regards - Neil


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by neil_at_tigera.io (3,740 points)   2 3
0 votes

On 2017-06-28 10:50 AM, Thierry Carrez wrote:
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.
Who is going to staff this team?

I think a large reason that we are in the situation we are in is due to
the fact that large corp can't see the importance of paying salaries for
people to help others and keep things clean and tidy. They will foot the
bill for building the thing, they tend to be reluctant to pay to keep
things tidy and well maintained.

I'm not saying it isn't a good idea. I felt the work was very valuable
when I did it and I thought the community appreciated it a lot. But for
the last year I have not had the benefit of an employer who feels there
is enough value in this approach to pay my salary to do the work.

Would be glad to be proven wrong.

Thanks,
Anita.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Anita_Kuno (21,320 points)   3 3 4
0 votes

Anita Kuno wrote:
On 2017-06-28 10:50 AM, Thierry Carrez wrote:

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.
Who is going to staff this team?

I think a large reason that we are in the situation we are in is due to
the fact that large corp can't see the importance of paying salaries for
people to help others and keep things clean and tidy. They will foot the
bill for building the thing, they tend to be reluctant to pay to keep
things tidy and well maintained.

I'm not saying it isn't a good idea. I felt the work was very valuable
when I did it and I thought the community appreciated it a lot. But for
the last year I have not had the benefit of an employer who feels there
is enough value in this approach to pay my salary to do the work.

Would be glad to be proven wrong.

At the TC level, we started to try to pair prospective teams with
mentors to help them through. I'm pretty sure current and past
volunteers on this task would be happy to help and seed that team.

It's not that much work, and it's work we end up doing anyway (questions
always get asked, they just get asked at awkward times in the
application process).

Currently the first contact we get is when a project team applies to
become an official project (which invariably comes too early). Engaging
earlier with a team of mentors sounds like it would save us a lot of
problems down the line, and clear out a lot of confusion with the process.

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

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 ?


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Clint_Byrum (40,940 points)   4 5 9
0 votes

On 06/28/2017 01:07 PM, Clint Byrum wrote:
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 much this.

Best,
-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Jay_Pipes (59,760 points)   3 11 14
0 votes

On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez thierry@openstack.org
wrote:

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

Do we no longer think openstack hosted infra holds a competitive advantage
for teams that are trying to efficiently collaborate building software in
service of the mission?

If we do, why would we agree on a plan that basically tells teams that are
trying to "get stuff done" to go work it out on github and travis ci or
whatever? Maybe worse, what happens when a team/project/community grows up
around one workflow (not because it's better; but just because the
OpenStack workflow is exclusionary) but then it sees it's
operators/deployers/users adoption swelling around OpenStack and wants to
"join"? Is adopting the hosted infrastructure later... optional?

If we do NOT think hosting on openstack-infra offers competitive advantage
for teams that are trying to efficiently collaborate building software in
service of the mission ... why heck not?!

-Clay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Clay_Gerrard (5,800 points)   1 2 2
0 votes

On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez thierry@openstack.org
wrote:

It's hard for newcomers to the OpenStack world to see what
is a part of OpenStack and what's not.

Just an aside, this Perception problems works in our favor sometimes too.
I know in the past some BigCorp contributors have been told to "go work on
OpenStack" and the ambiguity leaves room for creative allocation of
resources. Sometimes the rule-of-thumb is as simple as "if it's hosted on
OpenStack infra you can contribute". I think internally we understand
software in service of the mission isn't strictly limited to projects under
TC governance - but on the outside ... there's a "perception problem" ;)

-Clay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Clay_Gerrard (5,800 points)   1 2 2
0 votes

On 06/28/2017 01:48 PM, Clay Gerrard wrote:

On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez <thierry@openstack.org
thierry@openstack.org> wrote:

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

Do we no longer think openstack hosted infra holds a competitive
advantage for teams that are trying to efficiently collaborate building
software in service of the mission?

I think it absolutely does.

If we do, why would we agree on a plan that basically tells teams that
are trying to "get stuff done" to go work it out on github and travis ci
or whatever? Maybe worse, what happens when a team/project/community
grows up around one workflow (not because it's better; but just
because the OpenStack workflow is exclusionary) but then it sees it's
operators/deployers/users adoption swelling around OpenStack and wants
to "join"? Is adopting the hosted infrastructure later... optional?

++ to these questions

This is the reason I do not think we should stop hosting 'non-official'
software. There are many things we have that allow for collaboration
across individual project domains that we have developed over time
exactly to address all of these issues. They may not always fit everyone
perfect, but they provide enough value that our problem is currently
that "too many people" want to collaborate directly, rather than that
our tooling is driving people away.

If we do NOT think hosting on openstack-infra offers competitive
advantage for teams that are trying to efficiently collaborate building
software in service of the mission ... why heck not?!

-Clay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Monty_Taylor (22,780 points)   2 5 7
0 votes

On 06/28/2017 09:50 AM, Thierry Carrez wrote:
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:

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?

  • 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.

  • 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?

Guess what? We're big. Software is hard. Life doesn't fit into neat
packages people want it to fit in to.

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).

The work to do this provides absolutely no benefit.

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.

Monty


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 28, 2017 by Monty_Taylor (22,780 points)   2 5 7
...