This is a transcript. For the full talk, see Lessons Learned: Contributing to Open Source Projects (Part 1) Tag1 TeamTalk - #029.1.

Michael Meyers: [00:00:00] Welcome everybody to another episode of the Tag1 TeamTalks, the Tag1 Consulting podcast and blog. Today's topic is going to be Lessons Learned: Contributing to Open Source Projects.

We're going to look back at over 50 years of collective experience working on open source projects and talk about what we've learned in the hopes that you can learn from our mistakes and capitalize on our successes, become an even more amazing developer and increase your participation both as an individual and hopefully as part of your organization in open source communities.

I'm Michael Meyers. I'm the managing director at Tag1 and I'm joined today by three of our top engineering leaders who are all really well-known contributors to open source projects, including the Drupal community.

Lucas Hedding is the Drupal Core Migrate maintainer. He built the new Auto Updater, which is a huge addition to Drupal and he helps mentor and review module contributions from new developers.

Janez Urevc is the Media Initiative owner for Drupal. He has helped really forward how Drupal handles media, both from a technology and interface standpoint, and he's made major contributions to modules like Mongo DB.

Doug Green built and maintains the Coder module. which is a linter and helps you ensure security and quality code. He's also the author of the original Drupal search system. And, everybody has made many, countless contributions. We're going to tackle today's talk in two segments. Part one we're going to do right now is the challenges and the lessons learned as a new contributor, and along the way.

And then in part two, please stick around and join us for the benefits, why you should contribute and get more engaged, why your company should support you and the benefits, what you're going to learn and get out of all of this. So without further ado, let's jump right into things. At this point, you know, you guys are all really well-known Drupal contributors.

I'm curious. what other open source projects have you contributed or any. So tell me, well, tell me more about your open-source contributions in general. Doug, how about we start with you?

Doug Green: [00:02:32] Of course, you'd start with me, Drupal has really been the only, open source project that I've contributed to. Here and there, every now and then, there's a library, a plugin that we use that needs to be patched, and I've made a couple of crunch contributions to that, but overall the majority of my contributions is Drupal. Both core and contrib.

[00:02:54] Michael Meyers: [00:02:54] Janez?

Janez Urevc: [00:02:56] Yeah, my majority of my contributions is Drupal as well, but I did contribute to a few other things like JavaScript libraries. In the past two years, I became really excited about the Elixir programming language. So I contributed to some of the libraries there. But yeah, those were mostly like minor patches to fix like a small bug or something like that and majority would be Drupal as well.

[00:03:26] Michael Meyers: How about you Lucas?

[00:03:30] Lucas Hedding: Primarily Drupal. I would say that almost exclusively Drupal, outside of sort of the things that hover around it. You know, Github projects that sort of are around Drupal, occasionally, you know, contribution to things like DDEV or, other projects that helped me do my, my, my day job.

[00:03:54] Michael Meyers: So, I'm curious, you know, you guys are very focused on Drupal, which makes a lot of sense, and it is that because that, you know, that's where you focus all of your time and that's why you're contributing to Drupal primarily. And then the things that surround it.

[00:04:10]Doug Green: I'm still working a hundred percent in Drupal. So it is, it's a work. And when we get further along in this talk, I'll share a few things. But, now most of my contributions are work-related and because my work is a hundred percent Drupal, I have worked for a client recently that is transitioning some of their stuff off of Drupal and to more PHP and Laravel systems.

But I haven't gotten into that.

[00:04:37] Michael Meyers: What do you guys recall about your earliest code contributions? You know, maybe, some of the challenges or obstacles you faced early on, Janez is like, what do you, does anything stick out in your memory?

[00:04:52] Janez Urevc: Yeah. Yeah. It's a very clear memory and a really nice memory. I remember that even being like fairly active Drupal user and an engineer, a software engineer at the time, I was still, I still felt a little bit intimidated by trying to contribute. And then at my first DrupalCon, which was --, which was Copenhagen, I decided to attend a code sprint at the end of the week. And there I found Randy Fay.

And I remembered him from attending his session like two days before that. And he really felt like somebody that was really approachable and, and I was not afraid to go and ask for help. And he basically helped me start to contribute and, then after this first patch that I got into a module, I think it was like the Examples module that Randy maintained at that time.

Then I realized that it's not that hard and I totally jumped into it immediately. And I still have like really, really nice memory about that day. It's almost like it happened yesterday.

[00:06:14] Doug Green: Randy is a great guy to get started with.

[00:06:18] Michael Meyers: How about you, Doug? Anything stand out?

[00:06:21] Doug Green: I had two stories. One, one was really my first contribution.

I remember creating some new module, pushing up to D.O and, within an hour, somebody on the other side of the world posted an issue where they found a bug, you know, and, and I thought this was the coolest thing in the world because I've written this module because it helped my client. And here's somebody that wasn't even on our payroll, you know?

I didn't know, halfway around the world found that bug that we fixed within, you know, very quickly, you know, it was a cool experience to do, you know, and, now I've got a CHX story. I don't know if this is the right time or place to, to share it.

[00:07:08] Michael Meyers: If there ever is. I love Chx.

[00:07:13] Doug Green: It was 2000. My first DrupalCon was actually OSCMS, in Sunnyvale, California in 2007, and I'd already written the Coder module. And I gave a lightning talk with Robert Douglas about some search improvements that I was working on. And by the way, I want to collect, correct you Michael. I did not write the original Search module. I improved the original Search module and became Drupal 7 search co-maintainer or, or maintainer.

But someone else wrote the original search. Anyways. Chx, I attended the code sprint just like Janez did after OSCMS. I was sitting in the room, started to work on my own stuff and then decide, what the heck am I doing? I'm here with the Drupal community. I should reach out and, and see what I can do in the community.

And I went up to Chx, who was kind of running the sprint. So what can I work on? And he says, I don't know, what can you work on?

And I started to tell him, you know what I did. And then, he had a remark that has always made me feel good and I'll just edit out the vulgarity, but, you know, “Holy blank. You're Doug Green. You wrote Coder. I give you something hard.”

[00:08:52] Michael Meyers: The way I see that Chx is CH X and he was one of the most prolific contributors to Drupal through Drupal seven.

How about you Lucas?

[00:09:09] Lucas Hedding: Well, I came into Drupal, because I thought it would be a kind of a neat way to be able to give me the opportunity to work anywhere in the world. but I had pretty extensive experience with software development in corporate America. And so, when I joined the community, I was like, Oh, this is great. I can. I can work anywhere. And I was started, to get involved a little bit and I went to DrupalCon Portland. And I sort of faked it, I think, because my first contributions were to help mentor people. And I went to a mentor session, given by, by Jess and, and others, DrupalCon Portland in 2013.

And I said, well, this isn't so bad. I can sort of build on my experience working with Java and other things. And so by the end of the week, I ended up doing, mentoring for the first time as a mentor. Tour, I figured it, you know, the best way to learn is by teaching others. And so my first contributions were opening up patches, opening up issues for the Views module as it's coming into Drupal 8, way back, then was it Drupal 8.

Yeah, it was Drupal 8, early, early, early on in Drupal 8 development. There was like 50 issues that had to be opened to like. fix up some of the function prefixes and things as we were converting from functional programming into more class-based and, so nothing, nothing is as cool as the others.

Unfortunately, it's just like diving in and, and faking it till I made it. And that's kind of how I started.

[00:10:56] Michael Meyers: It's pretty amazing that, you know, this is 10, 15 years ago. You guys have such strong memories of that first experience. I think that's, that's really telling, you guys all had, it sounds like very positive experiences.

Almost every contribution I made to the Drupal community is outside of code. but I did not have a very positive experience with my first contribution. I patched a module and the module owners said something to the effect of who the hell would want this, this, this is stupid. Like I'm not going to, I'm not going to commit this.

Like, nobody wants this. And I'm like, me, me, I want this. and you know, I, you know, So, you know, there are many experiences in the, in the Drupal community and I think that's one of the challenges we'll get into later. but it, you know, it is, it is very clearly to me, you know, to this day, you know, 16 plus years ago in the back of my mind, that experience

[00:11:55] Lucas Hedding: Does that story end well, did, did they come around to your, your point of view or did it end in dust?

What's the end of that story? Do you remember?

[00:12:03] Michael Meyers: I was fortunate enough to get into Drupal when it was really early days and was, you know, worked with some really amazing contributors like Doug and Chx. And so, I don't remember who, you know, then came into the picture and it changed everything, you know, you know, being a known quantity or a name, You know, that that was game over, you know, it, all of a sudden the commit happened immediately.

But, but me, you know, some random unknown, you know, w was a total blocker.

[00:12:37] Doug Green: Yeah. Yeah. Sometimes the issue queue can be unkind and, you know, I've had, I had one experience like that, that I really remember. And, it hurt when someone did that and there are two lessons there. One as someone that's experienced, you know, be kind, you know, we're tech people, and sometimes less skilled in the human, you know, part of it and especially less skilled in the writing and getting involved in the technical, technical problem, problem solving, But, you know, I'm on the, newbie side of it too, to, you know, have a little bit of a thick skin and be persistent and, you know, try to argue for your technical merits and why this is a good thing to do.

Nobody likes to be called an idiot in the queues and we shouldn't do that.

[00:13:36] Janez Urevc: And, yeah, I did experience the thing that you Michael mentioned, as well, like when you are a relatively unknown or new contributor, your voice doesn't count as much as the voice of more experienced members of the community. and hear you, if you really want to do this, you have to build your reputation, obviously.

But at the beginning it helps. Like it's, might, not be enough to just submit a patch on an issue queue. Maybe you need to go into Slack and find people that are involved in that module or on that issue and talk to them. and maybe then you will find an easier way, explaining why the thing that you want to do is beneficial for the module.

And you might even find somebody that is more experienced than you interested in it, and they will help you to push it forward. So it's not. A lot of the time, it's not just like coding work that is required. It is also necessary to do like communication people kind of relationship skills.

[00:14:56] Michael Meyers: That's a really great point.

I came out of left field. Like I just randomly made this commit. I, you know, I think I would have been much more successful. Had reached out to this person and had a conversation and introduced myself, that probably would have changed everything. So.

[00:15:14] Janez Urevc: Yeah. Or for example, if you're on, on DrupalCon, or, or on any other event where there are code sprints, usually you have people that you need in that room. So this kind of events or opportunities to push things forward. Like I literally had patches that didn't move anywhere for months. And then on the sprint day, it got finalized and committed because you can find the person that is responsible, in the room, go there, talk to them.

And yeah, it could be easier to achieve it this way.

[00:15:55] Michael Meyers: So over 16 years later, I learned that I made a misstep. I'm curious, you know, you guys are, are really well-known, you've made major contributions to Drupal and, and, you know, have really been a part of its success and adoption as a platform. but I want to know what missteps have you made, you know, where did you guys, you know, fall down?

You know, does something stick out like mine?

[00:16:26]Doug Green: Well, that time I, I was mentioning when you're being called an idiot in the issue queues, maybe wasn't misstep of, trying to it's both a success and that failure, you know, I think one of the things that I recommend is take risks. Submit patches. The community is better off for it, even if it's the wrong patch, you know, that, you know, even if you make a mistake in it, it will get fixed and we'll have a solution faster.

The story that I think about there was, back in the early days of Drupal, there was a major bug in the file system that whoever wrote the original code, didn't understand Octal math and -- masking, you know, and we were creating files with the wrong permissions and someone coming from a Unix experience and a C++ background, which is where I came from.

You know, that was pretty common, simple stuff. So there was a call to fix this. It was a critical problem. I fixed it in, you know, I don't know, five minutes, 15 minutes put up a patch. But my patch was wrong and yeah, but because it was out there, this was the first start of it. And, you know, I may have made it a second or a third or fourth patch to finally get it right.

But it got fixed quickly. And, you know, I tend to like, to not show the messiness in my code. You know, when I'm working for a client project, a lot of times I will, Rebase, which is where you rewrite your commit history. So you don't show all that messiness. And that's actually a bad thing. I think in Drupal contributing it's, it's better to show that messiness, get it out there quickly and let the community help you solve it.

[00:18:18] Michael Meyers: I, I can't believe I'm going to share this. you know, I'm, I'm not, you know, I've, I've done development because I think it's really important to understand it. I've mostly played other roles. But one of the first commits I made to Drupal, I didn't know what a diff was. So I like create, you know, it was just a couple of lines, so I created it by hand and, obviously, you know, it didn't work and didn't get well received, but, I, I look back at that and laugh pretty hard.

[00:18:50] Doug Green: And we don't need to worry about you rebasing,

[00:18:54] Michael Meyers: But I learned about rebasing from a talk that Greg did. So, I love it.

[00:19:01] Lucas Hedding: One of my first, well, my first contribution, I felt it was not a coding, coding contribution was, was at this mentoring event, this well we need help with mentoring. I kind of faked till I made it a little as sort of my, what I told myself and, We needed like 50 or 60 issues opened around Views, changing, changing the function method, for, for Views.

And, and that was really great for me. Like, Hey, I can do this. I can copy and paste. And, I think DREditor was a tool that I just installed for the first time. I think it just came out and it helped this and it, but it took a couple of hours to open up all these issues and, Well, I think it, you know, a good story.

Good story is that, you know, we had 50 contributors on the sprint, all able to provide like a 1K patch to change the method, on these views. I think it might've been adding public in front of them or something, but we had 50 of them. So lots of easy commits for novice people, come to find out, that was not the right way to go about this because reviewing 50, 60 issues and patches that trivial, you can easily script this and do one big commit. And still today I will hear. Comments from people when, when I'm at a sprint or yeah, we're not going to do it like we did with Views back in 2013, where you open up 50 issues to do something so simple, so good stories.

We had a lot of contributors. There's a lot of people who are able to hopefully date their first contribution back to Drupal. Bad thing is we give the, the committers a really bad set of issues to commit and lots of conflicting re-rolling of batches over and over again. And, it was, it was pretty, pretty tricky, but you know, you learn and now committers will say, no, don't do that.

We're not going to do what we did with Views because before that, they never really realized. And so now we use tools like. Shell scripts to sort of re rewrite our code to, to add these, these trivial changes.

[00:21:26] Doug Green: There's a balance that reminds me of right after had written Coder. I ran Coder on Drupal Core and, I created a patch of all the, a code issue infractions on Core.

And it was a huge patch, you know, And it did get committed and it was actually kind of miraculous that, you know, there was some comment that this is the biggest patch to Drupal Core in the shortest amount of time that it got committed. Cause it was automatically, you know, fixed. But, I think there's a balance there between having too many issues and too many small patches and, Because of the rewriting you're talking about the conflicts and making something too big because you want your contribution to be really just to fix the one thing you're supposed to. And this is a problem I run into constantly. That I'm fixing this, but while I'm fixing this, I notice, Oh this comment is wrong or this code style is wrong.

Or we can do a small refactor here and your, your patch is going to be better received and easier reviewed if you just keep it to exactly what it's supposed to fix.

[00:22:42] Janez Urevc: Yeah. I have really funny anecdotes related to your Coder patch. when one of the companies where I worked at, I was one of the people that were helping others adopt Drupal.

And one of the things that we were discussing were coding standards and Coder module to check that. And some people were unhappy about it. Drupal's coding standards. And when we said, okay, when we contribute, we'd have to make sure that everything is according to the standards. So you can use the Coder module and one of the developers there went and checked Core and he was like, Oh! They're not respecting their own standards. I will file a patch. And if they don't accept it, I won't use it either. And I was like, maybe don't do that.

To your question, Michael, like my biggest mistake was that at some point I totally burned myself out. mostly because I took too much responsibility on myself in the community and when you're really passionate about something and especially me being also that kind of personality is really easy to dive too deep into it.

And then, you know, cause most contributors still have jobs or they do, maybe you use the same software, Drupal in our case, but it's not that you're paid full-time to do contributions. And if you want to do a lot of things, a lot of major improvements or to be in my case, leading like a major initiative, most in your free time.

Then it can get too much. And I did that mistake and, at some point it's it, wasn't doing it. Wasn't very well situation that I ended up and I really need that sometime to, to pause and then restart.

So now I'm definitely more and more careful when it comes to taking over too much responsibility.

[00:24:50] Michael Meyers: I think that's really common.

I've heard that from a lot of major contributors that at some point they ended up in a situation where they got really burned out. you know, there's no, you can't learn, grow and be successful without making mistakes and overcoming them. So, looking back, what advice do you wish people gave you that you want to impart on the folks that are listening today, what would you, you know, what do you wish people told you?

[00:25:22] Lucas Hedding: So, so for that, I would say, don't be afraid.

I did. so I live in Central America, so I went to a local camp down in Costa Rica and there was, session that I got involved with where I was like, you guys can get involved and you can do things.

Do you... at this time? I was very early on in the Drupal community, myself, no one, no one knew me. I was not a known name. And, and I, I used that as like a part of my, and I said, guys, just here's the encouragement just. [00:26:00] Come to the Sprint day, go home, write a small patch. I like to say throw spaghetti against the wall. See if it sticks. See if your contributions will be effective, starting contrib, start with something. That's an area that's of your interest. Core is a bad area to start in. If you want to get instant gratification, there's this phrase in Drupal Core called long tail of contribution. And that, that long tail can be years, especially on the really complicated, hard stuff.

So find a module that you're using, for a client and really just start diving into triage. The issue queue I've got. Hundreds of issues open on some of my contrib modules. I don't have the time to go in and just, Hey, is this still an issue? Put this back to postponed until someone says this is still an issue.

[00:26:57] Triage is probably one of the most thing that, anyone could do. So dive in, find something, write a patch, issue queue, triage, run a sprint. Make mistakes, be prolific, write small patches, lots of times your name will get obnothere. and eventually that long tail, even in contrib, even in contrib, has a long tail sometimes.

At some point in about two years, those initial patches will probably start to get committed. And don't, don't think of it as a short term. You know, if you're playing the stock market, you're hoping to make back double or triple your what your, your money in 20 or 30 years, right? It's the same way.

With software contribution, you write a patch and it might take a day, or it might take a decade to, to have that patch land.

[00:27:57] Michael Meyers: Wow. How about you Janez?

[00:28:00] [00:28:00] Janez Urevc: Yeah, I, I, first of all, I totally agree with Lucas. And, the other thing that I would say is find help because there are many people that are willing to help, especially like Drupal is pretty well organized when it comes to onboarding new contributors.

It doesn't mean that it's easy, but it's much easier than in maybe in some other projects. and even in Drupal you have, we're different people. So you, you might find all that a maintainer of module a, slightly harder to work with, but the maintainer of module B is easier to work with. So if that's a problem for you, you can try to focus on module B, but still .

[00:28:52] Even taking that into consideration, like my experience with other open source projects that I like in some [00:29:00] cases, there is absolutely no feedback at all. So it's much, much harder to start contributing to that kind of projects. And Drupal is definitely not one of them. And it's quite easy to start here compared to other places I would think.

[00:29:21]Michael Meyers: What about you? Doug?

Looking back, what advice do you wish that people gave you that you want to impart on people that are contributing today?

[00:29:35]Doug Green: [00:29:35] You know, we've got an opportunity to think about this and then, write it up. I'm not sure that I have, edit me out completely out of this one. I, I'm not sure that I have any advice.

[00:29:48] Michael Meyers: [00:29:48] Good luck.

[00:29:51] Doug Green: [00:29:51] Everything Lucas and Janez said is true. I dove right in. I dove into fixing Core. I dove into contrib. I, I think, Janez's story earlier about burning out, you know, have some balance in it. You know, and like Lucas said, it doesn't need to be done overnight. I wanted to build my reputation fast. I, I was addicted or I think is not the right word.

I was drawn towards the allure of having my name on the internet that people knew, you know, that I contributed to stuff. And, really it's just a slow burn.

[00:30:46] Michael Meyers: Cool. so contributing to open source. Isn't just about code and we've primarily talked about code contributions thus far. There are there, you know, there are opportunities for everyone to get engaged.

You know, you talked about code sprints and organizing events and mentoring people, you know, improving documentation. Do developers typically get involved beyond code, and you know, should developers get involved beyond code Doug?

[00:31:26] Doug Green: The really good ones do, but I do not as much.

[00:31:32] Michael Meyers: How about you Lucas?

[00:31:36] Lucas Hedding: I was honored to be part of the, the, the Core Migrate, subsystem support team for, for many years. And, for a brief, maybe 18 months, we had a gentleman from Finland who stepped forward and said, I can write good docs. I don't know if I can always understand all of what you guys are doing, but he wanted to really help out with docs.

His life got busy. And so he had to step down, but that brief 18 months were probably the highlight of the last five years of contributing to Migrate, because we had someone to write docs. He would write docs on Drupal.org. And occasionally he would dabble in the, in, in giving guidance and patches, but primarily his focus was on documentation of this massive subsystem and, sitting in on a couple of, of Core conversations at DrupalCon.

This virtual, this last summer, there was some, mention about, some deep intricacies inside of Drupal Core and, my mind immediately, we went back to, this gentleman from Finland and, Oh, that would be the perfect thing for this. I think it was like, What is it like type of types, the type system?

What does that, that, there's a, there's a, there's a comp there's at least one complex system and Drupal Core that I know of that could use a lot of help with docs. And, if someone can grok it, someone told me this once. they said, if you've read through the issue, you've spent 30 minutes, two hours reading through that issue.

And you understand that issue. Write it down, write it, write it down as the issue summary update, write it down as a comment, write it down. I think this is what we're talking about for at least the last 50 comments. Write it down because at that point in time, you've spent more time recently than anyone else in the whole world.

And if you write down what your understanding is, even if it's wrong or even if it's only. 70%, right? It's way easier for someone [00:34:00] else who kind of does know a little bit about what's going on. There's yeah, you're mostly right, but this one little point, do you need to fix this little thing here? And then now we've got an updated issue summary because after 223 comments, no one knows what's going on, except you, you know, because you've just spent the last hour reading through this long summary and

What you just did there is entirely non code, entirely. I'm not breaking out anything at all. It's just trying to figure out what's the general consensus of what we're trying to do here. That's the thing that like a project manager can do that a tech writer can do that. most people that work with technology can do so do it.

[00:34:48] Michael Meyers: Sorry, go on.

[00:34:49] Doug Green: I think the question also, that you were asking was what type of contributions can developers also do? I think what Lucas was talking about was somewhat non-developers and maybe a little less technical, but, I'm going to say I'm bad at this type of stuff. I want to call out two people in the community that are really good at it.

You know, I look at Jess and Angie, you know, XJM and Webchick, you know, who are excellent developers in their own right. But they do so much more for the community by actually doing the types of things. Lucas just said, managing issues and organizing people to solve problems.

[00:35:32] Michael Meyers: Yeah. I mean, like I said earlier, I'm not a, an awesome developer.

But I've made major contributions to Drupal in many other ways and it's hugely benefited me. you know, I've gotten. To meet many of the top contributors in the process through, you know, helping to run an event or, you know, trying to find funding for improvements. you know, and it's really helped my career in companies and the work that I've done, having these relationships, and getting an opportunity then to work with these people professionally.

So, that's a really great point, you know, It's not just about developers, there's opportunities for everyone in every capacity to both contribute. and by extension benefit from, that contribution. last thing just before we wrap up, you know, Janez, you talked about, you know, burnout and, and, you know, being in a leadership role and taking on these responsibilities, you know, I've heard that in particular as one of the things that happens most often, I'm wondering, you know, when you get to that point, what are some of the biggest challenges that you have faced?

[00:36:51] Janez Urevc: Being overwhelmed. It's just too, it's just too, too many things or a lot of things. and, especially if you are in a leadership position, it's usually not enough to only contribute through code, but you have to go to events. Make presentations about what you're doing. you have to talk to a lot of people, you have to manage different expectations.

You have to try to prevent people arguing about small details that, you know, we could argue on for a long, long time, but they're maybe not that important. you it's good if you. write, for example, blog posts, updates about, you know, what you've been doing for the past few months, or few weeks or whatever.

So there is much, much more things that you can do or you have to do as somebody that is more in a leadership position. and it can be too much, very quickly.

[00:38:08] Michael Meyers: Something people have to look forward to as they become more successful.

[00:38:12] Awesome.

[00:38:13] Janez Urevc: Yeah, I guess so.

[00:38:14] Michael Meyers: Well, thank you guys. so much, for, for doing this today.

We're going to wrap up part one, stick around, or, part two, everybody we're going to cover the benefits. You know, why should you contribute? We touched on a little bit, but I think it's really important to dive into that. So please check it out next. all the links that we mentioned, today, in the talk are going to be in the show notes in the description.

If you like this talk, please, upvote, subscribe, share it with folks. We'd really appreciate it. you can check out our past tag team talks at tag1.com/tagteamtalks. and as always, we, we really appreciate your input and feedback. topic suggestions you can write to us at tagteamtalks@tag1.com and again, a huge thank you to, Doug, Lucas and Janez for joining us.

We'll see you soon. Thanks.