Open Stack

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

-- 
Thierry Carrez (ttx)