 There's mics, right? People... They're... that's... Ah, where is it? Okay. Alright. Well, thank you, Dries, and thanks to everyone who's coming here. Yeah, so that was another excellent keynote that you've done for Drupaton. Thank you. But I'm sure many people have questions, so if you have any questions, I think there's some roving mics, but also you can... yep, so the people in black t-shirts, if you put your hands up at the right end. So if you want the microphone, just wave your hands and you'll sort you out. And you can also ask questions through the app. So if you go to the program section in the app, you can go down, find the Dries Q&A, and in there you can ask questions, and that's what I'll be looking at. So, question today started. Alright. I'm really excited about all of those contributorials that Tim talked about. So, when did he say that it would be all ready? When can we use them all? Yeah, good question. Probably a question for the DA, but... Because they're a small but mighty team. They have a lot to do. But some of the things are already available today, and so they use this kind of sort of rolling thunder where they continuously, you know, launch new capabilities once they're about a time. My guess is, I don't know if any one of the DA's here, actually. Neil is there. Neil, what's the answer? Because I shouldn't be guessing. I couldn't hear it, sorry. It would be guessing too. It's ready when it's ready. So is the eventual plan to discontinue the issue queue on Drupal.org and move entirely to GitLab? Sorry, is it what is this? Is the plan to remove the issue queue on Drupal.org and move entirely to GitLab? Yeah, it's also a question for Neil. I think we want to move everything over. The vision really is to use as much of GitLab as we can, because if we have two different systems at the same time, it actually creates more work, not less work. And we really want to just go all in on GitLab, where it makes sense, obviously, and just rely on GitLab. And then we get the innovation engine from GitLab because obviously, they're now a well-established company. They're adding a lot of capabilities. There is a whole ecosystem of integrations with GitLab. And so we just want to tap into all of that. And I think if we keep too many Drupalisms, like sometimes we do, you know, like a lot of these opportunities and integrations just don't you know, we might not be able to fully take advantage of GitLab that way, you know? So one of the reasons it's taking a little time is, one, we have a small team, as I mentioned, doing a lot of work, too. We have 20-something years of history and content and issues, which is very complex, you know, 40,000-something projects. Just core alone is a lot of history. And so all of that needs to be migrated. And interestingly enough, you know, we built our own infrastructure, but even the GitLabs and the GitHub's of the world that don't have all of the capabilities that we have. Like, we really built something over the years that allows us to scale to a project the size of Drupal, where we have 40,000 integrations and we have a million users on Drupal.org and we have 10,000 people collaborating on Drupal any given year. So we've built this massive, massive collaboration tool and GitLab and GitHub wasn't necessarily invented for projects like Drupal with the scale and the complexity of Drupal. And so a lot of what we need to do is actually push GitLab, in our case, to add the features that we need to run and manage a community as large and as complex as Drupal. And so the Drupal Association has done a wonderful job collaborating with GitLab and GitLab has been very generous as well, contributing time and money to help us build these features. And they're also very eager to work with us. I'll give one more example if that's okay. Yeah, go ahead. But like, you know, Drupal pioneered this credit system that you might be aware of. And we have integrated the credit system in our, you know, collaboration tools. And that doesn't exist. Like because we were literally, you know, the first or one of the first to have this. And GitLab is very interested in having a feature like that so they can make it available to every other project in the world that uses GitLab. And so when we think about how do we bring the credit system into GitLab? It's not like a quick, it's not necessarily an easy, quick effort, you know? There's a whole lot of work and thought and design thinking that needs to go into that to not only migrate the existing credits, but also to evolve it so it can be applied to the conceptual principles of GitLab, which is a little bit different. And then also they wanna then make it available to every other open source project in the world. And so they have to think about how do we make it reusable beyond Drupal as well. And so just wanted to highlight that, you know, to show like, you know, we are leading the world sometimes in how we work and the tools that we have to build Drupal with so many people. And, you know, GitLab doesn't have all of these features, funny enough, right? And so it takes a while to get all of these things on it, which is why it's hard to say it's gonna be done, you know, in three months or in six months. But I've been very encouraged by the pace, though, of the progress. Every time we meet at DrupalCon, there's a whole bunch of new features. That's very good. I really like the Kanban board, a few of the issue queues, so I find that really difficult to navigate and manage as a maintainer. So with all the work that is going on, like on say that initiative, but also other initiatives that you have, like how is that all being funded? You mentioned the Philanthropy and the grants. Can you talk a bit more about that? Yeah, so one of the things we want to start doing is go after grants as an example. So there's a lot of organizations, could be government organizations or philanthropic organizations that have grant money, that will make an investment in a project, hopefully like Drupal, when our ideas and principles are aligned with their vision. I'm actually presenting on Friday this week at a conference of the European Commission. And they have billions of dollars in grants. And at this conference, there are some high profile policy makers and grant makers. And they invited me to present at the conference because they want to learn from Drupal and open source collaboration. And they also use Drupal by the way, but they like how Drupal is a global community with local communities as well and how we all work together. And they want to apply some of that thinking to other industries in the European Commission because they recognize that Europe is a collection of smaller countries, but if we can all kind of work together, maybe in a Drupal-y way, that they can build something bigger across country borders. And anyway, I'm not saying they'll write a grant, but I'm saying grants are available. And historically, we have never tried to get a grant. All right, never tried to apply for... To the best of my knowledge, we have not... We had a few grants as it related to around COVID. I forgot what they were called, forgiveness things. Yes. Anyway, but we really have never applied for grants. And so we're gonna try it, which is nice, and see what happens. But imagine we can get two or $3 million a year in grants and we can use that money to promote Drupal or invest in strategic initiatives for Drupal, those kinds of things. That would be pretty nice, right? And we have a team now. We hired a person, Kristen, and she has a long background and a lot of experience with grants, grant programs and raising money from different institutions. And she's coming in very excited and ambitious and hopefully we can get some grants. And that would be another way to help grow Drupal and sustain the project. Yeah, applying for grants is like a whole other still set that you need. Yes, and that's why you need people specialized in it. We never had that skill, but now we do, which we'll see what happens next. So there used to be a promote Drupal initiative before. How is that going to differ from what the current plans are? Yeah, I think promote Drupal has been great, first of all, and a lot of people have put in a lot of great effort. Sometimes I still think, and I don't mean this as criticism, we're only scratching the surface sometimes of what we could do to promote Drupal. And so it's really about doing what promote Drupal does and then more, like how do we give them more resources and how do we support initiatives like that more broadly and it goes all the way from making sure Drupal is present at relevant industry events to having more and better content on Drupal.org as well. I mean, if you think about it, if you go to Drupal.org, it's actually really hard to learn about Drupal in a way, in some ways. Like if you were to go to websites of competitors, they would have a lot of content for all of the features they have. Like I'll give one example, but let's say our workflow tools, our content workflow tools. We have some of the best content workflow tools in the world, but it's really hard to go to a page on Drupal.org where you can learn about here's Drupal's workflow tools and maybe with a little video and really tailored for people that are sort of curious about Drupal and they're trying to assess if Drupal would meet their needs. Same thing with multilingual. We're really good at multilingual, but do we promote it well? If you are new to Drupal, you're trying to figure out, is Drupal a fit for my project? It's not that easy. And so we miss, for example, long story short. We miss sort of the classic product marketing content, which is promoting the features and the capabilities of Drupal. And for every feature in Drupal, which is maybe a hundred features or more, we should have a page that explains the feature in a way that helps people understand what Drupal can do for them. So I think there's a lot to do. Go beyond what we do today and also promote Drupal for different verticals or industries, promote Drupal to different buyer personas. Developers, obviously, but also marketers, like really good content for marketers or good content for, you know, CIOs, like another kind of more strategy-oriented roles. And to me, and I've talked about this in the past, but like I think about this, like we've built sort of one of the world's best engineering machines and one of the world's largest engineering teams with 10,000 plus people. Like why haven't we done the same on the marketing side? Why can't we get hundreds of people in the Drupal project market Drupal together, just like we do for code? I think there's a lot of things there that we can try and I think that could be pretty exciting. We've had a question from Tony in the audience who says, you'd like to do better at promoting Drupal. The story is so inspiring. So isn't it time for Drupal to movie or the book? Is it time for Drupal to move? Is it time for the Drupal, the movie or Drupal, the book? Wow, that would be cool. I don't know. Yes? Trying to picture what this movie will be about. But maybe a nice like documentary style movie, maybe, you know, could be fun. Another question, going back to GitLab. So is it the right path? Do you think to offer the option to opt in for GitLab, as described in the keynote in the video, or would it be better to do a cut and only support GitLab? I don't know what the best process is. I mean, I think the end state is GitLab. I'm pretty clear about that in my head. But how we get there, I think we're doing sort of a gradual, you know, get there step by step. And we have to think a lot about how we manage a change like that, right? So I think change management is pretty important so we don't disrupt, you know, Drupal. For example, we are about to release Drupal 10. We don't wanna, in the middle of the Drupal 10 release process, kind of make things impossible or hard. So we have to be very careful about how we roll out these features and how it impacts our packaging scripts and all the things that we have that we've built over all the years. So the end goal is GitLab and GitLab only, almost, or as little Drupalisms as we can. But yeah, we just have to get there in a gradual piece that brings everybody along and doesn't disrupt the project. We don't lose anyone on the way. And in relation to the marketing effort, another question, you mentioned the different industries and the different verticals. Miro's wondering, should we pick specific segments and that we're trying to go too broad, perhaps? Yeah, well, I think Drupal is already brought. I think the power of Drupal is that it's very flexible. It scales from small to large, from simple to complex, and because of the pluggability, the composability, and all the modules Drupal is being used in every industry today. So that is a fact, right? Like every industry uses Drupal, so I think it's a strength right now that we are that platform that can be used across every industry. So I think we should try and promote it for multiple industries. Having said that, I do think there are industries that we're better at than others. Like we continue to be really good in government, in higher education, media and entertainment, and so yeah, we have a lot of amazing references there. But even in other industries, we're getting better and better references. Like I've seen a lot of people in financial services adopt Drupal and healthcare adopt Drupal. Like in these were traditionally industries that were a little bit more, maybe reserved about open source, maybe a little bit less risk-taking, but they've gone all in on Drupal as well. So given the size of the install base and given just incredible organizations using Drupal in all of these different industries, I think we have to promote all the industries really. So how can we help promote Drupal? Is it case studies? Yeah, I think it's a great question and I think that's what I meant with, would be helpful if we had sort of that coordinator role. Cause if you think about it, like we have all these amazing Drupal agencies and guess what they do? They're often in the marketing that help their customers market, their customers by doing brand design, content creation, website building, not everybody is a pure website builder. A lot of the agencies in Drupal, they're like full service forms and our marketing experts. And so we have all these talents in our community, but what I see missing sometimes is kind of like, how do you organize? Coordination all. Across them all, right? And so when you ask, how can people help? Well, there's a million ways you can help. We need all the contents. We need, we could translate the content to different languages. We need campaigns. We need all the things. But it feels a little bit like unorganized and people don't know where to get involved and how to help. And so I don't have a great answer to how can you help other than maybe work, you know, kind of work with your local community and promote Drupal in your area and try to write about Drupal on your own website and all of these things. But we really need a coordination role, I think, that kind of creates a marketing plan and then kind of figures out how people can contribute as part of a bigger plan. So thinking of the different industries and verticals that Drupal is in and thinking about what we currently have like our distributions and then there's the plan for the recipes. Do you think you'd be good to highlight those and promote those? Yeah. Yeah, and actually one way you can probably all help just to circle back to that real quick is you all have the relationships with your customers. You know, you do projects, it's your customer, right? If you're an agency, but getting the references I think is key. Like being able to go to your customers and ask that they are willing to be a reference, write a use case, a case study, and bring those case studies to Drupal.org. I think that's one way that everybody can help promote your customers and in the process you can promote yourself too. So it's hopefully a win-win for all the stakeholders. But I think the recipes are great because then we can have recipes and promote the recipes with case studies along the same way. Yeah. So I have a couple of questions in GitLab again. So, with Drupal's GitLab CI tests, will they be agnostic or packaged in a way that agencies can use them within their own workflows? Especially the automated tests like accessibility. I don't know. Maybe Neil knows. Yeah. We don't know, yeah. Sorry, I'm not the GitLab experts. Yeah, but these are good questions. Maybe. Maybe somebody can give Neil a microphone. I have a microphone here, Neil. Or will those tools be open source? I don't know. Yeah, I mean you can use the same testing on a custom module as you would for a module on Drupal.org. So that would be about the same. So yeah, there's some reuse there. But yeah, testing a Drupal project on Drupal.org, like a module or a theme or whatever, like that's different from and testing a website. For a website, you want integration tests and more kind of behavior-driven development tests to test the whole thing, not just a bunch of parts. Okay. I'm thinking about the, okay, I won't go too much into that part, but you know the automated accessibility testing. So there's that aspect. But then currently on Drupal.org, you have the option as maintainer to opt into security advisory policy or into the security team coverage. Is there, and you get a badge then on your project page saying you're covered by the security team. Do you think we can move towards something like that for accessibility so that maintainers can opt in and say, yes, I commit to, dear to the WTAG or ATAG standards? I think my initial reaction is that I like that idea, right? If you are the maintainer of a project and you wanna make a commitment to accessibility, which today that's not a requirement for a contributed project, but if you say, I will commit to this accessibility level, I think it would be nice if people could state that, right? On the project page, and obviously that doesn't guarantee that they'll be actually accessible, but at least it demonstrates that they are, that they would be willing to accept patches and consider accessibility bugs as serious bugs to fix. And then if you have it on the project pages, what's nice about it is that as an end user, you can now filter modules by accessibility too, because if you are a certain kind of organization, that might be really important to you. More and more we see government mandates around accessibility. So you may wanna filter modules by accessibility compliance, let's say. And so yes, I think that would be a good idea. I'm sure there's a lot of little details that are to be figured out or there's no guarantees, that kind of stuff, but at least I think it would be nice. I think it's a good idea and it's Tom's idea wherever he's sitting. But like this, it would increase awareness even among developers that this is something that they should strive for and achieve. Regardless of whether they've opted in, is throwing, oh, maybe I should. Right, I agree. So, sounds like a great idea. Yes. Switching then topic to the automated updates. So, do you think this will also ship with a tool that you could have the automated, eventually, it's like a later phase perhaps, that the automatic updates project could commit the code to get, so you're not just doing it in development environment and then you can push it through? Or is that really more for the hosting companies to provide a way to do that, what are your thoughts? Yeah, I think it's a good question I'm kind of curious to see how different people will use it to be honest. I can see some people using it the way I demoed it where you hit a button and it updates your site. That will probably be scary for many organizations because they use a dev staging production workflow, obviously, so we'll have to fit into those workflows. But even in those workflows, they probably will use Composer and Command Line scripting, but even so, maybe there's a way to do it this way where maybe you can upgrade a staging environment with clicking buttons, if you will, and then push to production, so I don't know. I think people will figure out different ways to make it part of their workflow, depending on their risk averseness, depending on their resources as well, like not everybody has dev staging production workflows. I think it's that difference or conflict maybe between the needs of enterprise sites and agencies who are working with it and then the end users that maybe the smaller sites, you know, I feel a bit more like that other CMS between with W that it's more towards that sort type of audience than necessarily enterprise, seems like a bit of a... I think what we're building is actually nice in that it allows these enterprise use cases really well. You know, we have all the right tools for enterprises today with Composer, I think, and then automated updates and project browsers actually built on top of it, but just kind of makes it a lot more user friendly, but it's not like two different ways of doing things in many ways. It's just making these complex powerful tools available in an easier to use way. And so in that way we can perfectly cater to both, which is the magic, I think, you know, and you can even start with the UI and then as you get, your site gets bigger or you get more serious and you need to like move into a more typical enterprise workflow you can and you won't have to make any changes. So it's a great way to get people started and experiment with Drupal and even for a small site, maybe it's perfectly fine. The site grows and grows, maybe it becomes more important and now you can be more serious between quotes about it too and take it to that next level all with the same software, which is, to me, seems like a huge, compelling, very compelling story versus like a negative. It's a positive, not a negative. Do you think it would help new adopters who or even new developers sort of download and play with it and then maybe start treating Drupal like I did as a hobby and get more involved? Yeah, I think a lot of the things, so I think a lot of us probably, a lot of people in the project, they got involved because they used Drupal for a hobby project or a small project and could have been their soccer website or their blog or something small and simple. And maybe raise your hand if that's, how many of you got involved with a small site? Yeah, there's a bunch of hands, see? Maybe 20 people that got involved because Drupal was accessible and easy and it allowed them to do something quickly. And now a lot of us kind of grew up with Drupal and ended up building these large complex websites as well. And so that's a very interesting recruiting dynamic. And it's important that we don't completely lose that and I think a lot of the work that we're doing today, project browser and automatic updates and et cetera, et cetera, we'll make it, we'll bring that back a little bit, like admittedly we've lost that a little bit along the way. And so if we can make it easy for people to get involved with Drupal and make Drupal a little bit more user-friendly for smaller projects, it's a great way to recruit contributors because what happens is you start with Drupal, you built things through the UI and then it's like, oh, I wish it could do this. And then you have to maybe dabble a little bit with codes and before you know it, you're building modules and contributing back to Drupal. Yeah, so finding Drupal developers is an issue for all the Drupal agencies I've talked to here at Drupal. Do you have any other ideas and how to? Yeah, a lot of ideas, yeah. I mean, I think I was talking to some Drupal agencies last night actually and a lot of them allow their employees to contribute to Drupal as a tool to recruit people because guess what? A lot of the best Drupal contributors or aspiring Drupal contributors, they wanna work for companies that allow them to give back as part of their job. Doesn't mean like full-time necessarily, but maybe several hours a week that can be set aside for them to contribute back to the project or make it part of the rhythm of the organization, meaning sometimes I see agencies and companies you run into a bug, they just fix the bug on their local environment and never contributed back. And that's a little sad and can be frustrating to people that work at these organizations. And so they like to work for companies where you run into a bug or you have to add a feature, they're allowed some time to then contribute it back to the project. And that's really nice because I think it allows and hopefully a lot of you feel that way, it allows you to be part of something bigger. You're like a part of the Drupal project, not just as an end user, but as a contributor. And you can actually learn a lot of things from contributing to, like talk to a lot of contributors that say I've learned so much from contributing to Drupal. And so it's good for a career development, it's good for attracting some of the best talent to Drupal. So I think it helps and then you should advertise it. And that's one of the reasons why we have the credit system too. And companies use the credit system to show potential employees like, hey, if you come work here, we contribute back, we allow you to contribute back and it's, I think it helps you hire great talent. It definitely does. It's definitely a promotion tool for recruitment process, I think. The fact that you can provide people at the time, they'll want to work more perhaps with your company. But I have a few questions on the Drupal learning curve and what can be done to help new developers overcome that? To make it easier for them to get involved? Yeah. Yeah. It's a great question and it's probably not a quick and easy answer, but. And that's a new question. Yeah. That's been an ongoing journey. But I think we can do a lot more, I think, around sort of the onboarding of people too. Like, I'm gonna give another example maybe. And I think it's an opportunity for the Drupal Association too, but when you join the project, typically people will create an account on Drupal.org. And when you do, right now that's it. You've got an account. But if you think about what other organizations do, they usually nurture people. So maybe a week after or immediately, you get an email, because you created an account and the email will say, now do this. Or they point you to things, you know, and they have like this nurturing process to get people, you know, let's say in our case, productive. And they support that journey. Maybe we email them a video, hey, you created an account. Watch this five minute video to learn about how we work together. Watch this video to learn how to make your first contribution, you know? So that I think we don't do. So there's all this untapped potential, I think, to help people along. But that's on Drupal.org, I think. You know, there's training, documentation, books, all these things that can help people get started. Simon wants to know if there are any specific plans to improve documentation? I don't know if there are specific plans. I'm sure various people in the community are working on improving documentation. I'm not sure I know all the details. So, change topic. You mentioned in one of your slides that all the great work that we've done, like we're symphony six ready, we're nearly there for PHP 8.2. And you also mentioned smaller core. So how do you make the decisions of what features leave core, what features are going into core? Somebody's mentioning the paragraphs module. You know, then we have layout builder. But, you know, how do you decide what should be in core and what shouldn't be? It's a good question. There's a couple of different ways we think about it, I would say. Some things we decide sort of grassroots, I would say. And so people just contribute things. And when we see them, they're like, wow, that's cool. That should be in core. That's one way that happens, which is great. Another way sometimes is we look at you know, a principle that we use for core is like if it's in core, it should be used a lot. You know, like it should be infrastructure. It shouldn't necessarily be something used by 2% of the people using Drupal. And so we try to apply that filter. And it's actually also the filter that we applied to remove things from core. So we remove things like aggregator and for a module. And that's because when we look at the adoption of these features, we felt like they were not used enough to warrant inclusion in core. And so that's another principle that we do. And then the third piece I would say is like we do, I organize like a Drupal product survey every few years around every major release and we survey everyone in the Drupal community. And people kind of vote, if you will, about what things they would like to see in core. And so we use that as an input as well. And so for example, the last survey, automatic updates was like the number one thing by far. And so that's how we decided that we should have that in core. So there's very grassroots ways. And then there is kind of top down ways based on community inputs. It's not like just me deciding it. It's like we go through a survey and a process of looking at the data, that kind of stuff. And then there is also this lens about core should be about infrastructure. And so we actually talked a little bit about this in the previous Drees node in Portland where we look at how many people use it, what's the effort to maintain it as well. And we kind of try to decide if it's core worthy that way. So, and then sometimes we move things from contrib to core. I don't think I've completed that point, but if something gets built in contrib and it gets really widely adopted to the point that basically everybody installs it, then we move it into core. And examples of that are what was called CCK, as well as views. These were two modules that basically almost everybody used. And so we felt, all right, it's better if we put it in core because then we can maintain it in core and we can kind of simplify a few things around guaranteeing a good upgrade process and that kind of stuff. I think Path Auto is the one that's for me. I use it in every size. Yeah, that's, yeah. Is it the number one module right now? Yeah, it is. No. Definitely in the top five, I think. That's token. It's probably one of them. Show your questions. It might be candidates for inclusion. Yeah. Just a changing topic ever so slightly, like a bit back to the promotion, but Drupal Commerce is quite powerful and it's sort of the leading Drupal platform for e-commerce. Why is it not promoted as much or talked to? I don't know the answer, but it should be promoted more because it's pretty a great set of modules to build, for a certain category of commerce websites, it's like excellent and very full-featured and powerful capabilities, but that's a good example of what we need to promote more because they have incredible references. There's like 60,000 websites using Drupal Commerce. Wow. It's a lot of sites. And some of these sites are pretty impressive sites. I was actually talking to Ryan who is sort of the founder of Drupal Commerce. I don't know if Ryan is here, but he was talking about a website, I won't say the name, but it's a pharmaceutical company that uses Drupal Commerce to, I think they sell COVID tests. And they're now doing billions of dollars in like e-commerce revenue through Drupal Commerce. Incredible, incredible use case. And that's just one of the sites of the 60,000. So there's all these great sites using Drupal Commerce, but it goes back to like, we need to have some promotion around Drupal Commerce. And again, Drupal Commerce in a way competes with large commerce platforms. And commerce is a larger industry than content management. Like CMS is small, commerce is large. So we're up against the commerce tools of the world's, magentos of the world, these large companies. And so you could think these companies probably have marketing teams of 20, 30 people, that all they do is promote commerce. And so we have nothing. So I think that alone, we could spend a lot of time and effort promoting our commerce solution. I don't think we'll ever get to 20, 30 people to promote Drupal Commerce, but just promoting it better, I think, could go a very long way. So I'm conscious that we're out of time. It's now flashing at me. But I do have two more quick questions. I'll be brief. So are you still willing to submit a video recipe for you, Mami? Yes. And what recipe would it be? I'm going to enroll my wife into the project. Together, we can do it. What recipe? Oh, good question. Well, actually, it's a fun anecdote. Like, one of the things we like to do is write a cookbook together, because she is a great cook and I like photography. And we have all these ideas for recipes, so we would love to contribute a recipe. We don't know which one, but we'll find something. And last question. Where did you source the amazing background pictures you had in your sites? Where did you source? Where did you get the amazing pictures you had in your sites? I actually don't know. So I work with a designer. So I make black and white slides, I call them, ugly slides, and then I hand the slides to her, and she makes it all pretty, and she has various sources to get the artwork in the slides. Yeah. They were amazing. And I'm very lucky that it's Ash, and some of you have met her. She's been helping with my slides for many years. And actually, we were talking about this the other day as well, but like around 10 years ago, I decided to get serious about my Dries notes, because I felt like I only get the stage in front of the Drupal community, like at large, if you will, twice a year. And before that, some of you might remember, I actually presented black and white slides. And about 10 years ago, I said, you know what, I'm gonna actually spend a lot of time and money too, creating slides and upping the production quality. And so I hired a designer to help me, and I still work with her today. So all the credit goes to her. Well, she does an amazing job. Yeah, she does. You've also given an amazing keynote, so thank you very much, Dries. All right, thank you very much.