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