 Hello, everyone. Good morning. How are you, friends? Yay. Last day of OpenStack Summit Forum. I have to get used to saying that. So welcome to our session. We're going to talk a little bit with you today about the OpenStack Technical Committee vision that was written for 2019, and we also want you all to talk back. First, some introductions. I'm Colette. You can find me on IRC at Gothic Mind Food, or if you want to tweet at me, I'm Colette Cello. And I am the chair of the stewardship working group in OpenStack. John. Hi, I'm John Garbert. I'm known on IRC and the Twitter is John the Tuba Guy, because I do actually play the Tuba and just make that up. So I'm an OpenStack developer. I was previously an over-PTL. Right now, I'm also on the OpenStack Technical Committee. So hello. My name is Thierry. I work for the OpenStack Foundation on the OpenStack Technical Committee and do release management stuff for OpenStack. So that's who we are. And how many of you here have heard of this technical committee vision that we're going to be talking about today? All right. So not a ton. All right. Well, it makes sense then to start at the beginning of the story, which is that we all kind of went to this training for leadership that explained to us what visioning is. And we wanted to talk a little bit about that before we talked about the vision that we wrote with you, because some people have different ideas of what visioning means. So first off, you probably heard of mission statements or vision statements as a thing that groups or companies have. And the kind of vision that we wrote is a little bit different than that. It's meant to describe a specific point in time in great detail with pros. And it's meant to be inspiring. So it's telling you a kind of story. And it's meant to be, it's supposed to be strategically sound. So it has to be something that it can't be like an OpenStack is going to take everyone to Mars in five years, right? So those are the main elements of a vision. And one of the reasons that we learned that writing this vision can be helpful is that it kind of describes a point in the future where we can all imagine success in a positive way together. And it doesn't really focus on how we get there, right? The most important thing for us before we decide how is where exactly we want to go and what that looks like together. So we wrote the vision. Well, why did we write the vision theory? I mean, mostly because I think people had been talking a lot around the community about a lack of forward thinking and kind of like collective understanding of where we're all going together, not just on a project by project basis, but as an entire community. And so this seemed like a really good opportunity and tool to try out to see if we could come together as a group and agree on where we want to go. It's also like informing our decisions, like having this vision set future. It's like a desirable future. And we it informs the decision of the group and helps with consensus building. And work prioritization. The personal thing I find is it's really easy to get stuck in detail in a little little detail. And you dive down in there and you forget, like, no, we need to make progress on these things. It's great to step back, look at the vision for 2019 and go, okay, so we need to be sort of heading this direction. And it just it really helps to sort of understand what the stuff that's ahead of us. Yeah. And that's what the leadership training we went to allowed us to have like take that step back and think about the big picture. And to me, the vision is like taking that step back, look at the big picture and write it so that we can refer to it again, when we need to take that step back again. So the idea of a vision again is something in the future, this prose description of what that is like. And we chose 2019. Now, I've read visions that are 20 years in the future. I've read visions that are six months in the future. So why did we choose this two year mark? Well, when we sat down and thought about it, we thought a six month release cycle time seems like we might be trying to limit ourselves in our head of what we're capable of too much. But too long. And we might not really be able to effectively react to the changing marketplace around open source cloud platforms or cloud platforms in general. So 2019 seemed like a good sweet spot in between that not too soon and not too far out that we can't possibly predict the environment will be in. And why the TC and not all of OpenStack? Well, the truth is because the TC is a smaller body and it's easier to practice this because this is the first time we've tried to do this as a community in any form. So it was easier to say, okay, you know, we're going to herd 13 cats in a room and try to get something to move forward with. And then if this goes well, we can learn from the things we didn't do as well during this process and maybe iterate and in the future write a whole vision for OpenStack with the entire community. I think that would be great. It also helps with being strategically sound because there is only so much the technical community can actually influence. And so like a broad vision for OpenStack would for coming from the TC members would not necessarily be strategically sound because we need more stakeholders to buy in like all the organizations that back the OpenStack development to actually share those goals with you in order for them to happen. That's a lot of cats to herd. So maybe next time. So on to how it was made. We all met in Boston a couple of months ago in a room. It was the day after the TC and the board had some meetings together and they also did a strategy session together. And the sort of third day of that was, maybe the second day I forget, was all of the TC in a room with some outside facilitators and myself sort of helping people come together write about what they really, really saw as this positive future. We had a lot of writing on paper and then posting on walls and voting on things and to consolidate ideas. And then we each took turns with etherpads writing the pros out in an etherpad for a specific section and then switched teams and Dean was actually just saying that he has all the etherpads still up in his browser and it's pretty nuts. So we tried to use as many sort of passes through by every single person in the room to edit and rephrase and rework this. After that day, some members of the TC volunteered to kind of put everything together, do some final grammatical editing and figuring everything out and then we decided to push it to Garrett for review. So it's currently up for review in the governance repository and I also sent out a survey which if you're a member of the foundation you should have gotten in your email inbox that basically is a link to the text of the vision itself and asked three questions. What do you like about this vision? What is, what needs to be changed about this vision and then what's missing from this vision? And that survey closed just a couple days ago right before we got here because this was our sort of third plan for feedback intake from you all in this room today. So those results are actually, I emailed the dev list. I've published all the results in just a sort of little CSV sheet, Google spreadsheet thing. So you can go in and read them at will. They're very interesting. And yeah, and so this will be the final point that we'll be taking feedback and then we're sort of starting to push a discuss a plan with everyone on how we're going to incorporate that feedback into a final draft and then put that out for review with the community. Any other comments that we need to cover on the process? Was it fun? It's an interesting exercise. I mean honestly that that, I think is like the time to step back and think about like what do we want to do in 2019 and realize that a whole like an awful lot of the TC members all had a very similar vision that the overlap was huge. We probably didn't actually have the same language for all the things we were talking about. We now do. So we now sort of like talking the same word when we mean that thing in the future that we're all worried about. And there's a whole load of things that I hadn't considered that some other people had said and it's like actually, no, this is like super important. We really need to make progress on this. And I think lots of other people had exactly the same thing. You know, there's like all these different bits of the jigsaw and coming together and having that discussion like in itself was super useful. And now we can start to like share that and like get feedback on the wider community. It's been like fantastic for me. Now for the vision. So we thought that we could read you the vision to be totally honest. We haven't timed it in like a sane way reading it aloud. And we want to make sure that we have a lot of time for your feedback. But it seemed when I asked for a show of hands of who had read the vision, it didn't seem like many people in here had. So it's probably a useful or you should ask who didn't read it, who okay, who didn't read the vision, who has not read the vision at all. So I think that it's probably useful at this point for us to read it, right? We will try to make it snappy. All right, you guys want to start? Sure. 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? We have finally released our fourth consideration for OpenStack available at 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, a purchase 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 deployment completes the picture. Many of the deployment tools are now providing high-level macros to install specific constellation, which gives users a great way to see different configurations of OpenStack without getting lost. Constellations have become the new standard way to start exploring OpenStack. For more advanced users, the project navigator helps connect the dots from the constellations into which the projects 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, well, have definitely reported by 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 working adjacent communities or were not consistent with the OpenStack mission. Other projects were refactored to clearly define their scope as they were placed on the map. While the constellation view has helped understand some pre-built patterns within OpenStack that are successful, it has also demonstrated that there are 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 different 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 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 integrate Keystone into projects written in Go, Node.js 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. 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 those 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 an OpenStack solution. In addition, we have also been able to share some of the hard-learn 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 go. The five-ten groups we have formed close partnership with are continuously asked for feedback to ensure their satisfaction with our partnership. Our partnerships focus on this quality of partnership rather than the 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 commuters within these other communities. 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, et cetera. 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 a 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 meet continuous integration, mirroring needs, and works to expand available resources as well as ensure that there is no undue impact on limited resources. No, we're reading because it's a long, long, long. It's very long. Sorry. That's the end now for the vision part. No one said bingo yet, right? Yeah. We did say synergy. So you'd be forgiven for cringing. Reaching out to so many other communities and sharing lessons between us really confirmed for all of us how critical diversity is 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 a 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. 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 the near term needs of operators in the field. It has also brought back much more sympathy to the needs of part-time contributors who can't complete a perfect patch in order to get it accepted. A small organic team of shepherds has been taking the drive by contributions and working them into the system, either by taking over the patches or by applying follow on changes. The new bot that converts get or pull requests to get change sets instead of just discarding them imported several patches in each of the last three months. 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 assisting with many of the TC initiated efforts. The TC now looks much more like our contributor base. The TC membership now includes several women and representatives from APAC in 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 efforts underway. There is the new OpenStack ladder program inspired by the Drupal ladder program and it is aimed to bring more traditional users and operators into the contributor space and ensure that they don't feel overwhelmed getting their first patch in. For members of the community that are already engaged, we have built into our ladder program a specific mentoring program around interproject 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 percent 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 a whole as well. With more community members having success in interproject work it is now common place for pop-up teams to form around this kind of efforts often led 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 operators communities are often a part of these pop-up 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 interproject teams has come from the improved feedback group between user operators and developers. Indeed this feedback coupled with the increase in diversity in contributions makes it hard to distinguish between users operators and developers. One visible success story has been the T-secured top 10 hit list. It has been brought, it has brought renewed focus on some of the problems we need to go after in the near term. It is now common place 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. When TC members and other community leaders started talking, taking deep dives into projects they don't normally contribute to there was a ton of enlightenment. Old prejudice took a back seat as we walked a mile in each other's shoes. This new understanding is is part of why hierarchical quotas are now implemented in work 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 and adjacent communities to have supported this 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 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 in 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 the 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 not just OpenStack but Open Source as a whole and that is something we can all be proud of. So there were some themes that we touched on and those themes that we started with broke down into different sections of that vision. So we just wanted to go over some of them since that was a long read before we take your questions. The first one is constellations. Fancy or nicer word than reference architecture? What else do we want to say about constellations really quickly? I think one of the aspects of the constellation is that it also has like a mapping component in it, so like visual component and I think that's one thing that's been missing with all the work that's been done on use cases and reference architectures in the past. It's this idea that it's a combination of several things that get together visually with things that are optional, things that are like alternate solutions, but more of a use case-centric view of OpenStack. Traditionally we talk about OpenStack as this group of projects, whereas we're now talking about these projects that are working together as more sort of clear linkage and view of the bigger picture. All right, and OpenStack projects and services standing on their own? Yeah, we've already seen like during the keynotes on Tuesday some example of that. I think we're getting to realize that some of the things we have developing up and stack are useful outside of OpenStack for other communities and they don't really have the need to reinvent things that we already did produce for them. So like shared block storage, driver system or networking, shared networking systems are potentially useful for other types of open infrastructure and we need to make sure that those projects can be consumed easily just to avoid reinventing the wheels in multiple communities. Which ties in nicely to our adjacent community outreach that we talked about in there too, right? Do you want to say something quickly about that? No, that's good. User-operator contribution growth, there are a lot of numbers in there about what we expect both from users and operators participating more and in terms of their presence on the TC even. And then that TC diversity reflecting an actual contributor base. Mentoring program and ladders were mentioned. Increasing cross-project contributors was a huge theme towards the end and now we want to know what you think. And we'd like to invite you to the microphones. Yes, you can shout at us but you have to shout at us through a microphone. You can also sing if you really really want to. But yeah, your choice. Are you going to add anything more to your adjacent communities which are the high priority once you are looking at what are the areas you are trying to have collaboration with them? One of the things I am very interested in is the new on-app community which for the telco perspective is going to be working very closely with OpenStack all the time. There are opportunities for driving collaboration with them on the testing side. Maybe making all their tests into tempest plugins. So which are the adjacent communities you are actively working with? What are all the areas that you are driving alignment with them? Are the things I would like to hear a little bit more about? What are your plans for 2019? From an adjacent community perspective we started to see efforts to like invite other communities to come to the summit for example. Like we have open source days this week and it's proven very useful for cross-community collaboration. Like last night we were at the dinner with people from the communities community interested in sharing governance and release management practices and I think that that's the type of thing we need to get going. We need to be more actively reaching out to those communities, establish relationships and get to know those people personally because otherwise it's just like technology versus technology and as geeks we hate someone else's technology obviously. But once people realize that it's made of people you can like bumble around parties and beers and it's all that collaboration comes naturally once you get personal. Do you think that the types of communities that you all choose to be more involved with will be kind of an organic growth thing or do you think it'll be also planned in the sense that you know they might relate to the specific constellation or something like that? Yeah I think we need to be careful on the vision is meant to like empower the work we're doing and give us direction. Like we don't have to get all of these things written down. Like I don't want to write a list of communities down we should talk to because there may be a new community that gets created tomorrow that's more important than all the other ones that exist today. That probably won't happen but you know it could. And so I don't think we want to exclude with a vision we want to just say it's really important as OpenStack. Like we're aware of our ecosystem we support and work together. You know we have to go to other people's you know events and understand what they're doing you know and vice versa. It's great. I don't think we should exclude any particular community at this point in time. I don't think we really actively exclude. I mean we've been looking at adjacent communities for a long time. What the vision helps with is prioritizing it because it's always like you have plenty of work to do within your community. And reaching out to adjacent communities is like takes the second seat. And what the vision helps us is like oh this is actually important and I need to take that step back. I need to take the time to go to those events organized by other communities and reach out to them. Slightly different topic but what's your point of view on like other open source methods of gaining traction like bug bounty programs or a feature reward type things. So corporations that are looking to get involved need additional help and they have funds to you know reward people for contributing to their projects. So my take on it is that the kind of artwork in a number of open source projects not necessarily the ones that have a high on-ramp thinking like video land client. Yeah it's easy to get like a bug fixed in WordPress because a lot of people are using that code or familiar with it so when you when you start a bug bounty program you can have like a student fixing it and it would grab it. In the case of open stack the on-ramp is slightly more significant so the investment you get that bug fixed if you go out of nowhere is more significant and so I'm not sure that would work as much. I also think it's a unique way of looking at a contribution that hasn't really been the typical contributor case and so far right and who know I mean one of the things that seemed really apparent in the room when this vision was written is the awareness that the community is is is sort of slowing down its growth right and so it could be that as we move forward the types of contributors that we see will be more motivated by something like that but I don't since it's always been basically people who are full-time paid to work on open stack whether that's from an operator perspective or that's a hard thing to make a case for I think. The part of your question I think that resonates with something I've been thinking about all week is there's lots of rooms with uh in the forum it's been great having the developers and lots of different operators all working together and understanding like the common needs like I think a lot of what we're doing right now that's improving things is like all these five people have exactly the same problem and have been sitting in their own silos worrying about it now we've got together and like working on it we're starting to make progress like if if it turns out you know I think the the interesting question is is how do you get people to work on that I'm sure there's different ways we can do that but it's like it's getting the right people with the right problems with the right priorities I think that's super important how we do that you know we need to work this out I think like bug bounties type programs are like plan B when the natural economics and open collaboration fails and so I would I would start considering it when when like all the other options are gone because I like to see a healthy ecosystem where where people that are actually making money using the software end up contributing back and and and like a natural link but I can see where you know do you have that need and it's spread out across a lot of organizations and nobody we know classic tragedy of commons scenario and nobody is actually doing that full-time equivalent person that will actually get it done so it's it's a bit of an up and question but I still think we need to prioritize getting more of the market economics around open collaboration to try to work in there just to follow up on that I've I've not seen a lot of good success stories for tactical incentive in I mean free software projects are generally written by those who use it and have a need to solve some particular problem in the case of open stack due to the level of complexity it's not something that that one person generally runs companies tend to have teams that run the software and so companies are are voluntarily contributing funds and developers to solve the problems that they encounter so there is an incentive on the part of of the donating companies in that situation to solve these problems in smaller community projects you often see the individual users again have an incentive to solve a particular problem but the motivation is it on the the solution level is hardly ever you know financial direct financial incentive to the contributor yeah I think one of the items you had was on a diversity of like a TC members I mean is that the reasoning behind it is that it's to get different points of view or is it for in general developer growth I think it's both the what we realized with more diversity is that we get a broader set of views and and broader representation of the needs of the users but also it's also about growing new leaders in in in specific geographies like how do you how do you get to to build the next leaders in your community if you're excluding with IRC meetings on on on US time zones a wall a wall continent of contributors it's just not working for us especially as as we've we're seeing explosive growth in in country like China if we're completely making making it very difficult for contributors in that area to reach that level where they can be self-sustaining in in in getting new contributors on boarded and and have it needs to be leaders we need to grow those leaders in those areas so that so that we bootstrap that virtual circle of of good strategic contributions coming from those areas yeah I know definitely plus one all of that that my personal perspective is you know I I think back like I've been in some ways forced but I thinking back like what do I love about working on OpenStack and I think I love not working in an echo chamber I love being told that I'm barking up completely the wrong tree with this idea it's fantastic it's better than like spending a month on something that's pointless and so I like I see the diversity of opinion is really important and I think we have to have that throughout the whole community at all levels like it's you know like and it even even like at the meta problems like does our process like in our the way we're working exclude people from like different cultures and different backgrounds is that a problem like how do we and you can see this been some great talks this week about people from different cultures getting together and saying look this is how we found that we can be productive in this community and like share those ideas like all that stuff's fantastic and we just need to keep like driving you know driving that forward and I don't think like diversity is a funny word I think there's lots of axes on that right it's not just like on the globe it's not just the people it's you know it's the different perspectives and all those things I think it's that that's sort of all the problems coming together and you seeing the full picture I love that and we need you know let's just keep that growing and I think there's something important there especially around the the leadership mirroring the content of contributors right as a woman like it's really it can be incredibly frustrating to be a part of a community and see no women in any leadership positions and wonder well how would I ever get like why would I want to try because it seems like it's not possible right and I can't imagine like I'm sure that's the same for many different types of people so that having that reflection only means that you can increase diversity and have a lot of really great contributors in the future absolutely I think actually even taking it a little bit beyond that the the the leadership needs to needs to lead the way somewhat in increasing diversity because we can serve as an example to the community to help get a more diverse involvement in the project in the first place and also as an example to other communities who who may be looking to us for you know ways that they can improve their contributor base and their leadership and it's not really an easy challenge you know it's not as if any community was really successful at being at operating all over the globe and collaborating there so it's a it's an interesting challenge to try to to to crack and that's why we're looking into trying to limit our reliance on our on on synchronous meetings so on our sea because that's always excluding somewhere and somewhere and and we we should definitely work we started removing the meetings for the stewardship working group who are looking into how we can evolve the technical committee meetings in a way that makes it less reliant on on being present at a given time of the day because that's what we need to do at in every up at stack team if you want to be very inclusive all those contributors so perfect thank you so the like I read the the mission and compared that with the idea of having that towards 2019 it read to me as a little bit of the factual statement of where we are 2017 so we are seeing the constellations of the projects which are working together well we've seen that things are projects are used separately we begin to work with a just in community here so this is more of the statement of the present can I ask you to somehow project that to 2019 and say in 2019 how is that going to be different so I see where you're getting and part of it is because we've been starting to address those problems I just think it's a question of priority I don't think we did a great job so far at including contributors from China for example and we we need to take active steps and if we just say like like it's always priority two and we'll get to it that just never gets done it's not as if those problems we discovered them during that workshop in Boston two months ago it's like there's been lingering problems that have been always in the background and what the vision helps us with is is really taking that step back realizing that those are the problems we really need to solve rather than the immediate problems that that we have on day to day and so it's it's more of a tool it's not like plenty of new things that will change over the next two years to me it's it's it's a tool we can collectively use to prioritize those important things above the urgent things yeah I was supposed to the quick time oh yeah it's 1140 so I just wanted to okay but I we totally want to talk more and you should feel free to come up to all of us you should also feel free to go look in the governance repository and comment and Garrett the survey is now closed but you can also just IRC chat feedback to me if you want seriously like send me a Twitter DM and tell me what you think of everything like that's totally acceptable I will put it in the feedback because we need to hear from everyone while we do this next round of revisions and yeah thank you so much everyone for coming we did not expect so many people yay thank you