 As part of the CDF Foundation, there's a lot of companies and enterprises around the globe who use the capabilities, use the different projects that are created by organizations like the CDF, CNCF, etc. And this panel talk is how we as enterprises use capabilities, what we look for from organizations like the CDF or CNCF and also trying to encourage more companies to become part of the CDF Foundation to join it, represent the interests of enterprises who actually use all of these products out in their real world and how we can influence the roadmaps, the priorities, the backlogs, etc. of these projects as we look to drive continuous delivery, enable scale across our organizations and I'm here joined by a few colleagues who are again like Fidelity Investments, users of products and I'm just going to ask them to introduce themselves first in the roles. Thank you. My name is Peter Wunder. I work at Ericsson as a senior expert in deployment architectures in our central technology organization and after working a lot with cloud native transformation of our applications, bringing them on to Kubernetes, helping to deliver our 5G core in a cloud native manner. I'm now trying and helping our deployment and deployment organizations bring the software to our customers. My name is Tiffany Jackja. I am an engineering manager at Autodesk and I'm working with a developer enablement team supporting platform services and emerging technologies at Autodesk and so we've developed different activities and services and solutions to help support a bunch of the teams that are building out services that help deliver better software across our customers and also internal developers. So I'm Brett Smith. I work for SAS Institute. I am an architect for the pipelines. I built the current pipeline we have and I was working on the next gen pipeline that we're building out. I am now working on a security observability across the R&D organization because I know where all the bodies are. So the innovation that we're trying to do is to make an event driven pipeline that gives us the ability to deliver at speed and that's what we basically did and now I'm trying to secure it basically. Cool. Thank you all. So we get fidelity investments where we joined the CDF a couple of years ago. We strongly believe the problems we're solving are not unique in any organization in any part of the world. So we've got X number of technologists as part of fidelity. There's thousands and thousands of technologists all over the world participating in open source. So there's greater scale to deliver high quality fantastic capabilities that we can do it much faster using open source, using the community, open source community and using these foundations like CDF to help create an ecosystem in which these tools work together. Like examples we have, the CD events project and how that's now been integrated with Tecton and we did our first open source contribution there with the Jenkins plug-in. Actually we got it out last month. So it's our start of being part of the open source world and not just building things proprietary just because you're in an enterprise and you have budget to custom build things. So we want to work with open source. But so we find a huge amount of value being part of CDF. We think we get a huge amount of scale and efficiency from the CDF and from the projects. What do you think about end-user computers or end-user members of any of the foundations and from an Ericsson perspective, what kind of benefits do you think they would bring your organization? I think as Ericsson we typically take a dual role here as an end-user of course, but also as a contributor in many of the foundations and many of the projects. I think it's super important particularly for us in the telco industry or coming from a telecommunications background to express the I would say particularities we have sometimes in this industry also in broader forums. I mean what we've realized is that building telecom specific software and applications doesn't have the scale than if you go out for a wider industry and particularly when it comes to continuous delivery or software delivery in general, it's a generic enough problem so we can actually benefit from such a large and big community like the CDF. Yeah, I think additionally it's helpful to acknowledge companies that have gone beyond where we are in our journey because now you can get to see how it has been done and how can you take what's been done and carve your own path towards that. Some of the things that we try to focus on it then leads into like other versions of solutions that we're developing so like at Autodesk we've moved from our spinnaker instance being called sort of like a V1 or V2 into a V3 version and that was borrowed from things from learnings that were shared within the community from the vendors in this space as well. So we want to drive innovation into continuous delivery. What better way to drive innovation into continuous delivery than to collaborate and what better way to collaborate than to join the CDF and so from the CDF we get to do meaningful input into the specifications and the best practices and the workshops that we teach with and that's part of the thing that we get to do and it helps us to move away from building things on-prem and be able to consume open source projects better upstream. Actually Tiffany you raised an interesting point of learning from others who have gone before you and how we take what people do and what people build and be able to bring that back into the community and people then can benefit from that who come afterwards like the lessons are already part of the solutions that we adopt. So to add on to that we get to lean on the CDF's engineering community to help us solve our not invented here syndrome and then so what we end up doing is that I make stuff like events on Andreas problem and then we consume it. And then so as we consume that we are more apt to go, hey this thing mostly works let's go contribute upstream and help the rest of the community. And then the next thing that I do is I take my early careers and I go this is the way. You contribute it back upstream, you use the upstream open source products and now you're not building in-house and you don't have to support it forever and so if you don't have to support it forever you can be a maintainer on that and it's not your siloed problem that you built and it's not your fault. You can blame Andrea. So we've just gathered that Andrea is going to solve world hunger and the entire continuous delivery solution for the world, congratulations. You just passed on to the Welsh rugby team now and you'll be a hero. But you know one of the things we see so like as part of Fidelity we're in our journey we have technology within Fidelity that's come back to the mainframe so there's a huge amount of different types of technology running on-premise, we're part of our adopting Kubernetes, adopting cloud services, multi-cloud and then there's all these tools and all these projects and all these things that you have to do and everybody's at a different state in their journey. What are the types of challenges do you face on a day by day basis and what types of solutions or ideas or innovations are you coming up with to solve for the legacy, solve for the modernization and the digital transformation that you know we're all going true. Do you want to start? Okay, thanks for the bus. So the, he threw me for a loop. So what we did was is that we went out and built an adventure of an asynchronous framework that lets us tie the legacy systems back into the greenfield modern systems that we're building out, right? So I've got stuff deployed on Kubernetes, I got stuff deployed on OpenStack, I got stuff on VMware, I got stuff running on a mainframe in the basement, right? I've got stuff written in SAS, which is a language by the way, and I've got stuff written in C, C++, Python, Go and what we did was we wrote a bunch of SDKs for everything except for the SAS, we probably should have and then it allows us to take the legacy systems that we have like the Jenkins nodes that we have thousands of Jenkins nodes and integrate them into the event-driven system without having to rebuild the systems with some new technology. You just need to be able to post a JSON to a service that will then create the event that will trigger all the robots to run. So that's one of the things that we have done. The other thing we've done is we've swept through and made a security profile of all of the stuff we built that we were pretty proud of that has no security on it. And now we're going to put in HTTPS, OpenIDC endpoints on it and we're locking it down. And so eventually what we're going to end up with is we're going to end up a mildly secure current pipeline and then we're taking all those lessons to the next gen pipeline and we're just not making the same mistakes, right? So that's kind of what we're up to. Yeah, we're in a similar situation and one thing that's been pretty interesting to see in Autodesk specifically is them taking an approach from a developer enablement perspective. So that's where my team kind of comes into place. And so it helps when there are new technologies or new processes or new iterations of technologies to be able to understand like what are the differences and then how do you quickly adopt that so you can get the ball running and productivity doesn't hurt just because we're adding a new process or a new technology or a new team in place. And at the same time, if challenges do come up, you get to catch them fairly quickly almost as if you had it similar to a external like DevRel type setup, but it's internal now. So you're quickly able to get developer feedback and the challenges directly and then bridge the gap between the platform services that are being developed and then the users that are using them. I think for us, being a bit particular again, one of the particularities we're dealing with is that we're actually in a very rare case is only have an actual DevOps type of environment in the telco sector. Traditionally, you have a software supplier and you have a communication service provider, telecom operator operating the software in their network. Of course, we have more and more telecom operators who start to build their own software and deploy that software so they actually have a full DevOps process in their environment. Those for us, one of the big challenges we're trying to overcome now is the very good integration and CI CD pipelines we have internally in our systems at Ericsson being able to deliver software actually quite frequently gets hold up by the process we have towards our customers. I mean, how do we ship software to them? How are they deployed in their network? And particularly that handover in between two entirely different organizations with an entirely different set of processes and tools and so forth is really something where interoperability will play a significant role. If we want to close that gap in between these two sometimes free organizations, if you have a delivery organization in between. So we're really trying to bring the learnings we had from or we have from our own CI CD environments and our own testings, our own integration systems into that process. And CD events was partly done based on the build systems we have created at Ericsson. Sorry. I love what you were saying about how there's, when there are more events, there's more data. And that's also another point that I wanted to add on is it's been interesting to see how much data is generated and how we use that. So even from the perspective of making it, making platform services more open, we're approaching a more API first approach to it. So that's something that's been happening. And then secondly, is also utilizing the data that comes from introducing new processes or new technologies. There's a lot of tribal knowledge that comes from that, right? Especially as more and more teams utilize CI CD technologies or delivery technologies, you get a lot of tribal best practices, certain teams doing certain things a certain way. They're documenting it. You find it in Slack. You find it in Conversations. How do you replicate that and really sustain that in an organization? And so we're also using AI and ML to help with that, like harnessing the knowledge base that we have within the company and then being able to feed that or give that as a service for developers to use at the touch of their fingertips if they were to search something or try to get some help on Slack. So that's another form of automation that has been happening within the ecosystem, but sort of on the side, right? When we talk about continuous delivery and building up the services, we tend to talk about the actual teams that are building it, platform engineers or even the users that are using it. But looking at it from a different perspective, it's been interesting to play with the data there, too. So another point on the data, and I'm not finished with this, so don't kid yourself, right? This is hand wavy. But I've got this ton of data from this system that's been running for two and a half years, collecting everything that happens in an event. And then the idea is that at some point, we analyze that data and then we go and start making predictive test selection. And I go, oh, look, I touched this piece of code. And I know that this piece of code touches this piece, this piece, and this piece. And then I go, oh, what test suites do I need to run to make sure that I have tested those, but not the whole six-hour test suite, right? Because it's six hours for us to test our stuff. Then we go into deployment disaster analysis, right? So we do 40,000 deployments a year, 10,000 of them fail. Why did they fail? And then we trace it. The binary that failed, we trace it all the way back to the source code. And we go, oh, look, that if statement is killing us. And then we go and we fix the if statement. It's probably not just an if, but you get it, right? So that's the type of stuff that we're working towards. Now, are we there? No, but that's where we're headed. Yeah, I will add that. It takes a while to get there, but the idea, or the premise behind it, is you expose that data and let the teams that are using it or that maybe find it useful to be able to build their own solutions or come to their own conclusions about how they're delivering and optimize on that themselves. Don't run the six-hour test suite because Evan changed the readme. I really envy you that you have access to all of this data. I mean, we, to a large degree, fly blind. I mean, we throw our software over the fence. It's loyal to the customer network, and it's super hard to get that data back. I mean, we're working more and more to actually have our own live deployments, working stronger with our managed service, which actually run networks worldwide. But getting that data back, I think, is super, super valuable. Wait till we get the metrics. Then I'm going to let you down. Yeah, and it is interesting because one of the reasons, as part of the Jenkins plugin, because we run Jenkins for CINCD, is there is a world of information that's created, and it's all digitized. It's in machines. Now it's ephemeral if it's in Kubernetes. And when we think about data is powerful from a number of reasons, right? It's got compliance. It's got security. You've got audit. You've got organizational things. But one of the more interesting things is developers. At the end of the day, we build and create solutions for our development teams. So if those things aren't very good or they're not wrapped up in an experience that they really want to use, it's easy to adopt, they're going to go off and do their own things. They're going to work around. So how do you view the developer experience? How do you put that lens on top of the platform like a platform is pretty straightforward, to be honest? It's just code and automation, but providing a fantastic experience on that and that adds value and makes their life easy and simple. Where do you focus or have you done much in that space? Want to go first? Yeah. Sure. Never went first. Yeah, yeah. And a great pivot towards the kind of work that I do on a day-to-day basis anyway. There's a couple of different things, but I think the biggest is to get away from the story of productivity because we've all fallen for the trap of looking at what project is doing the best, who's delivering the fastest, why are they doing so well. But if we don't look across the board, across the entire software development lifecycle, we're missing the bigger story around that platform experience or that delivery technology experience. If you're just focusing on Dora metrics, lead time to deliver, meantime to recover, all that stuff, you're missing the bigger picture. And I think it's really important to be looking at other things like bug reports, feature requests, and actually how long does it take for someone to onboard into a new processor, a new technology? Because I think oftentimes we're so trapped in the engineering of it all and the numbers of it all that we forget to take the pulse of the community and of the users. And we miss those stories or the side conversations that happen in meetings before some decision has to be made or some deadline has to be met. So I think that's a big part of it when we look at developer experience and developer productivity or, yeah, experience. I think for us, developer experience was extremely important going through the transformation into an entirely new generation in the telecom network, which made us basically implement a product from scratch. We don't get that chance so often in the telco industry with the generations of the networks. We typically have a good chance to implement and redo things when a new generation comes up. Not for all the releases, but certainly for some of them. But that also meant that we had to get our developer community on that journey, on that journey going from a traditional, I mean, some of them basically started with physical, low-level, embedded programming and now had to move to containers. And I think giving them the right tools, giving them the right environment to work with helped tremendously to go through that transformation and educate, help them build products in an entirely new way they have not done before. One thing, we have nearly 30,000 developers in Ericsson working on a whole heap of different products. One thing we're trying to do is to have a certain alignment in terms of quality or coding best practices and where the tools helped us tremendously was trying to automate certain rules on how things are being implemented, how things are being designed as part of the process. So you don't have to read a lot of manuals, it's just you code, you see this is working, this is not working. It's aligned with our structure, our best practices and then you just focus on what you actually have to do. So I'm gonna take a different angle on it to everything they said, really important. But what I'm trying to do is shift left. So with the current pipeline we have, the technology is of a vintage that it makes it hard to shift everything left. So what the developer ends up with is several different panes of glass just to go figure out what's going on. And I don't know if you guys know developers but they don't care. They want to come in, pull their code, hack, push their PR, get Jamie and Evan to review it and then submit it, right? And then they're complaining because they had to get two reviews. Once they get it submitted, the continuous delivery pipeline needs to be transparent, right? And so they shouldn't have to think about like their SaaS scanning and their SCA scanning. So we shift the SaaS scanning left into their IDE, right? Now they can't even get the code to get into the pull request because it's busted, right? And then they run their SCA scan in their IDE and then they can't even get into the pull request because they've got 25 criticals because they grabbed some random library off the internet that they weren't supposed to grab and they curl pipe bashed it into their environment and then they're expecting it to end up in the pipeline. So we cut down on those type of things and then they don't get to commit the bad code to the repo. So now we're keeping the stuff out of the repository and what we get into the repository is stuff we've agreed on that is either, yes, we can't fix it because it's busted upstream and they're not gonna fix it for two months. Yes, we have a remediation plan. I can tell my customers the remediation plan so they're not screaming. And then it's the, he didn't have the, they did not have to leave their IDE, right? And now it's not there yet, but that's what we're working towards. So that's kind of what we're working on. So Tiffany, you mentioned metrics and Dora and personally, traditional companies use metrics and analysis to find the bad people, to kind of wire you a poor team and they stack rank you up. And I always feel personally that we're a very large organization. We have 17,000 technologists. We've bought four or 5,000 application teams and some people are much further along in their maturity, their development, their engineering practices, et cetera, than others. And I always find like we miss a trick with metrics or how we measure things or how we look with view data to say, well, who are the people that are setting the bar? Who are the people who have gone out there, they've innovated, they've got further and how do we learn from them? So how do they, what they do? How do we feed that back into the system, feed that back into the teams? So they essentially can go jump from the ground halfway up the ladder as part of their cloud journey. And have you used any metrics or have you used anything that, in a positive way, not as a way to kind of weed out people or kind of punish the weak? We should make Tiffany answer this, because I can't. I do have an answer for you. Yeah, I think one thing that has been nice has been just looking at the incidents and time not onboarding. So if there's a spike in, say for example, incidents related to observability, what technologies are we using there and why did that happen can tell a bigger story about how do you improve that process. Maybe it's, there's an outage and it wasn't related to anything that any engineer on our side as an end user you did, but there are other things around reliability around the products or projects that you're using and that can lead into better conversations about how do we actually sustain this or what are the uptimes that we're gonna need in order to ensure that people are actually going to be able to use the service because the other thing is you just need only one bad experience with a product to be like, okay, I'm done with this, like I'll just use something else. We're so lucky in this ecosystem now where developers can really pick and choose for the most part. I mean, some places you don't get to choose and that's normal, but there are a lot of developers are more than happy to share their opinions about what's working well and what isn't. So being able to acknowledge like when something is going well and then being able to replicate that is a lot more difficult, but like I said, it's good to make note of that and then reuse that then again conversations or trainings or things that you facilitate, right? Conversations that you facilitate or even internal trainings that happen or conversations within like all hands sessions where you get to double down on the principle and so that then the practice and the tools will trickle down into the actual engineering teams at the side that like, if you were to look at things from a very like pure engineering standpoint, right? We tend to align that upper management will decide what are the principles that will guide our engineering orgs and then our actual teams will decide what the practices and the tools are and so being able to trickle that back up now, right? Becomes more of the conversation and why we measure the metrics. Happy to hear from you all what you measure in terms of metrics as well. Actually, I'm in a position at the moment where I'm trying to consult our management on exactly the principles to be set and one item we're extremely interested in closing that gap from us as a server supplier towards the operators is how can we actually measure the impact of the technologies we're introducing? It's very easy if I can count the improvements on an application which is running, how much more throughput, how many more gigabits of data can I push through? It's very easy to measure that and we have all the metrics. I think where we are not as good yet is the metrics for the entire delivery process. How can we understand what benefits do we get? What kind of improvements can we make on some of the principles we're setting? If we're moving towards GitOps, if we're introducing pipelines or certain items in pipelines, what does that give us? This is also one of the reasons why I'm here this week, trying to understand and learn a bit from this community is what are best practices? How have you measured the benefits out of these technologies? Basically, for us, it was a gut feel, right? It was like, man, we delivered 8,000 units this week. I think we're fine. And so when I saw the door on metrics, I was like, cool, I've got metrics. Let's go run the door on metrics. Well, my system's asynchronous event driven. It flies, right? But it doesn't, it skews the door on metrics to the point where you're like, wait, wait, are you sure that piece is okay? Because the door metrics say I'm world-class. I got news for you, buddy. We are not world-class. We're fast, right? And we're cheap, right? But so here's my CDF story, right? David Benderi, if you guys come to the SIG software supply chain, you will meet David Benderi. And David started a work group to work on the secure, the software supply chain security, the maturity metrics. I'm sorry, let me try that again. The software supply chain maturity metrics, I got it. So what David did was David looked through the door on metrics and he goes, man, they just omit things, right? And like one of the examples is how long does it take you to restore your stuff, right? And how long does it take you to remediate stuff? And how long does it take this or that? And are you complying with salsa standards? And if you read the doc, it's out on GitHub, it's excellent. And so what I did was I took the door on metrics, which were mostly useless for us. And I took David's stuff. And David was nice enough to put me on the pull request so it looks like I did something. I just reviewed it and was like, oh man, I'm using that. And we took that maturity metrics and went through the pipeline again. And then we realized we're really bad. We're not near as good as we thought. I got this test suite. The test suite runs six hours. An hour of that is set up, right? And if I get it set up in an hour, it runs 30 minutes and crashes. All we do is fire up a new one while we're working on fixing the old one. That's another hour and a half. And if you do your metrics right, you're now two and a half hours behind instead of an hour, which is what you said it takes you to deploy, right? So those are the type of things we get out of the CDF. And it's very beneficial to us as a company because I wouldn't have thought of this to go that way. So. Yeah, I think these are really great stories around how we're gathering the metrics. I think you brought up a really great point, Peter, about the story that you tell around it, especially when you're communicating upwards, because the impact or the end goals can kind of get lost in the Dora metrics and the studies that we do on productivity. Like, what was the actual outcome or what product story are we really telling here? And closing that feedback loop can tend to be quite difficult. One thing that I've found that has been relatively helpful when it comes to telling the story is really looking at it from a performance angle. So telling the story about how does this impact us technically? What is the technical impact? What is the team impact? And what is the business impact? And looking at it from those three lens gets to, you'll first have like a bullet point, but then it tends to come together into a very cohesive story that you can then turn into a one sentence or one paragraph that leadership can tend to buy in on and they're like, wow, this is amazing, you know? But that part is really important because we have so many engineering cycles before leadership is like, oh, so what was the updates? Or, you know, it's a quarter has passed or two quarters has passed. Like, what's really going on here? And it can be really hard to set principles, right? Especially for organizations that don't have strong engineering principles. Everything else that comes after that can get very mucky, like very, very disorganized very quickly. And so being able to align and make sure that every time we iterate on a technology or we iterate on an iteration or some time has passed by that we continue to add momentum by sending a cohesive story that is going to be really important. I know we're coming in time. So I'm going to ask one final question. You can try, you know, I think someone said it earlier yesterday. 60 seconds to answer. But I'm going to do a shameless plug for the Continuous Delivery Foundation and for anybody out there watching this, join, please join, end users. There's, you know, just thousands, and thousands, and thousands of companies. Just the more ideas, the more thoughts, the more feedback we all get, the greater and the better, every all of our solutions are. And the more secure it is out there. But, you know, if you don't wish, right? So if you wanted to ask, you know, we're here at an open source, you know, with CDF, CDCon here, OSS starts tomorrow, there's vendors out there who build products and create products that we all use in our organizations. There's open source projects out there that are creating solutions that we all use within our organizations. If you had an ask to all of those people, all of those groups, what would it be, including the CDF, what would it be? Listen to the particularities also from the industry I'm coming from. Do you know we're sometimes special, but we're really trying to align and play nicely, and interoperability is key. We've learned that in our industry, and I think also for CDF, this will be a very important factor. Yes, I love the interoperability angle. I think one ask that I would make is promote your solutions, especially if they work across multiple solutions and things that may be helpful for end users at the end of the day. I think sometimes it can be a little bit scary to be in a space like this where it's like, oh, it's supposed to be vendor neutral, but we wanna hear the engineering innovations and we wanna know them because we're using them to help us as end users deliver better software at the end of the day. So Andrea is going to help us with interoperability with CDEvents, and then the one thing I wish is that Fatih would let me finish at least one of the things he's asked me to do for the CDF before he asked me for another one. So with that, I think we have a few minutes. First of all, I want to thank everybody for their time today, for attending the conference and listening to everyone, and all the presenters who prepared material and gave up their time into travel here and shared their stories, but if anybody had any questions, we're happy to take them. Hi, I'm Tracy Reagan. I've been with the CDF since its beginning, and what I really wanna know from each of you is what can we do for you? What are we not doing? What's the CDF not doing yet? What should we be thinking about in terms of continuing to build on the CDF and what should the future look like from an end user perspective? I'd like to start. With Cloud, the amount of work developers have to do just to get their application into their customer services increased exponentially between the monolith, you know, with probably a Confluence page or an Excel set of instructions of how to install something. So I think how do we create solutions that work together and make it simple for developers essentially to get their code into production, but security, compliance, audit, quality, you know, just a list goes on and on, infrastructure's code, my application code, my observability code, everything's as code now and all of that work comes back on the developer. So that increases and that actually then slows down those teams to get business value into the hands of their customers. So my wish would be that as the CDF or companies that how do we make their developers life easier to get value to their customers? Ooh, hard to add on top of that one. That was really good. Maybe a personal reflection, I think that the sharing being done on these meetings is amazing. I mean, listening to what people build out of the solutions and out of the components which CDF has at play. If I would have a wish, I would like, I really appreciate to see larger setups. I mean, most of the talks this week were around specific projects, maybe two projects in combination would be really interesting to also see larger setups with a number of projects being integrated, presented at these types of venues to see how this works end to end. Yeah, on top of the potential runbooks or templates to get started quickly, I think it's also helpful to have the discussions like round tables and things like that for us to specialize in discussions that aren't brought up very often in continuous delivery. I thought you prepared a lot of really great questions that touch on pillars essentially, right? And we can only cover so much in a two day event and would love to see more of these kinds of sessions and conversations in and outside of the actual tracks. So we have space on the workshop's work group. If you guys have time, I'll turn this around. These guys have all covered it. What do we need to do for the CDF? And what I need to do is to continue to convince my colleagues and my acquaintances at other big tech companies that this is important and we should go contribute to this. And trust me, I try. I mean, every time we go out for beers with these guys, I'm like, you need to come to this meeting and then I hit them up and then they block me. But anyway, so it's still, it's not stalking. But the idea here is that us, as the big companies, we should be socializing this much more so that we get more people in so that I don't have to do all the work on the workshop committee. I'm not doing it, but you get the idea, right? We want more people. We want more bodies. We want more contributions because we have more eyes. We get more eyes on the upstream projects. We knock the vulnerabilities down. We've improved the interoperability. Everything gets better. And Gern, I don't have to work so hard. Thank you Fatih. So we're going to stand up, actually re-stand up. It used to be in existence before. It's called the End User Council. So the End User Council is open to everybody and anybody who is an End User member or is interested in becoming a member just to get their feet wet and explore more and discuss more. So we will be standing that up shortly. We'll be inviting anybody who's interested to connect either with myself or with Feteen, the CDF or Lori as outreach. And we're looking for as many members as we can get so we can build as big a council as we can. And with that, unless there's any more questions I said, thank you very much.