So Drupal post-PHP renaissance. We're really here to talk about what this Drupal thing looks like as the PHP movement starts to really get their act together. Quickly, talk a little bit about me in case you don't know me. I'm Chris Van Der Water. I am currently the developer evangelist over at Acquia. I go by Eclipse GC just about everywhere. Never run into that username that it's not me. I'm one of the co-maintainers for Chaos Tools, which is actually very near and dear to my heart. But that's a completely separate talk. And I maintain a little-known module called Context Admin, which is also near and dear to my heart. So the purposes of this talk really... I want to talk a little bit about Drupal's history, because I think it's really important to know where we've come from in order to clearly identify where we're going. I'm going to compare that to what PHP just generically was doing around the same time. And then I want to spend a little bit of time kind of framing those two things against each other to bring some, like, cohesion to the picture. That's what I just said. Yeah, so I want to relate all of this history to where we are today, why we're here, and where I think we're going. So I have a couple of things I want you to consider as I give this talk, because I think it's really important to have in mind the same sort of things that I had in mind when I wrote it. So first of all, I want you to give serious consideration to where PHP in general is going. If you aren't out there doing PHP separately from Drupal, that might not be completely obvious right away. I hope that I'm going to give you enough of a working knowledge of that, that it becomes more obvious. Second is what's going to become of existing PHP-based projects that aren't embracing PHP's emerging best standards, like best practices. And then with all of that said, I want you to seriously consider what is Drupal, right? We'll have this conversation again. If not here, although we will, elsewhere, because this is going to be an ongoing topic sort of stuff. So let's talk about Drupal's history a little bit. Introduction of modules. Does anybody know when modules was introduced? No takers? Okay. Got some very knowledgeable people in the room, so... Okay, we've got a 2002. For purposes of today, the beginning, when I say in the beginning, that is May 18th of 2000. That is the first commit to the Drupal Git repository. So in the beginning there weren't any modules. But by Saturday, December 23rd of 2000, we have this little bit of code. Now this is module execute, and you'll see that it does this wonderful thing with globals. And here's my favorite part. It returns a string, right? Like if that thing doesn't exist, it returns an empty string. Anybody want to guess why? You went directly to the page. That's right. All of these things rendered directly to the page. That's exactly what it is. So if you didn't have the thing, you got an empty string. By Saturday, May 5th of 2001, we had this familiar-looking code, which is the first incarnation of module invoke. You'll see that it checks to see if a function exists with, you know, this hook naming thing that we do and passes two parameters to it. Apparently we didn't have get args or something at that point. I don't know. I don't know PHP well enough at that time period to know. But I believe at this point we could return things other than strings. By the way, happy Cinco de Mayo. May 5th, right? So, you know, it's a good gift for all of us. I want you to just kind of look at what first went in versus what sits in Drupal 7 today. Because they're really not all that different. They do a lot of the same things. There's a little bit more elegance built in here and a few things to build your own auto-loading abstractions and stuff like that in case you want to put your hooks into a different file name and those sorts of things because that's what module hook makes you able to do. But by and large, these are really similar functions. That's 14 years worth of difference. Right? So we haven't really progressed a heck of a lot. Our solution to begin with was actually kind of okay. So, however, it did introduce a few problems. Has anybody ever wanted a module namespace and not been able to get it? It's happened to a few of us. Some of us in the room have done even worse things than want that.  Once upon a time, there was a module named Dashboard. Has anybody ever used the Dashboard module? No, probably not, because I think it only went as far as Drupal 6. Now, the reason it only went as far as Drupal 6 is because there were some mock-ups for the Drupal 7 stuff that included a Dashboard.   And it was only a proof of concept, but they put it into core, and next thing I know I've killed the Dashboard module. Yeah, the end, right? I mean, there's not a lot more to say. Like, sorry. I am sorry. So, yeah, and this persisted outside because we went on to have OO class names as a problem space, right? Like, you can't just have a views class. No, you cannot have that. You can't have a database class. Larry's got that, right? That's not yours to have. Someone else already has it. Let's see. Whose class is it anyways? So, yeah, you declare a class query.  This isn't actually a Drupal problem, right? This is a PHP problem. You just can't have that class name because someone else already has it. If you want to include some external PHP library into Drupal and it has a query class, good luck, right? Have fun with that. So, everything we've talked about up until this moment, this still defines Drupal 7 as it exists today. All these things are pretty well true. We've gotten around like some of these class naming difficulties with, you know, custom PSR 0 and 4 class auto loader module things and stuff like that. But, you know, generic Drupal 7, everything I've just said is totally true for it. So, let's look at PHP roughly through the same kind of time frame. 99-2000 time frame, it was really hard to nail down an exact date. Like, Git commits, they're kind of a sure thing. PHP history is a little less sure of a thing, but there was a developer meeting around PHP and at this meeting they began the concept of Pair. Anybody in the room use Pair? Yeah, a few of you? Okay. So, Stig S Bacon? Is that right? I don't know. It's Larry Dunno, I sure don't know. He founds the Pair project around the same time frame and begins moving this thing forward. Now, Pair is essentially a structured library for open source PHP code, right? It looks really similar to a lot of other things that we've begun to use today, but it had a few problems. No, I guess I'll get to that later. So, why did we invent modules and not embrace Pair if they're already doing this, right? Oh, no, it is now. We have kind of a historical not invented here syndrome within Drupal and we're beginning to get over that. We're beginning to contribute the things that we do to the wider PHP world, but for a very long time, if we didn't make it, we didn't use it. Classic, not invented here. And I actually have some questions about how aware people were of Pair in the same time frame, but because we introduced modules, like, on the same year, right? So, I mean, these things are parallel. Did you have, like, a comment or just saying you were aware? Oh, yeah, go. Just for the irony factor, if you go back to the ancient, ancient Drupal code base, we used the Pair database layer and then ripped it out and wrote our own. Having used PairDB before, that was a good decision. I actually learned that at Amsterdam, so we have done some Pair things, but we didn't just outright adopt it. We did our own thing, which I think has probably been an enabling factor, but Pair requires, like, this peer review process. There was a lot of restrictions in order to get something actually up and running within Pair. So, and kind of the death knell, if you will, was that it was only really at its most useful if you had root access to the box that you were doing this stuff on, and hopefully you didn't. So, this wasn't the best of scenarios. So, having looked at kind of PHP around the same timeframe as Drupal's introduction of modules, let's look at it today. Today we're doing 5.3 namespacing, and this is, yeah, this is good because now we have namespaces for things, like in Drupal 8 we have this Drupal component namespace, we have a Drupal core namespace, we even have a symphony HTTP kernel namespace, and that's because these various projects, Drupal, symphony, others, are now namespacing their classes, which of course means that if I have a query class and you have a query class, that's not a problem if we namespace them, right? I can call the thing something that makes sense instead of, like, literally namespacing it as my module underscore query, which is what we did. Composer, who in the room's using Composer, anybody? Yeah, I got a few hands. For those of you not really using Composer yet, Composer provides a number of things. It's class auto-loading by namespace, so it'll actually find the directory that your namespace is tied to, and then when you say new some class name, it knows what directory to go to to find your classes, right? It also does package management, so you can create a new Composer package and say, I depend upon this thing over there, right, some other package, and it'll grab those packages for you and assemble it all together from talks with Fabian Potentier. He tells me that it's actually a more capable package management software than App to Get is, so I'm no pro on App to Get, so I don't know. And it's definitely not as strict as Pear.  That's really pretty much all there is to it as long as you conform to the standard. It's really wide adoption because of this. If it's easy to use and it does good things for you, strangely enough, people start using it, and so Composer's everywhere. It's even in Drupal 8 at this point. And this has kind of led to a situation where we have all of these interoperable components. So, yeah, unique namespaces allows for overlapping names. You can now take that external library that I told you good luck with earlier and you can include it into Drupal and as long as it's namespaced its classes, no problem, right? All of a sudden, something that was a total pain of a problem is now just simply gone. Use that external library. Have fun with it. Yeah, I said that. Yeah, and so obviously, this leads to the same sort of things we've seen in Drupal for a really long time where people can actively contribute to a project and push it forward. So I want to talk about FIG. Who in here is familiar with PHP FIG? Okay, like four people. All right, PHP FIG is the framework interoperability group. This is a group of people who are really dedicated to creating standards that any PHP project can embrace, right? Drupal's embraced a lot of them. Symphony's embraced a ton of them. All of these different standards are coming about. The first one you may have heard of is maybe PSR0, anybody? PSR0, right? This is a class auto-loading standard. We have PSR1, which is a basic coding standard. Drupal's like, meh, screw that. PSR2, same story, different verse. Larger interface, believe it or not, Drupal conforms to this one. Thank you, Larry. So you rewrote Watchdog to actually conform to the PSR3, right? Yeah, cool. PSR4, improved auto-loading. I'm not sure I can claim this, but I'm gonna try, okay? People can try to prove me wrong, and maybe they will. I'm pretty sure Drupal8 pushed forward the adoption of PSR4 within Composer more so than any other project, and we may have been the first PSR4 compliant project in the world. I'm not sure about it. Well, we did push forward Composer auto-loading, getting PSR4. The Composer PSR4 support was written by a Drupal developer. There's some more PSRs out there. You should talk with Larry if you want to know about 5, 6, and especially 7, which is super cool. No. StackPHP. Who knows what that is? StackPHP. So we're teaching. That's what we're doing today. So Stack is essentially a group of people attempting to collaborate around Symphony's HTTP kernel, right? This isn't, like, people who are stuck using this code. These are people actively opting in to using someone else's code, someone who published their code independently, someone who they have no control over, right? And they're saying, this is a standard we can get behind and use, right? And what it means is that, you know, any framework that begins using this and using it properly can actually interoperate to a certain degree with their various routing layers, right? And finally, component libraries. This should be kind of self-evident with the rest of the conversation thus far, but there are lots of different component libraries out there, Symphony components, Doctrine, Zend, that's what the ZF is. This is quickly leading us to, like, this interoperable vision of PHP where you just say, I want a little bit of this, I want a little bit of that. I will write the glue code in between that makes this thing work, right? Is that something familiar to anybody? Has anybody in the room been doing something similar to that for the last, I don't know, five, ten years? Maybe less. So Drupal, let's talk about Drupal, Drupal 8 specifically. Drupal 8 at this point is really a mixture of modules and PHP components, okay? So we also still have kind of some procedural approaches within our code base. We've eliminated a lot of it, but, you know, you can't ever completely get rid of that and we've worked really hard to eliminate the low-hanging fruit that made a lot of sense and some things that were much more difficult to eliminate, like our routing layer. A lot of these things have been converted into stateless services, which is to say, it's a good thing. And we have our own PHP components at this point. Drupal 8 literally has an entire directory just full of PHP code that we intend to make publicly available for people outside of Drupal to use. We don't have it exposed yet, but we're close. And Drupal just has a single git repository. We need a subtree split, which isn't actually separate git repositories. It's still one, but you get to treat it like it's multiple. So having talked about all of that, I want to talk a little bit about what I believe the future of Drupal is, and I believe very sincerely that Drupal is going to be a standardized collection of PHP components, right? Charable with the PHP world at large, if you are using some project and you want to use Drupal's utility or plug-ins, something near and dear to my heart, that should be very achievable in the near future. Symphony, just like symphony, right? You can pick and choose the pieces of symphony you want. You don't have to use full stack, right? Oh, see, I even enumerated those. Look at that. Sorry, I went through these slides a while ago, my bad. Which all leads to this notion of a Drupal second approach. I think we should code for Drupal second, right? Write something that works, solve the case, and then build an adapter around it to Drupal. You've been doing that for a long time with every API you had to work with, somebody else's module that you liked what it did, but it didn't integrate with CCK properly, whatever. We've been actively doing these sorts of things for a long time, and I think if we were to begin doing it more publicly, releasing more components, we would get more buy-in. Yeah, that should be obvious from what I said. Really, though, maybe it's not obvious because what are modules, right? Yeah, I said that. Create a PHP-native solution, write a Drupal adapter. Like, you start doing this, the code that you're producing is gonna have to be higher quality because you're gonna write all the unit tests for it, you're gonna host that stuff maybe on Drupal, maybe on GitHub, somewhere, you're gonna have Travis integration to it, you're gonna have all of this stuff just at your fingertips to begin actively testing what you build, and then building adapters. Who in here has ever built an adapter class, like one class wrapping another so that it can communicate with some different layer? Yeah, it's not hard. Usually it's like, oh, they named it that, I named it this, let's call that method here. These things are usually fairly simple to do, and especially if you're in charge of writing that generic code layer. Yeah, if we do this, though, you have to ask the question, like, what happens to modules? Are modules even a thing? I think for Drupal 8, obviously they are, but we have to start making these decisions. What is a module? Do we do packages of modules still? Because that gets more complicated when you start looking at external dependencies or delivering this stuff together. Does anybody know what this is? Not Larry. What is it? The ComposerJSON file, that's exactly what it is. That is its name. That's its description. There are its authors, its requirements, other things it depends upon, how it can auto load its classes. Does this look like anything to anybody else? Yeah? Does it look like, I don't know, an info file? It has all the exact same features, point for point, and many, many more, I'll mention. It's not Drupal, that's true. So it's not all roses. We do have modules that are beginning to depend upon PHP components, and that's kind of a hard nut to crack. We have ComposerManager, which has gotten rewritten since the last time I gave this presentation, and it's better than it's ever been before, and I think that there's some really great things happening with it. Does anybody use ComposerManager? Have you used it recently? Okay. It hooks into Drush now, so when you do an EN against your module, it finds the Composer dependencies, downloads them, and installs them. Yeah, it's super cool. It's super cool. Thank you, Boyan Zavonovic. I mean, all my suggestions are worthless after talking about that one. I was doing this through Hooked Requirements for a while, so that you had to actively go and download this. I don't think that's required anymore. So I think this is kind of the money shot of the Drupal 8 story, though, is that Drupal 8 is really in a transitional stage. It's not one way or the other. It has a collection of PHP components. It still has this notion of Drupal modules. It still has hooks. It's got event dispatching. It's got all of these parallel systems. So we're going to have to figure that out, like bottom line. I think it's still a good thing. This is kind of an interesting point. The first time I gave this presentation was actually in Munich. And someone asked me about upstream dependencies, because obviously we have a few of those.  And I looked at them and I said, well, that's a fair point, but it's not really any different than what you have today. Has anybody in the room ever used panels? Has anybody in the room who's ever used panels filed a panels bug? Okay, of those of you filing panels bugs, have you ever been told that's not a panels bug, that's a page manager bug? Yeah? Okay, same problem. These are detangling the dependencies of how modules interact. The same thing is going to happen within this new componentized future. Okay, same problems. Different implementation, yeah. It's funny you should ask. Because I really think that build process and version pinning must be the day. That's what you have to do going forward. Anybody using Drushmake?  If you're getting it from Git and you haven't tagged a particular commit, shame on you. The next guy who comes behind you and builds this, if you're collaborating with some other team of developers and they try to run your build and I've committed something to Ctools since then, man, they are so screwed, right? Maybe, Ctools is actually pretty good about it. But there are plenty of modules that aren't. I mean, great example. This one sucks, I'm sorry I'm not picking on you. Rules, 2.4. Totally screwed me over, right? Like, I couldn't even do DB update. It was done over. 2.3 and figured out. And you know, these things happen. It just happens. That's a widely used module that I can pick on because it probably happened to some of you in the room and you're going to remember it. But, you know, and I was pinning versions, right? And when I did my upgrade, it was like, oh, well, that ain't going to work. So I backed off rules. No big deal. Same thing's going to happen here. And so when we begin doing build processes that depend upon composer components in the future, it has the exact same abilities that Drushmake does and you should definitely pin versions. It's the only way to do this sanely. And composer even has a couple of extra things like that composer lock file, if you've dealt with it at all. Composer lock file is actually a great thing because it means that everybody gets the same version of everything all the time. So when I build the project that you're working on and someone else builds it and anybody else builds it, we're all collaborating against the same thing always. Suffice it to say, yeah, it's a potential problem, but there is a solution to it, right? Licensing, wow, do I even want to talk about that? All right, so most of the PHP components that you might run into today are typically MIT. There are a couple out there that are BSD, but most of them are MIT, right? Anybody not Larry know what Drupal is? Because I'm showing you. It's GPL2 plus, right? Well, that means anything we've ever committed to the Drupal repository is GPL2 plus, period. If we start serving up different components as being their own thing, it's still GPL2 plus. If it's on Drupal.org, it's GPL2 plus, right? There may be some nuance to that. How does this relate to the Drupal second thing? You know, I guess you can make your own components, like the license that makes sense to you. I personally, and I'm definitely in the minority here, but I personally would encourage you to make GPL components. I think that this has some really interesting security ramifications, and in this day when we continue to run into security issues and privacy issues, that having the strongest license for that on our side is probably a good thing, it does limit the upside potential of your component in terms of who might adopt it, because there are some people out there who just want to use the code, and they don't want to be forced to give it back, whatever they may use with it. If you go MIT and GPL can coexist in terms of what you might do on the Drupal side of this equation, Symphony is an MIT library. So it's guzzle. Most of the things in the composer file. Core version, what did I say here? Meh. All right. This is the internet. Anybody know what percentage of it we occupy? I know, right? It's tubes, yeah, it's a series of tubes. Drupal occupies about 2% of the web. That is the number that we claim, and at least for the portion of the web that Acquia bothers to crawl, it is fairly true, and they crawl a very significant portion of it. This is WordPress, okay? Between Drupal and WordPress, we occupy a quarter of the web, right? Anybody happen to know how much of its PHP that rests, the 75%? Not Larry? PHP, period. Five? 87%. So between Drupal, WordPress, and PHP at large, we run 82% of the web. We being PHP. Yeah, 82. There's the number with exclamations and everything. Right? So that's, you know, 28 times what Drupal runs all by itself. Right? That's the number of people I'm talking about getting involved with, right? So here's kind of my breakdown of the whole talk, right? Drupal's built and maintained a really great working solution for the last 14 years before PHP had anything worth considering, okay? We did a pretty good job. It served us well. But they clearly caught up. They have a technically capable, similar solution that does everything ours does and if we were to adopt this, I think, this is just me hypothesizing, but I think that the more components we create, the greater adoption of Drupal components we're gonna see. So if dbt and g were a separate component, you know, I could see someone using that because they preferred it over doctrine maybe. Plugins, utility, whatever. Like if they have a problem with one of those things, if they need to learn it inside and out, who are they gonna call, right? They're gonna call us, obviously. They're gonna call the Drupal community in order to come solve their learning or support needs for a Drupal component, right? Yeah, so I think this is like a very clear sort of response to what the PHP world has done is to simply like, if you can't beat them, join them, right? Clear future. We join them, we do what they do. We contribute to their same ethos and workflow. We're gonna get a lot of really interesting benefits out of it. So I want to bring these back up. Where's PHP going? What will happen to PHP projects that don't adopt what the rest of PHP is doing? And more importantly, what is Drupal? And I'm just gonna leave you with my answer to this last one, okay? My answer to what is Drupal is really simple. Drupal's a community. Drupal's the people at this event, right? Drupal's not necessarily a collection of software, though we may think that it is sometimes. But increasingly, as we abstract and pull apart that collection of software to operate independently, like what Drupal really is, is the community that builds that software. So, you know, these are just kind of my thoughts about what's happening here within PHP in the Drupal world. I'd be happy to entertain any questions you have. I have no idea how fast or slow I went. Yeah. Okay. It's a little fast. Not too bad. Questions, anybody? And I won't exclude Larry. Well, I think, like looking at our largest rival, WordPress, they couldn't care less as best as I can tell. Having recently walked through some of their new OO code, I had to put it down. Because Larry has drilled into me way too many dependency injection and things like that. Yeah, Larry's taught me too well. I can't look at WordPress as code. And that's not like to deride them. Obviously they've done a really good job at what they do, right? Yeah. Yeah, about three of them. I could look through most of Drupal 7's code base and feel the same way. Right? So, you know, like I said, it's not to deride them. But that's not a priority for them. They're busy taking over the world in a completely different way. Right? You know, if there's one to talk about, it's probably Laravel. Right? Which is definitely component-based and, you know, moving forward there. And I mean, you've got, I think what's more interesting to see than the Drupal's an interesting beast of its own. I'll put it aside. But if you look at the WordPresses of the world, of which there aren't really many, they aren't really moving towards this at all. But we're seeing all these little micro frameworks and things like that pop up like Laravel, Sylex, those sorts of things. And they're all embracing this. Yeah, Larry? Yeah. Disagree away. No, you may not. Right? Now based on symphony. Yeah, well, and I think it's interesting because they're definitely not dying. I think long-term, you know, like what they've really succeeded at is being hyper user friendly. Now, having used WordPress pretty extensively over the course of the last 10 months, I don't understand that analogy. Like people say that all the time. I don't really see it as being particularly more friendly than most of the Drupal stuff I do on a day-to-day basis. But it's definitely got a simpler concept that you can bootstrap sooner. That's where they're succeeding. But they're quickly attempting to infringe, like, on Drupal's space around, you know, typical, like, structured data sort of processes. And they haven't cracked that nut yet. I don't know why. Well, I do know why.   And that's not going to go away quickly. No matter what the technical underpinnings of their solution. So, yeah, I mean, like, to characterize as anybody not adopting this or WordPress is dying, maybe that's totally fair. But a lot of projects have, like, figured it out.  Like, for so long, they've had a really great forum, but they've had serious security issues on and off forever. And, you know, they're getting really serious about their code base. They're adopting this componentized solution. I think, you know, they could be a really serious contender going forward on the forum side, which, interesting note, Drupal started as a forum. So, yeah. I guess, take that information and do with it what you will. Other questions? Totally, totally something like that. Or we move to a situation where modules are where you have already are. There are some things you can do to Composer to make modules be Composer-able. You can do a Composer install and end up with Drupal modules. But, like, I would like to see us actually embrace real legitimate Composer support and essentially turn Drupal.org into our own packages to install for that sort of stuff. But there's some nuance to doing that and what it actually means on the code side, right? Because a Drupal module, right? So, I guess what I'm really advocating is that we begin seriously thinking about what it looks like for it not to run in Drupal. If we happen to be running the same routing system as everybody else, which, by the way, we largely do, then what's holding us back from writing code that Laravel could adopt? Right? Or Silux or any of these things? I mean, if we build it, will they come? So to speak? Yeah. And that's actually the reason I talk about licensing because I think the answer is, sure, if it's good, right? If we build something worthwhile and worth using, we've got 14 years of history showing that people will absolutely come and use it. You know? So, I guess the bottom line to that one is I really hope that we get to a point where I can just add a require statement for C tools and boom, I've got it. Right? That's what I'd like to see happening. Other questions? No other questions? I don't know, I feel like I think that that's a totally fair question and I don't actually have an answer, so maybe it's like, I don't know, let's think about it. What are the downsides? Yeah, I think there's some really obvious ones right off the bat. We have certain things that aren't componentized yet and we have other legacy code within Drupal that's going to be really hard to pull out. Case in point, form. Right? Like, form API is a big deal and we've made some really cool changes to it in Drupal 8. If you haven't played with it yet, form state is its own object which is a ton easier to deal with than it's ever been before, but I digress. But you know, symphony has their own form component which some symphony form component with Drupal form component maintainers and convince them that they could totally switch to symphonies. Nobody attempted that because it's going to be a really big thing and we already did a lot in 8. But I think form holds this back for all of 8. No doubt. Like until we decide to remove form, we are going to be building Drupal-specific code. Right? I think really clearly that's obvious to me. Unless you build something that doesn't need forms. Okay, so whatever. That'd be interesting code. So I think it's stuff like that. It'd be interesting. It's happened, I'm sure it's happened. Does anybody know of a module that doesn't have a form? Okay. So, yeah. I'm not saying there are no downsides. I think there totally are some downsides that we probably haven't run into yet. There have been downsides to adopting every component that we adopted except for Guzzle. Guzzle was like what, we removed something on the order of like 25 billion cyclomatic complexity points for Drupal-HDP request and replaced it with something that had 100% test coverage? That's a big win. But I mean, there were downsides to adopting symphony routing. There were downsides to adopting YAML. Downsides to adopting any of these things. But again, I guess I would go back to the site building analogy. You make these sorts of decisions every time you pick the modules you want to use for a customer. You write glue code to make stuff work. I guess going back to my what is Drupal statement, Drupal from a code perspective might be a collection of components with a little bit of glue code to make it all work together. I would even argue that the entity system, like doctrine's entity type thing, it's pretty good. I hate our existing entity system. Right? I mean, so what? I mean, in terms of code doing the thing you need it to do, doctrine can totally do it. So can Drupal's entity system. So can, gosh, there are a half dozen PHP-based solutions for that problem space, right? I'm sure there are even a few views like things though I would never want to give views up. And if I'm not willing to give up views I'm probably not willing to give up entities, right? I mean, simple math. So, yeah, I mean, do I agree? Yeah, but I'm going to move all the code away and say mostly it's the community, right? I think Drupal's big ad are the people sitting in this room, the people building Drupal, building its contrib, implementing it, teaching others. That's what Drupal has over every other PHP anything. Right? In fact, it's what Drupal has over almost every open source anything. Right? Top 10 Drupal, the top 10 open source projects in the world, right? In terms of scale and a number of other items, right? So, I guess that to me is our big value ad. And the code that we do it on top of should be as good as possible. But I think what we do with that code and I would agree could really increase the adoption of Drupal as a whole. And I guess my point here is to encourage you to look at this for yourself. Decide whether you think I'm right or whether I'm wrong. And help get Drupal there when you decide I'm right. Because I think you will. Right? Anyways, I'm going to let you go a little bit early if you have other questions. Feel free to hunt me down. I think it's a little early. Do you have a couple fear? Two more questions? Sure. Go Joseph. Yeah, I agree. So, I'm going to hit your first question which was how far along are we on this process? Which is to say it depends upon what component of Drupal you look at. If you're looking at actions, not so far. It's tied to forms. Which might be an argument in favor of our conversation earlier today. But, you know, if you look at anything sitting in the Drupal component directory, all of that stuff is intended to just have a composer file dropped on it and be put out on the Git subtree. So, there are at least a good dozen chunks of code sitting in there that are ready for the rest of the world to begin using. We just haven't made them widely available yet. It is by far the minority of Drupal. And so, I would guess I'd say not very far. Right? We've begun to dip our toe into the waters and see what that looks like. And in terms of your second question, I guess I would respond with, you know, I'm not just talking about core. Core definitely has its own workflow problems. But if you look at modules as a whole, what we call modules today, there's really nothing about module maintainers if they have the technical underpinnings from the support system from adopting a very GitHub similar approach that the rest of the PHP world could just tie right into. Whether they would or not, whether us all being located on Drupal.org is a barrier to entry for that. I think is a completely valid conversation to have but it's one that is probably a good two, three hours conversation all by itself. So, I'm not going to get into that except to say that there are probably solutions technical in nature that could be implemented to help smooth that transition to some degree. Right? I mean, I don't know. Maybe we implement login with your GitHub ID on Drupal.org. Right? Like, that might be a quick solution. Might not be. Maybe there's a legal reason not to do that. I don't know. There are options. So, any other questions? To clarify, I think that that is a good strategy for Drupal 8. For Drupal 9, ideally I'd love to see you just writing what we consider modules today but having them actually be generic PHP components that Drupal can just use. Absolutely. Absolutely. But I think you know, they do the exact same things we do. Like if you hit packages, okay, little story. I'm going to do a Redis store for an API calls I was doing in the recent past. So, I went to packages and I look up Redis and there were probably a dozen different Redis components. One of them had 3.5 million installs and no one else was close to that. So, guess which one I picked? Right? I mean, they do the exact same things we do in terms of kind of, you know, if you will, letting market forces determine where it goes. Like, we went CCK. Why did we go CCK? Because it was the solution everyone was using. Right? So, core has a lot of the same sort of solutions. I mean, we may not have adopted the same schema which is a different topic. But, everything else is pretty CCK in nature. So, you know, they're doing the exact same things. And which is just to say, before you go writing something, see if something like that exists. When I was looking at WordPress's code, as I mentioned, their OO layers, recently I was actually looking at some O embed code that they had written from scratch. Because, like, okay, O embed is kind of cool. What's WordPress doing? Oh, they wrote their entire own class structure for it. So, I went to Packagist and I'm like, O embed comes back with a half dozen different ones. I picked one at random. It was the wrong one. I picked another one later. It was really good, you know, and it took me, like, 30 minutes to write a filter for Drupal 8 that just made O embed work around that. I literally, I wrote a filter plugin. That's what I did. It's no big deal. So, and this is why I say, like, Drupal 2nd, you know, find the component or build the component, write the adapter layer. In my case, it was a filter. It's a text filter. No big deal. So. I pulled it from Chris Plikas, who's another Aquian who's doing a ton. He actually, I think, was the guy who started Composer Manager. He gave it away to people who he felt like were going to take better care of it than he could. But he's been doing a lot of really cool work at Aquia around various components and things like that, and he was the first person to ever say it to me, so I stole it from him. Which he told me, feel free to steal it. So, yeah, it's mine. It's totally mine. Yeah. On what? Oh. I'll start writing things. I don't know. You know what? Actually, Chris has a great post on Aquia.com in the blogs. If you hit me up afterwards, I'll find it for you. Olivas? Yeah. Well, he's a really smart guy. Yeah. It makes great business sense. Like, if you were maintaining a Drupal 7 wrapper and a Drupal 8 wrapper, your code path to maintain would be dramatically smaller than if you're maintaining completely separate modules or different versions of the same module, right, where all the code and logic is right there. Okay.  Like, write objects. Make your Drupal 7 one dependent upon like X autoload or Trotoload or whatever it is that you like to use over there. No big deal, right? Solved. If you want to write a backward compatibility layer, this becomes much easier because the code is not changing. You're just writing layers, right? Drupal 9 comes out. What do you do? You write a new layer. You don't rewrite all of your hooks, right? Or maybe you do, but there's much less code sitting in them. This is the same notion over and over and over again. So, all right. I think we're out of time. Out of time? Yes. Out of time. Thank you.