 I'm recording now. Please, Mark. Let's start. OK, good morning. Welcome to Austin. It's the first time slot. So yeah, we get to kick this summit off, I guess. So Alexia and I are here to talk about contributing to the success of OpenStack. And here's our pictures in case you don't know what we look like. So I'm Mark. I'm an engineering director for OpenStack at Red Hat. I've been an open source developer for 15 years. So I'm here more on the kind of open source developer side of things. Yeah, so I am here to represent the work that we are doing to improve our organization. And I'm a longtime agile contributor. And we will speak a little bit more about this. First, we will start with I will have some trouble to get used to the clicker. That's interesting. Yes, the clicker is really awful. Just use the arrows, I think. I just want to stop this. If you are looking at the video, you can see that it was live. And I would like to have the speaker nods. We don't need the speaker nods. We need the speaker nods. That's interesting. We lose the speaker nods there, OK? Sorry for that. There we go. It will be really OK. As you can see, it's all working perfectly well. I can go back to my nice picture about introducing the raising hands survey. So it's the time you will be able to participate a little bit. Yes, you can. You can try now. You haven't heard the question yet. The first question was, OK, who ever contributes to the OpenStack project? Thank you. Who ever contributed to an open source project before OpenStack? So you can see in the room, there's some long time contributors there. Who is there because they are working for a company and this company wants them to contribute to OpenStack? So there's not so much contributors on their spare time there. OK, it's more you are there because the company you are working with wants you to contribute to OpenStack. Or maybe it's the other way. You want to contribute to OpenStack and you'll find a company that wants you to do it. It could work either way. Who ever worked in an agile environment? That's great. We added one more question there. What was my question? Oh, yes. Was it a good experience? And actually, I'd asked that to both. Was it a good experience on the open source side and was it a good experience on the agile side? So who found working on the open source projects in the past a good experience? Oh, that's good. And how about agile projects or agile teams? That's great. Yeah, good. Everybody's had one. Everybody's happy today. That's really good. OK, so agile is this. If you think agile is really do several things at the same time and doing whatever you want, whenever you want, changing always what you are doing, it's not necessarily that. It's a set of principles. And the collaboration is one thing that is really important there. And it's really the collaboration between people, between individuals to achieve a greater purpose. It's probably something that some people have some troubles to understand. But it's really that. And I'm sure you know that. And I think the interesting thing about open source, when you look at it, again, we've got Wikipedia definition here again. But I think also you should be thinking about what open source is in terms of a set of abstract ideas and principles, just like agile is. And if you look at these two paragraphs, the first paragraph emphasizes a license. So if you've got an open source license, you're doing open source. But the second part emphasizes more of the kind of collaboration and transparency and self-organization. And that's if you're doing effective open source, right? That's if you really, really get open source. So it's not just enough to check some boxes off when you're doing open source. And I think that's the same for agile. And obviously, there's also people that have some trouble to understand this. But it can be OK. And if we look at both things, we are working in communities. We are working on agile and open source. And there's a lot of things that we are doing that are nearly the same. Obviously, there are things that are really different. But there are things that are nearly the same. And if you speak to an agile contributor that is not doing open source, you will speak about a lot of things that are on this diagram. And the opposite is also true, of course. And so I think what we're trying to show here is if you think about all of the really abstract ideas behind open source and agile, there's a lot of overlap here. And maybe agile emphasizes some things. Open source emphasizes some other things. But there's an awful lot in common here. OK. So yes, so in the open source sense, I guess we talk an awful lot about community and building communities and diverse communities as the way of really achieving a better way of developing software. The key thing for me, I think, about an effective community, really strong trust-based relationships within the community between individuals. That's interesting, because I would have said exactly the same if I look at a team, several teams that are working together in an agile environment, saying that really it's the trust between individuals that is the key foundation of all this. Definitely the same thing. And if we look at the work that we are doing, but maybe you don't, you want to know what is it? It's a hat. Shapo. It's really a great drawing. You can see my drawing talents are really high. You can see that it's a hat, because you can wear it on your really happy face, as you are all really happy. Nice thing. And if we are speaking about hats there. Yeah. Basically, hats is the way I've already approached my work in the open source community. So it's, yes, you're employed by a company. In one sense, you wear what I think of as your corporate hat. I work for a company that wears red hats, but that's another matter altogether. That's not why we use the term. But you also sometimes have to think about wearing your community hat. I think it was the Apache project first kind of came up with this idea of thinking. And the idea is, you need to switch contexts how you think about problems sometimes. So if you're approaching a project in the upstream community or wearing your upstream hat, but sometimes you also need to think about what your red hat hat on or your corporate hat. So that's why some people are speaking about balancing their community or corporate commitments, or balancing their upstream or downstream responsibilities. And this can be even thought about in terms of balancing say work that's kind of directly driven by very immediate interests versus kind of the upstream might be more about your upstream responsibilities more about might be about the long term sustainability of the project, for example. So there's all sorts of balances going on here. This is probably the things that we are arguing about the most between Mark and I. Because when I look at how the team, a successful team, is working, I say, OK, the successful team is taking some ideas and build a product based on the idea. And it's the collaboration between those individuals that creates what we need. But it's not only that. It's also the idea that what we are building is needs to satisfy someone. So we want to have this feedback loop. We want to know what the users are thinking about using our product. And we want to have this feedback loop as soon as possible. And that's why we are trying to find some loops, the shortest loops that we can, to have this feedback. One thing that Alexi, one insight Alexi had as we were talking through this was if you think about many open source projects, and I've been working on many open source projects, a lot of them we talk about scratching in each, right? That's how you start a project, right? So you're the user, then you understand the needs of the user because you represent the user. And achieving that direct feedback loop with the user is a little bit more easy. In the context of something like OpenStack, I think many of us aren't necessarily scratching an itch. We're not necessarily working on software that we use day to day ourselves. And so how do we establish a real connection between the developers working on the project and the people who are really using it? And the cool thing is if we look at who are the users, they are probably users, internal users of companies that are contributing to OpenStack, or customers of those companies, partners of those companies. So we can say that when we are wearing our corporate hat, we are in a way proxy for the users of the software. So it's quite cool thing to bring on the table for the community. Yeah, and if you just came from the keynote hole this morning, you saw many kind of users represented up there, like I don't know, Volkswagen and AT&T and Betfair. Many of these companies are attempting to contribute to the project in various different ways. But for the vast majority, kind of their interests and their needs and their requirements are being represented by companies that they have a kind of vendor-customer relationship with. And it's the employees of those companies who are then kind of acting as proxies for the requirements of those end users. And where my community at, I can challenge those users that are coming to, with their ideas of how to use the software and think, okay, but you want to do this, but it's not necessarily the good way of doing it. Or maybe you are trying to use a product that is not really the good product to do what you are trying to achieve. Or maybe I can say, wow, that's an interesting idea. I didn't see the things like that and I didn't think that users can have those kind of troubles. Well, that's interesting. And so this idea is to try to reconcile those two ads. And maybe you can speak about a concrete example around that. Yeah, absolutely. I mean, there's three, I've always had this very, very strong sense of wearing those two different hats. So when I'm wearing my community at, I'm really trying to build that close relationship based on trust with my peers within the community. Like that's the team that I'm thinking about being a part of. But I'm also conscious that I'm working for a company, I'm trying to represent the needs of those users. I'm understanding where those users are coming from. And I'm trying to reconcile those two views in a way that works for both the community and works for both the company I'm working for. And genuinely works for both. You're not trying to compromise your commitment to the community and you're also not trying to compromise kind of what your company is doing. In the context of NOVA and NFE, we had many customers coming to talk to us about requirements that they had for how to do NFE, how to transform telcos with OpenStack. And initially I thought, this has nothing to do with OpenStack. Go away, use a different product. The more I understood though, the more I talked to them, the more I realized that they were really trying to do Elastic Cloud, but they had some really interesting requirements around deterministic performance and such things. And as you start really understanding those requirements, you understand the way that they could be implemented in OpenStack in a way that actually makes sense for OpenStack too. So like high performance flavors are tagging devices with labels and all this kind of stuff. Really cool features generically for OpenStack, but satisfies the use of this use case. And so I think Red Hat developers wearing both of those hats, trying to represent those two views actually came up with some really really nice solutions for Nova that made sense for both for the project and for these users that are trying to use OpenStack. So probably when the community, when the people inside the community are really supportive of your ideas, you are bringing a new idea and it's definitely something that will help your internal users, your customers or your partners and you are bringing this on the table and the others are really supportive. You can say, okay, all is doing really well, but sometimes they are really hostile. You can say, okay, that's all. How can I say that? Maybe they are not doing good in the community. They are not supporting my ideas. It's the others that have the problem, right? Or maybe it's the opposite. Maybe I'm not doing the thing in the good way. So it's a strong signal that I'm not doing the thing in the right way, I think. So we need to use that because we can refine what our internal users, what our customers, what our partners want. See, using all the knowledge of all the community. And if we speak about this at the beginning of the cycle in the ideas generation, it's something that it's the same process, the same benefits all along the cycle even for the implementation of something or at the end for the use of a feature or something like that. And that's why the diversity factor is so important. Yeah, absolutely. I mean, if you think back to what I talked about there in terms of effective open source, right? It's a community based on diverse views, diverse interests and it's that diversity of people trying to achieve different things and trying to figure out a way of making that all work together. That's really where a lot of the value of OpenStack comes from. And that's why in the, I forgot what we call this, what we call this thing. In maturity. No, the website. It's a project explorer or something like that. I don't remember how it's called. Anyway, it's representing the maturity and adoption rate and various aspects of the OpenStack projects. But one of the key parts that it's representing in the maturity is just how diverse the community behind the project is. Because we really see that that's important to the project in terms of its ability to kind of develop great software but also the longevity of the software. Is that this software going to be around for a long term? And if there's lots of diverse interests involved then there's a better chance. Thank you. So all we need to do is to see those ads as one ad we need to wear and to reconcile those two ads in a way that will bring values to the community and will bring values to the company and their users so we can benefit of both. Certainly. I just thought of one word as you were talking about hostility there. I thought about empathy, right? When you have to reconcile these two hats and you're getting, say, negative feedback from the community, you really need to put on your upstream hat and really try and understand where that negative feedback is coming from. You can't just wear your corporate hat and go, these guys are getting in my way, stop getting my way. There's often good reasons for that negative feedback and in the case of Nova and NFE, the feedback was actually, why are you guys adding all of these crazy new features when we actually just need to make Nova work? We need to improve the core functionality of the software before adding new features. And to a large extent that was actually very good feedback and I guess the way of reconciling those two views are we need to do both, right? We need to be working on improving Nova core functionality but let's also figure out how to add these new features. Okay, and all is happening in one really flow, one information on workflow that is really smooth as you all know as contributors. Okay. Yeah, there's some people that are really saying, yes, yes, it's working well. It's really a flow that is really working well. If you look at when you are working and there's one company you have your nice ads, you have IDs, you are working with a team and you are building great products and it's really nice and it's really working well. It's really simple to handle this information on workflow and when you are working with others, it's really this friendly thing that will bring the best IDs and build great products. That's really, really nice. But is it really? When I see some companies and we are struggling with this sometimes within our company and they are trying to organize the work of the teams that are working internally and those teams are working in a larger big team like the OpenStack project and it's two information on workflow that we are trying to assemble together. And it's not necessarily easy and some people are really in between two things are trying to say, okay, I will wear my community hat and that's the only hat I will wear and some others are trying to do both but are really struggling and some others are saying, okay, so I will wear my corporate hat and that's all. And each time we are not able to reconcile those two, we are losing some value somewhere. So how can we improve that? And it's really, I really like this picture because for a lot of my career today, I have to admit my focus has been more on creating that effective sense of that team in the middle there. So if you imagine that's an upstream project making that a really efficient, diverse project that's really kicking ass and stuff and the more corporate teams involved, the better. But if you're looking at this from the perspective then of trying to build really, really strong teams within a company that can really be an effective part of that upstream team but also have a really good sense internally of a team too, it's a struggle trying to create two different concepts of teams that are both working well and people being a part of both of those teams. And you can see that we are not alone to have those kind of problems. People who are working on Storyboard are trying to foster cross-project collaboration and are trying to give people a view of the several projects to solve one business problems for example and people that are working in the product working group are trying to do nearly the same thing. So we are not alone to have this kind of problem. So what we are trying to achieve internally is to give the possibility of people to focus on one set of business problems. Yeah and I guess it goes back to that picture of teams again. I think what we found when we emphasised more kind of the notion of being a member of the upstream team and kind of building teams that were really built around emphasising that, we kind of struggled to build this notion of really owning and having close relationship with users and having ownership of the end-to-end delivery of users' needs. So getting a patch merged in over for example doesn't solve everything to do with a particular user need. There's a whole bunch of steps that need to happen afterwards and how do we really emphasise that notion? Maybe we can speak about building those focus teams. We will need to think about the way we will be able to collaborate with those people that will work on different technology. It will be cross-technology teams and we will need to reconsider the way the technology is working for example with those ideas about splitting the stacks or the composable world thing to help those teams to be independent enough to be able to focus on one set of business problems. Maybe to make this concrete again to go back to say my Nova example where we've added some features to Nova that allows you to create say high performance flavours in a cloud and for those high performance flavours to be used to run what we call VNF's virtual network functions. So we've landed that code in Nova but how, when one of our customers goes to take one of our products, when they go to use our product how do they actually go deploying compute nodes that can host these flavours, creating those flavours, helping users understand how to use them and it's everything from changes in our packaging, changes in our deployment tool and form a triple O heat templates, documentation, all of that all the way through and what we want to create in our compute team, the team that's really focused on these kind of use cases is not just let's get this patch merged into Nova but how do we really make sure that customers really see the value of that? So how do we tackle the problem end to end? And one of the cases for that, I mentioned triple O heat templates there for example. Right now triple O heat templates is like one big playbook for how to deploy OpenStack and it's maintained by our triple O team and what we're trying to do is create the sense that actually our compute team can have complete ownership of their part of those triple O heat templates. So that's why the team is splitting apart these triple O heat templates to kind of create more kind of independence amongst our teams at Red Hat for kind of delivering functionality to users. So you already speak about that? I did. Yeah. Jump the gun. Sorry. No, no, but it's really great. I thought when we speak about that, you were speaking about back in the day the open source project. Yes, so I've just talked about triple O heat templates and as we were thinking through this, we thought about the example that back in the day with open source projects maybe 15 years ago where projects were typically deployed on one machine, it was really operators that took control of making it easier to install software and machines by creating packages. But as things evolved over the time, at least internally at Red Hat, the teams that were working on the code also took responsibility for the packaging of the software, how to install the software. And we're trying to take that step a little bit further to this distributed system now to these teams being responsible for the code, for the packaging of the code, but also how the code gets deployed to really create that sense of ownership. Unupgraded. Yes. So what we want to achieve with these ideas of focus teams, it's a focus team internally inside Red Hat. So we are able to give this clarity and to bring this clarity to the OpenStack project to say, okay, we are trying in the next cycle to solve these kind of business problems in those focus areas. So we will be able to say, okay, we want to achieve that. And it will involve a lot of cross-project collaboration. And if people can see that they have the same kind of business problems that we have, we can join our effort on this. And they can also bring those kind of clarity of what kind of business problems they are trying to solve. And also have done, foster these cross-project collaborations that we need now to have. Or to think of it another way, maybe inside Red Hat we're thinking of our teams now more like agile teams where the team is kind of self-sufficient in terms of has all the skills it needs to deliver a certain set of functionality, including a product owner who understands users' needs. So that's our teams at Red Hat. But there's also the challenge of upstream. How do we create teams upstream that either do cross-project collaboration and have that clarity of focus and understand the problems they're trying to solve are kind of similarly focused teams within a bigger kind of project. And these are kind of challenges that are, they've been long-term challenges in the OpenStack project. And I think it's going to be really interesting for us to tackle the notion of our internal teams and that clarity of focus, but also a better sense of focused teams upstream. And I think you have summed up the world ID. Yes. So for me, 15 years doing open source, I've always really used this notion of two hats and trying to reconcile the view of two hats to really help me be effective in my work. I think Alexi is now opening me to the real value of agile being around clarity of what the team is doing and the value it's delivering to its users and how we're going to bring that to teams working on this open source project, I guess. Thank you. That's all that. Thank you very much. Thank you. Thank you. That was us. And we have time for questions. And it was, thank you. And yes, we have time for questions. We didn't plan to have someone in the audience to ask the first question. Dave Neary is always good for a question. Thank you, Dave. You need to go to the mic because I'm not able to repeat your question. I don't speak English, as you know. I can speak English with a French accent. Very good, very good. So how do you avoid a tragedy in the comments when people are wearing community and company hats? How do you avoid, I mean, different companies are going to have different interests when they align around a community. How do you avoid those competing interests and polluting and poisoning the pool? That's a really good point. What we've said is when you have competing needs or competing interests inside a community, I think it's bringing some value to the community and it's also bringing values to the company. And I think if you are not able to negotiate on what you really need as a company, if you are not able to see that if the rest of the community is really hostile to what you are bringing, there's some reason behind it. So you need to reconsider what you are bringing. So you need to be able to negotiate and to be able to reconsider what you are bringing. And I think it works both ways. For me, the tragedy of the comments with open source projects is where, yes, you have all of these interests coming into the project, but there's this notion of kind of, really critical interest of the project that isn't a high priority for anyone, right? Like if you put on your community hat, it's really, really high priority for your community hat, but no one when they put it on their corporate hat really thinks of it as a priority and everybody assumes someone else is going to do it. And that's a real challenge and that's why I really take this notion of a community hat seriously for developers at Red Hat because it's easy for us to miss those things that are really important to the project. It's easy for us to not prioritize those kind of things when we take a look at features that are important to their customers, but that kind of stuff is really, really critically important to the long-term sustainability of the project. And to give an example of that, when I started working on OpenStack, I think that one of the things that I identified as a problem for the long-term success of OpenStack was all of these projects basically copying and pasting each other's code, not sharing code for simple things like configuration files and stuff like that. So I started the Oslo project. That wasn't a business priority of Red Hat, right? There's no product manager coming along and saying it's really important to customer X, Y and Z to do this, but we understood that it was important to the long-term success of the project. But that's what our community hat on, but able to influence people at Red Hat to ensure that that got prioritized. So it's a real challenge, but we have to figure out our way to it. Yes, please. Oh, yes. We want to have a recording of your voice. So I guess the question would be, what would you do to model this in a project that's largely driven by one company? Like, you know, I think the, you know, I think what you've portrayed up here is upstream communities that have like, you know, diverse stakeholders, but how can things go wrong when it's largely one company? I think when a project has not yet achieved the corporate diversity, it's one of the maturity metrics of the OpenStack community. It means that there's a problem there because it's not attracting other users from other companies or customers of this company and so on. So it can be, the root cause of this could be really a lot of different places, but there's probably a strong signal there to listen, to understand why, and to really conduct this analysis of why it's happening. Yeah, for me, it's a... I know it's the problem for us. For me, the metric of corporate diversity is a nice shortcut to thinking about this, right? But you can have a project that is dominated by one company, but diversity of interest and like the project to be self-governing and really open and really transparent and really, you know, that is easy for anyone to come along. So Dan was the triple OPTL in the last cycle and this is where his question is coming from. The majority of people working on triple O are Red Hat developers with contributions from various partners that are integrating technologies in and other users, but we have created the project in such a way that it's not just one team at Red Hat working on this project. It's a variety of teams. We're welcoming that diversity of interest even within Red Hat to the project, but also externally and we're setting up the structure and the governance of the project to ensure that it really is an open project that anyone can collaborate to. So, you know, it doesn't look great from the diversity, the corporate diversity metric point of view, but we still value diversity of interest within the project and setting up the project to enable that kind of diversity to happen. Okay. So, one more question. So, do you have any problem that you have been struggling to solve for a long time but haven't been able to solve successfully to your satisfaction, something that you can talk about? Personally or? No. Anything related to what you just talked about? My mind is on triple O because Dan just talked about triple O. We're trying to solve the problem of deploying OpenStack, right? But beyond just deploying OpenStack, deploying OpenStack with many different deployment scenarios. So, you know, all the various different ways you can deploy OpenStack, all the various different technologies you can deploy. We're trying to solve for a lot of different use cases people who are deploying a small POC cloud to people who are deploying a massive big kind of customized cloud. It's a real challenge and I think it's a challenge that we're trying to tackle in the triple O project but I think it's a challenge that is something that the OpenStack project has an opportunity to collaborate on more to solve together as opposed to individual companies trying to solve it on their own. So the reason we created the triple O project in this way was to try and generate more collaboration upstream around something that's holding OpenStack back I guess and there's a real opportunity to collaborate there. So the problem that I think we've been trying to solve for a while is how to create more collaboration within the OpenStack project around how OpenStack should be deployed and build more consensus around what OpenStack should look like in real life, not in DevStack but in real life and how it will collaborate on some consensus for what that looks like. If you think about the installation of a feature or the upgrade of a feature when the cloud is really running I think it's some problems that we share with others in the OpenStack community. Something else? It's now. Okay then. Okay, so thank you very much and if you have some feedbacks you can use Twitter or you can use our emails or you can use... We will be there all the week so please give us some feedback it's really important and valuable so we can contribute together to all that. And where is your next talk? In Ballroom C on the first level and yes I need to go now. In 10 minutes, right? Thank you everyone. Thank you very much.