 that's recording? No. Okay, so this is what I... I'm already off. Yeah, so this is what I want to get through today. I'll quickly go through who I am, my Drupal journey. What I was wrong about with backdrop, what it was wrong about with Drupal, and what I'm excited about with Drupal, and but why I'm still promoting backdrop over Drupal. And so if you want to find me, the easiest way is to Google Kevin Drupal Beard. My full name is Kevin Reinen. I know my last name is hard to pronounce and spell. That's kind of a marketing faux pas on my parent's part. But I'm currently a senior developer in the web apps team at the University of Colorado System Level University Information Systems Group, and that's a very long way of saying I'm a Drupal developer above the campus level. We serve four campuses for the University of Colorado, but a lot of what I'm going to talk about is from my time at the University of Colorado Boulder campus, and there I was the manager of product development for our CMS as a service solution called WebExpress. And that was a no-code self-service model for colleges, departments, academic programs, labs, faculty, and even student groups to build their own sites for free. So pretty common model and higher ed now, but fairly unique at the time we started that project. And so as I'm giving this talk, it's important to understand that I now build solutions that solve problems for all four campuses, and the types of sites I build now are different from most of the sites I've been involved in at the University. So I'm not this person who unfortunately competes with me for the name Kevin Beard. So why should you listen to me when the title of this session is that we did things wrong. We made the wrong choices. So I'm going to share the slides and try to summarize some of this stuff in blog posts, but in the presentation you'll notice there's a lot of footnotes to previous presentations at Drupal camps, Drupal cons. I've been talking about the same things for a very long time, as have several people on the teams I've worked on. They're very smart, talented people. We've done big Drupal sites, lots of Drupal sites, and I think we do them relatively well, as shown by WebExpress. The Express Insult profile is the fourth most popular distribution on Drupal.org with more than 2,500 reported installs. I know reported installs isn't a completely accurate measure, and most of these installs are coming from the University of Colorado, but it's far more popular than open social, open atrium, lightning, open EDU distributions that are a lot better known. And then every once in a while we run into sites like this, where even though all over the distribution it says this is for inspiration only, the University of Colorado does not intend for people to use this outside of our campuses. There are people, all the codes available, there are people that will do that. And it's frustrating because if you look in the source code, they don't actually do it well. So I really wish as a group we were able to support this, and I could reach out to them and ask them why they have debugging on, why they aren't optimizing their CSS. But that's not what our group does. We're only interested in selling Drupal to our university. We're not pitching this as a solution outside of CU. So most of you know the Drupal learning curve diagram. In here I actually tweeted about this earlier in the week. Somebody tracked down the origin of this, and it's actually like a video game meme from even before Drupal. So you can read about that if you're interested. But I built my first Drupal site in 2004. That was just a intranet for a computer lab where documentation about the lab was stored. And then in 2006 I had been promoted to the Director of Instructional Technology at this college. And so as part of my job managing computer labs, because I knew computers, I also managed the website. And so I launched five sites for the college, one for the college and four departments. Then I left to do some work for the Knight Foundation and worked on a couple different projects, one for the University of Nevada, teaching Drupal to journalists, and we built a lot of Drupal solutions and taught Drupal. There ended up hearing about a conference in Sunnyvale, California that was going to be talking about Drupal. Submitted a session there, got accepted, didn't really know what I was going to. Turned out it was the open source CMS summit, which is technically the first North American Drupal con where Drupal and WordPress were both so unpopular that they were at the same conference at the same time. So kind of fell into this at that point. And so part of what we were doing with the Knight Foundation was building solutions for journalism organizations. And there were two different projects, one for community television, one for community radio, that took some of our funding, and the Drupal Association matched that. And we helped fund package distributions on Drupal.org. And so I've been building distributions since distributions were a thing and built distributions for a lot of different organizations, both big and small, National Social Realtors, Corporation for Public Broadcasting, Pearson Education. But I also work for a lot of small nonprofits doing Civi CRM starter kits for them, and hosting those on Pantheon to do more of a self service model. So at CU, I worked there at CU Boulder campus from 2015 to 2019. We thought we had a team of seasoned Drupal developers, we had gotten to the top of the Drupal learning curve, we cleared off all the dead bodies. And we had built this train of a large number of Drupal sites based on the same install profile. So when I got there, there were 200 sites, only about half of them were actually using the install profile, like many other groups, they started with an agency model where each site was inspired by the site before it. But we never had time to go back and update the previous sites. So 100 of them were using a modern approach to Drupal 100 required a developer to log in and manually update every time. And so we got serious about DevOps, wrote our own DevOps solution, everything was hosted on prem. And we were able to scale that service to 1000 sites once we started treating every site exactly the same way. So there are a number of presentations we've done at Drupal cons and Drupal camps about this. I'm not going to talk much more about it. Other than in 2018, we were we were sure that we had nailed this. And this train was just going to keep right on running. And then we started looking at Drupal 8. And we had basically been ignoring Drupal 8, because we were so focused on solving Drupal 7 problems. We thought, well, you know, Drupal 8 is coming, Drupal 6 to Drupal 7 was fine. Surely, everyone will consider our use case when developing Drupal 8. And it'll it'll all work fine. Obviously, there were a lot of challenges getting a large number of sites upgraded to Drupal 8. And so we had the option of getting this train these 1000 sites up to the top of the next Drupal learning curve, which wasn't wasn't that appealing. And so we we were unfaithful. We started dating other CMSs. And so we tried WordPress with Gutenberg. That was kind of cool. New something new. We tried backdrop. We did Nova, October strappy, contentful API platform, basically any CMS that someone said, Hey, you should check this out. It's a great solution. Other than Drupal, we would install and spend some time with it. But we really kind of landed on on backdrop as a potential upgrade path. And what we pitched to our leadership was well backdrop wouldn't get us to the level of ambitious sites that Drupal 8 was marketing itself to be able to build. It would be an improvement over what we were currently offering faculty and staff. And so we kind of sold it as you know backdrop being the shortcut instead of having to get this train of 1000 sites all the way to the top of this hill by rebuilding them all both the code and then going back and rebuilding the sites, we're just going to go through this tunnel and end up on the other side and it's going to be going to be great. I was actually like super excited about this. We had Nate and Jen out before to the Boulder campus before Drupal Camp Colorado, and worked with them on some of the things we thought were sticking points, we ported a bunch of modules, we launched a site on this. And then I met with my boss and other leaders in the group, and they shot it down. And I'll talk more about why, but rejecting this option with the pending end of life because this is 2018 2019 now, which the end of life was going to be in two years 2021. I just couldn't get motivated about migrating all these sites. Like it wasn't exciting for me to work on this problem anymore. So I quit. I quit Drupal. I went and did Salesforce development for two years. I just ignored everything that was happening in Drupal. And I honestly am much better for it. I don't think I would have survived the frustration of trying to tackle this problem. So I still do a lot of Salesforce development. And I'm not going to try to convince you all to give up Drupal and become Salesforce developers. But Salesforce has an open source component to it. I'm going to be back in San Francisco next month for the community commons sprint. And they're even lightning web components themselves are open source. So you can build those those are the UI building blocks within Salesforce, but you can also build solutions with lightning web components that inherit the Salesforce look and feel outside of outside of that. So that's a lot of what I do now I do very tightly coupled marketing solutions for CU, where I do both Salesforce development and Drupal development part of marketing cloud, all of those types of things. So I want to be clear about this because I'm going to say some things that are going to sound contradictory. And I'm really two minds about the about modern Drupal and the future of CMS is what I want to work on personally, it is not always aligned with what I think we should be doing as an organization. And so I titled this that the University of Colorado chose Drupal over backdrop, but I really want to own this. I chose Drupal over backdrop. And I was wrong. I pushed for backdrop. But ultimately, instead of continuing to push for what I thought was the right direction technology, I quit. I just I gave up and went and did something else. So Zach Chandler, who said the same thing at the backdrop summit. The main reason that CU didn't go with with backdrop is because no one gets fired for buying IBM. We made a decision to use Drupal a decade ago. We had been upgrading Drupal. We had a huge investment in Drupal. But going with backdrop was was really an unknown. And so it was an unproven fork. And our leadership wasn't confident that that it would it would last. Ha, I guess they proved us wrong. So it really made sense from their perspective, because they were being deluged with marketing material from from aquia, and every agency we'd ever work with who wanted the work of upgrading our sites to to Drupal eight. And so everyone was hyping the advantages of Drupal eight. As a development team, we weren't really seeing those advantages. We didn't understand why we would we would upgrade why we would spend so much money. And so the shirt I'm wearing today is what I wore every day at Drupal Con Nashville. On the back, it asked people to change my view and convinced me that upgrading 1000 sites to D8 was was the right path. And what I was really hoping is that someone would pull me aside and be like, Kevin, this is the thing this is the killer app that will make all of the effort worthwhile. And it it just didn't happen. And so we we weren't able to go with backdrop. The team was told that we needed to focus on upgrading Drupal eight. I quit and my entire team quit. None of the developers that built that solution continue to work at at CU Boulder. Most of us continue to work in Drupal. We're just not interested in upgrading all of those sites. So another thing that we hear outside of CU's leadership, and I've heard it here this week as well, is that backdrop is only for people who who don't want to change. It's for people who don't like the command line. It's for people who hate composer. None of that is true. And if you take a look at backdrop, and earlier today, I learned that you can install backdrop with composer, which is just one less thing that that I have to worry about. So in a 45 minute presentation, I don't have enough time to do backdrop justice as to how awesome it is. And sitting through that summit, it's even better than than I thought it was. But I will say this that the backdrop community more than any other open source project I've ever worked in lives their values and principles. And how many of how many of you are still running Drupal seven somewhere? Okay, and how many of you are running backdrop? Okay, so yeah, you if you're not the same person, then you should talk to those people, because I I'm already sold on backdrop, but I'm I'm not currently running, running backdrop sites. And while I'm focused on the things I did wrong, and got wrong about both Drupal and backdrop, I do want to talk about the things I'm excited about as far as the future of Drupal and the type of solutions I want to build with with Drupal 10. So backdrop, obviously, is still around still gaining popularity. They do three features releases a year and have never never missed one. So the pace of change with backdrop is is slower. While at the same time, their road map and features are kind of like mind blowing how much better than Drupal seven. It is. And again, I'm not going to try to sell you on it. You can install it on pantheon or your own land or D dev instance. It is truly a much better Drupal seven experience. So the other thing that's happened, and I love looking at this because, you know, backdrop is a fork of Drupal, but they kept all of the commit history intact. So when you look at the project, you can see all of this activity until the fork and then it gets less active. And some people will look at that and be like, Well, look, it's not as popular. But it also doesn't change as much, which for the type of sites that we run at our university is a really good thing. Our sites haven't gotten spontaneously more ambitious in the last decade. They're basic sites with basic needs run and administered by people that aren't technologists and don't want to keep up with every change of every dependency off the island doing the most innovative things imaginable. But what I really like about this is that there's a whole new list of people that are contributing to backdrop core that are not were never core maintainers in Drupal. And so the community has changed its its focus changed its leadership changed its project management approach. And I really think it's all for the better. So backdrop continues to evolve. And I'll just use one example. But if you take a look at backdrop and the number of Drupal contrived modules that they've imported, it's it is really shocking how much better things are when when they get unblocked by legacy decision making. But here's a project that I'm involved in CSS injector. I haven't touched this project in five or six years. Somehow there's still 25,000 sites reportedly using it. Seven months ago after running a call for new co maintainers for over a year, I decided to post an issue saying that if no one was going to step up, we're going to market as unsupported. No one no one stepped up, no one responded 25,000 sites are going to see a notice if I click the unsupported button in the release manager. And on the last one of all the people that have contributed to this project, I'm the only one still active. And I have no interest in fixing PHP eight problems, rolling new security releases, answering any support requests for this project. But over in backdrop, not only are they actively maintaining it, they're adding new features to it. So it's it, there's life beyond Drupal for a lot of the tools that we developed over the last decade. So back drop doesn't have the same level of security as Drupal. That was somewhat true at the time. backdrop was piggybacking on the Drupal security team. But now the project is really coming to its own. It files CVE issues the same way that most open source projects do. So if you're using if you're an enterprise user using a tool like a rack knife to scan your servers for code that has potential issues, that's where services like CVE or where they get that information. And now backdrop shows up there, just like Drupal. So this is one that I have some some issues with and we've talked about this in the backdrop community that backdrop describes itself as being for small to medium sized businesses. CU is an enterprise. Okay, that's true. I mean, you can look at the backdrop about page and it literally says that's that's who it's for. But the question I keep coming back to is if Drupal seven was good enough for for this site, and this is the University of Colorado Boulder campus homepage, it's our highest traffic site of all the CU campuses. And the first releases of backdrop did nothing but improve the performance of Drupal seven. And it's a fork of what we are already using. Then how can backdrop not be better for the enterprise than what we what we're using right now. And so Stanford went forward where the University of Colorado would not and they've launched two sites. Zach Chandler talked about this earlier today. There's plenty of screencasts about this. They worked with Atten Design, Denver, Colorado, shop that is well known for doing Drupal sites. And they host this on Pantheon service that's well known for hosting Drupal sites. So the idea that backdrop isn't for enterprise is kind of, you know, misleading. If Drupal seven met your needs, and you happen to be an enterprise, backdrop is going to meet your needs just as well. So we've talked about the backdrop side of things. So won't last it won't won't improve isn't secure can't handle enterprise traffic. Obviously, none of that is true. So let's talk about the Drupal side of things. So before Drupal con Nashville, I made a blog post, there was a very active Reddit discussion about the things that I were have our team was having issues with with Drupal eight. And I'm just going to run through them here and how these have been fixed. You know, composer one worked fine for core. It as you built larger projects, you almost inevitably had to give it all of the memory in order for it to scan the the dependency trees. Composer two has solved most of those problems and really allows a lot of things that were never possible before. And then auto update is something that's coming with composer two three. So composer, I love composer now, I would never build PHP solutions without it. And now the fact that I know that you can build backdrop sites using composer is even better. But that was something that, you know, a lot of people struggled with early on. So the no longer supporting sim links, this may be an issue that was specific to our hosting environment. Again, we hosted everything on Prem. We use sim links to sim link all of the 1000 Drupal sites. So that from an APC opcode level, they were only being cached once. If those words don't mean anything to you, that's fine. It just know that we were doing we were trying to run Drupal in a very cost effective way. We only have three PHP servers in our environment, which we've now traded for 1000 pantheon instances, which doesn't even mean 1000 containers, it's 1000 PHP containers times the number you need for the performance package you're on, plus your database container. But what that allows us to do is run different solutions with different parts of our stack site structure. So when you look at Colorado DTU, if you go to slash engineering, that is a separate Drupal site from dub dub dub. And that's part of the architecture that got us to 1000 sites, because we built it as if to look as if it's one gigantic site, but it's a bunch of individual Drupal instances. And now on pantheon with advanced global CDN, we can actually reproduce that stack site. But slash engineering doesn't have to be Drupal seven. It could be Drupal nine. It could be WordPress. It can be backdrop. It really doesn't matter as long as it adheres to our accessibility security and branding standards. So Drupal eight was slower than Drupal seven. This was really frustrating. It took more memory to run and it responded slower, not only just in page render, but with editing experience as well. And so users had to do more clicks and use more steps to achieve the same look on the page. And so obviously, symphony and PHP continue to improve Drupal 10 on PHP 81 will probably be the fastest version of Drupal ever. And modules and services have evolved to improve the editor experience as well. We use Atten's layout paragraphs at CU at Drupalcon Portland, the sessions for drop solids rocket ship and paragraph layouts were just packed. So there's obviously an appetite to improve the out of the box editing experience beyond just us. And obviously, Acquia has their cohesion purchase that they rebranded as site studio. So all of these things kind of improve that issue of solve that problem. So install profile inheritance. This is one that that I was I was very wrong about for a very long time. So if you're not aware of this issue, it's over a decade old, it was still active until recently, we had to create a be continued version of it because it was actually breaking Drupal.org. So every distribution maintainer of a popular distribution at one point or another has been involved in trying to get install profile inheritance to work. And the concept is really easy to explain now because starter kit themes in Drupal work the same way where the idea is that instead of developing an install profile for the University of Colorado Boulder, and then forking that for the University of Colorado Denver, we create a University of Colorado install profile, and then we have sub profiles that handle the individual campus configuration. And it sounds great in theory. But the reality of anyone that worked with this and Acquia's lightning distribution included this patch to make this work knows that this was just a bad time and a bad idea. And so we went so far before Unami was added into Drupal core, we showed how it could be used as a as a sub profile because Unami doesn't add any additional contrib modules. It does everything with core. It could just be a sub profile of standard. This went nowhere slowly. And so we kind of gave up on that. But this is a case where where I really had had blinders on from a decade of Drupal experience, where everything was a module. I it made sense to me that install profiles were just another type of module that you discover during during the install process process and that themes could be just another type of module that happened to have PHP template support. I like to think of my blinders as being these modern Panasonic blinders. This is a real thing. I don't understand why it exists. But Panasonic will will gladly sell you one of these. So I'll talk more about about install profiles in a bit and how that is solved. But critical contrib projects weren't mature enough. We did some presentations about web form specifically and how we struggled to get that to work in Drupal 8. And core was only getting bigger. And so like I was a big advocate to get a WYSIWYG editor in core, but adding demo content to core that was only like would only be used on a fraction of the sites that existed in every production environment on the planet seemed like the wrong direction. So core is getting smaller. So I drippled on Portland. Dries didn't say small core. But he did say smaller core, which is which is progress. So all of these things are going away. So yeah, so we talked about the backdrop problems, the issues we had with with Drupal 8. All of these things are are now resolved. So so what's the problem? What why am I why am I putting together presentations and still still talking about this? So back in 2018 2019, I was saying that there were no way that the Drupal 8 problems that we were facing were going to be solved before the Drupal 7 end of life. Ha, you got me there. Like, while Drupal 7 is still hugely popular, we just keep pushing that end of life out. So when faced with having to recreate something that took four years to write the first time in a completely new stack that would require a completely new hosting environment, with only two years to do it. That was daunting. And then we had three years and now we have four. And who knows how long we'll actually go here. But the CSS Injector conversation is one that I can't stop going back to that just because Drupal and the Drupal Association are saying that Drupal 7 is supported does not mean it is and we're going to see a lot of pain from organizations that are going to try to get contrived modules to run on PHP 8 in supported releases. You'll be able to do it with patching or forking. But the number of projects they're going to have to change hands for that to happen is going to be, it's going to be a lot. So CU leadership wouldn't do this. We didn't fall off a cliff. The Drupal 7 track just kept going. One of the other things I said about Drupal 8 is that it was going to be remembered as Drupal's Lisa, a product so expensive it didn't have a market. Now, you could argue that Lisa needed to happen in order for the Macintosh to happen in order for the iPhone to happen. And it might be right there. But I was definitely wrong about this. I thought the learning curve was just going to be too steep. And the project would completely implode. And it is too steep for sites that aren't ambitious, that have basic needs. And I really like the release cycle of backdrop as compared to modern Drupal. But I want to, I mean, everyone's familiar with this Venn diagram. And, you know, the joke is that you can only have two of these. But one of the things that working in Salesforce allowed me is to get some perspective, like step back, get out of the module, everything's a module blinders, and start seeing things for what it is. Just spoiler. If you do switch from Drupal to Salesforce, the grass is a greeter. It's the same same problems, the same chaos, just different, different cults, different chants, different t-shirts. So I'm gonna argue that if you just ignore the 10 years that took us to get up the first Drupal learning curve, and you discount that, that you can have fast, good and cheap. If you take the tunnel, if you if you instead of going and rebuilding everything and relearning everything you do, if you just use an incremental improvement that is designed for lower cost hosting and less ambitious sites, you do get all three. What you can't have is ambitious, stable and cheap. If you're going to do ambitious sites, if you're going to cater to ambitious site builders, if you're going to keep up with the off the island pace of your dependencies, it's going to be expensive. The infrastructure you need to do Drupal, modern Drupal well is not trivial. So for those of you are as old as me, if you think back to when you were still using a page building tool like Dreamweaver or the front page, if someone from the future had come back and talked to you about the DevOps and automated testing solutions you were going to need to run a modern CSS or modern CMS environment, the fact that you couldn't even just run it on your own a single web server in a second server for a database and then another server for a reverse proxy in front of all of that, would you have done it? Would you have gone down that road? Or would you still be using Dreamweaver today? So I struggle with this because most of the sites that we gave away for free are less than 20 pages. It benefits us as far as training people to teach them one way of doing things and then allow them to work on any of our sites. But the reality is that most of these sites, if front page or Dreamweaver were still well supported, could easily be managed with those solutions for far less than we're paying to do it with a modern CMS. So Drupal 10 is expensive to build. It's expensive to do well. But man, is it a lot of effort to maintain? The updates are coming so often and are so critical that all we do is deploy updates anymore. So I feel like a boiled frog that I've been doing this so long. And the temperature just kept getting higher. And we just kept doing the same thing. But we didn't really notice and we never questioned. And I know some people jumped out. Brian Olandyke from Penn State is a good friend. And he presented at DrupalCon Nashville as well as a number of other Drupal cons and kind of railed against Drupal and WordPress and the CMS way of doing things. And for whatever reason, we kept inviting him back and doing that. But he eventually quit. He said, you know, the PHP based CMS approach is just crazy. We don't have it doesn't have to be this complicated. And so the Hacks project went off and instead of just being a headless authoring solution for Drupal or WordPress, they now have the Hacks CMS, which is a completely web component based solution. So this is a an issue that we're dealing with right now. Simple SAML PHP does not work with Symphony 6. So we started evaluating Drupal 10, and what our pain points are going to be for the sites where we're currently running on it. And in that thread, this guy said, Symphony five is the current long term support version of Symphony and support until 2025. Well, that's great. Except we skipped that. So we're going from four to six. And that was only released in November. And with the current rate, they're farting out new releases, no one can keep up unless it's your day job. So why do we care what what Tim says? Well, Tim's the lead developer of the simple SAML PHP project. So if he's not going to support Symphony six, our options are to fork the thing we depend on for single sign on authentication to all of our sites. So are the goals of these sites actually more ambitious today? Does our organization have more money to spend on web DevOps, web ops? Can our organization keep up with the ambitious pace of innovation? Well, there's a simple solution for the simple SAML PHP problem. Atten and Stanford already ported it to backdrop, which doesn't depend on Symphony six and doesn't have these problems. There are other solutions to the single sign on problem. That's not going to be our Achilles heel here. But the pace of change in a project impacts the cost. And ignoring that is is putting on blinders again to to the module situation. Just because we've done Drupal doesn't mean everything has to be that said, I'm super excited about some of these things. So I personally can't wait for Drupal 10. And so I want to show you some of these. So this is the app exchange in Salesforce. This is the project browser in Salesforce. So in Salesforce, most of these are very expensive packages, but they're searchable and can be installed within within your Salesforce instance. This is incredibly popular way to find things. This is the profile module manager in our install profile. This is a solution we wrote in Drupal seven to allow site owners who could not actually install modules to install additional functionality. We needed to do this because of support. So we broke our install profile up into a core offering of features. And then I don't have the right screenshot, but we have bundles that add additional functionality because we wanted to boil our users. We wanted them to start simple and be tricked into using Drupal to the point it got more and more complicated. schema.org blueprints. This is the educational data architecture in Salesforce. Those of you that work in Salesforce and higher ed have heard of Eda and Heta for the last decade. But what this does is it allows common objects to be used across Salesforce instances. So it adds courses, enrollments, terms, program plans, requirements, facilities to your existing objects and extends the content object for students with things like application, education, history, and academic certification. Okay, blah, blah, blah. Well, what that allows you to do is, well, on the Salesforce side, it allows us to find solutions in the marketplace that are built for the educational data architecture to begin with. But the what Jacob Rockowitz has been working on with the blueprint module is a way to do something similar with schema.org. So schema.org supports organizations, supports people, supports places, creative works. But where Salesforce has an advantage is that those standards have been adopted by that community. And so schema.org and sales, what Jacob's working on is still experimental. He's been doing a lot of talks and creating YouTube videos about this. I'm super excited about it, because it doesn't end with those objects, every object I use in a site frequently asked questions. The events, everything I've done on an academic site is already covered in schema.org. The solution I'd like to see are projects within Drupal.org that are tied to those common objects, similar to what what Salesforce offers. And then distribution. And now recipes, and I know recipes is a very overused term. But rather than spend the next year bike shedding what that should be called and try to find a new word when there aren't any, we just settled on recipes. So it's recipes, but it's not the recipes that we've used before. But recipes solve some of the problems with install profiles being modules. But they were difficult to keep updated. They can't be added to after you start your project, you'd install Drupal and then you decide you want to do commerce, guess what, you got to start over. So and they can't be even be removed. So you adopted a install profile. And then that maintainer ghosts. Guess what, your updates are tied to that on on Drupal.org. And they can't be mixed. So you have a new site and you want to add commerce functionality, there's no way to do that. So recipes is going to solve a lot of these problems. There's functional demos out there for 94. This is a official Drupal initiative. So it will end up in core at some point. So at the University of Colorado, we're moving to GitLab. Drupal is also moving to GitLab. How how kismet? So what we're doing, though, is we're moving to it at the system level. And this is the first time that we've actually been able to collaborate with our campus development partners in the same version control system. And I know for people that work in agencies, that's like really crazy. But we have every version control system under the sun. And they don't all talk to each other. So this is huge for us. But it's huge for a number of reasons. Beyond that, because GitLab allows push rules, where the documentation talks about preventing exes. What I'm super excited about is applying push rules to a group of collaborators, ambitious site builders and limiting them to only editing twig and CSS. Why I can't trust these people to just go crazy and PHP or modify composer files. We've had to exclude them from being able to participate in maintaining their site at all, because we didn't have tools like this. This is another project that allows for config management to be done within Drupal. If you haven't checked this out, it requires a premium plan on GitLab to be able to do project tokens. But it is another way to engage with ambitious site builders without them ever having to use the command line, Irina. This is this is how I'm dealing with people like you. So yeah, so this is designed to leverage modern DevOps, but hide the fact from our users, but engage them in a way we weren't able to do with Drupal 7 because twig is not the same as PHP template. These are not PHP files. We can trust people to make design edits. And then autopilot. This is I'm not going to talk about this too much. Pantheon will be more than happy to talk your ear off and sell you on this. But we've actually reversed our whole DevOps deployment process to allow site builders access to this tool. Because it doesn't really make any sense for us to run behavioral testing on the functional aspects of code. If when we go to deploy it, it results in visual errors. And this is an error in the most recent update to bootstrap Barrio. It's a base theme we use on some of our sites. It was a security update that also included the last year and a half of feature development because Drupal is a contrived project and everyone not everyone does semantic versioning correctly. So this failed the visual regression test, you can see well, maybe you can't see but there's an additional white box around the request info button, because someone added additional web form styling to the bootstrap Barrio theme. And the result was we didn't move forward with this. But we've completely re architected what we're doing so that we're involving site owners in this process. So again, Drupal backdrop, both great solutions. The current plan at CU is to rebuild these 1000 sites on triple eight triple nine. Oh, wait, no, we're Yeah, we we can't get the the code done fast enough to actually start the migration project before the code is already end of life. So I'm going to make the same pitch that I made three years ago about maybe using backdrop for some of these sites. And now that Stanford has proved that they can be hosted on Pantheon. And Stanford did it. So it must be great for everyone, right? Everyone loves Stanford. So So I feel like we're at this this kind of breaking point where we've had just like the triple seven, everything's a module phase. We're looking at every site we build as if Drupal is the is the answer for it. And there are groups out there that balance between Drupal and WordPress. But I'd like to add backdrop to that mix and kind of take the blinders off and evaluate sites based on their needs and how ambitious they are and the total cost of maintaining them. And I'm not going to have to make the decision about which sites go where because I read has already written up a great chart that walks you through this process. So I don't know if we're going to be able to do backdrop. It's definitely going to be an easier argument to make now than it it was several years ago. But part of the reason for putting this together is that I am going to be making this pitch to our leadership in a few weeks. So that's really all I have. I'd be happy to stick around and answer whatever questions anyone has. Or if you think I'm completely wrong again, please speak up because I would like to avoid spending the next decade of my life trying to push something up a hill that shouldn't be on top of it. That's it.