Open Stack

On Tue, Aug 2, 2016 at 11:29 AM, Thierry Carrez <thierry at openstack.org> wrote:
>
> Doug Hellmann wrote:
> > [...]
> >> Likewise, what if the Manila project team decides they aren't interested
> >> in supporting Python 3.5 or a particular greenlet library du jour that
> >> has been mandated upon them? Is the only filesystem-as-a-service project
> >> going to be booted from the tent?
> >
> > I hardly think "move off of the EOL-ed version of our language" and
> > "use a library du jour" are in the same class.  All of the topics
> > discussed so far are either focused on eliminating technical debt
> > that project teams have not prioritized consistently or adding
> > features that, again for consistency, are deemed important by the
> > overall community (API microversioning falls in that category,
> > though that's an example and not in any way an approved goal right
> > now).
>
> Right, the proposal is pretty clearly about setting a number of
> reasonable, small goals for a release cycle that would be awesome to
> collectively reach. Not really invasive top-down design mandates that we
> would expect teams to want to resist.
>
> IMHO if a team has a good reason for not wanting or not being able to
> fulfill a common goal that's fine -- it just needs to get documented and
> should not result in itself in getting kicked out from anything. If a
> team regularly skips on common goals (and/or misses releases, and/or
> doesn't fix security issues) that's a general sign that it's not really
> behaving like an OpenStack project and then a case could be opened for
> removal, but there is nothing new here.
>

+1 to all of this.

As someone who was in leadership training with both Thierry and Doug,
I just want to point out that 'reasonable, small goals' and 'support a
particular library du jour or get kicked out of OpenStack' are
immensely different reads on the potential of this situation.

OpenStack suffers from a perception that it is not a usable, cohesive
set of projects that work together. Like many perceptions out in the
wild about OSS projects, that is part PR/spin/haters-gonna-hate, and
part reality. Apart from PR-land, the idea of having some basic
standards and cross-project goals to meet not just before a project is
accepted, but also as it matures, hopefully serves the ultimate
purpose of presenting an OpenStack with enough consistency and
usability that it doesn't make a user/operator want to throw a server
out the window.

Where does the technical independence of a project begin encroaching
on the ability of other projects to effectively work for their users
or their developer participation? Where do the desires of a single
project begin to negatively impact the entirety of OpenStack, and how
does the community respond when faced with tough situations like that?

The TC, as a body that oversees the overarching technical direction of
the entire group of projects, has identified areas where OpenStack
could be *highly* improved in its functionality and usability - those
certainly, on their surface, seem like noble goals for any person
creating any project with an end user that is not themselves. That the
TC is the mechanism to do that unifying, helpful, future-preserving
thing for OpenStack and also the same mechanism that, in the wrong
hands, could be used to ask impossible things of projects (and use
their failure to kick them out of the community, eventually) is
totally true, but it's also always been true of the TC. That's why
preserving our culture of leadership by election is so important -
leaders are elected to serve their constituents - *not* the other way
around.

-colette/gothicmindfood