 Okay, thank you everyone. I hope you enjoyed that presentation. It's great to have all of you here asking questions and thank you to everyone who's already submitted your questions. I'll be doing my best to go through the most sort of upvoted inquiries from all of you here in the community. As I said earlier, if you have trouble using the online service, we do also have mics available as well, so go up and stand at the mic and when I catch your attention, I'll have you ask your questions. But let's jump right in. The top voted questionaries is how have the last two years changed your thinking about our continued reliance on in-person events for both building the project and funding the Drupal Association? I mean, I think in-person events have always been critical to Drupal success. So I wouldn't want to get rid of them in any way or shape, you know? I think it's hard sometimes to work together without never having met each other in-person. I think, I mean, it's entirely doable, of course, and we're the proof of that. But what I've noticed in the last 21 years is that relationships can really change once you've met somebody in-person. It's a lot harder to be, you know, to be, you know, people trying to use the right words here, but like to put it bluntly, I think it's a lot harder to be an asshole after you've met somebody in-person, you know what I mean? And so I think that's probably too strong of a statement, but like making these connections and building relationships is critical to how we interact. And I think it's also what gives meaning. You know, I talked a little bit on stage about how my person, a purpose, has changed over the years, and it's, today, it's a combination of meaningful work as well as the meaningful relationships that I've built over the many years in the Drupal project. And I really do believe that they've become meaningful relationships because we've met in-person. It doesn't mean you couldn't have a meaningful relationship with somebody just without meeting in-person, but I do think it helps a lot. It helps a lot to hang out together, get to know each other more on a personal level than just talking about maybe code or the kind of stuff. So I'm kind of long winded here, but I think it's critical, you know? I would never want to see events go away. I think that's fair, and I think speaking from the Drupal Association's perspective, events have always been a big part of who we are. As Dries mentioned in one of the earlier sessions this week, the Drupal Association was founded out of the kind of surprise that DrupalCon events, volunteer-driven, were getting bigger and bigger and bigger and creating this community of people and a source of funding that could be used to do a greater good, to amplify the Drupal project further. And since then, obviously, we've become, you know, aware of the risks that come along with that, having a major funding source be these in-person events, right? We had to weather that storm over the course of the last two years, and we did it very well, thanks to some really good planning at the board and leadership level of the association and the support of the community, which was critical. But I know that's a conversation that we talk about a lot and that the board talks about a lot is just that diversification of the base of the Drupal Association support so that we can adapt to these changing situations. I'd also add on a personal level that one of the more delightful outcomes of going virtual over the last two years is we had so many people present at our virtual DrupalCon events who could never have made the trip before, never afforded the travel, all those sorts of things. And that's something we've also talked about how to capitalize on that again in future and make that possible. And one of the things we've realized, and I don't know how many hybrid events any of you may have attended before, like the idea of doing the simultaneous in-person and virtual, is those can be very tricky. Like I myself found myself feeling a little bit left out of I think it was the All Things Open Conference, which I attended as one of the virtual speakers, and I saw so many of my friends from this community and other communities who were attending the in-person component and like didn't quite work. So we're trying to figure out the right model for enabling those interactions, but also being fully present when we are here together in person and can take most advantage of that. So I hope that begins to answer the question and I'm sure we can go through it more. Also related to sort of the new environment of the last couple of years, the question is how is the health of our contributor pipeline? Has the pandemic helped or hindered our efforts to grow the community? It's a good question. I think I would give it a mixed scorecard in a way. I think the commercial ecosystem is doing well and they're hiring people. So that's a very positive sort of result and I see it at AQUI and my own company as well. The negative is actually that a lot of these people have been so busy dealing with client work that they haven't had the chance to contribute as much and also maybe had some fatigue because they're always on their computers. So what we've seen is that Drupal is kind of accelerating the businesses in the Drupal ecosystem are accelerating, but we did see a small drop in total amount of contribution. Now, the other thing that I should add because I did all these analysis on it because I look at contribution annually, which I've come to realize might not be the right way to do it because there is a cycle. There is a time element to contribution. So what we see is that just before a major release of Drupal, there's this huge spike of contribution because all of the contributors are trying to get their modules ready. And so when I looked at the data, last time I looked at the data was like six months ago, we saw a short drop, a small drop in contribution, but we were also not measuring like this peak of the cycle. You know what I mean? So I fully expect that contribution will go up this year because of the Drupal 10 release cycle and the timing elements of that. So anyway, I think overall the community estate pretty healthy despite everything. I think that's my perception as well. I'd love to actually ask you to, I mean, speaking of contribution, at the end of your presentation, you gave kind of a vision of more organizational contribution. And maybe you could just expand a little bit on what you're seeing as the right first step for an organization who's interested in doing that to take to begin this process. I mean, I think there's many different ways to get involved, but it always helps, I think, if you start with something that you are actually passionate about or that you have a need for yourself or that you see one of your customers has a need for. I mean, I think it's a natural place to get started with those things. And that could be anything from making our documentation better to fixing a bug that you've run into to taking on something that you really need yourself. If you look at the history of some of the bigger innovations, a lot of the workflow tools that we added to Drupal 9 were actually funded by Pfizer. They said, we need these improvements and we're gonna contribute them to Drupal Core because they also recognize that they could build them really quick for themselves or even put them in contrib, but they've made a long-term strategic bet on Drupal. They wanna keep using Drupal for the next 10, 20 years. And so, if you think long-term, it actually makes a lot of sense to try and get these things into core so that the community as a whole kind of keeps innovating and improving on those core capabilities, right? So, sometimes it's driven from a need like that, like it's something that's missing in Drupal. So, yeah. Okay, awesome. So the next question here has to do with the extension of Drupal 7 End of Life, which is something we've mentioned across a couple other presentations. And the question asks, how can we best confront the reality that Drupal 7's remarkably durability represents a branch or even a fork of Drupal in a way with its longevity and one that might need maintenance, perhaps in perpetuity? How do you think about it? Yeah, well, I was the person that helped push for the extension and as you know, it was a topic of debate, right? Not everybody liked the fact that we extended Drupal 7, but at the end of the day, when we looked at the data, 60% of all the Drupal sites were still using Drupal 7 and it just didn't feel right to not support those people. And actually have a funny story that's related to that. So, my dad is a medical doctor. He doesn't really know much about the web or Drupal, but one of his patients has a Drupal site. She runs a small non-profit and they use Drupal 7 and they've been integrated with CBCRM and it's a non-profit that helps, I think it helps women with cancer. And she has a very small budget and she went to visit my dad, you know. And she starts complaining to my dad that she has to upgrade from Drupal 7 to Drupal 9. And of course my dad is like, oh, here's my son's phone number. You should give him a call. And she did and we had a great conversation and she was saying like, you know, my budget is $10,000 a year. You know, we spent all of it building our websites five years ago or six, I forgot what she said, but maybe 10 years ago. And we really don't have the money. We do not have the money to upgrade. We can't do it, you know. And I think there's a lot of people in that situation that literally can do it. So sometimes I hear people say, well, you know, we should stop support. People just have to upgrade. But the reality is a lot of organizations just can't afford to upgrade. And that's why I felt it was the responsible thing to do to extend the life of Drupal 7. And we're doing it sort of minimally, you know. We're not committing to fixing bugs. We actually reduced the scope of it too. We said we're only gonna focus on sort of important or critical security updates. You know, like Acre even committed to helping doing most of the work, frankly. And so I think it's good, you know. It's good for our end users. And that's what, I mean, I feel strongly that it's the right thing to do. I also understand it is a burden on some people. I also understand that it may have cost some pipeline to dry up for some of the Drupal shops because all of a sudden we gave some relief and all of these things. But the reality is these organizations, they do have to upgrade. And it's not just because of Drupal but a lot of these sites are built on, I forgot what it was, which version of PHP. But that version of PHP is actually end of life in November of this year. So even though we will provide support for Drupal 7, their underlying platform PHP and even my sequel probably are end of life, you know. So there is other problems and other drivers that hopefully will encourage organizations to upgrade, so. Awesome, thank you. I think the next question here relates a little bit to our conversation about the future of the web on Monday and emerging technologies, which is the question is how can Drupal best take advantage of the boom in web three technologies and what do we risk if we don't quickly adopt them? And maybe first I should ask, what's your understanding of what web three technologies are, what that could mean? Yeah, yeah, I think it means, so first of all, I'm very concerned about the impact on climate and on the environment. And so I think we have to tread very carefully. And I think we have to find the right balance. I think we have to be curious about them and monitor what's going on. I don't believe we need to rush to any of these things. I believe that either they'll die these ideas or they'll become better, right? And I think a lot of technology in the world goes through this long optimization cycle. A lot of things that are invented are actually bad at first for the environment and then over time, people work out all of the problems. And I think we can be patient, like keep an eye on these things, but be patient. So I wanted to start with that because I'm, I don't wanna necessarily advocate that we jump through these technologies and I haven't. I haven't spent my own time, my own resources into them, but I have tested a lot of the technologies kind of at night and on the weekends. So I feel like I have a reasonable handle on what they are. There's probably a lot to talk about there, but in a way, I think about them as a set of services that we may or may not wanna use in our projects. Like let me give an example of that. I mean, you have some core technologies like ENS, which is an alternative to DNS and these kinds of things. You have the interplanetary file system, which is actually not blockchain based, but it's a new file system technology that's more decentralized. They have a blockchain layer to it, which is called Filecoin and some alternatives that provide incentive models using the blockchain to incentivize organizations to replicate data, which is interesting, but I do believe there's gonna be new technologies in the future, like one example. There's a lot of innovation sort of in financial services right now, and so let's say you have an e-commerce website. One of the hot trends in the last few years is like this and you probably all have seen it where you can buy something and when you pay for it, you're actually signing up for a loan and you can pay it in 12 months, you know? Have you seen those things? I feel like it came out of nowhere, but so there's third party companies that provide these kind of loans for e-commerce purchases and like a component like this, I could see a blockchain based alternative where you don't have to rely on a central company like a bank or a financial institution to provide these loans. I could see that being a completely automated service with a smart contract that just brokers between different parties and I can see that being interesting because I can see that being at lower interest rates than banks and that is interesting because if I can offer that kind of pay-over-time service at a lower interest rate, the product will cost me less as an end user and so now I can see organizations adopting that because either they have to pay less to these financial institutions or they can make the product available at a more attractive price. So I think at some point we'll see services like that and I think of them as a web service that you may wanna use in your e-commerce, website implementations, but at the end of the day, we'll be building websites in HTML, CSS, JavaScript and we'll be integrating with some of these, potentially it'd be integrating with some of these components. That's how I think about it, I don't know, maybe I'm oversimplifying it, Tim, but and then I also do think there might be some interesting outcomes, not for how we build websites, but how we run an open source project, like there's a lot of experimentation with governance models and how do you make sort of decentralized decisions, funding models I think is interesting? I mean, I don't like NFTs at all but there are some interesting ideas which is basically how do we make sure that value artists create things, developers are kind of artists, they create things, how can we make value go back to the artists? How can we, when somebody maintains and builds something, how can we actually reward them? Financially, is there models for sustaining open source? It's early, early days I think, but you can see some experiments which I think is interesting, but again, to me to be very clear, it's only interesting if we can do it in a responsible way and who knows what will happen. So I would encourage people to pay attention, doesn't mean you have to, you can pay attention without having to make huge investments in it or even any investment in it, so. Very cool. All right, so our next question here relates to the new vision for the ambitious site builders, the new mission for the ambitious site builders and it's kind of a clarification, do you think that this concept is in conflict with a move towards headless or decoupled experiences or custom JS front ends? I don't think so really, they might feel like that to people at first, but then you look at something like Next.js for Drupal, it's basically a decoupled UI which allows you to build forms with it and drag and drop things, so I think they go hand in hand. I mean I think we have no choice but to invest in headless because we need to publish content to multiple channels, we need to embrace those JavaScript frameworks, but we can make it so, we can do these things in a way that is interesting to ambitious site builders, so I don't, I can see why people might think that it is in conflict, but I personally don't think it is. And I think I can give another example. I've seen an implementation, I think it was with Penn State News where they have a Gatsby front end and there's a sort of a prototype of doing a full site preview directly in the Drupal editorial experience, so retaining Drupal's editorial experience and control for the site builders with that fully decoupled front end layer, so these kinds of things are possible and still being built in an area of innovation. And honestly, I think these frameworks are probably gonna end up focusing on site builders too, I think it might be a natural, I mean, I think a lot of these technologies, headless, decoupled, I do think they're all coming together. Like the headless and decoupled vendors adding more capabilities for marketers. Traditional CMSs, if you will, like Drupal, we've added the headless capability, so I think in the end we'll be more alike than different. I think that's the long-term steady state. Okay, our next question relates to the governance of the Drupal project. And Drupal was often spoken about along with many other open source projects as a BDFL project, a project with a benevolent dictator for life, and I've noticed that you've moved your language to project lead, and I think that's been a deliberate choice, but the question is, does the project have a succession plan for you? Yeah, it's a good question. And first of all, I agree with that language not being, actually, I don't recall using it ever myself, it's what other people have called me. But yeah, I do think a lot about succession planning and over the many years I feel like I've put a lot of things in place, people may not think about it that way, but like even the Drupal association is kind of part of a succession plan because I ended up, in the early days, I administered to Drupal.org. That was what I did, you know, and obviously that's been taken over by the Drupal association. You know, on the core committer side, we have a great team of core committers. You know, we add people, we have provisional committers, so like we're thinking about succession planning for each of the roles on the committer team. You know, is there more I can do? Probably, but I do think that I could go away for six months or a year and everything would keep running. I feel like I understand some people are concerned still and that they like to see more and I'm very open to put more things in place to be quite honest, but I do think about it, I feel like I try to put things in place, I understand there's still some things that I do uniquely, like maybe going up on stage here and talking about a vision and a strategy, so maybe that part we need to think a little bit more about. There's different ways to do it, you know, and you can be public about it or you can, you know, and again, I'm not comparing myself with Warren Buffett or something, but people speculate who's gonna be the successor of Warren Buffett at the same time, he has it written somewhere on a piece of paper, you know, in case, you know, it needs to be. Does the DA keep a secret vault? So yeah, I don't know who asked the question and if it satisfies, the answer satisfies you, but I do feel like, you know, there's not many big, not many decisions that I'm actually involved in or that need to be involved in. I might be, I don't know if people realize that, but a lot of things are at a place they've kind of run themselves and sometimes I'm an escalation point or sometimes I contribute to do the decision, but it doesn't mean I have to be involved in a decision. All right, so our next question is about the great module migration that you've just proposed. A goal being to reduce the size of core or more specifically kind of the maintenance burden of core really. On the inverse, are there any essential contributed modules that might be brought into core and there's a related question here as you mentioned like web form, for example, as a top 10 module, was that the sort of thing that fits in the content model bucket and therefore under the rubric maybe should be in core? Yeah, no, I think it's a great idea and we actually talked a little bit about it, like we can use that exact same algorithm to have modules move the other way, right? Instead of moving them out of core, we could move them into core. We haven't explored that, but it could be potentially interesting to do that. So I don't know at the top of my head if web forms would classify, but most likely it could classify. And let's say it does, it doesn't mean we have to either. It's being maintained well and this is where the starter templates and project browser comes in because we can actually make it really easy for people to discover it and install it, you know? And so that relieves the need to be in core. Like we add things to core because we feel like everybody should know about this module and a lot of people will install it. So it removes friction. We remove friction by adding things to core, but if we can remove that friction in another way through project browser, for example, and we also add things to core because it removes friction from the maintenance and ongoing updates, right? Like you update core as a whole. We test every core module with every other core module, for example, so we know that these modules will work together and that they're upgradable. But I think we can get to some of the same ideas through project browser, starter kits, automatic updates, all of these things and that would be pretty compelling to me. And I would add to that, if we successfully reduce the friction of using modules, non-core components in people's Drupal sites, I think that would also relieve an underlying anxiety that to call back to our earlier conversation, some individuals or organizations have about the idea of putting forward some new innovation when they don't feel like they know how. Like core seems like the essential gate to bringing these big ideas, but there's so much room for innovation in the contrib space that can achieve the same scale. Like again, we're using webform as the example, but like that's used a lot more than forum module on most sites, right? It's not in core. So I think we can enable that more and hopefully enable folks out here who are trying to figure out how can I be part of the next big feature of Drupal to do so without necessarily having to have this conversation about, well, does it belong in core? Let's take a question from the microphone. I saw the microphones here, so I thought I'd just jump up since I put a question in that's basically piggybacks off of this. And that is, is there any interest in maybe splitting core from a model repo that has all of the sort of core modules in it to having and not just a core and contrib, but having like a core supported tier of modules as well so that you can really sort of build this out and bring modules in and out of that core supported tier more easily? Yeah, I mean, I think it's an interesting idea. Not sure if we've recently discussed that idea to be honest, but the way I would look at it is through the end of the end user. Like we can do these things and if the help is innovate, great. But like how do you make sure it's really good experience, right? For the end user, whether it's installation, upgrade or maintenance experience. If we can guarantee, like I would say, first we need to guarantee the best possible user experience. And then the second thing is like, how do we, what's the organizational structure for how we built these modules? So I think if we can guarantee a great user experience and do this because maybe it helps us go faster then we should strongly consider it. You know, and that's why I'm excited about this composable core strategy because it allows us to take steps in that direction. You know, and we're gonna remove some modules. We're starting with 20% of the modules and these are the least used modules or the least strategic or important modules. And we're gonna see how this works. You know, we're gonna take a first step and then if that goes well, I think to me that feels like maybe like a second step, right, like we can learn from the experiences and as the software project browser which we haven't built yet, matures as we know that automatic updates work which is a really complex thing to do because we don't wanna break people's sights, obviously. If we know that project browser works and starter templates and we've built this robust, reliable, automatic update system, then I think that opens a lot of doors for ideas like the one that you just, you know, suggested. So I think it's a good idea. I just wanna go be careful that we don't impact sort of the end user experience. Right. You know, so. Thank you. I'm really excited about the ambitious site builders plan. I think it's great. One thing that I've noticed amongst site builders that are less technical and are not writing custom code is that they tend to be a bit scared of configuration management and that they're not actually using that on their projects. Like at the higher ed summit yesterday, I think I heard about frameworks where there's, or platforms where there's 400 websites and nobody's using configuration management for anything. So I'm wondering if putting some, something like automatic updates but for configuration management to be more UI based into Drupal would be something to consider. Yeah, could you repeat the last sentence? I'm not sure I got the last sentence, sorry. If putting something more visual so you could have a UI for configuration management, that was easy to use. Oh yeah, okay. Yeah, I think it's a great idea. I think you're right. Like there's kind of different levels, right? Like there's using the UI where you can drag and drop or configure things. There's still some configuration only in, configuration files that's maybe hard to manage and then there's actually a writing code and I do think a lot of ambitious site builders, they may not have a, they're not professional developers per se and I know a lot of people got into Drupal because they started using the UI and then they hit like some sort of limitation and then they had to learn some PHP and that was like often their first experience writing code. So if we can push that out as much as possible, the better it would be I think. So if we can build more UIs while providing a lot of flexibility and power, I think that should be our preferred path. So I would be curious what we can do around configuration management specifically to make that easier for site builders. So. Awesome. Okay, back from our set of online questions. Our next question is what's your continuing vision for decoupled experiences with Drupal or headless experiences with Drupal? Yeah, no, it's a great question. I mean, first of all, I think, I think what we have right now is very good. I can tell you from what I see at Acquia, it's one point of view, but we don't lose deals against the contentfuls of the world for capabilities. When we lose a deal, it's only because they have a SaaS solution and it's kind of easier to install and they don't have to do updates. But it's never because of the headless capabilities. In fact, we often win because we have better authoring, we have better multilingual. There's a lot of things better in Drupal. So just wanted to start with sort of the competitive viewpoints. But sometimes I feel like people don't realize how strong Drupal is in this space. At the same time, I think there's a lot of things we can do. We can add more REST APIs to more parts of Drupal and that's why we have the decoupled menu initiative because whenever somebody builds a JavaScript front-end, very often they hard-code the menu, right? And they do that with Contentful and others too, by the way. And so that was silly. I think that is silly. And so that's where the decoupled menu initiative comes in because we want people to be able to administer, create, administer menus in Drupal. We want to empower, let's say marketers or content creators to do that and then magically their decoupled application is updated. And that's not something that competitors do. We have a quote that works. We're trying to get it into core. That's just one example. But there's other examples like that. Pieces that we can take where we can say, we can go from like, why are people hand-coding this too? How can we make this sort of like, you know, deeply integrated with the CMS? So I think there's a list of opportunities like that. And personally, and I alluded to this, I think it would be great if we could actually rewrite the Drupal admin UI using a JavaScript solution at some point as well. The challenge is not, the challenge is like, it's just a lot of work and who's gonna do it. But that would be healthy too for Drupal because it would really, obviously, we would be eating our own dog food, as we say, or drinking our own champagne, I feel like that better. You know? Absolutely. I think there's lots of folks out there who've been working on decoupled projects and have those projects who are well positioned to understand this problem space, to come in and take their recent client work in this area and turn it into contributions. And in case some folks don't know, for more than a year now, you have been able to publish components on Drupal.org, Drupal components other than just modules and themes. You can publish JavaScript components. You can configure pipelines through new GitLab integration for publishing to NPM. All these sorts of things are possible now. So it should hopefully open up the capabilities for people who are working more in the JavaScript world to bring that back into our Drupal ecosystem. Yeah, one of the things I would love to see, and maybe somebody feels compelled to work on it, is a headless install profile in core. So right now when you install Drupal, you can select between, I think, standards, forgot what it's called actually, an umami, let's say, as another install profile. But imagine there's another option that's like the headless install profile, which would pre-configure Drupal for headless things. So it would basically disable things that you don't typically need in a pure headless configuration because I think that would actually be good marketing too, in a way. Like when you install Drupal, you can actually see, like, look, it has this other way of being configured. And then it also kind of removes some friction out of the configuration process because that's an advantage that some of these other systems have. Like they're just the experience, again, the experience is optimized for that kind of use case, and we haven't done that. So often people have to enable JSON API module because it's not enabled by default, I think, or they have to disable, I don't know, some stuff because it's not relevant for a headless application. And that might be a reasonably doable contribution. That might be doable, I don't know how long it would take, but maybe a couple of weeks of work or something. Get over to that contribution room and we'll get it done. All right, let's take a question from the mic. It seems like one of the bigger challenges with upgrading from D7 to D9 is the lack of, you know, where did this hook function go? How do I replace it? Is there any plans to add something like that to the documentation? Because currently it's like, you can look through the comments and hopefully there's like a link to the D8 version in which you'll find one to the D9 version. Or is there anything on the horizon for that? Or is that been discussed? I'm not sure I know the answer to that. It's a good question. The current documentation, right, as you know on Drupal.org, you kind of get separated by major versions. You have kind of the self-contained Drupal 7 and then the Drupal 9. I'm not aware that there is a like machine, parsable mapping between what were the deprecated functions or the changes in functions from 7 to 9. So I don't think that is currently an active plan. I think probably this is an area, there's another question here as well about, you know, considering that Drupal 7's life has been extended and we have, you know, 55%, 60% of sites there. Are there more efforts planned to make this upgrade path easier? People continue to work on the upgrade path. Like, you know, there is a migrate modules in core and every week there is improvements being made to these modules. So we're finding bugs or additions that we add to it all the time. Even though it's been out for a long time, it keeps on getting better. And I think there's really something interesting about your question because it reminds me of what's being done today for the like 8, 9, 10 cycle where we're using Drupal Rector and PHP stand to have automatic kind of deprecation patches and things like that. And there wasn't really an equivalent kind of bridge between 7 and 9 and maybe there's still room for people to try and work on one. Thank you very much. Thank you for this suggestion though. Yeah. Good morning, this is Jason. It's a privilege to be here and I have attended a few Dries notes before. In a previous talk, you just, I think you presented a video that walked through the different steps that it takes to get Drupal set up. And so I was wondering, I know that was a pain point, you know, in terms of like that steep learning curve to get like new people into the platform. Can you describe like how you feel about where Drupal stands now and making that objective or if there's more room for improvement? Yeah, no, I think we made a lot of progress but there's more room for improvement. That's again at the headline. If you think of what we did over the years, like first of all, you have to install all the necessary tools to install Drupal in. And now you can actually install Drupal with a one line command line commands. Is that right? But a command line, that's like one sentence. All right, so that's a great thing. We also see things like DDEV and Lando that make the installation a lot easier. So I think there's a lot of great steps taken towards making that simpler. And then we did things like Umami, you know, for people that are exploring Drupal and just want to learn about how Drupal works and how you create some content. So that was an initiative that we completed to make that experience better. And in many ways the project browser and the starter templates that I just talked about are kind of next steps in that kind of mission to really improve, you know, the onboarding journey as well as the installation experience of Drupal. And honestly, I don't think we'll ever be done. We'll have to continue to work on this. And funny enough, I don't know if you were in the, was it the Monday keynote panel? We had Adam, was it Adam? From WordPress in the audience? I'm not sure if you are here, but he actually is a WordPress core committer. So deep into WordPress. And he was actually saying like, wow, I installed Drupal and I was amazed how easy it is to install compared to WordPress. I mean, I don't think I would ever expect to hear these words in my lifetime, you know? Let alone from a WordPress core committer, right? So what that means is we're making some good improvements. But I'm not, you know, I'm well aware that we have many more improvements to make. So. Thank you, Jason. Yeah, thank you. All right, let's take the next question. This may be our last one or maybe we'll have time for one more, let's see. Good, I got in line. So, yeah, Todd Smith, Digital World Biology. One question is the future of PHP. So, one of the challenges I see is getting students interested in it. It just, you know, I hear from faculty and stuff, no one wants to learn PHP. And yet, when I look at the internet, it kind of runs a lot of things. And from my perspective, it seems like there's a lot of job opportunities. Yeah, yeah, yeah. Well, that's a great question. Thank you. I have a two-sided answer, I guess. You know, one, I see like the amount of innovation PHP is receiving is at the highest levels that I've seen in the last 20 years. You know, like some of the advancements in PHP 8, they're pretty exciting and impressive. Impressive, very. Like, PHP is closing a lot of gaps relative to other technologies very quickly. So, there's almost like this Renaissance, PHP Renaissance, which I think is very good for Drupal. And we're taking advantage of these new improvements in Drupal. It's one of the reasons why we wanted to go to 8.1 even, because there's like cool innovations that would make Drupal easier and better and faster. So, that's great. And then, the factual reality is, PHP is still, I think, the number one used language on the web today. It may not have the most buzz today, but it's, you know, it's used a lot by a lot of sites. I think WordPress is now 80 or 75% of all of the websites in the world. So, that alone makes PHP, you know, it's not gonna die anytime soon. Like, the massive install base combined with the innovation, I think makes it a great technology to focus on. If you look at Symphony, for example, I mean, Symphony is exploding. You look at the charts, they're going like, you know, straight up. And so, you know, Drupal is built, obviously, on Symphony. You can think of Drupal as a Symphony application. So, that's been a great choice that we've made, you know, and we're kind of taking advantage of that in a way. So, I think we're good. You know, I'm not worried about it. At the same time, I'm not blind to the fact that JavaScript is growing very, very fast, that they may not be teaching PHP in schools, but they're more likely to teach JavaScript in schools that people that come out of college, they want to use JavaScript because it has a lot of, you know, buzz and momentum. It feels like a great career choice to become a JavaScript developer. You know, that is also true, right? I think both of these things are true, and I think they can be true at the same time, which is another reason why it's great that we're investing in headless and decoupled. People are using Drupal in combination with these JavaScript technologies because you still need a content store, you know? You still need to manage content, and Drupal is one of the best solutions for managing content, but it's also why I would love to see more investment in headless and could be really smart for Drupal's longevity to rewrite our admin UI in JavaScript, right? Like, we can evolve to be a mix of PHP and JavaScript or, you know, shift the mix, I guess, the distribution of how much PHP versus JavaScript we have. So we're kind of working on that steadily, but slowly. That's how I think about it. So we're in good shape with PHP. We can work with all of the JavaScript-based solutions out there, but we should consider adding more JavaScript to core. Could be nice to align ourselves with trends because I don't think the JavaScript movement is gonna go away, you know? It's so vast, it's so big, it's gonna be here forever, just like PHP will be here for a long time, too. I think that's all the time we have for today, so thank you again, everyone, for joining us and the wonderful questions, we really appreciate it, and please enjoy the rest of Drupal.