Making the Case for Open Source Code Contribution

Good morning. My name is Chris Burge. Good morning, good morning. I built my first Drupal site back in 2011 when I was still in grad school, and all these years later, I'm still a Drupal list. Um, early on, I was fortunate to have a mentor who instilled the values of open source contribution and engagement, and these values have shaped my Drupal career. And they're why I'm here today. Um, for my day job, I'm a technical account manager at Acquia. However, I'm here today wearing my community hat. So let's begin. Let's start with a few words on forking. Most of us in the room are probably familiar with forking, taking existing open source project in a new direction. Uh, there's a couple that are pretty well known from the realms of content management systems. Joomla is actually a fork of Mambo, and a little closer to home. Backdrop is a fork from Drupal. Now, due to Drupal's open source license, all Drupal projects can be forked. That includes Drupal itself. As we saw with backdrop modules themes, everything can be forked.

That doesn't mean it's a good idea though. And one quick side note. Um, you're not obligated to release your code publicly under GPL version two. So no one can fork your code if they don't have it in the first place. Um, but again, just because we can fork doesn't mean it's a good idea in the Drupal, in the Drupal community. We encourage members to collaborate first, and we'll see how this ties in with restrictive code contribution policies. So in the Drupal community, collaboration probably looks like someone filing an issue on Drupal.org and opening a merge request. Now, this merge request isn't a true fork, because the entire point is for that code to be merged back in. So in today's talk, we'll return to the theme of forking versus collaboration a few different times. But this is why we're here. Um, some of you may have worked at places where you run into a policy that's roughly worded like this. Any code written by an employee is deemed intellectual property of the organization, and cannot be shared outside of the organization.

There are plenty of organizations that run Drupal that are shackled by antiquated policies around code ownership. And while this talk is geared towards organizational users of Drupal, most of the issues raised here and are directly applicable to agencies and dev shops too. I was actually motivated to put this put this talk together because a couple of my large customers as a technical account manager have policies like this, and I've seen firsthand what, what kinds of workarounds they have to do in order to use Drupal without being able to contribute back. So when an organization is operating under a prohibitive contribution policy contribution is blocked. And at that point, organizations have to choose from among bad options. The first one is a private fork. And so that's where you take the module and you just wholesale you copy it into your custom modules, and you just do whatever you're going to do with it. You have forked that module because you deemed that was the least bad option available to you.

Um, you can also go to the private patch route where you continue to download the module from contrib, but you apply a patch that you didn't contribute to an issue on drupal.org. So you grab the code from contrib and you apply a private patch to it. That's a that's another way that people kind of get around that issue. And finally, you can also code your own module and really flexible. You can do whatever you want there. To be clear, writing custom code isn't a bad thing. Every every project launches with custom code. But if you're doing it as a workaround because you can't contribute code back and you're kind of in a corner, then in that case it's a bad thing. Custom code is great, but it's by and far probably the most expensive option out of those three there, potentially. And one thing on those private patches, uh, there are some ways that doing a private patch is better than a fork. Um, but if the patch is complex enough, if it touches enough pieces of code in enough places, it can be more of a hassle to maintain than just privately forking it to.

But these are all bad options that I've seen customers forced into choosing among because they can contribute back. So we've taken a high level look at some of the risks associated with what I would call operating in a silo. And now we're going to dive in deeper. We're going to move on to some scenarios here. And the point is that most organizations are risk averse. And so I find that managers or are more receptive to hearing about things that can go wrong. So it's usually the way I lead the conversation. And then we can talk about things that go right later in the in this presentation. Okay. So we're going to run through some scenarios here. Um, so in this first one the customers identified a caching bug in the OMP providers module. This module extends cores embedded system specifically related to providers, and in this case, the module needed to make an update to accommodate a change in core media. Um, that provider list had been stored previously in cache, but the decision was made to store it in key value instead.

And so this module embed embed providers module had to make it uh, had to make a change to accommodate that. Um, but when this happened a bug got introduced. It sometimes happened that also alluded test coverage. And the end result is that provider list was no longer being invalidated when it should be. So it's pretty straightforward for the developer to, you know, create a patch fix it is a pretty simple issue. But in this particular case, um, the developer, she couldn't post the patch back. And so really, from that standpoint, how many of you developers are going to file the issue in the first place? So in many cases the fish the issue doesn't get filed. Now the main risk here is that somebody else fixes the bug and your private patch no longer applies. And it's possible that they may fix the bug in a different way than you did. Which will you have to sort that out on the back end of the deal? And so in this case, that's what happened later. The maintainer, which happens to be me, filed an issue and committed the fix.

So now we're in a situation where we have a bit of technical debt. That's a term I'm going to use a few times a day. I'll try not to overuse it, but when the customer now tries to upgrade to the latest version of the module, that update is going to fail because the patch will no longer apply. So whatever you're doing, whatever deployment you're testing, full stop and you have to figure this out first. It's a blocker. Um, so you figure out why doesn't the patch apply, and is the patch even still needed in the first place? I hope you have some detailed comments in your JIRA ticket or wherever you kept track of that. To make sure you can validate that you no longer need your custom patch. And what this means in real terms, is that you're going to have to commit some developer hours to this that you weren't planning to. And so that means there's a direct financial cost, and those developer hours could have been allocated to some other business priorities. So there's also an operational cost that we're seeing here.

And the thing about technical debt is it doesn't always make itself known in a convenient time. This is something that could come up that could block a Drupal core upgrade. Do we just back out the upgrade for this particular module and deal with it later? Um, it could also inhibit a security release deployment. So these things don't necessarily happen at convenient times. So in this next scenario, we have a customer who is using the mail login module and wants to add a new feature. So mail login allows you to log in with your email address. It'll send you like a one time login link so you don't have to keep track of password. In this case, the customer wanted all their public facing users to be able to use this feature, but people who were employees of the company, they didn't want to have that option. So this would be a, you know, a feature request in Drupal speak. And, um, yeah. So the customers developer decided that there's just too much going on here to try to attempt to patch. So now, uh, they're just going to go ahead and privately fork it the, you know, the path of least resistance in this case.

But forking comes with risks because first of all, you don't get access to other new features. Um, you also don't get access to bug fixes. And you're also at risk if a security release drops. But that rarely happens, right? So here we have c contrib 2023 048. So now what we have is a situation where we have a module that we have privately forked, um, that we now know there's a high likelihood that it has a vulnerability. And so this is this is a kind of an issue here. And if we if we go through and look at the commit where they fixed the vulnerability, it touches several pieces of code. It makes changes to the mail underscore login module file. Uh, makes changes to the routing YAML file. It removes an entire form class. So there's a pretty good chance that the, um. Yeah, you're kind of in a tough spot here. So the first question you have to ask is does the vulnerability exist in this custom fork? Maybe or maybe not. So that's the first thing you have to spend spend some dev time on. And assuming that it does in this case it does.

Now what? There's a couple of paths forward. Um, the first one is you could, uh, grab the security fix from contrib and backport it to your custom fork. And that feels gross because it kind of is. The other thing you could do is you could reforge the module all over again and then try to adapt your custom code from the private fork to the new, um, uh, version you just forked from contrib. And that's basically it's the definition of insanity. We're doing the same thing over expecting a different result. So there's no no good options here. Um, and I'm part of the reason I'm using these scenarios is they're real world examples. It's not hypotheticals. And I think that managers tend to be more receptive because these things can actually actually happen to your organization as well. And again, there's financial and operational costs here. This one potentially could take um, um, depending on how quick your dev cycle is, how fast you can push things to QA, this could, you know, delay a release by, you know, a week or longer.

Okay. So we have another scenario here to take a look at this one. Um, this this one was, uh, creative solution, but it still has lots of issues with it. So in this case the customer uses the search API autocomplete module. And what this does is it extends search API to provide autocomplete for search forms. So when you have a search form, um, start typing in letters you start getting some live feedback. Um, search API will start making calls. That happens over Ajax. So the issue here is that, um, that Ajax endpoint is returning responses that are uncatchable by varnish or CDN. So every, every time you hit a letter, I think after three and above letters like your bootstrapping origin. Um, so if you have, you know, 100 different people search for him or that's a lot of extra requests that that can't be cached or, uh, the edge of the network. Now, the good news here is there is already an issue for this very, uh, for this very issue, this file on Drupal.org and there's a merge request that's already been opened.

So the works underway for the feature that we want. So open source to the win. Right. And here's the issue. So there's an issue out there. And the primary basically what needs to happen is the controller needs to return uh symphony. Sorry. It needs to return a Drupal Cacheable JSON response object instead of a symphony JSON response object that will allow, uh, for the response to be cached. When it makes it all the way through, it'll render the proper cache control header. So we should be all set, but that's not the direction the customer went. What they did was they copied the search API autocomplete controller class to a custom module. They made their modifications there and then in their custom module, they used a root subscriber to swap out the controller class to the contrib modules. Ajax root. We can argue about whether or not this is technically a fork or if it's a custom module. Maybe it's both, but the end result is the same. That, in my humble opinion, this is a fairly brittle solution.

The class in question interacts with multiple other parts of the module. Um, it calls other internal methods. The root itself is called by some JavaScript from the front end. It's perfectly reasonable to for a future bug fix or feature request to touch all three of these internal methods. The JavaScript code and the controller class itself. And we're really in a situation where that overriding controller class is is a not an insignificant risk for our project. If, uh, if upstream changes aren't incorporated, we should expect that autocomplete may break. It may break in a way that we don't notice initially. Um, so we have some risk we need to manage there. And and if it were me, I think they would have been better off. They just would have done a private patch because then at least you would get some feedback. That patch over failed to apply. Um, so let's let's talk about mitigating the risk. So one thing you could do is you could diff that controller class every time you upgrade the search API autocomplete module.

Uh, something else you could do is you could write some good test coverage. The first one is problematic. And I think for all honest with ourselves, we can document this. But like that step is going to get skipped. We can have high degree of confidence. That's not going to happen. Um, in terms of good test coverage, I think that's that's the better mitigation strategy. And we should all be writing tests for all of our custom code. But we know that doesn't happen probably the majority of the time. Um, so that's you got to write the tests. And then even if you do have well written tests that catch the upstream changes, then you're still in the situation of, okay, it's broke. Now we need to figure out why is it broke? Is is this still needed? You have to go through the whole list of things. And again we're burning some dev hours here. We weren't planning on. And this could be blocking some, some business priority that we were trying to get pushed out the door. So financial costs, operational costs with this with this as well.

So a few scenarios there to try to, you know, get get managers attention about. There's some, some very real things that can happen, um, that have happened and can happen with your project too. Uh, so the first takeaway from section one is that working in a silo creates technical debt, and eventually those chickens are going to come home to roost. At this point, I should acknowledge that open source collaboration isn't perfect. We've all seen issues that stagnate. They can hang out there for months or maybe longer, and some flexibility is needed. You might be in the middle of another sprint working on something else. When a maintainer gets back to you some feedback on your merge request, you need to find the flexibility to, um, respond to that feedback in a timely manner while it's still on the maintainers mind, so you have to have some flexibility there. Now, the second takeaway from this section is that open source can only work for you if you don't sideline yourself. You have to put yourself in the game and we'll see what that looks like here in this next section.

So the benefits of community collaboration. In other words, what can go right? So now let's talk about not forking. This ties us back into the beginning of the talk. The first benefit of playing nicely with others is that you're in the game and sitting on the sidelines, and that means that you're helping shape the solution that will ultimately get committed. And that's big. Uh, you're also going to get feedback from other Drupal lists. And if the solution you're working on is committed, that means you don't own technical debt. As part of the module, you can wash your hands of it and move forward with your project. So I would encourage folks to go ahead and file that issue on Drupal.org. And if you have code, open that merge request. Um, in some instances it may make sense. You have to evaluate this in context of your organization, but it may make sense to help out maintaining an existing module, or maybe to spin up a new module on drupal.org. Uh, your organization can also benefit Reputationally.

Contributions, equal visibility and recognition within the Drupal community. So let's do a quick crash course on contribution and Drupal. Um, as always, start by checking the project's issue queue. If an issue already exists, stop right there. That's your starting point. That's your issue. If the issue doesn't exist, then create a new issue, document the issue and make sure to include steps to reproduce if it's related to a bug. If you're working from an existing issue and it's vague on details or the issue summary isn't particularly well written, now fill in those missing pieces. Make it actionable for the next person to come along. Um, particularly if it's a bug. If there aren't steps to reproduce and I come across bug reports like this. Um, add in the steps you use to reproduce it. You can help fill in the gap there. And don't be afraid to rewrite an issue description if it's if it is just plainly poorly written, or if it's missing key information. If you have code to post, then go ahead and open that merge request and post the code.

If you don't have code, that's perfectly fine, but still open the issue. It can be a starting point for someone else. You could ultimately benefit in the end. And if you're interested in maintaining projects on Drupal.org, we don't have time to cover that today. That's a talk all by itself, but I gave that very talk at Drupalcon Lille, so I'd encourage you to go check it out on the Drupal Association's YouTube channel if you have, if that's of interest to you. Okay, let's hop into some more scenarios here. Um, so this one involves fences module and the Drupal Corps major upgrade. So the fences module is a contrib module that allows for field element rendering to be controlled via the UI and stored in configuration. So it's kind of technical because it kind of is. But what that means in the real world is this idea of a field, the description field on job posting, content type. And you want a particular class to be rendered on that field wrapper for that description field. Normally you'd have to create a twig template file to do that.

Fences allows you to have some control over that, that wrapper markup, um, controlling it all through the UI. So that can help expedite some, some builds. So in this scenario, the site's theme was used in the classy theme as a base theme for the the site's theme. And as many of us know, the class was removed from Drupal ten. Uh, as being part of core. So what the customer had to do was to go include the contrib version, which a lot of sites did, because a lot of sites use Clasi as a base theme. And so lots and lots of sites did this, and it shouldn't be a big deal. But the thing is that core treats contrib and core themes differently when it comes to template inheritance, and we'll skip the nitty gritty details. But fences needed updated to accommodate that behavior change in or not that behavior change, but to accommodate that behavior in Drupal ten, particularly because all these sites that were now using the contrib version of classy. Um, the end result was fences was basically broken at that point in time, but we already had an issue.

Somebody had already filed this issue, so that was good. It was a starting point. And when I hopped in, most of the code had already been written. So the hard part was over. So what my contribution looked like was some manual testing, did a code review. I was able to identify cache invalidation issue related to the module settings, and then I also wrote some test coverage for the merge con merge request. Um, during the entire process, the module's maintainer, anybody was actively engaged and in the end the code was merged. But in the meantime, I had a patch for the merge request that was likely to be committed with only minor changes. So I can't say there was no technical debt here, but there was minimal technical debt because once it got committed, I'd need to pull my patch out when I updated the latest version of fences. But I helped shape the patch that ultimately went in, so it's pretty minimal technical debt. In this next scenario, um, I was working as a dev responsible for creating a new distribution at the University of Nebraska, Lincoln.

We made the decision to leverage Layout Builder for the page building experience, and anyone who's used Layout Builder knows that, uh, options of blocks you get to insert, like it's all the blocks that are available in the system that's overwhelming for content users. It's way too many. Um, it includes everything, including the Powered by Drupal block, which your content users are unlikely to use. If you've built a site with Layout Builder, then you probably also use Layout Builder restrictions, and that allows the site builder to pare back that list of blocks to things the content, uh, author will actually use. So in our case, we had certain blocks we wanted to allow in some regions, but not in others. Um, the example that comes to mind is like a full width banner image that can go in a full width, um, uh, region inside of Layout Builder, but it's just not going to work in like a 5050 column situation. So we wanted some granularity about where certain blocks could go within the layouts in the layout builder restrictions model got us most of the way there, but it didn't have granularity at the region level.

And so after I overcame the urge to write some custom code, um ultimately determined that I'd probably be a world of pain. What we did instead is we reached out to the maintainer. I sent an email to Mark Fulmer at the University of Texas, Austin. We ended up sending a zoom call. Um, kicked around some ideas, and what came out of that is we had a path forward. Um, University of Texas would, uh, rewrite the module to use a plug in based system, and then we would contribute the code to implement the granularity feature, and it would be a sub module that leveraged the new plugin system. At the end of the day, we got what we wanted in the module. The University of Texas and the rest of the Drupal community got a much more flexible module, and we didn't create technical debt. In the end, this is one of my favorite examples of collaboration. So don't be don't be shy about sending an email or reaching out to somebody on Drupal.org about a collaboration opportunity, especially if you're willing to put in some dev time yourself.

Okay. In this next scenario, I was working as a freelance. I was working with a freelance customer, and what we were doing is we were processing content updates retrieved from API. So we were talking about thousands of pieces of content that were getting updated every six hours. And the entire process is automated, but the customer wanted to be able to manually trigger this job. Um, so the Q UI module allows for just this. It allows for users to process, uh, queue uh, with batch API triggering it from the front end. So it provides a wrapper around that. But in this case we'd still be looking at this two step process. The customer need to manually pull the content updates from the API, get them in the queue, and then they have to head over to Q UI's user interface to trigger the batch API process queue. The the code has really interested in was tied up, I believe in a form class or something like that. Um, or maybe the class wasn't exposed to the server. It's been a while since I worked on it, but I need there's something I needed them to do to expose the thing as a service so I could use it and call it programmatically.

Um, so I opened the issue in the queue, I issue queue, and I propose that the queue UI batch class be exposed to the symphony service. Um, since I'd already dug through the module's code, I had a good idea of how this feature would be implemented. So I opened that merge request and then from that point, just kind of took on a life of its own. Another developer hopped in, um, made some, uh, some made some minor tweaks to it. The maintainer jumped in, uh, addressed a few coding standards issues, rebase the Mr.. And the next thing I know, like this thing, this thing was merged and it got merged before I even made it that far. And implementing the customer's project. Things don't always happen this fast, but you got to give yourself a chance. Um, so this one worked out really well. In this case. I didn't have any technical debt. I didn't have to deploy a patch in the first place. And if you maintain projects on Drupal.org, there are some benefits as well. First off, users will file bug reports against your module if they find things.

If there's a bug in your code, the people they will find it. It could be something like a benign like a PHP notice. It could also be a fatal error or something that's just not working correctly. And as a module maintainer, I have a bit of humility here. I have released bugs in my code. So it happens. The benefit is open source is you'll get that feedback. I've also seen instances where code optimization or code improvements have been offered in a merge request. And these things are, I'd say, almost free because a lot of the work is being done for you, but you still need to review it and make make the commit. So there's a little bit of work there, but I think it's a pretty good trade off. So let's take a look at a bug report. So I'm the maintainer of the Layout Builder component attributes module. What this allows is when you're working in Layout Builder when you have those individual blocks in there, if you want to add a class or ID to them. And this module allows you to do that, that can be useful for some folks as design systems for implementing those things.

Um, well, as a result of a code refactor, it was rendering some classes where they weren't supposed to be rendered. And this is something that evaded test coverage. So a user found found the bug after I released it. Unfortunately, they documented it, opened a merge request. Turns out is pretty simple thing to fix and they uploaded a patch. Um, so from there I updated the test to provide coverage for the bug so it could never happen again. And we got the thing committed. And if I just add this bug report, had it been filed, I don't know how how long it would have gone without with with me not noticing. It could have been quite a while because I wasn't actively using it like creating content on the site. Here's a code improvement example. Um, the user of the embed providers module. Notice that some, uh, actually more than a few for each loops in a particular method. The reason that could be cleaned up by using Php's Array.map function and some anonymous functions. I looked over the proposed code.

It did in fact clean things up. So I gave it a give it a whirl, tested it out test passed so went ahead and committed it. So I got I got better code and took me all of maybe 15 20 minutes of my own time to to get that committed. As I mentioned earlier, there are some reputational benefits for being an active contributor in the Drupal community. First, when you support a project, your organization is listed on the project page. You've probably seen these modules supported by So and So. So you get some visibility there. And when one of your developers helps push an issue over the finish line, both the developer and your organization can receive credit. This is also a marketing opportunity for your organization. If you happen to be an agency, it's a plus to show your clients that you're a leader and you're actively engaged in the Drupal community. Um, it can also serve to boost recruitment. Too many developers care about open source and are looking for an employer whose values align with open source contribution.

Plus, open source contribution is an opportunity for your developers to boost their own resumes by publicizing your organization's contributions. You're building your street cred, which is vital in today's competitive market when you're trying to attract Drupal talent. Um, Matt Glassman, who actually presented yesterday on PHPStan. He recently authored an article titled Drupal has made Contributing to Open Source a marketing opportunity. Um, he this blog post, I think, went up last week, so this is definitely worth worth a read. Um, I think that directly supports the idea of, uh, encouraging organizations to, you know, loosen up, so to speak, when it comes to open source. Um, it's not just the the technical debt. Um, it can it can benefit you in other ways as well. Okay. And while issues and drupal.org are the formal communication channel, Drupal slack is the is where a lot of the real action happens. In my opinion. It's a resource where you can discuss issues and pose questions and do things in real time.

Um, get a lot quicker feedback than just on the issue queues. And many of the big players in the Drupal community are there as well. Um, so if your team isn't using Drupal Slack, you're missing out. And I think it's worth noting that many organizations, particularly ones subject to regulation, have restrictions around like communication tools, and it's possible for your organization that slack may be on some list that you can't use it. Um, I think it's a it's a battle worth fighting to get an exception. I've noticed there's a fair amount of overlap between customers that can't use tools like Slack or Drupal, Drupal slack, and can't contribute back. There tends to be some overlap there. I think it comes back to, um, it, it culture and um, maybe, maybe folks who are a little, a little too risk averse. I use that phrase with some hesitancy. Um, I did have a prior incident at a job as a publicly traded, highly regulated financial services firm, and they were able to for our core dev team, we were able to get an exemption so we could access Drupal Slack.

So it can happen. It's a battle worth fighting. Okay, so in this final section we'll discuss how to make open source contribution reality in your organization. Because change doesn't just happen at a very high level. You're going to need a culture shift probably in your organization. If what we talked about so far is, is your organization, um, many, many folks are used to operating under the old rules. So education is the first step. Many decision makers and even some developers, they don't understand what open source is and how it works. Oftentimes their understanding stops at you have the ability to download and use the software for free. That's that's where the open source stops for them. And most of this presentation has been geared towards education and examples you can use yourself. Education is a key part of building buying into. For any strategic initiative to be successful, you need to need buy in. There's entire books and presentations on that, so we won't dive in here. And for the rubber to meet the road, you'll probably need to provide some mentorship.

If your team hasn't been opening issues, hasn't been filing merger requests, um, on Drupal.org, they're probably gonna need a little bit of coaching. So that can include some things like how to create an account on Drupal.org. It's possible some of your devs don't even have accounts on Drupal.org, so don't take that for granted. Um, how to file an issue? How to open a merge request? I'd also coach them up on writing quality issue descriptions, which they should already be doing in your organization, but it never hurts to coach that up a little bit more. And also how to advocate for their issues on Drupal.org. I know these sounds like these sound like basic things, and they are, but there's some uniqueness to operating in the Drupal open source community. And so it's let's not overlook that, um, operating in Drupal is different, in my opinion, better than some other open source models. Think about if there's some some project in GitHub, you want to go open a pull request against, you got to go open your pull request.

It's not collaborative. You're the only one who can work on it. And that just kind of it. I think the Drupal model is is a lot better than that. It's entire ecosystem. So put it in writing. It's important for your organization to codify its stance about open source contribution in a policy. And if it's not in writing, it does not exist. And I think it's important to be direct at your organization. We have a contribute first policy and then state what that means for your organization. Um, you should also define any processes and procedures. I would absolutely recommend you track your contributions that you're making. Um, when I was at the financial services firm, we had a place where we kept track of modules that we'd made open source contributions to, um, including specific, specific issues. Um, and that in that particular case, that was, uh, reporting threshold, I suppose that was triggered if we actually offered some code. So if it was just commenting on a particular issue that didn't that didn't trigger tracking, but the code was offered.

Um, then it was that, sorry.

>>:
Why did the organization ask you to track contributions? Um, I think it was important. So the question was, why did the organization ask us to track contributions? I think it's important if, uh, to have metrics around that. So you can say that we have been doing this and these are all the contributions we've made. Um, that way, management knows that you're actively contributing. Um, and. So that that was the first piece. And then I think it's also valuable because as that list starts to get longer, your building momentum, so that we have this list of all these modules and all these issues have been filed that it hopefully becomes self-sustaining, that other developers will see this, you know, new developers will see this and they'll see that we're we are actively contributing and we're building a culture around contribution. And so I'm going to go, you know, I'm going to go put this issue on this list. It can become a point of pride as well for your organization. Um, yeah. So in our case, I think we tracked it on a confluence page that'll probably need to go up into more mature issue at some point.

It could be a shared Google doc. Um, your organization may require some type of approval process. Um, so if that's going to be the case, figure out what that looks like, get it in writing, and make sure it's actually something that's workable. And it's not some policy that's going to stifle contribution. In terms of that approval process. I would I would advocate against a formal approval process because that's just going to gum up the works. And you shouldn't if you're in a position where you're looking to contribute code, which is somehow proprietary, then like something's fundamentally wrong in the first place. So I just I'm not a big fan of the approval process, but if if it needs to happen, then, you know, try to make it as, um. As, uh, um, painful as possible. Uh, now, the next thing here is to, you know, don't stand in the back of the room, be public about it. So create an organization on Drupal.org. From there, your team members can join the organization and start racking up credits.

As I mentioned earlier, if you're supporting an organization for module, it's going to show up on on the modules page. It'll also show up. That module will show up on your organization page. And uh, when your developers, they can assign credit. And if credit is granted, that's going to rack up for both the developer and your organization. So if you go to some of the organizations on drupal.org and go look for, I think they list credits for like the last is either 3 or 6 months, that gives you a pretty good gauge of how, uh, how engaged different organizations are. And when you're building your roster, make sure to highlight your contribute first values on job descriptions. Um, a lot of organizations don't do that, even if they, you know, do contribute back. That is a great way to stand out. Developers are going to notice that. And then the other thing is to make sure that your vendors and contractors know about your open source stance, um, documented in either the Master Service agreement or individual scopes of work.

It's important that your vendors and contractors know ahead of time that private patches and private forks are not your preferred way of operating, so just go ahead and nip that in the bud and have them operated from a contributor first standpoint as well. And these examples I've given here are fairly black and white. We we always find our situations where there's some, uh, some shades of gray and like, well, I don't know exactly. Should we contribute this or not contribute this? The important thing is that you're you're in the mindset where you want to contribute if you can, uh, as opposed to never contributing. So it's about kind of switching that mindset up. Then finally here. Um. I think some people get a little bit antsy because they feel like once you've engaged, like you've you've opened yourself to up to open ended commitments, that can be a fear of your managers. Um, and I would say as a contributor, you're only responsible for the commitments that you choose to take on. So be mindful about the commitments you take to choose on, to choose to take on.

It's entirely acceptable to document a bug and then to move on. If you decide to go a different direction with your project, you open the issue. You did your part. That's fine. Um, you're part of the community. Somebody else may jump on that issue down the road. And this is a key way that Drupal is different from some other open source models. Um, in Drupal, merge requests are collaborative. I can commit to a merge request to someone else opened up. So we don't have merge requests that like, you know, dead end because that person stepped away. And that's a that's a powerful feature in our community as well. And finally, I'd ask to be mindful with your commitments when it comes to module Maintainership. If that's a route you decide to go. Um, it does come with responsibilities. You'll need to keep an eye on the issue queue and be at least somewhat responsive. Um, you know, don't be that module that has half a dozen reviewed and tested by, uh, reviewed and tested by community issues and like, no release in the past three years, like, that's at that point.

That's not a good look anymore. Um, so to be clear, I'm not trying to talk anybody out of being a maintainer. Uh, completely the opposite. I'm encouraging responsible maintainership. And again, I refer you back to that Drupal con presentation. Uh, that was a lot of that was covered there. Then finally, the word I have not used during the entire presentation day is altruism. Um, this this word tends to get brought up to me by decision makers. When we're talking about open source contribution, they view it as altruism. Like we're just doing this to be good, to give back. It's like when you send your people out to do like, the highway pickups, um, give them the afternoon off of work just to be a good thing. And you don't need altruism. Seinfeld had a really good episode that explores altruism, and we don't even need it here. Make a business case. Uh, we went through a bunch of examples here today. Um, you know, lead with the business case. Don't talk about altruism if they bring it up. Swatted away.

So we're not doing that. We're talking about business cases here. You can contribute to open source without feeling warm and fuzzy. All right. So with that, I'd encourage you to fill out the feedback form. And with that we can open it up for any questions or comments. Well, no, this is a really good presentation. It's absolutely not for me. Um, I'm a pleasant retired old guy who is real interested in Drupal as the kind of thing that I'm doing lately, so there's no organizational involvement at all. On the other hand, I really love the idea that Drupal is an open source community and I want to continue to fit into it. So that's how I sort of experienced Drupal, and that's how I fit into this presentation. Um, I'm not good enough to know all of the things that you described in the scenario. But I love to come to this because every time I see somebody describe something, you know, it gives me something to aim at. It's something just above my pay grade. Then, um, I'm learning more about. So I'm happy I'm here, even though this did not work for me a bit.

Well, thank you for being here. Yeah. Question over here.

>>:
I guess it's more of a comment I was thinking about. Uh, so the Drupal projects and other large open source projects in the world.

>>:
Say Linux or. I don't you know, these, uh, GitLab itself. Those those products have codes of conduct and kind of kind of some rules. I was really a nice thing. And so I think as members of the Drupal community. Organizations or members of the general community because they use models and whatnot. Uh, we we have that sort of protection against sort of this, this the bad scenario of open source. I'll. I'll share this scenario. And that scenario is you have an employee who's saying, oh, yeah, I can make my, uh, I'm going to make this really cool TypeScript code, open source, great GitHub repository for it, great package for it. And it's all under their control. So this is a worry of some organizations right. They lose that control. And the scenario then is the employee moves on. And a few months later like I don't care about this anymore. The links. And because GitHub repositories, if you're not in a large organization without governance, they're going to delete the repository, delete the npm package.

Suddenly your project doesn't build anymore because you've lost the code. So I think the that's very is very specific to like, you know, it can't be used as a, as a reason not to contribute. But the Drupal community, you know, like other large scale projects, has governance. Like as a maintainer. Uh, I don't I mean, I could do some devious things, but that's going to reflect poorly on me in the community immediately. Uh, there's there's ways that, you know, there's an assumption that code of conduct or community working group. Um, you know, when we have conflicts, uh, there are ways to resolve them so that like that, that is a scenario of, hey, it's not it could happen, but not in in a disaster. Disastrous ways that it could have been a smaller project, letting everyone contribute willy nilly to GitHub. And what I suspect you've seen that example before where the package disappeared. Yeah. That's um, yeah, that's very true. And, uh, yeah. So open source plus governance, open source is way more than just the license.

The governance is a is an essential part of that. So thank you for pointing that out as well. Um, yeah. I'll say kind of.

>>:
Like to piggyback on yours. I know you're saying trying to get into like more into the community. One thing I've noticed, um, coming from. Uh, before I was more like a junior inside and kind of feeling the same way. Um, there's a lot of times where you can, like, contribute where you don't need to know code. You. Literally just reviewing someone else's, like kind of sharing someone else's, like, uh. Like stuff. So that to me, I think is always like a good thing of when it comes to Drupal and just contributing. Because to be honest, sometimes, like even me personally, like I will try to contribute and then it's just like. Let me look for the easiest thing to contribute where it's like, hey, let someone.

>>:
Put up a picture for, um, you know, like what they're going to use for. Abajo. And then does it look good? Pick one of these three. At least doing something like that kind of keeps. I think it's a good start to kind of get the ball rolling, because sometimes then later on you might want to like try to pick up something and like even more. I guess something that's a little bit more, uh, tougher, I guess. Or we'll give you more of a challenge deadline. Um, and then the other thing I was kind of going to ask was, um. When it comes to, uh, is there a proper way of like, say, if you're a maintainer, um, and then you are is there a proper way of. Kind of ruling yourself out of being a painter. Like, say, if you're like, hey, you've been maintaining it for years and like a motto for years, and then all of a sudden you're just like, hey, I want to. I think I'm done with it. Is there like a. Best practice or procedures, you know, handing it off to someone or just before just kind of I feel like sometimes I'll look at some modules and it's like, you see all this like contribution and all of a sudden it just stops because like the maintainer just disappears and then no one else takes it on.

Like, is there ever a way to I don't know if it's like putting a note in or something and just like, hey, I. Yeah, so we talked about that. I want to address something you said at the beginning of your comments there. I think it's important when we think about contribution is to recognize that, you know, we all operate at different levels, uh, contribute what you can. Your best is good enough for the Drupal community. When I, when I first got into Drupal, um, I did not know how to debug code, but what I could do is I could document that this bug existed. These are the steps I reproduced it. This is the error that's showing up in the logs. And that's as much as I could do. So I could post that. Um, so even though I couldn't, like, fix the bug, that's valuable information for the module's maintainers, the next person who comes along. Because what will happen is they'll they'll probably take the error or a snippet of it, they'll put it in Google and it's going to bring up my issue. So I've already jump started them there.

So even though you're not, you don't necessarily see progress. That is progress because it's going to be a starting point for the next person. Um, so your question was around, um, uh, so you've been maintaining a module for a while, and now as your career has moved on, maybe things have changed. You need to bow out. How's the way to do that there? There's a status you can add to your module. Um, um, seeking code maintainers so you can put out there. Hey, you're looking for this? Um, you're looking for another maintainer, and it can be a little bit difficult to, you know, hand off control to, to somebody else because you put this work into you don't want to hand it off to some, uh, you know, some junior person who the Drupal community has a total of one commit. So you kind of want to be thoughtful about that. Um, and it may be a case where somebody will finally step up to be a maintainer of the module because they want to upgrade to Drupal 11, and your module is not Drupal 11 compatible yet.

And that may be a motivator for for some people as well. Unfortunately, um, a module may stagnate out there for a bit before somebody comes along and picks it up. The good thing about Drupal is we have governance around those scenarios. Um, there's also that's actually how I first got into maintaining a module. I made an offer. Hey, I'd like to, uh, put out an offer to co maintain this module. That's that's how I got, you know, the keys to the car, so to speak, the very first time. Um, and there's also governance around if you have a maintainer who's just completely Mia, like they're not responding. Um, there's, there's entire governance around that, how you can actually get control of an abandoned project, I think I think they have a different term now, but it's initially referred to as abandoned project. There's governance around that too. Um, so I wouldn't I wouldn't necessarily let that end game scare you off from helping out maintaining a module. Just just be mindful that there's some responsibility that comes with that.

But if you have if you have bad if you, uh, you decide to leave Drupal development, like that's not the end of the world. There's community and governance for that. Oh yeah. It gets really does like the main point is how to learn them like. His pet projects. And I struggle with this too. Tips of. When? Yep. That that is a that is a tough thing, especially when you've been responsible, like a lot of times, like you'll be responsible for a module module for a number of years and maybe grow a little bit attached, but we don't like to see our work thrown away or um, just that I sit out there and, like, slowly wilting. Oh, yeah. Uh, in the back.

>>:
That's my good question. Um, one of the ways that our company has a very. Like our country's companies kind of altruism. Focused anyway. It's a very small organization, but we do a lot of things like legal help and. State high school sports organizations and things like that. And our bosses have set aside a couple hours a week for personal development. Oh, nice. So when I wanted to start doing my first, uh, code contributions, I hadn't used a code hours for a couple of months. And I said to my boss, like, can I, like, go aggregate all of my PD hours and take a week and do this? And I said yes. Oh, nice. So that was him. You know, if it comes up again, I can also be like, well, I haven't used all of my conference budget. So this is like, can I use some of that for this next project and that I'm not there yet? But what I'm hoping is that I can use that time to push these modules back out. That might be true. If your company doesn't have that culture yet, that might be a way to like, get.

Your foot in the door. Okay. Yeah, that's a good, good way to look at it. Again, culture that that word comes up when we have conversations about open source contribution. Because it is. It is development. It's personal development because you're learning more about. Give him one one tip. If I was starting you and I was working at an organization and I wanted to create my true cloud user account, I think I would not create it with the company email address. Just, you know. Because then your account, you could lose access to that email address in the future. So you probably want to make, you know, think of your of your user account as you. Oh, exactly. And then make sure that the organization is represented. Separately.

>>:
And then you can move around. Uh, and. And then that way. Yeah. You know, you're. Kind of protecting your, your, your yourself, you know, in case. Information. Whatever. Yep. That's a that's a really good point there. Um, you use a personal email address and setting up your Drupal.org account. That's that's you and many Drupal developers have had that same account and move, you know, through a few different organizations over their careers. That's some good advice there as well. Well, I think we're going to go ahead and wrap it up. Um. There is contribution day coming up tomorrow, so we'd encourage you to check that out. And with that, we'll wrap.