 So, Def Core as of today has really reached a critical milestone. Over the last two years we've been working on putting a process in place that lets us create an interoperability standard to tell people what is OpenStack and what is not. It's a vendor statement. So if somebody says I am an OpenStack vendor, we actually have a way to say yes you are or no you're not. So it's interesting. OpenStack has really grown in a lot of different dimensions, right? We've gained a lot of contributors, we've gained a lot of companies. We've gained a lot of users. And one of the things that really has been happening and is important to happen is OpenStack is growing in the user base faster than it's growing in the developer base. We love to talk about developers. We like to highlight users. So a lot of those new people are users of OpenStack, which makes me excited. So Def Core is OpenStack's contract to those users. And what I would tell them is Def Core means you can count on us to be stable, reliable, when you build things with OpenStack, those APIs are going to work, the vendors that you count on, you can substitute them, you can go from one public cloud to another, you can have a private cloud implementation that works, that we care about making that happen. And Def Core is really a commercial statement. And one of the things that people found confusing was that when we would talk about Def Core, they would assume we were talking about the code base, right? And we're going through this big tent process right now where we're making it much easier to be an OpenStack project. In some ways that's innovative, it's exciting, there's a whole bunch of new ideas coming into the project. That's also, from users' perspective, potentially sort of scary and confusing. So Def Core is this sort of filter that lets you say, well, these projects are the ones that I can count on, I'm going to build those up, and then you can sort of pick and choose which innovative projects you want to bring in. It makes a lot of sense. But you don't have to necessarily worry about all of the projects anymore. From a vendor perspective, that gives vendors a lot of freedom, too, to say, look, I don't have to support projects that I don't think are ready for prime time. And I hear a lot about that as a board member, there's people who have concerns about the favorite dog to kick, a salometer, I hear that a lot, or neutron versus novenette. There's all this confusion about what I have to use and what I don't have to use. And so Def Core says you have to use these things. And you can, and we want you to include these other projects, but if you don't think you should, you're not going to be penalized for it. So from a user and a vendor perspective, we're really trying to give a very clear signal, and it's a lot of what Def Core is about, it's a very clear signal on what you have to have and then what you can choose and pick and add in on your own. When if you're going to have people depend on the software you write, then you have to have a contract with them that it's going to be stable in the ways they use it. And if that makes you a little bit less innovative or have to go slower in some places than you want to be, then that's the price of getting adopters and users and things like that. Def Core is really about telling people no. In the end of the day, Brad, take everything off, it's about telling people no. Which I like to say is about telling people their baby's ugly. Because a lot of what happens is you come in and you say, look, you did this project, you think it's great, you've put your blood, sweat and tears in it, right? And it's your baby and we're going to look at it and say it's not mature enough, right? It doesn't do everything we need it to do, it doesn't have the acceptance, not everybody loves your baby. And that's hard. And if you're going to do it, you have to be very objective about it. You can't just say, well, I don't like that, baby, it's not bouncy enough. You have to come back and say, you know, we only accept children over this height and they have to have this grade in school and they have to have these very objective criteria. And when you do that, then you can actually have that conversation. You can say, this is what you want to achieve, this is how we can accept your baby in. And frankly, we don't want babies in Deafcore. What we really want is adults, we don't even want adolescents, we want something stable that carries work. Babies are things you nurture and care for and you help grow and foster. And they're really important to OpenStack's future. Deafcore has been about the current what you can depend on today. And so that's, you know, the baby's ugly, it's a nice way of saying all babies are ugly. We need to find the adults to carry the workload right now and then take care of the babies to help them grow up. Your baby is ugly as a guiding principle is funny. But it's true, we had to have a very strong way to tell parents of these projects why they weren't suitable. And then the fun part was we also sat back and said, well, if we're going to tell them that, that's actually sending them a signal to how we want them to shape their projects. So we very deliberately look at what the impact of those criteria are on our communities, right? We want them to be documented, one of our factors. We want them to have good APIs and play well with others and go through this process where we're giving them a signal of this is what a Mature OpenStack project looks like. The Deafcore work surfaced out of real fighting that we were having at the board level, very circular arguments. So the way I would describe it is one person would say something and the next person down the line would disagree and then somebody would disagree with them and somebody would disagree with them and somebody would disagree with them and that last person, the first person disagreed with. And so while there was some consensus, the fact that we kept going in these circles of disagreement was a real problem and I was able to sort of listen to everybody's position and see some relevant threads in it, what we ended up calling the spider. And Alan Clark and I sat down and graphed out all these contention, all these hard to reconcile issues and we started pulling those apart and I sort of had a vision with Alan on what that would look like at the end and then we just sort of sat down and cut string by string by string to do it. You say no to people by saying yes to their ideas, talking through what the issues are and accepting the kernels of their ideas or not being defensive about what your own idea was and maybe it's good at not being defensive. I want to be core. Early OpenStack, it was all about fighting to be the core projects and the reality is being core project is sort of hard. We're about to take APIs and say you can't change these APIs for years. We're creating contracts around them and if you want to be innovative and changing and have this mentality of oh, I want OpenStack to be different every week, well, we're going to say you can't do that and so we're going to have to have people self-select into well, I'm on these stable APIs, I can't break them. Core projects are going to be a little bit slower and more sedate than the fast, innovative new projects coming in at the edges and so I'm hoping the value of being a deaf core on a deaf core project or working on deaf core has an attraction that attracts some people to that and then allows the people who want to skate over to the new projects to skate over to the new projects. So the deaf core name, Alan and I came up with that in Hong Kong for very specific reasons. You're right, it is like a punk band. Deaf core, if you look it up, yeah, it's all about loud being so close to speakers that you can't hear the music at the end of the show. That's actually the other meaning of deaf core. It was a joke for us on deaf con and so that was a very specific choice but we wanted something that we could Google and would not be, you know, core is way too hard to Google so to find core, core definition were not searchable. We needed a sign that would Google well and so from that perspective deaf core, we Google that, looked good and then it's stuck, yeah, a very deliberate decision from that and then we name each cycle. So we have a little bit of fun as we go through and we name the cycles based on sort of a theme of what's happening. The first one was Spider and then Elephant for eating the elephant scale for weighing things out. This next one's flag because we're gonna be, we sort of planted a flag but at the same time we have to talk about test flagging so yeah, there's themes. So flag for us is a process as part of deaf core where vendors can say this test doesn't work for me and there's a lot of tests that don't work. Testing, the tests that we use weren't designed for this use and so we're stretching open stack into using tests in a different way and we very deliberately allowed vendors to have a relief valve which we call flagging the test. So a test can be flagged as not usable and not required and so what happens is, and this happened very much in the first, last couple of weeks where vendors were going through the process for the first time they'd come and say, ah, wait a second, this way you test things breaks or it has dependencies that it was, and it was a great conversational, vendors were very engaged, these early vendors were very intent on passing and so there's a lot of urgency in solving these problems and so we had to flag tests, remove them from deaf core spec temporarily so that the vendors could pass. And in the process of doing that we realized, wow, this is a really serious issue. I like to say deaf core is the front lines of the interop battle because when you take a test and say, oh, this test isn't required anymore, you're really making interoperability statement. And that statement has very serious implications for open stack and for the vendors in open stack and so it's our decision about how to flag test and the process we use to flag test is really an important thing that we have to figure out in the next cycle and it's gonna be very important so we chose flag as the name of the cycle for that. I like the very, it's aggressive analogy of saying it's a battle line because I want people's attention on the fact that we're actually gonna be discussing point by point which things are in or out. So we've worked for two years to get it to the point from I think SWIFT should be in, no, I think it shouldn't, that type of fight or I think it should be APIs, I think it should be implement. We had these huge battles over existential issues. At the end of the day, those are the things you can't resolve but you can resolve while I think the NOVA API should require you to have an SSH key when you register a system and I don't and that's where we can have a very concrete decision and go back to principles and figure out what we need to be and a lot of what Defcore was doing was sort of breaking things down into these very fine grain roles but we've been very cordial and we've been able to not have a lot of fights because we're at the principles level. We're about to get down to the this test will break me if you require it, my whole cloud is not gonna pass. That's a really significant thing. There's commercial implications for that. Whole vendors could lose their certification over whether or not a test is in or test is flagged. That's a battle line, right? And we know that and I don't wanna hide just like I don't hide from the baby's ugly thing. I don't wanna hide from the fact that there's money on the line on some of these decisions about whether a test is flagged or not and we need to be prepared that people are gonna show up ready to fight for their individual tests or not and they should add tests that they think are their to their advantage. And I don't want people to think that we're not gonna have these important discussions. These are really critical discussions for OpenStack. They're important for the vendors, they're important for the users, they're important for the developers. So by saying that phrase, which is a little bit aggressive, I'm trying to call attention to the fact that we're gonna have to work those things out. My commitment here, because I'm not an OpenStack vendor, I'm not pushing anyone distro or product is to be fair and listen to what it is and come back to the principles so that people get a fair hearing on it. And that's why it's been important to have a community process. And I don't think all vendors are equally enthusiastic about the project, about Defcore, I think that they're still waiting to see how it impacts what they do and where they had positioned themselves as being OpenStack vendors. So it's gonna take some time to shake it out. Defcore was not a done deal, it's been a challenge to come through. We were just talking in our panel that a lot of open source communities have had trouble achieving this state. We've gotten to at least a state where we can identify tests and choose tests. That's a big step. Still have to get further and we're not done. So we're at a point where Defcore is very real, vendors are passing it. There's real consequences for not participating and not passing, but we're not done. So I think it's, we need vendors to come in and say, this is important, I wanna do this. We really need users to step forward and say to their vendors, why aren't you passing the spec? Show me that you're passing it because the users are really gonna drive the vendors more than the board will. And so, it's still gonna take some time to go and I don't think everybody's 100% on board yet. I wish, I'd love to say they were. I think there's plenty of people who rightly have a wait and see approach and wanna see this proven out a little bit more. When you look at Defcore, one of the things that was really important to me and I think is really important to the community is that it's a test-driven thing. And so one of the things that people should think about as they look at Defcore and what we've tried to accomplish is it really depends on the community adding tests, the community valuing the fact that we actually test things and that we increase the body of tests. And so everything that people do when they think about Defcore, they should also think test and they should think validation and that we're actually going through and making sure things work and how can they participate in creating tests or making sure the tests work? So it's fun to talk about the vendors and talk about the projects that are being picked and things like that, and at the end of the day, it really comes down to the community's willingness to participate in testing efforts and not everybody's been willing to do that. And so we very deliberately wanted to create a economy for tests, meaning that for companies that put tests into the system, they get value back from adding tests and that was a very deliberate choice for us. And what I hope is that as people think about Defcore, they also reward the vendors that are invested in testing efforts and in being part of a testing community and contributing more tests into the systems. So one of the things that I hear a lot of when I talk to people in the open stack community and users in the open stack community is that it's confusing, right? There's a lot of stuff, they don't know it's mature, it's very confusing. One of the things that Defcore really does is it separates signal from noise, right? So part of our goal is to create, is to improve the signal noise ratio for users so that they can say, well, these are the things I have to pay attention to and these are the things I don't have to pay attention to. And so from a vendor perspective and user perspective, it's a very powerful tool to create this filter. And it's gonna have very profound impacts on the community. And one of the things I think the developers are not entirely looking towards when they think about Defcore is they're gonna be working on projects that might pass through that signal noise filter and be on the noise side. And so like your baby is ugly, they're gonna hear from users and vendors, well, wait a minute, maybe I don't need to worry about your stuff anymore. Just because you're in the open stack community, great. But maybe it's, I don't have to worry about you as much. And so, yeah, we're gonna, part of Defcore's effect is to have this sort of signal to noise ratio. And it might have a profound impact. I hope it has a profound impact on helping users trust open stack and know what open stack is and address that concern that I hear from the community a lot.