Talking Drupal #547 - Why Developers Don't Choose Drupal

John: This is Talking Drupal, a weekly chat about web design development from a group of people with one thing in common. We love Drupal. This is episode 5 47, why Developers Don't Choose Drupal. On today's show, we're talking about Drupal adoption, where developers live, and how Drupal can improve its standings with guest JD Flynn.

We'll also cover native observability as our module of the week. Welcome to Talking Drupal. Our guest today is JD Flynn. JD has been doing Drupal for over 10 years. Currently, he's a senior software engineer at Hero Devs, working on their never ending support for Drupal seven. In his free time, he streams software and game development on Twitch while working on various game projects using go.game Engine or his current project Creo Drop.

Did I say that right, jd?

JD: You said that right? But you said Gado wrong.

John: Ah, a simple hosting platform for Drupal sites. Jd, welcome to the, uh, show. It's Gado. Huh?

JD: Gado just like waiting for Gado.

John: Yeah. Okay. Okay. Yeah, I, I, I'm familiar with that reference, but umm, clearly not in the spelling. Thank you for the correction.

Um, I am, uh, John Zi solutions architect at ipam, and today my co-hosts are joining us for the next four weeks. Rod Martin, owner at Native, uh, navigate Tomorrow, excuse me. Rod has introduced more than 50,000 people to Drupal. Thank you for doing that through his live and video training since 2011. He owns Navigate Tomorrow and runs Drupal helps a site for site builders to get information and quick starts to using Drupal in their own businesses, uh, or nonprofits.

Rod, welcome to the show and thanks for joining us.

Rod: Good to be here.

John: And last, but certainly not least, Nick Laughlin, founder at Enlightened Development. How's it going, Nick?

Nic: Going well, happy to be here.

John: I will let you know there's a care package from DrupalCon in the mail just for you.

Nic: I appreciate that.

I'll send

John: some, uh, some, some Drupal community members wanted to send you some stuff. I wanted to send you some stuff. So we did that.

Nic: Keep it out. Thanks.

John: Hey, no worries. And now to talk about our module of the week, let's turn it over to Martin. It includes a product, product marketing manager for Drupal at Acquia, and a maintainer of a number of Drupal modules of his own.

Martin, what do you have for us this week?

Martin: Thanks John. Have you ever wanted a deep understanding of how your Drupal application is running without relying on third party libraries or services? There's a module for that. It's called Native Observability and it was created in February, 2026 by Giorgio Alfredo Pagano of Italy and has a 1.0 0.5 version available, uh, which is actively maintained.

In fact, that was just released in the past week, does have security and test coverage. And for documentation, there's a pretty in-depth readme. Now it does have four open issues, two of which are bugs technically. Uh, but all of those were actually re, uh, resolved for the latest release. So currently it has no open issues, which is not too bad considering it is officially in use by seven sites according to drupal.org.

Now, folks not familiar with the concept can think of a observability as an x-ray for your Drupal site that reveals exactly how modules, database queries, and themes are behaving under the hood. In real time, it moves you past. Just knowing the site is slow to see, uh, precisely where the bottlenecks are so you can fix issues before your users even have a chance to complain.

Now on the show, we've previously discussed solutions like the whoops module for debugging or the web profiler module for performance monitoring. They rely on third party libraries and listeners may also have used solutions like New Relic or Blackfire to have a deep understanding of how their Drupal site is behaving, which again rely on outside or even proprietary code.

The native observability module meanwhile gives you insights like trace requests in, uh, inspect execution, analyze performance, and explore runtime behavior directly inside your Drupal application. Using the Native service container architecture, it uses Drupal's own event subscribers, cash decorators, and PDO hooks, uh, to instrument the runtime from the inside producing open telemetry standard OTLP Trace data.

And a Prometheus metrics endpoint. This means that spans carry Drupal meaningful names, like cash bins, entity types, render ailments, and SQL queries rather than generic PHP function names. Now, the standard guidance for these kinds of tools is that they should not be used in production, though it is worth noting that on the project page, the maintainer estimates that the native observability has a 10% overhead for full tracing.

So on smaller sites, there might be some use cases where you might consider running this in production, at least within a limited window. So let's talk about native observability.

John: I, uh, you, you hit the New Relic, uh, checkbox. 'cause I was gonna ask, my first question was gonna be like, Hey, is this similar to New Relic?

Um, so you, you already, you already answered that question, and then I thought, I thought your point about the, um, 10% overhead was interesting because I feel like even, even on maybe a little bit of a larger site, you might wanna, might wanna run it if you're having like a kind of a deep seated issue just to see if you can get some, some, uh, some feedback there, um, without, without a ton of overhead.

Um, but yeah, I, I am familiar with New Relic. Ha. Has anybody actually used native, uh, observability, um, before? No.

Nic: Uh, no. It's, it's brand new and brand new and I would say 10, 10, 10% is an. Enormous hit. So I really wouldn't run it in production unless it, you're like really trying to track something down that you, you had to find, and I would disable it immediately because, just, just to keep in mind, 10, the way performance and the way traffic works, 10% is gonna be compounding.

Right. Each correct press is gonna take 10% longer. So that means that you can du you can, uh, you can have 10% more memory, which means that your overhead is gonna be tighter. Like, it, it, it's a compounding effect. It's not just, oh, it's slightly slower for a few minutes while this is running.

John: Yeah. Let me, let me clarify, like, yes, I'm not suggesting you run this in production, but Yeah, I was exactly, I was suggesting the way that you, you described it.

Yeah. If you needed, absolutely needed to figure out something, you could kind of turn it on, turn it off sort of thing. Um. Yeah, it feels like it, it does a lot of stuff and I will be fully transparent. I did not understand a lot of, of, of the kind of under the hood, um, looking that it does. Yeah. But I would say like, I, you know, new Relic is wildly useful.

So if this is kind of that, that free Drupal open source version of New Relic or, or not even, you know, you know, 75%, if it does, 75%, um, you know, I think that's, I think that's, that's good. Um, I also like the fact that there's an Italian guy at the, at the helm that's always a positive in, in my book. But, uh, yeah,

Nic: I, I will say, I, I, sorry, mark, go ahead.

Martin: Oh, I was just gonna to sort of add to that a little bit in terms of the New Relic comparison. A couple things I guess I didn't mention. So number one is that it does provide a dashboard so that you sort of have sort of a bit of a similar experience. On the other hand, I know with New Relic you can do things like set threat, uh, things like performance thresholds and then have it automatically trigger notifications.

I haven't seen any indication that that is currently available with this module. So if you do need some of those other kinds of capabilities tying into other systems and things, then, then that might be a reason to, to look at New Relic as well. But, you know, it'll be interesting to see how that evolves over time.

John: Have you seen any, um, notes in the issue queue or in module documentation about like ECA compatibility, like being able to set those thresholds that way?

Martin: It is an interesting question. I, I haven't, uh,

John: okay.

Martin: You know, I, I definitely can see where that would, would be useful to be able to do things exactly like that, trigger notifications and so on.

But, you know, maybe that would be a good, uh, feature request to open.

John: Yeah, absolutely. Nick, what were you gonna say?

Nic: So I, I, this is more of a meta comment. So one of the things, you know, we, we've had this discussion many times on talking Drupal, but a strength and weakness of Drupal is that you can, you can have a module, everybody can create their own module, right?

Mm-hmm. So in the case of like, webform, webform is one of the jewels of Drupal because it's kind of like one way to do forms, and we see how other communities have 75 different proprietary ways to do forms. Um, on the other hand, the fact that you can kind of create your own slightly different version of a module is great, because if something goes away there, there's something else to go up.

But one thing I am noticing in the last probably three or four months is, um. I think due to the ease of spinning something like this up with ai, we're getting more and more modules that just do kind of the, almost the same thing, right? And, and they might benefit from collaborating together. Um, and I'm not saying this, this specific module, but like I've seen a couple, like the dashboard module, I think we talked about there's like three or four dashboard modules I've seen in the last couple of months and they're, they're obviously solving a problem that the community has or people wouldn't be creating them.

Um, but I think, um, there's been a really long term kind of discussion in the Drupal community about how to make things more discoverable. And I think if we start getting kind of a proliferation, like I said, this is the beauty of open source. So this isn't saying that we shouldn't be doing this, but finding a way to like kind of collate these types of modules and say, Hey, there's these four different modules that do the same, slightly similar things.

See if one of them will work for you. Put your weight behind that rather than creating, you know, a fifth, a fifth dashboard module, or a fifth performance tracking module. Um, I,

John: I couldn't agree more with that, Nick. Um, I, I, I, as you're, as you're talking through that, um, I had a conversation at, at DrupalCon with somebody about something similar to that as we're like, Hey, instead of like, Hey, I'm gonna go build my own.

Why don't you like, put, put a feature request in, put a patch in, and like, as you're speaking right now, I'm like. Hey, just ask your AI to be like, Hey, I wanna, I wanna develop a feature built based on the, based on this module, like, develop me a patch that's gonna add this feature to that module, right? Um, make sure you review it yourself, make sure you have your friends review it.

Make sure you have Nick review it just to make sure the AI isn't doing something terrible. Um, but

Nic: IL let, let, lemme break in and say, before you do that, get permission from the contrib maintainer. Uh, we, we still haven't quite figured out in the Drupal community how to do that, but I think before submitting AI generated patches, yes, you should know your own code, but get, get buy-in from the maintainer of the contrib module before you do that.

Um, I

John: think, well, why, why, why do I have to do that? It's open source.

Nic: Uh, because if the contrib maintainer wanted AI generated patches, they could do it themselves. Right. So I, I think the etiquette is becoming, get, get buy-in before the feature that they want.

John: So to be clear, I'm saying like if you have AI generate the patch, test it, make sure it works, make sure you know what the patch does right before you submit it.

I mean, I don't know if I would necessarily go ask, um, I'm just gonna pick Jacob. 'cause you know, we talked about web form, but I don't know if I would go ask Jacob like, Hey, can I, can I have AI develop a patch for this feature request I wanna put in on, on web forms? I would just put the, put the patch up there after I reviewed it, after I believe in it and, and, and see where it goes.

Nic: I, I might ask Jacob what he thinks about that. I, I, I won't put you on the spot there, but I might ask Jacob because I have a feeling most contr maintainers. Would appreciate just a quick issue saying, Hey, I'm thinking about doing this feature. I was gonna use AI to do it. Is that something you'd be willing to review?

Because the truth is with any large feature change, you should get buy in first anyway. Right?

John: Sure, sure.

Nic: I mean, sure. Because you don't want to put the, you don't want to put all the effort in and then have the maintainer go like, no, we don't want to do that.

John: Yep.

Nic: The, the problem with AI is that you're reversing that burden.

You're, you're not spending all the effort to generate it. You're just giving up for them to be like, here's this feature I want, here's all this CO 5,000 lines of code. You get review. Please, please put that in. So if you, if you reverse that, just say, Hey, I'm thinking about this feature. I'm gonna use AI to generate it.

Is that something you'd be want willing to review? They can. They can opt in or opt out. Um, and then everybody's happy.

John: Yeah. I mean, I don't think I'm just throwing it over the fence. I think I'm reviewing it and standing behind it before I submit it. But Martin, you wanted to add something there?

Martin: Well, so I was going to mention something that Nick already brought up in terms of, you know, to me it doesn't necessarily change.

The fact that you probably should be approaching the maintainer anyway if you're proposing a significant change. Um, I think that's, that's a hundred percent valid and that's definitely something I've done in terms of it potentially creating, you know, more, more modules or more duplicate modules than we had before.

I mean, I've definitely seen, you know, as an example in the event calendar space, lots of modules that are very similar in terms of, you know, let's say, um, you know, full calendar IO integration with some small differences and actually gone into those modules and said, Hey, looks like you're doing some cool stuff here.

Maybe we could collaborate, you know, those kinds of things. So I feel like those kinds of things have happened even before the advent of AI and, you know, the ease of creating new modules, as you pointed out, Nick. Um, yeah, I don't, I don't know what the solution is. I don't know. I, I certainly wouldn't personally wanna see us go back to the days when you had to sort of, um.

Like propose a module and get, I can't remember if you had to propose a module and get approval or if it was that before you could become, get the role that would allow you to create modules. You had to sort of get a role added to you. Um, because I remember that being like a fairly rigorous process back in the day for probably understandable reasons.

But it does feel like, you know, there's a. A more open spirit of collaboration and innovation since we got rid of that. So, you know, where we end up. I'm not a hundred percent sure. I mean, I, I feel like it would probably not be difficult to, to even add to like standard CI checks. Things like, you know, the size of the merger request, the number of, of lines change because there are, you know, I think there was a, I think it was XJM, Jess gave a a talk back in dev days, Vienna a few years back talking about basically the cognitive load that these huge merge requests put on, on the maintainer and that, you know, whether it's human or a generated code, having merge requests, they're just, you know, huge thousands of lines of code is just not a good idea.

You, you. Sort of mentally exhaust the maintainer. And so breaking those up into smaller issues is definitely a better way to go. And I, and that doesn't change whether, you know, a human or the AI generated those. So, you know, I think in a lot of these cases, the, the same rules apply. It's just AI kind of potentially ups the urgency because as you say, they can be done at sort of a faster scale.

Nic: Yeah. Yeah. And, and, and in, in a way that the person posting it, like there's no proof that the person posting it completely understands it. Right? So somebody manually generating an a merge request that's 2000 lines of code. There's, it's possible that there's misunderstandings, that kind of stuff, but they.

In the past, they at least wrote it so they,

Martin: or or they copy and pasted it in from Reddit or something, right? Or

Nic: Yeah, that's that's true.

John: Uh, I'm not, I'm not, we

Nic: can,

John: I'm not suggesting that you, you've put in, um, feature requests for 2000 lines of code. I'm suggesting that you use your, your AI responsibly.

Um, I would like to highlight that we had a great opportunity here with this show, not to mention AI at all, and yet we, we've failed. So

Nic: let's go.

John: We can

Nic: move on.

John: We're, we're, we're doing it. We're gonna, uh, we're gonna thank Martin for, for bringing us this thought provoking module of the week. And, uh, Martin, if folks wanted to connect with you or suggest a module of the week, how could they go about doing that?

Martin: We're always happy to talk about candidates for module of the week in the talking Drupal channel of Drupal Slack. Or folks can reach out to me directly as man clue on a variety of Drupal and social platforms.

John: Awesome. Thanks a lot, Martin. See you next week.

Martin: All right. See you then.

Nic: Yeah.

John: All right. Worth noting before we jump into our primary topic, that we are actually live, we're streaming on, uh, YouTube and LinkedIn.

So if you have questions or comments, feel free to drop them in the chat. We have folks in the background looking at those places, and they'll, they'll bubble 'em, bubble 'em up to us as we're, as we're going through, um, today's topic. So, little bit of background on today's topic. Uh, JD delivered a talk at Drupal Camp Florida, um, with the relatively the same title as today's show.

Um, he adds in there, you know, what we can do about it as a, as a, in parentheses. But, um, I thought it was an interesting take on, um, something that I, I hear kind of out there in the world. Um, as I, you know, I, I work for a, a larger company and, and I talk to people all the time that go, oh, Drupal. That's still a thing.

Um, so, you know, I thought this topic was, uh, was interesting and, and worth, worth the time. So, um, JD I'm, we're gonna start right off with the, uh, you know, I don't know if this is a softball or a, or a fastball, but either way, um, what's the biggest reason developers aren't choosing Drupal at a, at a high level?

JD: So, I, I, I wanna preface everything with, I, I came at this as somebody who enjoys Drupal, who enjoys what I do. And it wasn't nothing that I say either in the talk or, you know, on, on this, on the show is directed, uh, to be, you mean towards Drupal? So I just wanna put that out there because, you know, there may be some things that come across that way.

That's not the intention. That's why I put what and what we can do about it, because it's something that's a problem for all of us.

John: Yeah. It's fair to say that we're all Drupal lovers here. Uh, it is a, a Drupal podcast. Right. And, you know, the reason we bring this up is to, um, look at our own inadequacies and, and see how we can improve, uh, you know, developer adoption, right?

Mm-hmm. So that's, that's kind of the lens we're taking on today. Thanks for, thanks for clarifying that.

JD: Yeah. Uh, so to answer your question, at a high level, uh, one word, it's invisibility, um, um,

Nic: marketing.

JD: Yeah. De developers can't choose what they've never seen. And anybody that I talk to who isn't in the Drupal sphere.

Doesn't even realize Drupal still exists or has no idea. Um, last night I was streaming, uh, shameless self promo, uh, and somebody, I was working on something for Drupal. I was working on, uh, the hosting platform I'm trying to put together and I am using AI for that don't hate me. Um, but, uh, I meant I did a quick recap of DrupalCon and somebody in chat was like, wait, Drupal's big enough to have a conference?

That that's really a thing. And that's kind of the mentality that a lot of people have who aren't in the Drupal sphere.

John: You're like, not one, but three or two and a half depending on how you wanna look at it.

JD: Plus however many local camps and other events. I mean, it's, it's a big thing. Um, so I, I did a lot of research preparing for this talk too.

I looked, you know, on Stack Overflow, uh, surveys, uh, a bunch of other surveys. So I'm not just making. Numbers up, even though I could, I do that 110% of the time is making up numbers. Um, but according to a Stack overflow in, uh, survey in 2025, only 1.4% of non Drupal developers even want to try it for any reason.

And that's a low number. Um, it, it shouldn't be that. And it's because of the invisibility. People don't know we're here. What talking Drupal is doing now, especially with the live streaming format, this is great because it's, this is the, the kind of place that people are looking for this kind of content, looking for new things to try.

So now that this is going up on YouTube and it's streaming it, it's, I was gonna suggest it before I even knew that you were doing it. So this is great what you're doing here, uh, because a lot of discovery happens on YouTube, happens on GitHub, Drupal's not on GitHub, uh, happens on Reddit. Uh, the Drupal Reddit's pretty active.

Nic: Yeah,

JD: but it's also Reddit and we're on drupal.org where zero discovery happens for people looking for new stuff.

Nic: Yeah. So I, I, I wanna actually feel, I feel, uh, obliged to chime in here too, even though I'm not a guest, but I, I, I think you kind of hit one of the biggest reasons on that, on the head, but with a slight spin.

The people that have heard about Drupal many times, they have outdated perceptions, right? Mm-hmm. Uh, I can't tell you the number of times I've heard, like, oh, yeah, Drupal, I haven't used that in 12 years. It was a little clunky back then. And it's like, well, nowadays, you know, I, I personally don't use Drupal CMS as a starter, but like with Drupal CMS, with other recipes, with site templates, like getting started is dead simple.

I, I think, I think honestly, the biggest barrier to more people coming in right now besides marketing is theming, right? Um, theming and Drupal is far more complex than, uh. Far more complex than I, I think it should be. And there's definitely initiatives to fix that. And, and then I think the, the other thing is the, I, I don't know if this is a human condition thing or what, but like the, the, at least with WordPress, the perception that it's easier to set up and maintain, right?

Um, people take like a short term view of it, and yes, WordPress, maybe you can spin up WordPress on a smaller host and get it up and running quicker, right? With maybe a couple hours faster. But like you lose like the rich permissions and rules system, you lose the responsive images and trying to build those things in.

It's gonna take you orders of magnitude more time than it is to just do a one-time setup of Drupal and get your recipe in place and get all that or your template in place and get all that stuff in, get all that stuff working. Um, so I, I think, yeah, marketing is one, but the marketing really is about outreach and resetting the perception of how easy it is to get started.

John: Well, so I look at those as two separate things, honestly. Like, I think marketing and, and outreach is, is one avenue and promotion is one avenue, but then I think perception is another, another avenue, right? Because, um, I actually wrote a blog post about this, uh, last year. Um, and it was, you know, it was titled, uh, you know, Drupal is great, but the perception might not be, and it was actually based on having an interaction with somebody where.

I was like, oh, you know, Drupal 8, 9, 10. You know, you know, it is great. You have all these great features. You have, you know, rebuilt cache system outta Drupal eight. And they were comparing it to, um, you know, they were comparing it to Drupal seven, and they were, they were basing their decision on a, on a brand new Drupal 10 site based on the, the information they had from Drupal seven.

And I'm like, no, that's not, that's not accurate anymore. You know, Drupal was rebuilt in Drupal eight. There's a new cache system, like multi-site works great. Um, you know, great benefits interaction with somebody where I was like, oh, you know, Drupal 8, 9, 10. You know,

Nic: we're hearing a repeat of, uh, John

John: on the screen.

Nic: So

John: I was, I was hearing myself. That was wild. Um, so. Anyway, I, I think like those are two different roads. S Nick, I think like the marketing and promotion of Drupal is one, one side of it. And then the changing perception, um, both in the developer community and in the, in the client user community is, is one of those things that's super important.

JD: Yeah. I, you, you kinda hit the nail on the head right there, uh, with, uh, the perception. So when I was prepping for this talk, you, some of the research I did was going on to other streams, other developer streams, or if people show up in mine and asking, Hey, this isn't a trap. I don't, I'm not trying to start off anymore.

I want to know your honest opinion on Drupal. And these were purposefully non Drupal developers. I've got some that I can't read on this stream because of the way that they worded it, but, uh, some of the others, thank you for that. The last Yes, you're welcome. Uh, the last Drupal video I saw was 2014 ish.

Um, I didn't know Drupal was still alive, had heard about the CMS in a long time. I think of 2010. I haven't done Drupal in more than a decade, haven't looked at Drupal in years, haven't touched Drupal in like 13 years. Everybody's still thinking about that, uh, that, that old perception, the, the seven, the six, they, they had one bad experience and they never went back.

It's almost like going to a restaurant where somebody spit on your burger.

Nic: Yeah. Yeah. I think, and, and I, I don't think you could

JD: convince that analogy, John. I can see that on your face. Yeah.

Nic: It's not exactly like

John: that because I'm, I'm definitely not going back to that place.

Nic: Yeah. Me. Um, well,

JD: but now it's under new ownership and has a new name, but it's, I'm sorry.

Nic: I, yeah. Uh, so, uh, so moving on, the, um, I think we, we've mentioned that there's a lot of technical, um, technical advancements that have been solved in Drupal as well. We've talked a little bit about the perception. Um, are there, are there any other kind of big categories that are kind of holding back Drupal Drupal adoption that you're aware of?

Jd?

JD: Uh, yeah, I, so one of the things that came up was the, uh, admiration or admire versus desire. So admire is the number of people who are doing it current, currently, who are working in a technology currently and want to continue working in it. And desire is the, the percentage of people who aren't working in this technology, but are interested and want to work in it for, for Drupal, the, the admiration was 33.7%, meaning that roughly a third of us want to continue working with Drupal.

A third of the people who responded, the, the desire though was 1.4%. Nobody's interested in, in jumping over to Drupal. Well, not many people are interested. Uh, so it it's got that, that rough perception. That's the biggest thing. And I think another part, uh, is the, the friction to get started. And I think you mentioned this earlier where with WordPress you can spin up something really quick and, and have it going with Drupal, you don't really have that, uh, you didn't have that.

Now it's getting better about it, you know, with a lot of the technical advancements, but it, it's not, it's not known because of that perception from, from the past.

Nic: Yeah. And, and I, and I think that there are some, if, if we're being honest, right? Composer is a pretty big barrier to entry, I think for some people.

Um, but I've worked, the thing is most PHP projects are using Composer outside of, I think WordPress is one of the only ones in WordPress. You can. WordPress really is the counter example, right? The fact that there isn't a community wide way to use composure. WordPress means that every time I have a client that onboards a few word legacy WordPress projects a year, and every single one is unique.

Like every single one is complex because whoever built it, built it in some random way. Like everyone is unique. And so, yeah, we might, um, whereas Drupal, no matter who built it, as long as it's a modern Drupal site, I can move that to a new host in probably two hours, right? Um, and, and I'm not kidding when I say with some of these WordPress sites, I've spent upwards of 20 hours just getting all the requirements in place and getting everything set up and then installing it and realizing that, you know, a, a plugin wants to override itself live on production.

Um, when you add the API key, because they don't want you to, they don't use composure. They don't want it distribute the code. Which I don't know how that works with GPL, but anyway, uh, like there's, there, there's all sorts of problems that come with not having kind of a standardized way of installing and setting up, but that is a barrier to entry for a lot of people when it comes to Drupal.

John: Well, hold on. I want to, I, I wanna an, I wanna ask a question just because I'm unclear as to the answer, um, because I have a perception, but I I might be wrong. Um, so when you say barrier to entry, Nick, I mean like if most PHP projects are using Composer, then most developers should be familiar with that workflow.

So who's it a barrier at entry to

JD: people who aren't using PHP? Yeah. People who are unfamiliar with it. People that we're trying to get from

John: Ah, you

JD: mean other frameworks?

John: Yeah.

Nic: Okay. Yeah. People are used to, people are used to NPM and like the one per got the one point. So just to be clear, jd, the 1.4% is PE is all developers that wanna start using Drupal.

Even people that use React primarily, for example, right? The Yeah.

JD: It's the, the 1.4% is the number of people, the number of survey respondents, uh, that are interested in using Drupal. Hmm.

Nic: Yeah. And the 37 from

JD: other technologies.

Nic: And the 37% is only people that are currently Drupal developers that wanna continue using it.

JD: Yeah. Uh, let's see. It's 33.7.

Nic: 33.7. Yeah.

JD: Which to our credit is, or Yeah. Is higher than WordPress developers who wanna stick around and use WordPress by 3%. So that, that number is 30.4%. So, so

Nic: I was gonna ask that.

John: So the second part to my question, right, is like. Does getting off the island like help us at all?

Right? Well, yes it does. We're off the

Nic: island already.

John: I mean, but I mean, like, so like incorporating things like Symphony, right? Does that, does that bring in more folks or more folks like, oh, you're using Symphony, okay, I'm, I'm now more interested in, in what you have to offer? Or is that kind of like a non-starter?

Nic: I, I, I think that was addressed to jd, but I, I actually have an answer for this. Um,

JD: no, go ahead. If you've got, if you've

Nic: got thoughts.

JD: Yeah,

Nic: I think that was the hope. So I think getting off the island did two things. There were two goals. One was, hey, if we use Symphony, people familiar with Symphony will be familiar with Drupal and will come in.

The second thing was there are parts of building an application that are hard. Symphony already has some solutions for it. Let's depend on that, right? Um, we've been on Symphony now for, since Drupal eight, so what is that? 10 years and. We can definitively say at this point that, um, the first case doesn't happen.

Like people don't go like, oh, I'm familiar with Symphony. Drupal uses Symphony. Let's try it. And one of the reasons is Drupal. Um, Drupal uses Symphony at a scale that most other projects don't like. We, we push the boundaries of Symphony in many, many ways, and we have different assumptions. So there there are two things that we do that make interfacing with Symphony difficult.

One is, we can enable our disabled themes and modules runtime, like right, you can just go to the running site and turn on a module, which makes that functionality available. Symphony is meant to be built in CI deployed. It cannot change until the next deployment suggest, other than,

John: and suggesting I should turn that module on, on production, right?

Untested.

Nic: No, but it's not even just production. It's like you're, you're, you're staging environment. You're local like all of them or, and like, you're not doing a deployment. Continue. And it, so we, we found that familiarity with Symphony doesn't necessarily translate to familiarity with Drupal because of the way that we use Symphony.

It breaks a lot of the core assumptions that Symphony framework developers expect.

John: Got it.

Nic: In ways that like letter Ofl doesn't, um, the second piece, like the, the maintainability piece, yeah. That's helped a lot in a lot of cases, but in other cases it created more work, right? So like the, the dependency injection stuff saves Drupal countless hours of maintenance, right?

The routing and menu system that we put in and then had to subsequently rip out, created a ton of work for the Drupal community. Um, but that's not to say that we should get back on the island, right? There's benefits. We just need to evaluate, um, which piece we're, we're doing.

Rod: Hey jd, let me, uh, let me switch gears for just a second if I could.

You talked about perception and reality. Um, and your numbers are really interesting on that. So the perception is that, you know, Drupal, what drupal's still a thing. Mm-hmm. Versus the reality of 33% of Drupal developers are, you know, gung-ho. People still wanna use it. I I use it for everything and all of us do.

Of course. I'm sure. What do you think then is the challenge here between perception and reality and, and, you know, how do you fix that?

JD: Uh, that, that's a tough one.

Rod: Yeah.

JD: Um, yeah, I, so there, there's that desire gap. The admirer versus desire and the perception. It's not just tied to Drupal, it's also tied to PHP and a lot of the people.

Right. Um. Uh, let me, one of the other quotes I got, which again, this is from somebody not me. PHP is a garbage language for garbage people, is one of their responses. I, I, I don't agree with that at all, and I gave him a, a, a, a thorough tongue lashing to after saying that. But, uh, I just, a lot of people who, who don't want to go over to, to Drupal or to Symphony or to anything PHP is because they haven't seen PHP since five six or even four.

They don't realize all the new stuff that we have.

Martin: Yeah,

Rod: yeah. In your talk, you did a, uh, a percentage of how much of the internet runs on PHP? What was that percentage, do you remember?

JD: That is 72.8% of all websites with known service side languages according to W three techs.

Nic: Wow.

Rod: How do you argue with that?

That's

Nic: actually very

Rod: happy. I mean, people, you, yeah. You cannot argue with that stat. You go, you know, somebody says PHP is garbage. Well, 72% of the internet would disagree.

John: So I wonder. Right. And devil's advocate here, I, I grew up and learned PHP, so I'm a, I'm very invested in PHP, but I wonder like of that 72%, maybe JD knows the answer to this, but of that 72%, how many of those sites or sites built in the last, uh, say five, five years, or even 10 years, right?

Like, is that legacy code that's just kind of still sitting out there, or is that, does that represent kind of new, new development?

JD: I don't have that number. Okay. Uh, but what I do know is WordPress built in PHP 41% of the internet. Um,

John: that's

JD: fair. Facebook originally built in PHPI think now they use, they went to HHVM and now they're in hack, which is a PHP extended or built off of PHP or based on PHP one interesting thing that I found though is, you know, even though it's nearly three quarters of the internet, it's on PHP, it's the 12th in programming language usage because only 18% of the survey respondents actually use it.

So there's a good chance that a lot of that code is legacy code. It's the, it's the, uh, old WordPress site that somebody created as a fan page for, uh, the Matrix when it came out.

Nic: I, I, I, I, I, I think also though, to, to keep in mind, to put this in perspective, is Stack Overflow isn't just for web developers.

And in fact, I would say

JD: right,

Nic: the vast majority, like it seems like that to us because it's on the web and we are web developers, so we interact with the web development portion of it, but I think Stack Overflow in general. It has a much, much bro, or had 'cause Yeah. But had a much broader, uh, standpoint.

And PHP isn't the kind of language you're ever going to, like any of these scripting languages, you're not really going to use them in most embedded applications. Right. Or, um, you know, they, you're gonna use c plus plus, C sharp, C something, or, you know, rust or something like that. And so the, the poor perception of PHP is kind of probably coming from that style of developer rather than from, you know, purely web developers.

If you ask web developers, they probably, JavaScript or PHP is gonna be the language of choice.

John: So before we move on to the, to the, what we can do about it, section of the show here, I'm curious, um, in listening to this conversation, like Drupal's done a lot to kind of remove its complexities, remove its technical hangups, if you will.

I'm sure there's still more that could happen, right? As as you know, any software, open source software evolves. But I'm wondering like. Well, two things. Let me, let me start with one thing is, you know, once people have said, I'm not gonna use Drupal, and they learn another technology, like what's the, what's the pull, the draw, the reasoning that they might say, ah, I'm gonna stop learning this technology and move to Drupal.

And then the other aspect that I'm wondering here is like, and not, not harping on developers, uh, just wondering like how many, how much of this is like old crusty developers that are like, no, I know this thing and this is the thing that kind of got me where I am. So this is the thing I'm gonna keep going with.

As opposed to like, I'm not gonna go back to Drupal because, you know, Drupal seven was, was was not great or I had a bad experience.

I don't know that there was actually a question there. I was gonna ask that. What, what was the question? It was more of just the statement, I guess. I guess the question is like, sorry, I, I guess if

JD: you had the upward inflection at the end, maybe I would've tried answering.

John: Right. So I guess the question there, um, JD in your research, in, you know, being on people's streams in delivering this at a camp, like what is the feeling there of like, are people just kind of entrenched in the technologies?

They're entrenched in? Are people just like, I don't wanna learn Drupal 'cause I already know this other thing and it's, you know, it's, there's no benefit to me. Like, I, I guess what's the hangup, what's the hangup that people are, are kind of saying is the reason they're not coming, move, making the move?

JD: So I think that there are, I mean there's multiple types of developers, but in this, there are.

For this scenario, there are two types. There are the type that I use this, it works for me, I'm not switching off of it.

John: Right?

JD: And there's also the type that, ooh, new shiny, and they wanna learn everything new that comes out and everything that has new features. I mean, I, I've seen people, uh, start off using jQuery and then as soon as React came out, Ooh, I want to switch over and learn all this.

And then, right, uh, new view, new angular, new, uh, new everything. HTMX. Oh, now I need to use whatever the new, new hotness is. And right now the, the perception of Drupal is that it's never been the new hotness. It doesn't really have the, the, the, the things that people are looking for. And that's it, that's not true.

John: Right.

JD: Um, we, we have the things, uh, I think another thing is that, you know, some of the terminology that is being used. Is you, you hear entities, bundles, views, fields that people aren't really interested in. Sure. And that's an analogy that I used in the talk is if I show you a schematic of a transmission, are you gonna buy that car?

John: Hmm.

JD: If I, that's a

John: good analogy.

JD: If I show you a Lamborghini, are you gonna buy that car?

John: Yeah,

JD: definitely

John: am.

JD: So, uh, we, we need to, you know, make Drupal the shiny.

John: So let me ask you a, a follow up to that question, right? So like, part, part of what, I mean, we're talking today about developers, right? And like, what, what makes, what brings them back?

Right? And that, and you just said it, bring, bring the shiny Right. Show them the value, show them that they can get, they can provide their clients a Lamborghini, right. What I wonder is any insight from your research, from what you're hearing about, um. You know, the client perspective. 'cause I, I mean, for a lot of developers it's like, oh, my client wants me to build it in this.

Right? As opposed to like, you know what, you know what technology I know and understand. It's, oh, my, my clients want me to build a Drupal site. Um, are you hearing that or is it really just the client going like, this is what I need. Build it in whatever you want

JD: it. A lot of it is build in whatever you want and what's going to cost the least.

John: Sure. Okay.

JD: And I mean, part of that, I, I haven't put together any sales, uh, proposals on my own. I'm sure at least somebody here has. Uh, and I don't ever want to, which is why I'm, I'm glad working for other people. Um, but uh, you know, if you go in to say, I'm going to sell, if somebody was trying to sell a WordPress site

John: mm-hmm.

JD: Click the big button, you have a site that you can show them exactly what it does. Somebody wants to sell a Drupal site, hold on. While I start up d Dev on my local and

John: mm-hmm.

JD: Uh, do this when you go to drupal.org to try and look at, uh, Drupal CMS, which would be the perfect for, you know, a quick spin up to show off all the capabilities with Drupal.

Uh, at least last time I looked at it, you had to put in all your information, click through, and then wait to get something. And I, that, that's a barrier to even showing a client. They don't want emails from drupal.org. They don't want to give their information away. Yeah. They, they want the big button to see, oh, this is what it does.

Rod: Hmm.

JD: So let

Rod: me jump in there if I could.

JD: Yeah,

Rod: please. Because I know jd, you're gonna mention Drupal Forge here at some point. Mm-hmm. Um, yeah. Drupal forge.org Amazing. You can spin up a site in under 30 seconds and keep it for 30 days, 12 hours a day just by providing your email address. They don't spam you.

Um. And it's terrific. I mean, it's absolutely amazing. And they've got different versions of Drupal or different, uh, I don't even know what they call it, templates for Drupal. They've got Drupal CMS, they've got Drupal CMS with ai. They've got my starter site is on there. You can spin up a starter site for a completely fixed out layout builder, uh, experience mm-hmm.

And more, right? So Drupal Forge is a tremendous resource for this. The fact that you can keep it for 30 days and use it for 12 hours a day, you could literally build a site and then pull it off and put it on your own. Hosting in, as Nick said, you know, in a couple of hours, it wouldn't take long at all.

Yeah. Um, it's, it's interesting what you said. So I do sales all the time. Uh, I'm sorry, my company. Oh yeah, I know. No kidding. Right. So my company builds sites for small nonprofits, small business and go local government, small government, and um, I'm doing pitches. All the time. And I, yeah, I absolutely hate it.

To your point, having a site ready to go and prepped for the pitch is not hard in dral. Um, and clients don't care what you build it in until it comes to cost. And so I just lost one for a tourism out in West Virginia where my pitch was awesome. My, my, uh, list of benefits and features for the website was exactly what they wanted, and I lost it to a company that would do half the, half the amount of work or half the amount of features for half the amount of money.

And I found that to be really interesting. And it wasn't even that expensive. Like again, I do small projects. I'm not the a hundred thousand dollars agency. I'm just me and a couple of contractors. So, um, yeah, I, I think you're right on. People don't care what you're building it in, but you've gotta be ready to demonstrate it.

Well.

JD: And that's why part of the talk was, oh, sorry Nick, go ahead.

Nic: Oh, hey. Oh, I just wanted to echo kind of what Rod was saying is like, sometimes it does just come to cost, but a, a lot of times those costs come at not just fewer features upfront, but fewer features forever too. What, and that's the, that's always the struggle when you're pitching to a client.

'cause you can be like, Hey, yeah, we, I could also build your Drupal site. Maybe you can't get to half the cost for half the features. There, there is a little bit of overhead to getting set up, but maybe for, you know, 60% you can do half the features. But then six months from now when they have more budget and they want the, the roles and permissions, you can set that up.

Or the responsive image tuning or the, whereas in, in WordPress, you, if you choose WordPress or something like, or Laravel. Well, WordPress, you're, you're just hamstrung. Like you can't do the responsive images the way you can do in Drupal. And the roles and permissions are laborious to get implemented in Laravel, you have to just, it's a framework.

You have to build all that stuff yourself. Right? So it's, um, it, it's uh, it's one of those situations where trying to find a way to, to present kind of the, the different options for building a Drupal site, I think is important as a community as well. And it, it is difficult. It's one of the hardest parts.

John: It's also hard to sell that too, because a lot of times people aren't focused on what they're gonna need in the future. They're focused on what they need now. Right. And like, I'll just use you, you, Nick and, and Rod. 'cause 'cause you guys are here. But like, if Nick comes in and says, Hey, you know, future proof we use Drupal, like you can extend it later, blah, blah, blah.

All this great stuff. Right? And Rod comes in and goes, Hey, here's what I can deliver you right now to solve your problem. Chances are they're gonna, they're gonna lean more towards, towards Rod. 'cause he is coming in, he's got a, a polish thing, and he is got, he's got the solution to their immediate need.

Right. Um, maybe that's not everybody, but like, I, I think that's what, I think that's what you guys are kind of, kind of getting at and, you know, that's, that's why, that's why sales is hard. Um, but yeah, but I can see the, like, I can see how that answers my question, you know, as far as like what, um, you know, what's driving, driving the, develop some of the developer decision making.

JD: That's why the, the, the talk was called Why developers don't recommend Drupal, or Why developers don't Choose Drupal. Uh, it oftentimes, it doesn't even get to the developer when, when you don't have the, the, the demo set up to, to show the decision makers who might go back to their developers and say, Hey, what do you think about this?

John: Mm-hmm.

JD: Yeah. We, but I'm glad that you mentioned Drupal Forward Rod, uh, Darren and Sli are great, great people. Put a lot of work into that. Uh, I I love 'em both. And, um, yeah, I, I mentioned that in my talk because that's, that's what we need on drupal.org. That,

Nic: yeah.

JD: You know, click a button and you can see that Drupal has, uh, you can see Drupal CMS, you can see Drupal started up with the, the bite theme.

You can see Drupal with ai. You can see all of these different flavors of Drupal right there spun up in two minutes.

Nic: So this, uh, kind of going back to discoverability, um, uh, Jada, you had mentioned some people like to try all the new tools. They like to discover new things. I, I think there's another kind of problem on the dis discoverability horizon, right?

People, people use what they're introduced to the, the tools define the technology. And I mean, for good or ill. AI generation is a way a lot of people are getting into building applications, and AI only knows TypeScript if you don't tell it to you something else.

Mm-hmm.

Nic: Like it's going to output TypeScript.

Um, do you, do you have any ideas or strategies on how to get Drupal in the conversation? Even there, like, or get even PHP in the conversation there? Right. Because as you said, PHP powers most of the internet, but for whatever reason, TypeScript is kind of the go-to. So is there, is there a way to kind of make a dent in that and get, you know, PHP on the map, get Drupal on the map when people are doing their research?

JD: So we need to be where people are looking and that's a big thing right now, for the most part, we're not, uh, people are looking at technical docs, and this is as of 2025. Stack overflow a survey, but they're looking at technical docs, so they're looking at video content. Um, uh, a big, big chunk, like you said, coming from AI tools.

40, 44% of people are finding that are using AI tools for code blogs. Podcasts are, are great things and like, like this one. Um, and that's how developers learn. They are, A lot of new developers will look for things in those places where developers hang out. Stack overflow, GitHub, again, I have fonts on that.

Uh, YouTube, Reddit, discord, hacker News. Even Twitch, uh, is about 10% of developers learn something from Twitch. And having content there, uh, in, in any of those places, making it visible and, you know, being where people are wanting to learn. The, the other thing is doing cool stuff. Uh, making the shiny that people are interested in finding.

Finding something that, oh, I didn't know Drupal to do that. That the things that are interesting.

Rod: So if I could jump in on that, 'cause you really challenged me to change my thinking on this when I watched your session. Um, I have thou, I have probably close to, probably close to a thousand videos between YouTube, LinkedIn, just all over the place.

My Drupal eight class on YouTube was 63 videos, 4.3 million views.

JD: Nice.

Rod: Pretty decent. Yeah, pretty decent. That's Drupal eight. The most prolific YouTuber right now is web wash. He releases stuff every week. He gets 144 views, 200 views, 300 views on his long format. Over an hour streams. Right. To your point, way too long.

Um, but also to your point. The videos shouldn't focus on Drupal. They should focus on the broader topic and then bring Drupal into it. I think because if you put Drupal, the word Drupal in the title, nobody cares.

John: People check out.

Rod: But if you say they do, they do. And, and this is where you really challenge me because my best videos over the last two years are all around layout builder, like 9,000 views, 6,000 views, and for now, for 20 26, 20 25, that's pretty good in the dral space where a lot of the videos I put out over the last couple of years have hundreds of views, not thousands.

Um, my, the 9,000 view one was, can lay, can, can you make Drupal's layout builder actually work for you? And of course my answer was yes. Um, and I still think you can, but a broader need to broaden out the title and the description of the video. Then hit them with Drupal and how it works, rather than keeping Drupal in the name.

'cause then as somebody said, you instantly filter half your audience out and you really, you really made a good point on that.

John: So I think if, if this, this live streaming thing, um, pans out, we're probably just gonna change the name of the podcast to talking and then like, that'll, that'll, that'll solve that.

Right?

Nic: Talking, talking talkers. Talking about a subject,

John: talking talkers. There we go. That's, that's it right there. Um, put it on, but

Rod: that wasn't quite what I meant, but Okay.

John: Put it on the tshirt. Four beards

JD: with

Nic: glasses.

John: We try to diversify. Sometimes it doesn't work out. Um, go ahead jd.

JD: So what you mentioned there, rod, uh, that was another. A comment that I got when I was asking people about, you know, on, on my stream or in other streams, and I don't see YouTube videos popping up with common questions like crud, blog apps with Drupal solutions.

Maybe don't answer the, uh, assume Drupal is the answer to the question. Look for the question of, for something that Drupal can do and then solve it, yeah. On a 10 minute video with Drupal and yes.

Rod: And

JD: that, that

Rod: might get the people interested. That that was my best takeaway. So,

JD: so,

Rod: and I, and I think it will.

Nic: Interesting.

John: Sorry, that's, that's a, that's an awesome, that's an awesome idea and also a segue into, into my next question, but, but Rod, if you had another thought, I'll let you, I'll let you offer that up before.

Rod: Nope, no, go ahead. Go ahead.

John: So we're talking about consideration set, right? And I, I think like in your talk, you kind of point out that like Drupal is removed from the consideration set kind of before the, the fine, the, the, the, the solutions or the, the, the technologies are presented, right?

Mm-hmm. I'm wondering like why you think that is and how we, how we kind of get it back into those conversations. 'cause I, I mean, I've seen it myself, that's why I'm asking like, oh, we're gonna present a CMS rebuild and like, you know, Sitecore, Contentful expression engine. Like we, we all sorts of, all sorts of things.

I'm like, where's Drupal? And they're like, oh, well we took it out because of X, Y, and Z. So I'm wondering like what you found in your, your, uh, research jd

JD: uh. The elephant in, in the room. Basically, the, the, the first pre-filter for that is PHP, the stigma around PHP, especially for those people who haven't used PHP in a long time.

John: Just keep going back to that 72%, but hey, you continue.

JD: Yeah. Yeah. Um, what I, what I noted down is that many dev see PHP and stop investigating. And a, a lot of a part of that is, you know, right now, any of those dev bootcamps that are out there, they're all teaching node, they're all teaching JavaScript. Uh, they're all teaching, you know, the, the, the me stack, uh

Nic: oh.

Yeah.

JD: And according to the jet brain survey, PHP, Ruby and Objective C are in long-term decline. Again, the 72%, I, I don't see that for, for PHP. It's not going anywhere. 8.3, 8.4, 8.5 have put some absolutely amazing things in. I mean, right now, I, I think that the, uh, the request. Count is is on par with Node. It is, I I think it's like 13 to 12 to 13, or 12 to 15,000 where node is 13 to 16,000 requests, um, for a second

Nic: by requests.

JD: Sorry,

Nic: can, can you define that number? Sorry, I'm not following.

JD: Yeah, I'm,

Nic: yeah,

JD: I have it in my notes, but, uh, the, the request per second, I believe, or,

Nic: oh, request per second. Okay. Yeah. Yeah. That, that, that's, that's what I, I, I missed.

JD: Yeah. Request per second. I'm sorry. I didn't, I didn't add the, the end of it.

Yeah. Uh, PHP eight three handles 12,000, 15,000 requests per second. Um, and that's competitive with Node, which has 13 to 16,000 and compared to Python or Django with three to 5,000, I mean, PHP is moving fast.

Nic: Yeah. And, and, and, and to be fair too, that when. You're doing a server side thing, like PHP, you can cache that more efficiently too.

So that gives requests per a second go through the roof. Whereas Node like, yeah, node is rendering some stuff server side, but inherently it's doing a lot of it client side too. So you're, if you're using Node, you're probably using React Review or something like that. And that's, that's doing a lot of heavy lifting on the single, the single page app side.

And so in a, in a reality, you see worse performance.

JD: Right. And you're also hearing, I mean, who, uh, um, among all of us, how many times have you heard PHP is dead in the past 10 years? Uh, PHP has been dying since, since it was May mentioned. Yeah. Um, it's kind of been, it's become cool to make fun of PHP and say how bad it is.

We're not gonna fix that, you know, without doing other. Doing other things to show. That's the thing, the, that's not the case. Um, and a lot of the time it's, it, it's almost a, an exponential effect of getting, you know, you tell a friend and they tell two friends and they tell two friends, uh, because a lot of developers are asking their peers, Hey, what should I be using?

And until you get that, that number of developers saying Use PHP, use Drupal, it's doing really good stuff. Uh, that's how a lot of people learn. Uh, and if nobody in, in the network is talking about Drupal and in a social network is talking about Drupal, it's not gonna be mentioned. It's not gonna be known.

Uh, and yeah,

Nic: so, so we, we, we've listed a bunch of areas that we know Drupal could deal with. Shoring up, right? We, we listed a, you know, some visibility issues, some. Perception issues, some technological hurdles, some like, we've, we've listed a bunch, but what's in your, in your opinion, jd, what's the kind of best application of effort?

Wh where should the community put most of its effort right now to help resolve, um, these perceptions? Because, I mean, as a triple core developer, I don't see most of these as actual hurdles. I see them mostly as you just pe people have a, a, a perception that they haven't had a chance to actually test against.

JD: Mm-hmm.

Nic: What's the number one thing the community should be looking at doing to help?

JD: In my opinion, and this, this doesn't have necessarily any, uh, evidence other than anecdotal evidence. Uh, but like the Tailwind model, um, he, the creator Adam, we, I think, uh, he streamed his way to a $4 million business. By live streaming, building tailwind.

So, you know, core contributors, core, uh, core developers, you know, it's open source software. You're not, hopefully, unless you're working on a security issue, you're not building to any kind of NDA build something. Film yourself, building it, stream it on YouTube, LinkedIn, Twitch, wherever, and, you know, get, get buzz around it.

Uh, find adjacent communities like I, I know there's opportunity with, you know, the larger symphony. This was mentioned earlier that we are, when eight came out, we are trying to say, oh, you use Symphony. Well, then you're gonna love Drupal or be familiar with it. The overlap isn't completely there, but there's a better or larger than small, uh, intersection in that Venn diagram of Symphony and Drupal.

Where, where it would be an easy way to transition over. My favorite thing is showing weird stuff, uh, on to do with Drupal.

Nic: What do you mean?

JD: Uh, so

Nic: can you,

JD: one of my, one of my best, uh, performing streams or series of streams is last year I built in Gdo a Minesweeper clone. And I, I made it multiplayer and I used Drupal as the backend for a leaderboard.

So, oh, the Minesweeper was sending all scores back to Drupal. And then another game that I built was a leaderboard that was taking those scores and displaying them that a giant screen to show who was, who had the highest score of the day.

Nic: Okay.

JD: And, you know, showing that I could do stuff with Drupal like that, got some people interested.

That that's where a lot of the, oh, I hadn't heard of it before this, but this actually looks really cool.

Nic: Yeah. I, I, so I, I think there's a, a lot of, a lot of what I'm hearing is publicity, and I think part, I think Drupal CMS and site templates go a long way towards that, you know, traditional marketing. I think also finding a way to highlight, like, there are, there are so many things that Drupal does that as kind of Drupal, uh, fans we kind of take for granted.

I mean, it's the reasons we love Drupal, but like the, the security team is outstanding, is one of the greatest strengths of Drupal. Mm-hmm. Responsive image handling is outstanding. Uh, the, the config management is one of the best parts of Drupal, the strong core. Set up with Composer, you know, the permissions and roles system, the performance, the cash tag.

I mean, cash tags are so good that CloudFlare implemented the ability to use cash tags to expire content. Um, there are just, there, there are many, many, many things that Drupal does really well. And the truth is most people don't need all of them. But we, if we can build kind of the, these are the things that Drupal does better than anybody else combined with each other.

And the, and the fact that you can affect it with hooks and intersect with it with hooks is, is outstanding. I mean. Um,

John: Nick, Nick's making me think that we need like an out of the box marketing campaign where it's like, oh, responsive images. Images. Did you outta the

Nic: box? Wasn't there a

John: No, no, no, no. Not like that.

But like, like a, a, a legit marketing campaign like working with, um, Ryan at the DA to do like a responsive images. Oh yeah. Our CMS does that out of the box. Right. Just like highlight all the things that you talked about that are like, Hey, you don't have to pay for somebody to like, implement this stuff, um, or build this stuff.

I should say. You should, you do have to pay for somebody to implement it, but like, you don't have to, you don't have to build this stuff. You can literally get this out of the box with, with Drupal. Right. So like,

JD: so that's something that I, I mentioned, sorry, I don't mean to interrupt.

John: Go for it.

JD: But, but it's fresh in my mind and if I don't say it, I'll forget.

Understand something that I mentioned understand when I gave the talk is I, and you know, we're not sharing screens here, but if you look at the sites like Laravel, um. And some of the others, uh, what was the one that I had written down earlier? Sta or a static, I don't, not sure how to pronounce it. Even WordPress.

The first thing that you see when you go to their sites is the backend. You get to see what the admin side looks like. You, you can scroll down and see what it looks like to use it. Um, Laravel actually, sorry, satanic, you can actually spin up from, from there. A 30 minute version of a Satanic site. Use it.

It's got content there for you to play with. Uh, you get to log in as David Hasselhoff and it's there for you to try out right from this first screen. drupal.org. And I talked to y the DA about this a little bit. drupal.org. You've gotta go through so many steps just to see what the backend looks like.

John: Sure.

JD: There's nothing showing how cool the new dashboard is. How great, you know, the backend is compared to seven. Compared to eight.

John: Mm-hmm.

JD: Uh, the, the new, uh, admin themes, the new everything that we have. Right now, it's, it's trust me, it's good. It's, you know, oh, you know, it, it's great, but you gotta sign up to, to see it.

Yeah. It, it feels very, very walled off. And that's not the way it should be.

John: I, I couldn't agree more and I would love to keep talking about this for the next, you know, next hour. But, uh, you know, I think we're gonna have to leave it there. Um, jd I thank you for your time today. I thank you for doing this talk and shining this spotlight on this thing that we all need to kind of, um, make sure that we're communicating out to the world better.

So thanks for joining us today.

JD: No, thanks for having me. This is always a good time here. Yeah, it was a great talk.

Nic: Do you have questions or feedback? Reach out to talking Drupal on the socials with the handle of talking Drupal or by email or [email protected]. You can connect with our hosts of the listeners on Drupal Slack in the Talking Drupal channel.

John: If you wanna be a guest on Talking Drupal or our new show TD Cafe, click the guest request button in the [email protected]

Nic: and you can promote your Drupal community event on Talking Drupal. Learn [email protected] slash td promo.

John: Get the Talking Drupal newsletter to learn more about our guest hosts, show news, upcoming shows, and much more.

Sign up for the [email protected] slash newsletter.

Nic: And thank you patrons for supporting talking Drupal. Your support is greatly appreciated. You can learn more about becoming a [email protected] and choosing become a patron.

John: Alrighty, jd, if folks wanted to get ahold of you to share their thoughts about, uh, Drupal, uh, adoption or hero devs or anything else that you do, how could they go about doing that?

JD: Uh, you can find me on the Drupal slack as dorf, DORF, uh, or you stop by my stream, Twitch tv slash jd does dev, which is no. Right behind me. There you go. Might be hard to read. Uh, I stream five to six days a week, usually from about five 30 central standard time until I'm done on Monday, Tuesday, Wednesday, and Thursday and Saturdays from 10:00 AM to whenever I'm done.

So sky the first stop

John: by sky. Always, always online. I love it.

JD: Yeah. I, I'm trying to put my streaming where my mouth is by, by doing cool stuff.

John: There it is. That's the soundbite for today's show. Rod, what about you?

Rod: Uh, I'm Rod Martin at the Dral Slack channel and, uh, Drupal helps.com.

John: And Nick,

Nic: you can find me pretty much everywhere at Nicks van, N-I-C-X-V-A-N,

John: and I'm John Ozzi.

You can find me [email protected], on social media and drupal.org at John Ozzi, and you can find out about [email protected].

Nic: And if you've enjoyed listening, we've enjoyed talking. Maybe we'll just be talking in the future. Who knows?

John: Who knows? Thanks a lot everyone.

Nic: See you guys next week.