Open Stack

Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +0000:
> On Tue, 16 Feb 2016, Doug Hellmann wrote:
> 
> > If we want to do that, we should change the rules because we put
> > the current set of rules in place specifically to encourage more
> > project teams to join officially. We can do that, but that discussion
> > deserves its own thread.
> 
> (Yeah, that's why I changed the subject header: Indicate change of
> subject, but maintain references.)

Ah, my mailer continued to thread it together with the other messages.

> I'm not sure what the right thing to do is, but I do think there's a
> good opportunity to review what various initiatives (big tent, death
> to stackforge, tags, governance changes, cross-project work) are trying
> to accomplish, whether they are succeeding, what the unintended
> consequences have been.
> 
> >> For the example of Poppy, there is nothing that requires it be a part
> >> of OpenStack for it to be useful to OpenStack nor for it to exist as
> >> a valuable part of the open source world.
> >
> > Nor is there for lots of our existing official projects. Which ones
> > should we remove?
> 
> The heartless rationalist in me says "most of them". The nicer guy
> says "this set is grandfathered, henceforth we're more strict".

Right. Poppy has been around longer than some of those, so it hardly
seems fair to them to do that.

> A reason _I_[1] think we need to limit things is because from the
> outside OpenStack doesn't really look like anything that you can put
> a short description on. It's more murky than that and it is hard to
> experience positive progress in a fog. Many people react to this fog
> by focusing on their specific project rather than OpenStack at
> large: At least there they can see their impact.

I've never understood this argument. OpenStack is a community
creating a collection of tools for building clouds. Each part
implements a different set of features, and you only need the parts
for the features you want.  In that respect, it's no different from
a Linux distro. You need a few core pieces (kernel, init, etc.),
and you install the other parts based on your use case (hardware
drivers, $SHELL, $GUI, etc.).

Are people confused about what OpenStack is because they're looking
for a single turn-key system from a vendor? Because they don't know
what features they want/need? Or are we just doing a bad job of
communicating the product vs. kit nature of the project?

> This results in increasing the fog because cross-project concerns (which
> help unify the vision and actuality that is OpenStack) get less
> attention and the cycle deepens.

I'm not sure cross-project issues are really any worse today than
when I started working on OpenStack a few years ago. In fact, I think
they're significantly better.

At the time, there were only the integrated projects and no real
notion that we would add a lot of new ones. We still had a hard
time recruiting folks to participate in release management, docs,
Oslo, infra, etc. The larger community and liaison system has
improved the situation. There's more work, because there are more
projects, but by restructuring the relationship of the vertical and
horizontal teams to require project teams to participate explicitly
we've reduced some of the pressure on the teams doing the coordination.

Architecturally and technically, project teams have always wanted
to go their own way to some degree. Experimentation with different
approaches and tools to address similar problems like that is good,
and success has resulted in the adoption of more common tools like
third-party WSGI frameworks, test tools, and patterns like the specs
review process and multiple teams managing non-client libraries.
So on a technical front we're doing better than the days where we
all just copied code out of nova and modified it for our own purposes
without looking back.

We also have several new cross-project "policy" initiatives like
the API working group, the new naming standards thing, and cross-project
spec liaisons. These teams are a new, more structured way to
collaborate to solve some of the issues we dealt with in the early
days through force of personality, or by leaving it up to whoever
was doing the implementation.  All of those efforts are seeing more
success because people showed up to collaborate and reach consensus,
and stuck through the hard parts of actually documenting the decision
and then doing the work agreed to. Again, we could always use more
help, but I see the trend as improving.

We've had to change our approaches to dealing with the growth,
and we still have a ways to go (much of it uphill), but I'm not
prepared to say that we've failed to meet the challenge.

Doug

> 
> [1] Other people, some reasonable, some not, will have different
> opinions. Yay!