Open Stack

Excerpts from Thierry Carrez's message of 2018-04-22 15:10:40 +0200:
> Doug Hellmann wrote:
> > [This is meant to be one of (I hope) several conversation-provoking
> > questions directed at prospective TC members to help the community
> > understand their positions before considering how to vote in the
> > ongoing election.]
> > 
> > We are discussing adding at least one new project this cycle, and
> > the specific case of Adjutant has brought up questions about the
> > criteria we use for evaluating new projects when they apply to
> > become official.  Although the current system does include some
> > well-defined requirements [1], it was also designed to rely on TC
> > members to use their judgement in some other areas, to account for
> > changing circumstances over the life of the project and to reflect
> > the position that governance is not something we can automate away.
> > 
> > Without letting the conversation devolve too much into a discussion
> > of Adjutant's case, please talk a little about how you would evaluate
> > a project's application in general.  What sorts of things do you
> > consider when deciding whether a project "aligns with the OpenStack
> > Mission," for example?
> 
> Thanks for getting the discussion started, Doug.
> 
> We have two main criteria in the requirements. The "follows the
> OpenStack way" one, which I call the culture fit, and the "aligns with
> the OpenStack mission" one, which I call the product fit. In both cases
> there is room for interpretation and for personal differences in
> appreciation.
> 
> For the culture fit, while in most cases its straightforward (as the
> project is born out of our existing community members), it is sometimes
> much more blurry. When the group behind the new project is sufficiently
> disjoint from our existing team members, you are judging a future
> promise to behave in "the OpenStack way". In those cases it's really an
> opportunity to reach out and explain how and why we do things the way we
> do them, the principles behind our community norms. In the end it's a
> leap of faith. The line I personally stand on is the willingness to
> openly collaborate. If the new group is a closed group that has no
> interest in including new people and wants to retain "control" over the
> project, and is only interested in the marketing boost of being a part
> of "OpenStack", then it should really be denied. We provide a space for
> open collaboration, not for openwashing projects.
> 
> For the product fit, there is also a lot of room for interpretation. For
> me it boils down to whether "OpenStack" (the product) is better with
> that project "in" rather than with that project "out". Sometimes it's an
> easy sell: if a group wants to collaborate on packaging OpenStack for a
> certain format/distro/deployment tool, it's clearly a win. In that case

Given the number of complaints we have had over the lifetime of the
project about the difficulty of upgrading, I am starting to wonder
if we wouldn't have been better off sticking to a single deployment
tool.

> more is always better. But in most cases it's not as straightforward.
> There is always tension between added functionality on one side, and
> complexity / dilution / confusion on the other. Every "service" project
> we add makes OpenStack more complex to explain, cross-project work more
> difficult and interoperability incrementally harder. Whatever is added
> has to be damn interesting to counterbalance that. The same goes for

Why do you think OpenStack has more trouble explaining our feature set
than other cloud systems that have a similarly diverse array of
features?

> competitive / alternative projects: in some cases the net result is a
> win (different approaches to monitoring), while in some cases the net
> result would be a loss (a Keystone alternative that would make everyone
> else's life more miserable).
> 
> In summary while the rules are precise, the way we interpret them can
> still be varied. That is why this discussion is useful: comparing notes
> on how we answer that difficult question, understanding where everyone
> stands, helps us converge to a general consensus of the goals we are
> trying to achieve when defining "OpenStack" scope, even if we disagree
> on the particulars.
>