diff --git a/reference/technical-committee-vision-2019.rst b/reference/technical-committee-vision-2019.rst index 0ad9e3b03..a07746c04 100644 --- a/reference/technical-committee-vision-2019.rst +++ b/reference/technical-committee-vision-2019.rst @@ -1,175 +1,190 @@ + ===================================== Technical Committee Vision for 2019 ===================================== -It's March of 2019 and we are getting ready for the upcoming Forum at -the OpenStack Summit. The OpenStack community has evolved quite a bit -over the last couple of years. Where do we even begin? +This document was written in June of 2017 as if it were created in +March 2019, looking back at what the OpenStack Technical Committee has been +involved with over the last few years. The aim is to describe an aspirational +yet realistic end goal. It doesn't intend to list out all the tasks needed to +reach the end goal, nor does it intend to stop evolving the direction as the +enviroment changes between now and 2019. -We have finally released our 4th Constellation for OpenStack, -available at https://orion.openstack.org. This new way of looking at -OpenStack reference architectures has successfully given people -concrete approaches to get started with OpenStack. Users have been -excited that not only do these constellations come with a dedicated -website explaining which set of projects make up this constellation, -but they have dedicated documentation for each one as well. A custom -install guide, an operators guide for the constellation in question, a -consolidated API reference for the environment, as well as a -validation script based on tempest that helps determine if the -environment is fully configured interoperable with other similar -constellation deployments completes the picture. Many of the -deployment tools are now providing high level macros to install a -specific constellations, which gives users a great way to see -different configurations of OpenStack without getting lost. +To help with setting the context of this vision, please review these documents: -Constellations have become the new standard way to start exploring -OpenStack. For more advanced users, the project navigator helps -connect the dots from constellations into which projects to -contribute. The old confusion about git namespaces is a thing of the -past, given how convenient and user friendly these new views -are. Users have definitely reported via the user survey a higher ease -of initial understanding of OpenStack. This Constellation based view -has helped shape the overall project map. As we have been going -through and building these constellations we found several components -that did not fit well. We removed components that either overlapped -with work in adjacent communities or were not consistent with the -OpenStack mission. Other projects were refactored to clarify their -scope as they were placed on the map. +* `Why and How Visioning Works `_ +* `OpenStack Technical Committee Mission `_ +* `Guiding Principles `_ -While the Constellation view has helped understand some prebuilt -patterns with OpenStack that are successful, it has also demonstrated -that there is more than one way to remix these components into -interesting architectures. Having multiple deeply worked examples has -helped clarify that OpenStack components can work well in many -configurations and use cases. As a result, new use cases are now -easier to envision and has led to the use of individual OpenStack -components in other deployments. +---- -At the most recent OpenStack summit, three users gave presentations -about using single or minimal components of OpenStack, including using -Keystone for authenticating services not related to OpenStack at -all. Everyone was really thrilled by that as the landscape of -technology does not begin and end with OpenStack. This happened -because we started thinking differently about adjacent -Communities. The TC identified OpenStack services that would be of -value in new use cases and scenarios in conjunction with other -communities and ensured that they can be run as projects independent -of others. We have done the heavy lifting that makes it easy to +The first OpenStack Summit of 2019 is great time to review how the +OpenStack community has evolved over the last few years. We've made +progress on a new way to understand reference architectures, on using +individual components of OpenStack on their own, on working with other +communities in the cloud ecosystem, and on encouraging and mentoring +contributions and leadership from an increasingly diverse community. + +Navigating with Constellations +------------------------------ + +We have released our 4th Constellation for OpenStack. This new way of +looking at OpenStack reference architectures gives people concrete +approaches for getting started. Users are excited not only about the +dedicated website describing which projects make up each +constellation, but also that each has dedicated documentation: A +custom install guide, an operator's guide, and a consolidated API +reference for the environment. There's also a validation script based +on tempest that helps determine if the environment is fully configured +and interoperable with other similar deployments. Many of the tools +used for OpenStack deployment now provide high level macros to install +specific constellations, giving new users a straightforward way to +experience different configurations of OpenStack without getting lost. + +In addition to making the initial understanding of OpenStack easier, +constellations have also provided other benefits: For users who want +to help improve OpenStack, the project navigator connects the dots +from constellations to individual projects. Building constellations +has helped identify several components that do not fit well. They were +removed either because they overlapped with more active work in +adjacent communities or because they were not consistent with the +OpenStack mission. Having multiple deeply worked examples has +clarified that OpenStack components can be remixed in many +configurations and use cases. New use cases are easier to envision +leading to individual OpenStack components being used in other +deployments. + +Working with Adjacent Communities +--------------------------------- + +At the previous OpenStack summit, three users gave presentations about +using single or minimal components of OpenStack, including using +Keystone for authenticating services not related to OpenStack. +Everyone was thrilled to see that the landscape of technology does not +begin and end with OpenStack. The seed of this work was thinking +differently about adjacent Communities. The OpenStack community in +conjunction with other communities identified services that would be +of value in new scenarios and ensured that they can be run +independently. We have done the heavy lifting to make it easy to integrate Keystone into projects written in Go, Nodejs, or Java, so -that new projects starting off can easily start with a multi-tenancy -user/project story. It also makes it seamless for users to combine -services from OpenStack, and all these other communities in their -composite applications. The users love not having to hard code -credentials from different services throughout their environment. +that new projects can begin with a multi-tenancy user/project story. +This work also makes it seamless for users to combine services from +OpenStack and other communities in their composite applications. Users +love not having to hard code credentials from different services +throughout their environment. -We have learned a lot from adjacent communities in the process, and -have made some substantial changes to the way we do things based on -these collaborations. The TC is proactive in reaching out to -communities with overlapping interests including consumers of -OpenStack as well as components which play a critical role in -deployment of a OpenStack Solution. In addition, we have also been -able been able to share some of our hard learned lessons and success -stories to help them on their journey. We now have a very repeatable -system for engaging with new communities, sharing some of our past -insights, and helping where we can, while being respectful of how -every community has their own culture and needs as they grow. The 5-10 -groups we have formed close partnerships with are continuously asked -for feedback to ensure their satisfaction with our partnership. Our -partnerships focus on this quality of partnership, rather than -quantity of groups we interact with, so the appropriate amount of -resources can be focused on success. It is a regular occurrence that -TC members are or have been committers within these other communities. +.. TODO(cdent): We need an example going the other direction. A tech + from an adjacent community that OpenStack has chosen + to adopt (perhaps even replacing something). -The outreach included both technical and non-technical aspects. Since -the OpenStack ecosystem is mature and has excellent systems and -processes in place for dealing with governance, vulnerabilities, -continuous integration infrastructure, leadership development, etc., -the TC shares the best practices with other newly forming communities -to help bootstrap them. On the technical side, the TC worked closely -with leadership teams of the other communities to find opportunities -to share code as services, libraries, reduce scope and complexity of -some projects to remove duplicated effort. This has empowered -contributors to easily move between OpenStack and other communities -and develop synergies to benefit everyone. The TC worked with the -OpenStack Infrastructure, Quality Assurance, and similar teams to make -sure there is a common understanding of how to deal with new language -ecosystems, new projects that will need continuous integration, -mirroring needs, and works to expand available resources as well as -ensure that there is no undue impact on limited resources. +We have learned a lot from adjacent communities and have made some +substantial changes to the way we do things. The TC is proactive in +reaching out to communities with overlapping interests. This includes +consumers of OpenStack as well as components which play a critical +role in deployment of an OpenStack solution. We have also +shared some of our hard learned lessons and success stories to help +them on their journey. We now have a repeatable system for engaging +with new communities that allows us to share some of our past insights +and help where we can while still being respectful of how every +community has their own culture and needs. We continuously ask the +groups we have close partnerships with for feedback to ensure +their satisfaction with the partnership. We focus on the quality of +partnership, rather than quantity of groups we interact with, so the +appropriate amount of resources can be focused on success. It is a +regular occurrence that TC members are or have been contributors within +these other communities. -Reaching out to so many other communities, and sharing lessons between -us, really confirmed for all of us how critical diversity is to the -future of OpenStack. There are so many good ideas out there, and so -many people that are motivated to help move the conversation -forward. The diverse community also drives a lot of empathy in our -contributors. It has been much easier to understand and empathize with -the wide range of challenges and problems people are trying to solve -with OpenStack when we have so many different perspectives in our -community. Diversity, on many axes, is now a key value in OpenStack -itself, and we have seen our contributor base get measurably more -diverse in each of the last three releases. +The outreach includes both technical and non-technical aspects. Since +the OpenStack ecosystem has mature systems and processes in place for +dealing with governance, vulnerabilities, continuous integration +infrastructure, leadership development, etc., the TC is able to share +best practices with other newly forming communities to help them to +bootstrap. On the technical side, the TC works closely with leadership +teams of the other communities to find opportunities to remove +duplicated effort. This collaboration has provided opportunities for +contributors to move easily between OpenStack and other communities +and develop synergies that benefit everyone. The TC works with the +OpenStack Infrastructure, Quality Assurance, and similar teams from +other communities to make sure there is a common understanding of how +to deal with new language ecosystems, new projects that will need +continuous integration, and works to expand available resources as +well as ensure that there is no undue impact on limited resources. + +Embracing Community Diversity +----------------------------- + +Reaching out to other communities has confirmed how critical diversity +is to the future of OpenStack. There are so many good ideas, and so +many people that are motivated to help. A diverse community drives a +lot of empathy in our contributors. It is much easier to +understand and empathize with the wide range of challenges and +problems people are trying to solve with OpenStack when there are +many different perspectives in our community. Diversity, on many axes, +is now a key value in OpenStack itself, and we have seen our +contributor base get measurably more diverse in each of the last three +releases. More than 50% of the contributors to the most recent OpenStack release identified strongly as an OpenStack user or operator. This has helped -grow different patterns and culture of contributions, that are more -focused on near term needs of the operators in the field. It has also -brought much more sympathy to the needs of part time contributors who -can't complete a perfect patch to get it accepted. A small organic -team of shepherds have been taking the drive-by contributions and -working them into the system, either by taking over the patches or by -applying follow-up changes. The new bot that converts github pull -requests to gerrit change-sets, instead of discarding them, imported -several patches in each of the last three months. +different patterns and a different culture of contribution to emerge; +there is more focus on the near term needs of the operators in the +field. It has also brought more sympathy to the needs of part time +contributors who for whatever reason are unable to see a patch through +to merging. A small organic team of shepherds have been taking these +contributions and working them into the system, either by taking over +the patches or by applying follow-up changes. -The TC itself has changed in the process. We now regularly have people -from the operator community and user committee both on the TC and +The TC itself has changed too. We now regularly have people +from the operator community and user committee on the TC and also assisting with many of the TC initiated efforts. The TC now looks much -more like our contributor base. The TC membership now includes several +more like our contributor base. The TC membership includes several women and representatives from APAC and European countries. These -changes did not happen overnight, or by accident. We now have very -heavy emphasis on mentoring in the community, with multiple different +changes did not happen overnight, nor by accident. They are the result +of heavy emphasis on mentoring in the community, with multiple different efforts underway. There is the new OpenStack Ladder program, inspired -by the Drupal Ladder program, has aimed to bring more traditional +by the Drupal Ladder program, which aims to bring more users and operators into the contributor space and ensure that they -don’t feel overwhelmed getting their first patch in. +don’t feel overwhelmed by our contribution processes. + +Growing New Leaders +------------------- For members of the community that are already engaged, we have built into our ladder program a specific mentoring program around inter-project work. This is not only technical mentoring, but focuses on the skills needed to interface with multiple communities, and work to build consensus across sometimes large cultural boundaries. We have -10 mentors and over 50 participants in this program, who are spending +10 mentors and over 50 participants in this program who are spending more than 40% of their OpenStack time focused on efforts spanning two -or more projects. This has not only given OpenStack a unified user and -operator experience, but this spanning of project communities has made -our community feel more whole as well. +or more projects. This inter-project work has not only given OpenStack +a unified user and operator experience, but has made our community +feel more whole as well. -With more community members having successes in inter-project work, it -is now commonplace for popup teams to form around these kind of -efforts, often lead by members of the mentoring program. They will -engage with key members from different project teams within OpenStack, -or projects in other communities, or both. Members of the user and and -operators communities are often a part of these popup teams. People -find it exciting and energizing to dive into such crucial work early -in their OpenStack engagement. Success breeds success, and as the -velocity of this work has increased we have seen a renewed investment -from member companies to keep accelerating this work. +It is now commonplace for popup teams to form around inter-project +work, often led by members of the mentoring program. They engage with +key members from different project teams within OpenStack, or projects +in other communities, or both. Members of the user and operators +communities are often a part of these popup teams. People find it +exciting and energizing to dive into such crucial work early in their +OpenStack engagement. Success breeds success, and as the velocity of +this work has increased we have seen a renewed investment from member +companies to keep accelerating this work. Much of the work done by these inter-project teams has come from the -improved feedback loop between user, operators and developers. Indeed -this feedback, coupled with the increase in diversity of -contributions, makes it hard to distinguish between users, operators -and developers. One visible success story has been the TC curated Top -10 hit list. It has brought renewed focus on some of the hard problems -we need to go after in the near term. It is now commonplace that key -features that identified in the Top 10 hit list get completed in a -single cycle. Not only does it easily express some of the most -important work that we need to get done as a community, but the -process of creating it made us all understand OpenStack that much -more. +improved feedback loop between users, operators and developers. Indeed +this feedback, coupled with the increase in diversity of contributions, +makes the interactions — as well as the contributions — between users, +operators and developers seamless. One visible success story has been +the TC curated Top 10 hit list. It has brought renewed focus on some of +the hard problems we need to address in the near term. It is now +commonplace that key features that were identified in the Top 10 hit +list get completed in a single cycle. Not only does the list easily +express some of the most important work that we need to get done as a +community, but the process of creating it has made us all understand +OpenStack that much more. -When TC members and other community leaders started taking deep dives -into projects they normally don’t contribute to, there was a ton of +When community members started taking deep dives into projects to +which they don't normally contribute, there was a ton of enlightenment. Old prejudices took a backseat as we walked a mile in each other’s shoes. This new understanding is part of why hierarchical quotas are now implemented and working in many services, and are now @@ -178,7 +193,7 @@ as well as a number of non OpenStack projects in adjacent communities to have this supported over the next year. Over the past year, the TC has proudly celebrated the good work done -by those who stepped up to lead and work on crucial work in the +by those who stepped up to lead and work on crucial needs in the community. It has been particularly satisfying to see the breadth of talent now involved in the technical leadership of the OpenStack community. More companies are investing longer term contributors to @@ -186,10 +201,10 @@ the OpenStack project, because they can see a clearer path for value delivery to their products and services delivered using OpenStack. We now have between 50 and 100 contributors with significant commits to two or more Projects every release cycle. Importantly, we have -retained 75% of those contributors over the last three -releases. Moreover, 50% of these contributors are part time, yet still -able to get actively involved in critical inter-project work. And we -regularly see those folks that leave our community become leaders and -mentors in other Open Source projects in the ecosystem. We have grown +retained 75% of those contributors over the last three releases. +Moreover, 50% of these contributors are part time, yet still able to +be actively involved in critical inter-project work. We regularly see +those people that leave our community become leaders and mentors in +other Open Source projects in the ecosystem. We have helped to improve not just OpenStack, but Open Source as a whole, and that is something we can all be proud of.