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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
