governance/resolutions/20170404-vision-2019.rst

===========================================================
 Technical Committee Vision for 2019 (Drafted April, 2017)
===========================================================

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
environment changes between now and 2019.

.. note::

   This is the vision of the TC from April 2017. Future TCs may
   publish new visions for the future.

To help with setting the context of this vision, please review these documents:

* `Why and How Visioning Works <https://www.zingtrain.com/content/why-and-how-visioning-works>`_
* `OpenStack Technical Committee Mission <https://governance.openstack.org/tc/reference/charter.html#mission>`_
* `Guiding Principles <https://governance.openstack.org/tc/reference/principles.html>`_

----

The first OpenStack Summit of 2019 is a 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 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.

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

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.

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
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 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 includes several
women and representatives from APAC and European countries. These
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, which aims to bring more
users and operators into the contributor space and ensure that they
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
more than 40% of their OpenStack time focused on efforts spanning two
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.

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 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 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
getting tested in the field. We expect most of the OpenStack projects,
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 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
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
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.