Talking Drupal #564 - Approachable Open Source

[00:00:00] John: This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 564, Approachable Open Source. On today's show, we're talking about maintaining Node.js, Parent, Parent Lab, and writing books and open source with our guest, Brian Munzenmaier.

We'll also cover AI web form generator as our module of the week Welcome to Talking Drupal. Our guest today is Brian Munzenmaier. Brian is a multifaceted community leader, engineer, and bald guy. He is a member of the Node.js web infrastructure team, triage team, and moderation teams. He wrote Approachable Open Source.

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

[00:01:02] Brian: Hey, thank you. Um, I appreciate being here. I also appreciate the, um, the Freudian slip of Parent Lab versus Pattern Lab, because I did tell you that I, I, uh, own a lot of children, and- ... it does feel like a laboratory. It's all accurate.

[00:01:21] John: Uh, yes. That, that is, that is parent.

Parent or pattern. It's actually pattern, but you know, uh, I guess, you know, depending on how you look at it, it could be a parent lab, too. Um, I am John Picozzi, solutions architect at EPAM, and today my co-hosts are plentiful. Starting with joining us for the next four weeks, JD Flynn, senior software engineer- Hello

at HeroDevs. JD, what's up?

[00:01:47] JD: It's... Oh, glad to be here. A big fan. Uh, yeah, excited to talk Drupal.

[00:01:53] John: Awesome. JD's a senior software engineer at HeroDevs. He's also streams game development on Twitch, and occasionally plays the saxophone. Uh, is it we- is it weird I immediately thought of Lisa Simpson? Any, anytime somebody plays a saxophone, I'm like, "Oh, Lisa Simpson," or Bill Clinton, but preferably Lisa Simpson.

[00:02:12] JD: Actually, I play the same kind of saxophone as Lisa Simpson, it's a bari sax. The, the big ba- not quite bass one. Well, it's bass-ish.

[00:02:20] John: I, I also feel like you're one of those big-brained individuals like Lisa Simpson. But, um, I got a lot of other hosts to intro, so I'm, I'm gonna, I'm gonna move on from that one.

Um, joining us this week, a special, special host, Bernardo Martinez, front end developer at Voltus.

[00:02:37] Bernardo: Hey.

[00:02:38] John: Bernardo, how are you?

[00:02:39] Bernardo: Doing good. Uh, are you doing the talent show at DrupalCon Orlando, JD? Did you hear about

[00:02:46] JD: that? I wasn't aware there was one, but,

[00:02:48] John: um- That's a good idea. That's a good idea ... we'll talk. I feel like, um, some, some, uh, some saxophone jazz is in your future.

[00:02:55] JD: Some jazz improv of the Drupal song?

[00:02:57] John: There you go.

[00:02:57] Nic: Yeah.

[00:02:58] John: And last, but certainly not least, Nic Laflin, founder at nLightened Development. Nic, what's going on?

[00:03:03] Nic: Not too much. Happy to be here. I, uh, I saw A Brand New Day yesterday. Won't, won't give any spoilers, but it's a good movie. I, I very much enjoyed it.

[00:03:10] John: Uh, you're talking about Spider-Man, for folks that aren't in the, uh, uh, in the Sp- Yeah,

[00:03:14] Nic: Spider-Man

[00:03:15] John: the Marvel universe, Marvel MCU.

[00:03:19] Nic: Yeah. MCU. Um- Yeah, it was a good return to form. Good movie.

[00:03:20] JD: Yeah, I can't believe that they, they made it so that Wolverine is Spider-Man's father. That's the weirdest thing that I've ever seen.

[00:03:27] John: Oh, man, I can't wait to turn that into a Short. And have a million people tell us why, why we're messed up.

Hey, uh, so, a funny story about that. My kids were going to the movies the other day with, uh, with my wife, and, um, I was like, "Hey, listen, there's only one rule. You can't go see Spider-Man." It really, really made that movie trip, uh, not as fun as it could be. All right, let's jump into our module of the week.

And to tru- to do that, we are going to turn it over to Jacob Rockowitz, a longtime Drupal contributor, a maintainer of the Webform module, and a maintainer of the Schema Blueprints module. Uh, Jacob's filling in for Martin, who, uh, who's had some, some travel difficulty getting back from his vacation. Jacob, welcome, and what do you have for us this week?

[00:04:14] Jacob: Well, I was deciding to scroll through the most recent modules on drupal.org that were released, and I saw the AI Webform Generator caught my eye, 'cause so the Webform module, and people ask us questions sometimes. And the AI Webform Generator module enables site builders to create a Drupal Webform or update an existing one from plain English instructions.

It sends the request through the site's configuration Drupal AI, configured Drupal AI provider, validates the returned Webform definition, and saves the returning resulting, or saves the resulting form. Um, it doesn't totally let you review the form before generating changes, but not totally when I did a test.

Um, the namespace is AI Webform Generator. It was created on July 2nd by, and I'm gonna have problems with these names, but Chetanya Desai. Can, if anyone wants to help me with that, please take a crack at it. You're,

[00:05:04] John: you're doing, you're doing great. Yeah. Don't ask, don't ask this guy about names.

[00:05:07] Jacob: Yeah. Okay, it's got a 1.0.2 release.

It's for Drupal 10 and 11. It, it appears to be actively maintained, last updated July 24th. Um, there's a second maintainer, Zeeshan Khan, and they both seem to work at SpecBee or that's the sponsoring organization, so it has a stable release, therefore it has security coverage. The test coverage includes unit tests, kernel tests, and functional tests for prompt building, just own validation settings, and route access.

But also test capture, which I think is an important thing that they recognize that anyone building a form's gonna want spam protection. Uh, there's documentation on the project page and a README. Covers, you know, the requirements, configuration, usage, security considerations, and what type, field types are supported.

It only has one open issue, and only one site reporting using it. Uh, the module features, you know, creating... Basically, I'm gonna skip through these to say it gives you a text box right near the web form module. You can just give it a prompt and say, "I would like to create a contact form with these fields," and it will generate a web form, return a web form with you that then you could review and tweak.

Um, the configuration is fairly simple because it looks at the, for the AI module and an AI provider, and basically just allows you to do some configuration on what model you wanna use, the temperature, the output tokens, the... It's setting some request limits, 'cause this could be dangerous if... I mean, but then it does all the permissions.

Basically permission to configure, administer, and then to use. And in full disclosure, to do this assessment of the module, I used AI to gen- to, to... Actually I, I said, I did very little research. I prompted Codex. I said, "Here's a module. I wanna look at it, set it up locally, give me a recipe, configure it and prove that it works."

And it did all that before I even looked at it. Um, so I included a link hopefully you can put in the show notes that has almost all this information, and I actually let Codex go at it and just do a little bit of an assessment, and just talking about... I mean, the big takesa- takeaways is recognizing the code quality, that it includes unit tests, kernel tests, and functional tests.

Um, it's useful for quickly setting up a form. It's very straightforward, which is nice, 'cause the other demos tend to nest web form building in a larger chat, which is harder to get to. You almost have to know it's there, and this is l- there's a use case to this. I'm in web forms, I'm building web forms, I wanna just talk about web forms.

I don't wanna talk about other configuration on the site. Um, I really appreciate that AI came back with a next step, which is, um, letting people review the changes before it makes any. And it's a really big thing that's happening in AI, where you wanna see a plan before it does something. It doesn't exactly do that.

It generates the form, and then you can adjust it. So let's just talk about this module and, and anything else you wanna talk about.

[00:08:00] John: I have so many, so many questions. Yeah. Um, 'cause I'm actually in a project right now with pretty, pretty, um, complicated web forms, and looking for a way for folks to, uh, be able to update them, um, relatively easily.

Uh, wondering, I'm assuming that this is doing, like, it's making all the updates to the web forms and then, um, you know, those still are happening in config and, like, you could export config and, and into your code base and all that stuff. So it's not really changing the underlying of, like, how Drupal works.

It's just simply going through kind of the, the point and click of the UI to, to create the web form and permission it appropriately and, and all that stuff.

[00:08:44] Jacob: Yeah. It's, it's more of a, a, a web UI. I mean, I will throw out there, I've done it a lot, where you can generate web forms just in a recipe. If you're a developer and doing- Mm-hmm

a complex web form, you can prompt AI, and frankly, get a little more success because it can look under the hood at the code when it's generating a web form.

[00:09:03] JD: Mm-hmm.

[00:09:04] Jacob: So you pick an element. That's where it's a question of inside and out Drupal for doing things. If you're outside Drupal generating a web form, it will go in.

If you pick an element it doesn't understand in its training material, it'll go find the plugin lu- loaded, and be like, "These are the properties. This is how it's supported," and find even test cases. So it's, it's an interesting... But this is really useful in the UI for people. I think, like, you almost want both use cases.

[00:09:29] John: Yeah. Interesting. Um, so, uh- I'm- Go ahead, Nic. Go ahead.

[00:09:37] Nic: Yeah. I'm, I'm curious if it has, um, if it's, like, hooked into, like, templates or, like, a meta prompt, 'cause many time, I- The thing with Webforms for me isn't so much building the form. That's usually pretty quick. Mm-hmm. Sometimes on the more complex field elements, it can be kind of tedious, like if you're creating a select list or something.

But it's all the little Webform settings that I want to keep set. Like, I want to purge responses after 30 days. Right. I want to... Like, those are the things that somebody that is not a developer creating it probably isn't going to remember or care. But, or setting up the email. Like, those things are- Mm

kind of standard. You usually have a template, and if you had a way to just enforce, a- and I guess you could do this with hooks or with templates or something, but enforce, like, hey, let them create whatever forms they want. But no matter what form they create, it has to purge all of them after 15 days. It has to set up two email plugins or whatever, whatever they're called, I forget.

One for handlers, one for, um, you know, one for the person responding and one for the site admin, and then w- and, you know, whatever other settings. I think that'd be, that'd be great. It'd give them freedom to set up or tweak fields, but you wouldn't have to worry about them, um, you know, storing data longer than they should or, or other requirements for the site.

[00:10:57] Jacob: It's a really good example, um, that you're bringing up, because it's not a hard prompt to say, "Use this existing template as the base with all its pre-configured values, and then build the form on top of it, and don't change these base values." And you, you... Nic, you are calling out a limitation that I didn't catch because you bring up, "I want to change the prompt."

The prompt currently is hard-coded in the module, and I will just say as a rule, I think all prompts need to be editable because you're gonna wanna tweak them. AI moves so fast. Depending on your model, you're gonna wanna change the prompt. Um, it's good to have a default prompt, but you don't want to hard-code it in code.

You want to expose it. Yeah. It could be in configuration, but this is hard-coded in a prompt builder service. Um, so that... But it, by the way, it is a good prompt. I'm reading it and it's basically broken down into rules and steps, um, to do it. But yeah, I- Very cool ... constraints are really hard, and Webform, as the maintainer, I'm gonna say has a slight limitation that what you can do is not so well documented because there's so many things going on and they're complex options versus like, um, config in Core has config schema to find...

If you do config schema exactly right, an AI can know exactly what values are supported, what are the options, allowed values, string limits. And the Webform- Yeah ... is not that, as strict with that. And so that makes it challenging for an AI to get it right. At the same time, there's a lot of examples, and AI does do a good job looking at the examples and basing what it generates off of that.

[00:12:28] John: So I, I, I mean, this module is, is great and seems like, seems like it's super powerful. Great use of, uh, AI within Drupal. Um, I have like 10 million more questions but, uh, you know, we just don't, don't have time for that. So-

[00:12:43] Jacob: Well but John, John, to your use case, just to throw it out there, I think if you had access to the prompt and you had a client with specific things you wanted to help them with, you could manipulate the prompt to be like, "Only help them with elements."

[00:12:55] John: Yeah.

[00:12:55] Jacob: And like, "Here are the elements I want you to look at." You know, you can get a lot done with that. Yeah.

[00:13:02] John: My big, my big hang-up right now is that, hey, you're gonna edit config and then w- how do we get that back into, uh, back into the code base to ensure that a next deploy doesn't blow out, blow up that config?

Um- Yeah, that's a

[00:13:15] Jacob: whole other discussion.

[00:13:16] John: That's a whole other, that's a whole other can of- That's a- ... can of worms. That's

[00:13:19] Jacob: a-

[00:13:19] JD: I do have one question before we go on. I, I don't know if you looked at this but is there any, uh, thing in the module that saves the prompt that you give it so that you can go back and look to see maybe where something went wrong or something went right?

[00:13:34] Jacob: It's a

[00:13:34] JD: great- To have kind of a baseline.

[00:13:36] Jacob: Yeah, it's a great question. It extends the AI module's ecosystem which has good-

[00:13:41] JD: Mm-hmm ...

[00:13:42] Jacob: logging and telemetric, I can never- Okay ... get that word right. Telemetry to track these things and you have to turn that on and look at it and then adjust it. Um, but yeah, no, for prompt engineering there's a lot more stuff you could do.

I think the AI module's doing a lot of that. They're gonna add evals and stuff like that to help with that.

[00:14:01] John: Cool. Well, Jake, thanks for filling in. Cool. Thanks guys. Pleasure. And if folks wanted to, uh, connect with you, uh, about-

[00:14:08] Jacob: Jay Rockowitz on the web.

[00:14:10] John: There you go.

[00:14:11] Jacob: Pretty much everywhere. Uh, you know, uh, s- Slack, LinkedIn are probably the best places to catch me.

[00:14:18] John: Awesome.

[00:14:19] Jacob: All right.

[00:14:19] John: And if you wanna suggest a module of the week feel free to, uh, connect with us on Drupal, uh, talkingdrupal.com, Drupal Slack, or you can reach out to Martin directly, uh, as mandclu in most, most places. Thanks Jake. Cool. Have a good one.

[00:14:35] Jacob: Take care all. Thanks.

[00:14:36] Nic: It was good to see you. Bye.

[00:14:39] John: All right folks.

Let's turn it over to Matthew. He's here to share some information about Drupal GovCon.

[00:14:48] Matthew: The Drupal community s-, does some of its best work when we get together, share what we've learned, and talk honestly about the problems we're trying to solve. That's what Drupal GovCon is all about. From August 11th through the 13th, more than 600 members of the Drupal and government technology communities will gather at the University of Maryland in College Park.

Whether you're a developer, a designer, content strategist, project manager, agency professional, or government digital leader, you'll find people who understand your work and sessions you can put to use when you get home. Come for the keynotes, trainings, technical sessions, and birds-of-a-feather discussions.

Stay for conversations and connections that happen between them. Drupal GovCon is free to attend. Register today and make your travel plans at drupalgovcon.org. We'll see you in College Park.

[00:15:45] John: Thanks, Matthew. Looking forward to, uh, to hearing all about Drupal GovCon. All right, Brian, you've been patiently waiting. We appreciate that. Um, for our listeners who, uh, may not be familiar with you, uh, and particularly your journey as an open source contributor, can you give us a little bit of background on, uh, kinda where, where you've come from and where, where you are today in your open source journey?

[00:16:12] Brian: Yeah. Thanks. Um, I'll do my best to, to cover all that. Um, so I've been, you know, in the tech space for maybe 20 years now, um, seriously, and I started my journey into open source like everyone does, um, and that's as a consumer of it, right? Um, it's so ubiquitous in our, um, daily lives, our entire environment.

Um, the software that we're running right now. It's in your car. It's on your phone. It's in your HVAC system. You know, like, you c- It's in all your school, kids' school systems, for better or worse, right? It's just everywhere. Um, and my, uh, my exposure started, you know, when I was working as a, a very green, new, uh, front-end engineer and, um, learning about jQuery Mobile and jQuery and, um, some of those kind of, like, golden age tools that were built, um, to help smooth over browser incompatibilities at the time and, you know, like, uh, clean up, uh, you know, perceived or actual gaps in standard libraries.

Um, and inevitably, when using something, um, you encounter a, a problem or a bug, um, a typo, right? And, um, that was how I started with, um, you know, finding something wrong in the... I think it was the jQuery Mobile docs. And, um Being curious about how, if I could fix it myself. Um, so the rest is a, a longer-winded history, but, um, that's really how I started.

[00:17:58] John: Have you always been- So yeah ... Sorry. Sorry, Nic. Have you always been, uh, focused on the front end or interested in the, in the front end side of things?

[00:18:05] Brian: Um, I'd say yes. Um, I, I try to coach other engineers now that we are all, um, you know, not just, and I, I say this because of my current employer, um, not just like React developers, not just web developers, not even just software developers, right?

We're, uh, a lot of us are engineers, uh, developers, uh, problem solvers. Um, but I gravitate towards, uh, front-end engineering, uh, the back of the front end more so than the f- the, the front of the front end to borrow from, uh, Brad Frost's analogy. Um, but I'm, I'm probably more of a generalist than I realize these days.

[00:18:48] Nic: So a- as you got hooked into open source, what did you find most useful in your journey? Did you make connections at conferences or projects or coworkers? You know, h- how did you get involved?

[00:19:02] Brian: Yeah, I think that was the, one of the big unlock moments for me, and I've heard other people describe the same thing too, where everyone seems to have an origin story for, for open source.

And for me, um, it, it coincided with that first job, and, uh, on, I don't know, on, on a whim or, or through some, some happenstance, um, my employer at the time decided to send me to, um, a web des- a web design development conference called An Event Apart- Hmm ... um, uh, run by Eric Meyer and Jeffrey Zeldman. Um, very formative, you know, in like the last, uh, 15 or 20 years.

It's where responsive web design was, you know, first, uh, um, presented by Ethan Marcotte. And, um, like, just in the most serendipitous moment I got to see him present a, a workshop about responsive web design and, um, he, like, signed my copy of, of A Book Apart and all this fun stuff. And, um, it was really there that I went from a, a singular, uh, web developer who lived in, uh, Northeast Wisconsin to realizing that I was a part of a bigger community, and that there were other people that cared about the same thing that I did.

And look, they all gather together and talk about the stuff, right? And, like, we're doing that now, right? And, um, you just need to kind of look around or, or be exposed to that spark in order to, uh, to get going.

[00:20:34] Nic: It- it's funny because the... one of the... part of the origin story of this podcast is I went to a responsive web design, uh, boot camp that Steven, one of the original co-found- well, he, he's still a co-founder, he still works behind the scenes, and John were there, and I went there and he invited me to start the podcast.

So and, and- That's neat ... a lot of the, a lot of it was based, I think, on the, the book that Ethan wrote. Um, I think we went through it in the... We had a web design book club.

[00:21:05] Brian: Nice.

[00:21:06] Nic: And, uh, yeah, it was the genesis of, of a lot of change on the internet.

[00:21:12] JD: All right. I do have a question, not even related, but you've mentioned Northeast Wisconsin.

Uh, have you ever encountered a hodag?

[00:21:20] Brian: No. Uh, no, not that I know. But though I'm sure, like, you know, this is gonna be super topical, but, like, Jimothy the Racoon is, like, very, uh- Yeah ... part of, like, the zeitgeist of, like, my children and, and, like, uh, you know, that could... Who knows what that is, right? Right?

[00:21:37] Bernardo: What is a

[00:21:38] JD: hodag?

A hodag is a, a cryptid of Northeast Wisconsin, in the Rhinelander area. I've got family up in that area, so. Oh. So, uh, so I've attended the Hodag Fest before.

[00:21:50] Brian: Yeah, we've gotta put that in the show notes.

[00:21:52] Nic: We... I will be looking for some links about that.

[00:21:58] Bernardo: So Brian, I wanted to ask a little bit about your involvement with Pattern Lab, and specifically the Node.js version. Can you tell us a little bit about that, and how did that come about?

[00:22:10] Brian: Yeah. Yeah, you bet. Um, so, you know, c- c- coming out of, um, some of my first conference experiences, everyone was talking about design systems, or...

They didn't even call them that then. They... It was component libraries, right? This was the era of Bootstrap, um, of Foundation. Um, gosh, I'm probably trying to think of other ones now, but, like, like Bootstrap was king, right? Um, and people like Dave Rupert were talking about, like, building tiny little Bootstraps for every client, and Pattern Lab and Brad Frost's Atomic Design was, uh, one of many tools that was exploring this space right now.

Um, I, I didn't really know a lot about how to build software then or how to maintain a project, and I only had a, a Windows, uh, laptop for college, I think. So, um, this was before Windows Subsystem for Linux, and the, the, the notion of, like, installing PHP on, on my machine was just, like, utterly foreign to me.

Like, I, I did not understand how to do that. Um, which is, that is kind of funny to, like, look back on now, 'cause it's, with AI and stuff, it's probably, what, like, a f- f- three-minute speed bump or something. Um, so because I, I didn't know better and I was just, like, some punk kid, um, the, the Twig PHP version of Pattern Lab was really, really interesting to me, and like I'd s- I had seen it demoed and, uh, you know, I, I, I loved its concept, but it was...

it wasn't approachable to me, which is maybe the operative, you know, uh, foreshadowing. So I, I did what any, any silly, naive person would maybe do and I, I forked it into Node.js. Um, that was the ergonomics and the platform that made sense to me at the time, and, um, JavaScript hadn't really eaten the world yet.

Um, but it was, it was just easier for me to, you know, grok the command line and see things more in, uh, instantaneously and like... You could do all that stuff in PHP, like of course you could, but, like, I just didn't really know better. So, um, that was, that was kind of the big thing, right? And a lot of good came of that decision, but it wasn't really realized for a long time.

[00:24:31] Bernardo: Was that your first open source package, or did you have some other ones at that point?

[00:24:37] Brian: Uh, you know, I think I might have had a couple other jQuery plugins. Um, they might still be on my GitHub as like a time capsule of sorts. Like, I was really obsessed with this, like, idea of like a compass rose and I made this J- jQuery plugin that would take a navigation, like, list of elements and, uh, put it on a unit circle and then you could, like, rotate it using, um- Hmm

geometry, which I, I hate geometry so I had to like, you know, steal all the math to make these things rotate. But you could do all kinds of fun things, uh, like that. And I had a couple plugins that were, you know, toy level, uh, things like that. But, but Pattern Lab was the first one where it started to attract a community.

It was the o- first one I maintained with intention. Um, you know, prior to that I'd been dabbling in, in fixing documentation. Um, the responsive image, uh, community group, which was kind of part of the W3C, I, uh, I think, um, they eventually created the... helped create the picture element. You know, very, very- Yeah

uh, uh, big part of the, uh, responsive web design, um, I guess, uh, strategy. Um, I was inv- a little involved with that, but it was, it was really, you know, dipping toes in the water until I, uh, formed Pattern Lab.

[00:26:01] JD: So you mentioned why you, why you forked it, why you got into Pattern Lab initially, but what, what kept you maintaining it over the time that you have maintained it? What, what kept you interested in, you know, a project like that?

[00:26:15] Brian: Yeah. Um, you know, I think it was just a fantastic vehicle for learning, and that's, that's me, like, retrospecting, right, some, some 15 years later or so.

But, um, it, it exposed me to so many new concepts, right? Like async generators and promises, and just, like, a, a, a lot of language concepts that I didn't really even understand, uh, very well at the time. Um, it, it, it was like a, a good outlet for my energy that still had tangible, uh, artifacts at the end, right?

I was still, like, a part of this bigger thing that was building, uh, you know, building a tool that was useful to me and others, and it had a fantastic spec, right? Like, the PHP version, which I was able to get running eventually, was- ... was, uh, a living, uh, you know, integration suite, right? Like, a, a, a really great regression, uh, test where I could, um, actually compare the source code, right, from, from one set of patterns to another and see, like, well, how, how do they do lineage, or how do they, you know, uh, integrate plugins?

And, and, like, the output, uh, in theory, could be, like, byte identical, but the, the engine was different. So, um, that was... The whole suite of interesting problems to solve, um, you know, came with that and, um, it, it sustained me in many, many ways, um, because I was using it every day too, right? Like, I- Mm-hmm ... I was a user and a maintainer, and, um, that's, that's become such an important part of some of my own, like, open source ethos too.

[00:28:00] Bernardo: But the Twig version, um... Oh, go ahead, Nic

[00:28:04] Nic: No, uh, well, I was, I was just gonna say that the, the Drupal community, uh, utilized u- utilized Pattern Lab for years. Like, it, it was adopted in a pretty widespread fashion. Um, I think even, even though Drupal is a PHP framework, I think for many years I used the, the Node.js version.

Like, it just was kind of the accepted way to do that. Um, obviously in recent years, Storybook has kind of taken, uh, taken root and, and taken precedence. But yeah, no, I thank you for your contribution. It certainly helped me. Mm-hmm. It helped me maintain a lot of complex, uh, design systems. Um, so yeah, I appreciate it.

[00:28:47] Brian: Yeah, thanks for saying that. It, um, it's always humbling to hear how people use tools you make, the things, the things you put out in the world. And, um, I mean, that... It, it continued to, uh, excite me and terrify me when I was younger and, uh, you know, didn't, didn't really have a good handle on, on the potential burden of, of that.

Like, people were feeding their family b- based off of the, you know, the, the work that I was doing and others were doing to, to make Pattern Lab. You know, they were running agencies on top of it, or, um, companies were using it for their design systems, and it's like, just... I don't know. It, it, it's... If, if that's the, the itch that you scratch or however you wanna describe it, right?

Like, it-

[00:29:36] Nic: Yeah ...

[00:29:36] Brian: it really, really, um, was an impactful motivator

[00:29:42] John: So how did you, uh, know when it was time to move on from Pattern Lab, and what kind of triggered that, that shift?

[00:29:55] Brian: Yeah, good question. Um, and some, uh, you mentioned Storybook before, right? Like, Pattern Lab was a, a proto-Storybook, uh, of s- of a sense, right?

Like, we never had-

[00:30:04] Nic: Yep ...

[00:30:04] Brian: a direct React crossover, and that was part of its appeal perhaps. Um, but it existed prior to or maybe, like, growing at the same time. But, um, as I hinted at before, there was a... there was this kind of natural progression where I stopped using Pattern Lab as a user. It was no longer a part of my daily driver workflow, and it, over time, I think made me a little insular.

Um, not to the needs of, of the, of others, right? I, I have empathy for, for folks, but, like, I had lost some of my own motivations to im- improve it one way or another or to push it further and further, um, because it was good enough for me or it was good enough the way it, it had worked. And I s- I stopped building it and started, like, keeping the lights on, and it was a harder and harder thing to, to reconcile with my work life and my home life when- Yeah

um, it didn't have as much of that, like, in... You know, every day I'm touching it, I'm using it, uh, kind of pattern that I think is, you know, obviously much more healthy.

[00:31:22] JD: Yeah. So I... With that, uh- Forgive my ignorance, but were you the primary only one maintaining Pattern Lab or did you have others who were assisting you on a regular basis with it?

[00:31:35] Brian: Yeah. Within Pattern Lab Node I was the lead maintainer, uh, by, by far, by, you know, commit count, by merge, uh, you know, uh, queue frequency, whatever. Um, I had a... There was a whole lot of awesome contributors that, uh, I don't wanna discount. Um, Jeff Purcell, uh, was one of my, uh, biggest, uh, co-contributors and, um, we've, you know, grown to be, uh, close friends.

Um, I had, uh, Rafael O- Okan, I think his name is, um, who is over in Germany, who contributed whole modules, um, that I didn't even incept. And of course, Brad Frost was, um, involved as a, um, kind of overarching, I guess you could call him a product owner almost, right? He... It was his original vision. And then Dave Olsen in the PHP community, um, Pattern Lab PHP, uh, inventor, um, like s- still to this day, uh, you know, a better code architect than me.

Like, Pattern Lab PHP was just fantastically written. So well-written that I was able to, you know, crib it to, to architect a whole, whole nother engine, right? Um, so we're, we're all still pretty close, us three. Um, but, uh, no, it was not a singular effort, um, uh, to... At all

[00:32:59] Nic: Ma- makes sense. Uh, so shifting gears a little bit, um, you are the author of Approachable Open Source.

What, what inspired you to write that book?

[00:33:09] Brian: Yeah. Um, you know, I think some of the theories or, or observations I've been talking about now, um, swam around in my head for quite a long time. And, uh, as, as part of my, uh, I guess growing away from Pattern Lab, um, I also burned out pretty significantly, where I didn't have that sustainable energy source of constant use and, and like strong sustainable governance or partners around me, um, to help.

So, uh, navigating the, the burnout and the burden of, of open source maintenance informed a lot of my thinking about how individuals and companies should be orienting to, uh, the open source ecosystem. Uh, so I, I think somewhere in my site it says I've been, you know, kind of writing this book in my head for 15 years and pontificating to, you know, team members about, "Well, this is how it should be done," kind of thing.

And, um- Yeah ... at, at some point I read, um, You Should Write a Book by, um, the lead editors of A Book Apart, which was what also, uh, you know, authored, uh, Responsive Web Design, or, or, uh, published Responsive Web Design. And, um, they accepted, uh, the proposal, which was just like utterly, uh, surreal, um, to- Yeah ... to be able to write a book- In the, the same, you know, vein as Jeffrey Zelman or, or Eric Meyer, uh, uh, so many s- smart, smart, smart people, um, was just, like, the opportunity and, and privilege of a lifetime.

Uh, that proposal and the rounds of editing that, that, uh, came about happened at the same time as COVID, and, um, as, as you know or some of the viewers will, will know or discover, um, A Book Apart did not, uh, survive the upheavals of COVID and changing work environments- Yeah ... um, less in-person eve- events, uh, Twitter changing into X, uh, communities fragmenting.

Um, you know, it didn't work out for, for us there, but Approachable Open Source, the, the manuscript, uh, lived on and, and A Book Apart was nice enough to, um, you know, give authors all of their IP back, and I was, I was fortunate enough to have three rounds of professional editing done with them, um, you know, bef- before, before that.

So I chose to self-publish it, but it's, um, effectively in A Book Apart title, um, in, in the jacket of, of my own design. Very cool.

[00:36:03] JD: So who would you say Approachable Open Source is for? Um, people just getting interested in what open source might be, uh, experienced open source maintainers or contributors, maybe somewhere in between, maybe someone completely different than what I described.

What... Who's your target audience with that?

[00:36:21] Brian: Yeah. I... Maybe it's a cop-out to say it's for everyone, but- Okay ... um, I, I like to describe it as a short primer on, on the entire landscape, right? Like, there's... I've found really, really fantastic resources that are 10 times as long as my, as my book. And, um, you can read mine in a weekend, right?

And that's kind of a sweet spot for our Book Apart titles, and that's why it's brief to begin with. But, um, it's fantastic for students or people kinda new in, in role or new in the field, um, who want to understand maybe the history or context, um, and even like the potential around open source software, like how it's been formative for my career and the career of so many folks.

Um, it can, it can be that, you know, for you too. Um, it also has, you know, a lot of, uh, battle-tested scar tissue thoughts for maintainers or people who are interested in taking that leap from consumer to, uh, contributor or, or beyond. Um, and so th- there's a lot of like tactical real work in there. Mm-hmm. And then, uh, the last thing that I, I, I think I'm most proud of, if I'm allowed to be prideful, is, um, it's, it's really oriented to enterprise developers or, you know, people who work in large companies that- Uh, might feel disempowered to be a part of the ecosystem, and that one of the big central theories of the book is that, like, we are participatory in this as consumers, and that means that we are also, um, you know, just, like, by, by nature of, of, of being here, um, enabled to also contribute upstream.

Like, you don't need permission to do your job, right? You fix that bug that you see, et cetera, et cetera. Yeah. So there's a, there's a lot in there, too.

[00:38:20] John: I don't necessarily feel that way, but I am gonna buy the book and read it, so that way maybe I can, I can, uh, educate, uh, other folks in my, um, large organization to that- I-

to that point.

[00:38:31] Nic: I'm, I'm curious if, if it talks about diff- One of the things that the Drupal community, you know, I think excels in is recognizing contribution from everybody, not just- Mm-hmm ... um, developers, right?

[00:38:43] Brian: Right.

[00:38:43] Nic: We have a contribution credit system if you do work. Mm-hmm. Whether that's code writing or attending or speaking at an event, you get a credit that shows up on your profile.

Does, does your book talk about, um, uh, how people that aren't involved in code can get involved in open source communities and help out, or is it mainly focused on developers?

[00:39:07] Brian: No, great question. Um, yeah, that's the, the central premise of chapter two, which is, uh, the spectrum of engagement. That's what I kinda call what you just described.

It's like, it takes, you know, many, many hands to make a successful, mature project. It's not just about developers. Um, like not even close, right? And, um, that's a, a message that I try to send into enterprise environments because there's fantastic data scientists, and there's fantastic product managers and technical writers and designers that, um, you know, might want to practice their craft or give back, you know, beyond the, the four walls of their, uh, of their employer and, and improve the commons, right?

Improve their skillset, improve their, um, uh, their, uh, resume, right? Um, and you can do that, all that out in the open, um, in, in community. So yes, I, I love the idea that, that Drupal's doing of recognizing those people. Um, I, I talk about, like, the all contributors tool or the all contributors spec that has, like, a little CLI that you can recognize folks, like, in your README in your project, um, for, you know, doing the simple things as, you know, bug triage or, uh, documentation, um, et cetera.

So yeah, that, that's fantastic that Drupal, Drupal has, uh, recognized that and is, and is celebrating that, too.

[00:40:34] Bernardo: As a side note, I met Brian last year at All Things Open 2025, and Brian, for somebody who is self-published, how did you manage to get picked up by them for the book signing? 'Cause I remember you had a session, and I just happened to be at the right time-

when Brian was coming and setting up, and I was like, "Oh, snap," you know, "Let me go meet this person." He was telling me a little bit about Pattern Lab and a couple of other things. So how did that come about?

[00:41:01] Brian: Yeah. Um, I mean, really the book signing came out of the, uh, you know, the speaker arrangement, right?

So I was fortunate enough to, um, be, be selected for, uh, a talk at, at All Things Open, and, um, coincidentally enough, um, that, the, that entire talk is on my website. Um, so I'll put that on, on the show notes or in chat here. Maybe we can figure out how to do that together. Um, but, uh, the, the real notion, right, was that, um, from the speaking arrangement, it's a great engagement opportunity with like-minded individuals, uh, within the open source community that h- are from different walks of life.

Um, you know, uh, right, right downtown in Raleigh is, in the Research Triangle, um, you're right by, is it the IBM headquarters, right? There's just like, like, the exact, uh, audiences that I wanna meet, if it's students or if it's, um, people within, um, you know, sophisticated enterprise environments. We all have a, a part to play, um, to im- improve this community that we're a part of.

So, um, it was a great, a great opportunity. I was, I felt very fortunate to be included among, um, a bunch of other folks, and yeah, it was a, it was a fantastic experience to do that.

[00:42:21] Bernardo: So did you apply as a speaker, and you had to apply to actually do the book signing separately, or that's something that you talked to them and went out?

'Cause I heard of people who were speakers, but they didn't necessarily-

[00:42:32] Brian: Mm ...

[00:42:32] Bernardo: wrote a book.

[00:42:33] Brian: Yeah. Um, after I was accepted, I, I reached out and said, "Hey, would you be willing to, you know, host a, a book signing?" And, um, and Todd was nice enough to say yes and, and the other organizers. So, um, it was a little bit of like a one thing led to another, uh, type situation.

But, um, you know, hopefully a good, like, one-two punch for people that, uh, wanna learn more.

[00:42:59] Bernardo: For sure.

[00:43:02] JD: So All Things Open, big, really, really cool conference. So I haven't had the pleasure of going there, but, uh, I've heard nothing but good things. But what, what other conferences do you try to attend, or how do you choose which ones you want to attend or get involved with, pitch your speech to?

[00:43:19] Brian: Yeah. Um, there's a lot of... Well, I guess this year I've been really, really lucky that, um, the, the marquee open source conference for the Linux Foundation, Open Source Summit, um, came right into my backyard, uh, in, uh, Minneapolis. So, um, I attended that this year. Um, I like to go to conferences that, um, you know, are, are large enough that, that they can draw, um, you know, d- uh, lots of diversity from, from speakers and, and topic.

So, uh, OSS, um, is always fantastic for that 'cause it's just huge. Um, there's, there's l- local conferences that are always easier to, um, you know, ask, ask the boss for the budget for. Um, I, I think that's a great place to start if people, um, aren't, aren't aware of what they wanna do, right? You don't have to, like, pitch for a multi-day, you know, plane, flight, hotel, you know, conference experience.

Like, if you live in a... live in or near a major metro area, um, there's probably conferences that are coming to you, um, or local meetups that are, are great ways to, to start, right? And, um, I attend a few of those when I can. Um, more, more lately, um, with some of my Node.js work I've been, um, attending, you know, more Node, Node or JavaScript centric conferences.

So-

[00:44:45] John: Mm ...

[00:44:45] Brian: I'm, I'm going to Render, uh, next week, uh- Oh, cool ... and speak, speaking there about, um, a Node.js project that we've been maintaining. And then I'm giving the same talk, um, in Italy, uh, in October, um, which is another fantastic experience at, uh, at NodeConf EU.

[00:45:05] John: That's very cool. Um, so I'm gonna ask my next question, and then I'm gonna kinda, like, edit it a little bit because I, I...

Listening to you, it's, it's, it's very interesting to me, uh, as to kind of your, your theory behind open- uh, Approachable Open Source and open source in general. Um, so the question is what is the biggest takeaway from Approachable Open Source, and how have you applied, uh, that to your own open source involvement?

But I guess the, the real question is, like, you clearly have this, this desire, um, to, to give back. You have this desire to, you know, make open source approachable for everybody. Like, how do you kind of convey that or, or get people to drink the Kool-Aid when you enter, enter into a open source project or enter into a room of people that are maybe skeptical?

[00:46:05] Brian: Yeah. It's a great question, um, because it doesn't work on altruism alone, right? Uh, a lot of us work in, in corporate environments. Um, the way I, I phrase it usually is that it's a, it's a win-win. Um, but that's not even enough. Um, if you need to get down to- at times corporate speak. Um, it's even just about risk mitigation, right?

Like y- everyone's software supply chain is so complicated these days, and I, I talked at the top about how, you know, like open source is everywhere. Um, you have to adapt your pitch or your argumentation to, um, you know, to the audience. So if we're talking to executives or leaders who are prioritizing or guarding time, uh, for me to do this, um, I, I communicate that all of my open source work translates into, um, a better, you know, common library for, for Node.js or, um, it makes me a better communicator 'cause I need to communicate publicly and in writing asynchronously with people all around the world.

Like, that is a fantastic skill for anyone to be able to do. And, um, it's... In my mind, it, it, it kind of pays for itself, right? Mm-hmm. Like, I'm not, you know, I, I'm not working on my Minecraft server, you know, open source, right? I'm, I'm building and helping maintain, uh, what I like to think of as enterprise grade foundational software that, like, we use here at, at my employer, right?

And, um, it levels up my acumen to the, the tools and skills and concerns of that ecosystem. It exposes me to tools that, um, I wouldn't otherwise have encountered because if you're in a, uh, you know, a more closed off environment, you use the tools that you know of, right? Mm-hmm. Um, how do you introduce change and, and innovation into those?

So, um, when I... Uh, I, I also run the open source program office at, at my company, and I talk about this all the time about, like, innovation coalescence loops, right? Where, like, you... Um, and I think there's a, a blog post on, on the website about this now, and open source is this, like, fantastic manifestation of- that change cycle.

Um, and it's, it's something we could go into a little bit, uh, deeper about, like pace layers. But, like, there's, you know, some parts of the, of our stack that are so, so important, bedrock, that they need to be stable and resilient and perfect. Mm-hmm. And there's some things that are breakneck, you know, change pace and bleeding edge, uh, like a new, you know, library or JavaScript framework every week, and it's really easy to lampoon it as, as frustrating.

But that's, like, two, two rates of change that are not in opposition. They are in, um, in concert, right? Mm. They're in healthy balance. And there's a lot of different stratifications along the way for you to find the type of work that is interesting to do. And that's what I also tell people, too, is, like, you don't have to, you know, uh, give a crap about, um, the latest and greatest.

But you might really, really care about, um, you know, like SemVer compliance and API resiliency and-

[00:49:41] Nic: Mm-hmm ...

[00:49:42] Brian: uh, you know, whatever, right? Like flaky test coverage. Like, there's places for you to do that kind of work wherever you want to, and you hone your skills.

[00:49:50] John: I, I imagine also it, it provides you with, um, outside influence, right?

So, like, if you're working in your silo, right, and you're doing your thing for your company, and you're like, "Oh, this is the best thing, like, that I've ever built," um, you're not really getting a lot of outside influence. And when you look at, you look at open source, and you look at open source, um, projects and packages, like, you know, for example right now I'm, I'm working with, um, IBM's Carbon Design System, right?

And, like, now I have insight as to how IBM's thinking about a design system and the things I might need to look at and think about, right? So I imagine, like, in your example that that applies quite a bit to bringing in kind of those outside influences into your, into your own work.

[00:50:36] Brian: Yeah. It's bidirectional, right?

Yeah. Like, we... Th- th- like, I think you had asked the question what the biggest takeaway is, and it's like what I said before about being participatory in the community. And, um, uh, you know, I, I, I'll provide one swear, um, here, but, like, companies need to give a damn about the software that they use, right?

[00:50:58] Nic: Yeah.

[00:50:59] Brian: And the way that they can do that is by empowering their employees to invest their time in maintaining it.

[00:51:09] Nic: Yeah. Yeah, I mean, it's, it's the, the age-old argument of takers versus makers, right? You're, you're benefiting from the, the experience of the open source world. You can help reduce the burden and main- maintenance level.

I, I think there's another benefit too that you haven't h- that you kind of sort, sort of highlighted that I want to call out that I've noticed in my own work, which is that, um, when you're maintaining a piece of software as complex as Node.js or Drupal, you see it from, from a main- maintainer's perspective, even if you're not directly involved in every issue or every ticket, you tend to see them.

And so you know if you're working on a project or something, or you have a customer or you have a client, you know, like, "Hey, this is a pitfall that other people in the community are, are hitting. Make sure you, you're aware of that." Or, or if they hit something, you already know this-- Like, you don't even have to search for the solution.

You already know what it is because you've seen it pop up to the top of the list five times. And even if you don't have to be the one to fix it, you can be like, "Oh, here's the issue. Read this. Comment 35 is the one that will probably fix it for you." Right. Yeah. Exactly. And, and yeah, and then you can follow up and, and it helps with that, um, that cross-pollination.

Um, I'm curious though, 'cause it, it sounds like you think about the, the act of open source, uh, contribution directly, like outside of your, your, your own contributions. What do you th- what's the biggest misconception people have when it comes to contributing to an open source project?

[00:52:42] Brian: Well, the one that leapt to mind is that I've, and I've heard this pretty, pretty routinely, is that, um, that it's hard. That they, you know, it, or it's nebulous to the extent that they don't even try to, um, to contribute something, right? That's someone else's problem. That's, that I don't have time for that, uh, kind of thing, right?

And Maybe that's a number of problems that, that are all kind of lumped into one around lack of self-efficacy or lack of confidence. Um, but you know, I coach people to start small and to, uh, you know, align their open source contribution with something that already gives them energy or that they have subject matter expertise in.

'Cause, like, each one of you does, um, and you just need to, to find that thing that, uh, is a net positive, right, in, in your workday. Um, and that's, that's key too, right? Like, I want people- Yeah ... to feel, uh, empowered to do this as part of their work, right? So I, I role model that at, at my employer. I just, I just do it during my workday, right?

I don't have to do it nights and weekends in the dark with a hoodie on, right? Like, just, just do it. Ru- run an experiment and tell your boss and your peers what you learned, right? You know, you spend two hours, um, I, I think there's a phrase in my, in my book, it's like, "Spend a cup of coffee amount of time," you know, working on someone else's issue log and s- or contributing to that project instead of buying them a coffee, right?

See, see where you can go from there.

[00:54:28] JD: You know, I'll- Yeah.

[00:54:30] Nic: That... Sorry, sorry, JD. I was just- No, go ahead, Nic ... that's, that's really fascinating. And I, I kind of found myself, as I became a maintainer more, from the maintainer mindset, I started doing that too. Like, if I, if there's a contributor module where I needed an issue to get resolved, you know, obviously in the past I would always contribute to it.

I would, I would work on it. Like, I would clean up the patch, get it up to date, do, you know, do a review, that kind of stuff. But what I've also started doing is I'll do that, and then I'll also spend 20 minutes looking at five other issues and updating them before I send it to the maintainer like, "Hey, um, this issue is important to me or to my client.

Uh, can you take a look at it? By the way, I also looked at these five other things too." And they appreciate that it's not just adding to the workload of, okay, now I have this thing that I need to commit and verify and make sure there's tests and stuff. Um, but this person is also willing to help with other things that they don't care about just because it, it, it helps reduce the burden.

Um, and I've found, you know, nobody's directly told me, but it's been pretty receptive. People are willing to help people that are more, that are helping them elsewhere. So that, I think that's good advice for getting your own bug... If you have a bug that you're trying to get fixed in an open source piece of software, uh, contributing to a couple different other issues, um-

[00:55:51] Brian: Yeah, and, and what's exciting about it too is that it kind of unconsciously creates osmosis for you into other people's problems and the surface area of, of, you know, the, the software that you're working on.

Like you said, like, I, I don't know how many times I have looked like a hero because I can find the GitHub issue faster than someone else did, right? 'Cause, like, people don't even have it, like, in their thought process to look upstream. Like, "Oh, this thing is a problem or a bug or whatever." And it's like, oh yeah, actually that's been reported, or it's a regression, or they're fixing it next release.

Or, you know, like, all of that just- Yeah ... makes you look better. And, like, it's just- Yeah ... funneling information faster and plus, you know, plus wanting things and it's-

[00:56:36] Nic: Yeah ...

[00:56:36] Brian: it's all good stuff.

[00:56:38] John: Clearly, clearly we're doing a good job here today 'cause our, uh, our YouTube, our YouTube chat, uh, somebody said we're providing good vibes, which we're gonna, we're gonna continue doing.

We have a bunch more questions. So. Sweet. Thanks. Thanks for the, uh, the love and support. Um, folks, if you're watching the live stream, you can comment on LinkedIn and YouTube. We'll see it here. We'll try to, we'll try to address it live. Um, so feel, feel free to, uh, feel free to contribute.

[00:57:07] JD: So before I ask my next question, I do wanna...

I, and Nic, John, Bernardo, uh, if, if you don't want me to shout out AmyJune, I'm gonna shout out AmyJune anyway. Uh, her, she talks at a lot of Drupal events about how you don't need to be a coder or a developer to contribute to open source. That's a huge thing, and I, I think that's, uh, that's probably one of the, in my mind, one of the biggest misconceptions, is that you don't necessarily need to know a programming language.

If you know how to read documentation and check for typos, you can contribute. Um, but anyway- Absolutely ... if, if, if you don't want to, uh, shout out AmyJune Hineline, uh, you can edit out, even though we're live, that I'm shouting out AmyJune because

[00:57:55] John: I expect now- Yeah, I was gonna- ... that you've said it three times she's going to appear, kind of like Beetlejuice.

But I could be wrong. Yeah.

[00:58:00] JD: Yeah. It's not in front of a mirror and the lights are on.

[00:58:03] John: Ah.

[00:58:03] JD: Um, so- Especially with the, the, uh, the, the two letters on everybody's mind, AI, uh, and you know, I don't know if you... You've probably heard the, the whole thing with the curl maintainer, uh, having issues with a lot of new issues coming through, whether security or bugs.

How do you, uh, avoid burnout while maintaining a large open source project? I believe earlier you said, you know, something about Node.js, a little, little thing.

[00:58:37] Brian: Yeah, and, and that's a great question. Um, it's something that I had to learn the hard way. Um, in, in Brad Frost's forward for my book, he talks about being, uh, he's, he was too kind, um, but he said being, like, stung by the double-edged sword of passion or something like that.

Um, and- It's too easy, I think as humans, but as, as open source maintainers or as creators of things, to associate too much of yourself to, to the output that you've created, right? To invest too much of your self-esteem in whether or not something was, uh, is purpose, per- perfectly representative of what, what you are or what you do, and you are not your code, right?

You are not your solution. Um, and it's taken me a long, long, long time to realize that. Um, and now I think what I have maybe just naturally gravitated to with something like the Node project and the, the teams that I work on is I'm not alone anymore. I'm a part of a, a group of, you know, a health- healthy, sustainable, you know, 10 plus sustainers, uh, on the teams that I have that, like, I can walk away and take vacation and not even think about it, right?

Like, it's, uh, it... The project moves at the speed of open source, w- which means it's either so fast that we all get in a tizzy, or it's so monumentally slow that we're frustrated the other way, right? And, like, who cares, right? Like, I, like, it, uh, the open governance model and, uh, the, you know, there is no SLA to, uh, to, uh, to meet, right?

And it's like if you show up and do the work, you, you know, you can help influence the pace. Um, but it, it, it took me burning out to understand that, and when I didn't have enough of a support network and enough, um, of my own values and principles behind this concept, you know, every single new issue on the issue log was, like, existential crisis, right?

Or, uh, code-oriented chat is even worse. Right? Because then people can just spew at you with little regard and, and, like, depending on the code of conduct, right? Like, uh, like, is that in- in- included or not, um, in, you know, in your, uh, the realm of, of your purview, I guess. Um, so it's just- Yeah ... it's complicated stuff.

[01:01:25] Nic: I, as, I'd like to, I'd like to chime in there as, as kind of a, a, a co-maintainer of open source projects because it's... I have a feeling as the maintainer of, um, uh, I, I think it's fair to say Node.js is a little bit bigger than Drupal. Um, but I think the bigger thing is, is that it's hosted on GitHub, and a lot of these, um, a lot of people are used to contributing or commenting or creating issues on GitHub, and a lot of the training has happened on GitHub.

So I think, um- One of the thing w- Drupal does, we're working on making the pipeline To contribution easier, like the road to I've never contributed to something to I am contributing something to the Drupal project. We're, we're working on making that simpler and simpler. I'm curious if you have advice to a project that's doing that, how they can prevent that flood of, I don't want to say low effort, but, um, a lot of them do end up being low effort.

How... Any advice on how to curb that flow before it starts?

[01:02:34] Brian: Yeah, I have lots of thoughts. Um, the first one that leapt to mind was that I, I think we need to stop thinking about growing maintainers as some kind of, like, ladder or mountain. Um, I've heard a lot about, like, the, the contribution ladder, and the spectrum of engagement that, that we suggested or, like, the Drupal community has suggested, um, around, like, all contributions of any kind being welcome means that, like, you might have absolutely knocked down fantastic, you know, technical writers that only wanna do that, and we should be welcoming of, of that skill set into the community.

Yeah. Absolutely. And they don't need to rise up to be, like, a, a doc lead or a project maintainer or whatever, right? Like, we need to figure out how to accept that. Um, and it's hard because you don't really know if someone's a drive-by or a low effort until you invest time in, in them, and that- that's also expensive to make them.

Uh, your, your question about, like, AI swap or, um, low effort PRs I think is very dependent on, on your goals and your, your values. Node.js gets so much activity, uh, whether it's, um, agentically driven or, um, people just being eager. You know, that good first issues aren't a thing, right? Simple things get picked up by 10 people, not, not one.

Yeah. And if, if they're low effort and they have, you know, like, plain text new line endings and they're very clearly, like, made by a robot, we just ban them. And we, we have y- you know, tried to find the right balance of empathy- Mm ... for newcomers a- uh, you know, against the, the total deluge of, of noise that we get.

Um, because protecting maintainer time is just as important as nurturing, uh, newcomers, right? Mm. Um, so the way that we differentiate them is, is mostly through a, um... And I'm definitely paraphrasing and we have a actual written policy, but, uh, you know, every contribution needs to have some level, besides like a DCO, right?

It needs to have some level of, um- Of understanding that we can interrogate the contributor for, like make sure if they, they actually know what they're talking about. They, they understand every line of code that they, uh, that they wrote and is defensible. Um, so there's- Right ... there's a lot there.

[01:05:16] Nic: Tha- thank you.

And what is DCO?

[01:05:18] Brian: That's the Developer Certificate of Origin. So you might have heard of, um, CLAs, like a contributor license agreement, which, um, is one way to, um, kind of like manage the inbound, outbound software licensing concerns. When a contributor comes into Drupal, which is, what is it? MIT, Apache, G- GPL?

I don't even know.

[01:05:40] Nic: I think GPL.

[01:05:41] Brian: GPL. Yeah, GPL

[01:05:41] JD: 3.

[01:05:42] Brian: Okay. So like, you know, when a contributor is doing w- is providing a, a, a patch to, to Drupal, um, you know, what are the circumstances by which they are, are providing that code, right? Um, a CLA, if it's written in a certain way, would allow a project to re-license the, um, the contributions at any, any given time, any later time, and this has caused all kinds of interesting rug pulls throughout history by, uh, you know, by companies, um, that are changing their business model.

A Developer Certificate of Origin has less of those assertions, and, uh, but al- but still, like, says, like, you as a contributor, um, have the, the legal basis to, you know, provide that patch. There's a lot more to it. Um, if you are interested, there's a fantastic book edited by, um, Amanda Brock that is huge, um, like very huge- Mm-hmm

um, called, um, Open Source Law, Policy, and Practice. Um, it's- Law, Policy, and Practice ... it's really, really good. Yeah. Um, and, like, this is a hugely expansive topic. Uh, if you're a lawyer or not a lawyer, um, it's, it's equally interesting. My book covers a lot of it, um, at least in, in a primer-like fashion, uh, within the license section of chapter four, uh, which is the four files of every open source project.

[01:07:16] Nic: Okay. But that's- I- I will get that So I- And, and, and the licensing core currently is, uh, GPL 2.

[01:07:22] Brian: Oh, okay. No worries ... sorry.

[01:07:25] JD: Off by one errors.

[01:07:27] Nic: No, no. It's fine.

[01:07:28] JD: I, I do wanna call out before we move on from, from this that two things you said about burnout really, really stood out to me. One, the, the communication thing, the, the code-based chat.

It is difficult, especially for a new person coming into a community, coming into contributing, to not read everything written as feedback in the worst possible way.

[01:07:50] Brian: Mm-hmm, yep. On the internet? Yeah.

[01:07:51] JD: Yeah. To, to not read, "Hey, would you mind taking a look at this? I think that maybe we could do something better."

It might be the way it's intended, but, you know, some of us hear it, "Hey, jerk, what were you thinking?" Yeah. Uh, "Fix it and never try again." And the other thing that you said was sustainers. Not maintainers, sustainers. Mm. And that, that word just, like, rung out to me because it, it isn't just maintaining, it's sustaining a community.

Whatever the project is, you're sustaining that. You're, you're, you're keeping it together, and I really appreciate the way that you worded that.

[01:08:23] Brian: Oh, thanks. Yeah, there's a, a great podcast that I've been on called Sustain OS, OS I think. Or Sustain OSS. I need to double-check. Um, and it's, uh, you know, they, they kinda have the, the best, uh, definition or, or, like, the...

I would say, like, they own that, that phrase and that mentality, and I'd very much encourage people to check that out. Um, yeah, the... I, I, assuming worst intent on every communication, like, really goes both ways, um, to, you know, to go back to your first point. It's a conscious skill to- You know, provide feedback to someone in a constructive way.

And when maintainers are busy and don't have time, brevity and terseness often win out, and they, they need to do better if they want to attract, uh, you know, more talent and, and have people come back, right? So they, it, it's, it's an, an element that, you know, gets factored into the code of conduct and our moderation policy and, um, we don't always get it right.

Right. And sometimes people, people struggle with that kind of comms.

[01:09:37] Nic: I'll, I'll say that you saying that actually made me real- 'cause that, you know, even if you're busy, it's e- I find it easy to spend the time to write a really good feedback comment for somebody who's new, who's trying, right? I do find, um, the times that it becomes more brief is when I'm working with a contributor that I've worked with a lot before, and I know that they know my intent, and I'll just reply like, "Oh, hey, we need to fix this."

Sure. It, it's never rude, right? Um, but it, but it's more brief. But you're making me... One of the things that you're making me realize too is that even those interactions you have to be careful because other people are reading these comments. Like, like if I'm commenting to John about the show, like I know John knows my intent, but if somebody's reading that and they're like, "Oh, wow, that was really, that was really terse."

Um, so, uh- Yeah,

[01:10:29] Brian: that

[01:10:29] Nic: happens ... you know, when it's really just I'm on my phone and I'm in between stuff and I just have to comment really quick and want to reply super fast so he could continue doing what he was doing, um, that's interesting. I need to actually think

[01:10:38] Brian: about that. Yeah. There's a, there's a third observer in, in- Mm

all those open source conversations, and it's your potential next contributor, right? And- It's

[01:10:47] John: like- It's like you need to start every statement with, "I'm really being nice here, but this is dumb." Like, you, you, do you need to, like, preface- Yeah ... your comment? Like, I don't know. Yeah.

[01:10:57] JD: I think there's ways to more politely say instead of, "Change this because it's horrible," i- as, "Hey, I think that maybe we should make an adjustment here. Everything else looks really good. I appreciate the work you put into it."

[01:11:10] Brian: Yeah, and there's an element of being a improv artist that I, I talk a little bit about in, in the book-

where it's, what I mean by that is like, "Yes, and..." Right?

[01:11:17] JD: Mm-hmm. Are

[01:11:18] Brian: you gonna do some zip zap zap? Yeah. You take, you take their energy and you, and you redirect it into, into the positive. And, and you need to be thoughtful too about are you interjecting your personal opinions a- about a design choice, um, or is it something that we should have agreed upon earlier with, uh, an, a framing issue, you know, before it ever even got to code?

Right? How, how could we have avoided conflict in the first place? Um, I, I talk about like anything that would be a blocking, uh, PR review of any kind better be written down, right? Yeah. Or, or even better yet, like lintable or testable. Wow. Um, so you provide that feedback loop for contributors without you even being involved, right?

And hopefully there's like RTFM, you know, like, they, they read the manual type stuff. Um- But that context that is asynchronously provided is like what unlocks- Yeah ... global collaboration.

[01:12:19] Nic: I, I also try to b- the other thing that I try to balance that I find really hard sometimes is when, as the maintainer, when do I, how to gauge their willingness to keep pushing, right?

Because sometimes there's something that just has to be do- like, a test that might be particularly difficult or complex, or like, if the person's willing, yeah, I'd much rather have them do it, 'cause I have a million other things to focus on. This is somebody who's now leveling up. But also, I don't wanna discourage them like, "Hey, this is your third or fourth contribution.

Here's a test that's gonna take you 12 hours to get right." Mm-hmm. You know, is it, i- so gauging that and be like, "Hey..." So sometimes I'll just be like, "Hey, we need to write this type of test. If that's too much, let me know. I'm happy to help with it or something." 'Cause I also don't wanna just step in and do it for them, 'cause that can be discouraging, too.

So yeah, there, there's a, it's a tightrope on a lot of different dimensions, I think sometimes. Um- Yeah ... but these are things that I'm always thinking about too.

[01:13:13] Brian: And there's no HR to help you.

[01:13:17] Nic: That's true.

[01:13:17] Bernardo: Oh. I was wondering, since you are part of the Node.js community and also a maintainer, what are some things out of the community, the Node.js community in particular, you think we could take as the Drupal community and learn from?

I'm sure there's some, uh, great things that you've seen as an outsider and now sitting in the inside with other maintainers. Um, yeah, what could you share about that?

[01:13:41] Brian: Yeah. You know, actually, I'm, uh, in, in learning more about the Drupal community even, you know, today, um, I'm really excited to kind of flip the script and like I'd, I'd love to unlock and figure out how to Celebrate, you know, a broader array of, um, of contributions within the Node community.

It's something that, um, I care a lot about because, uh, maybe because selfishly I operate on a lot of the periphery of, of the core project. Um, but, like, that work needs to be done.

[01:14:13] Nic: I will happily connect you with Tim Lennon, who's the CTO of the Drupal Association. It's kind of his, uh, his main initiative.

It's been, it's been around for about nine years, 10 years or so. Cool. But there's basically a form on drupal.org. Any maintainer can fill it out, and you basically say this person, this person, this person helped. And you... If it's, if it's a non-code contribution, you create an issue specifically for granting credit.

Like for example, if you create a drupal.org account, you'll get credit for being on the show.

[01:14:42] Brian: Hmm.

[01:14:42] Nic: Um, from the Talking Drupal podcast. Um, but yeah, I'd, I'd be happy to have further discussions and, and connect you 'cause it's something that he's, he's tried to spread outside the Drupal community intentionally a few times.

[01:14:55] Brian: That's cool. Yeah. Um, I mean, and I think, like, if I'm going back the other way, like one thing that I... And I, I, you don't have this problem in Drupal, um, but I am very happy and proud to say that Node.js is openly governed, and that means that there is no s- you know, singular VC-backed company that can steamroll us.

It'll never be acquired. Um, you know, like, we, we, we, we see that happen in the environment, and it sometimes casts, you know, a little bit darker clouds on, on the efforts that we do. Um, so that's something that continuously gives me, like, optimism that I'm in the place that I should be, um, because that, that bedrock, um, is aligned with my values.

[01:15:45] John: So speaking, speaking about optimism, um, as we bring this, bring this show to a close here, I'm wondering, like, what trends, um, either on the web or in open source, um, are you most optimistic about?

[01:16:02] Brian: Hmm. You know, I, I'm kind of happy to see a lot of alarm bells ringing right now, um, with regard to open source sustainability, right?

Like, uh, AI being able to ingest everything so fast and, uh, you know, quote-unquote just replace a library that, you know, people are using, um, is I think actually starting to work in favor of, uh, collaborative projects, uh, whatever they might be and of open source nature. 'Cause I think, you know, whatever what token costs or, you know, frontier models, whatever, um, understanding that there's a shared commons that we can all work on together as like a global project I think is, is just becoming more and more, um, in the spotlight as, um, as it gets threatened.

So, um, you know, maybe we're on the endangered species list or something, but I think that's also s- kind of spurring interesting conversations about digital sovereignty in Europe. And, um, you know, people exploring different license models that maybe aren't OSI approved, but maybe they shouldn't be, right?

Maybe we need to be pushing a little harder about what it means for open source in 2026. And- Mm-hmm ... uh, that's, that's kind of

[01:17:32] John: what I'm excited about seeing happen. Well, Brian, I, I appreciate your time. I appreciate your, uh, your insights and, and sharing, um, a little, a little bit more of those insights with us today.

[01:17:42] Brian: Thank you. Appreciate it.

[01:17:44] Nic: Do you have questions or feedback? You can reach out to Talking Drupal on socials with our handle TalkingDrupal, or by email the show @talkingdrupal.com.

You can connect with our hosts and other listeners on the Drupal Slack in the TalkingDrupal channel.

[01:18:00] John: Do you wanna be a guest on Talking Drupal or our new show TD Cafe? Click the guest request button in the sidebar at talkingdrupal.com.

[01:18:08] Nic: And you can promote your Drupal community event on Talking Drupal. Learn more at talkingdrupal.com/tdpromo.

[01:18:15] John: And get the Talking Drupal newsletter to learn more about our guest hosts, show news, upcoming shows, and much more.

Sign up for the newsletter at talkingdrupal.com/newsletter.

[01:18:24] Nic: And of course, thank you patrons for supporting Talking Drupal. Your support is always greatly appreciated. You can learn more about becoming a patron at talkingdrupal.com, and click on the Become a Patron button in the sidebar.

[01:18:36] John: All right. Brian, if folks wanted to get ahold of you, uh, chat about all the things, how could they go about doing that?

[01:18:43] Brian: Yeah. Uh, the best way is probably LinkedIn these days. Um, I'm trying to stay off of, well, doom scrolling social media, um, with various degrees of success. So, uh, LinkedIn, uh, I think I'm the only Brian Munzenmaier there. Um, I'm also haphazardly on, uh, Blue Sky, so you can find me there. And then, um, my full name, brianmunzenmaier.com, is where I, um, host various projects and blog posts.

And then approachableopensource.com is where you can, uh, buy my book, which I'd love to give physically into your hands. Um, and I'll be honest, you can also read it completely free online.

[01:19:26] John: Mm.

[01:19:26] Brian: Awesome.

[01:19:27] John: That seems, that seems fun, but maybe less fun than having the physical book in your hands.

[01:19:33] Brian: That's right.

[01:19:34] John: Maybe, maybe just me personally, I don't know. JD, what about you?

[01:19:39] JD: Uh, you can find me on LinkedIn, uh, JD Flynn. Uh, I also stream regularly on Twitch, twitch.tv/jddoesdev, and I'm also on Blue Sky, uh, jddoes.dev. You can

[01:19:52] John: find me there. I, I love, I love hearing the Blue Sky 'cause, uh, you know, I'm, I'm, I'm trying to get more into Blue Sky.

I need more people to follow so I have more content. Um, Bernardo, thanks for joining us today. Where can folks find you?

[01:20:04] Bernardo: They can find me on LinkedIn and also on Drupal Slack as bernardm28. And I'm still on X 'cause every now and then you see things over there, so I think it's bernardm28 also on X.

[01:20:17] John: There you go.

Nic?

[01:20:19] Nic: You can find me pretty much everywhere, @nicxvan, N-I-C-X-V-A-N.

[01:20:23] John: And I'm John Picozzi. You can find me, uh, personally at picozzi.com, uh, on the socials and drupal.org @johnpicozzi, and you can find out about EPAM at epam.com.

[01:20:34] Nic: And if you've enjoyed listening, we've enjoyed talking. See you guys next week.

[01:20:38] John: Thanks a lot, everyone.