How to Grow a Healthy OSS Community

Patrick Woods (00:00): Welcome everyone to our session at Community Camp called How To Grow a Healthy Open Service Community. If you're not aware, or if you are aware, this is a session as part of ... Community Camp is a week-long conference dedicated to helping folks be more effective community builders. I'll kick this off, and I would like to welcome Brian Douglas to the stage. Brian is a staff developer advocate at GitHub. He's also the host of the JAMstack Radio Podcast, which I believe is in its 81st ... 81 episodes, I had that in my notes. Lots of episodes there.

Patrick Woods (00:35): He's also the creator of Open Sauced, he's a champion of open source accessibility, he's a notable Beyonce fan and a member of the Beyhive, and I believe he's also a ukulele player. Brian, did I miss anything there?

Brian Douglas (00:51): Yeah. You might've oversold some of those things. I know a couple songs on the ukulele. Actually, it's been a while since I played, because my kids have claimed it as theirs. It's hard to find in the house.

Patrick Woods (01:03): Are they actually, have they surpassed you in terms of their skills?

Brian Douglas (01:09): Not quite. They're more show. If they were in a rock band, they'd be creating the cover art, rather than learning songs.

Patrick Woods (01:20): Okay. We'll call Brian an aspiring ukulele player then, maybe. He's definitely a podcaster and creator of Open Sauced, developer, staff developer advocate at GitHub. Lots of context-

Brian Douglas (01:31): Yes, those can be confirmed.

Patrick Woods (01:34): Yeah. Lots of great context today. I'm personally excited about this conversation. Brian was the first guest on my podcast called Developer Love, going on a year ago. Lots of catch up on, glad to get the band back together.

Patrick Woods (01:47): With that Brian, let's dive right in. This session is about growing healthy open source communities. Just to kick things off, I'm curious, what would you say are the key characteristics of a healthy open-source community?

Brian Douglas (02:00): Yeah. Some stuff off the top of my head, for key characteristics, is having ... I want to shy away from things like structure and process. Those things really do help. If I walk into a GitHub project and I'm like, oh, I want to contribute here or there, knowing who to talk to, or know who's leading the product, helps a lot when you have just a bunch of avatars and maybe not a real clear structure for how to get decisions done. There could be a lot of chaos.

Brian Douglas (02:28): It's funny because you mentioned the podcast. A year ago when I was on that podcast, that's when I really started taking Open Sauced a little more seriously that I had previous years. That's when I really started picking up on contributions. I had to think about, people are contributing to this, they're coming and going. How do I build community around this? I set up a couple things, like a Discord, and set up other things like a YouTube channel, actually. I feel like I've been doing it forever, but it's only been less than a year, I've been on YouTube. That way, when it comes to things like, how do I enable dark mode on my Chrome browser? Those are things not really specific to our project, but it's a question that comes up a lot when people just don't know how it works. By having documentation, having clear steps, contributing MD when people walk in is very helpful.

Patrick Woods (03:22): Would you say beyond the structure of the process and maybe the architecture of the repo, are there other characteristics you would say of a healthy open-source community?

Brian Douglas (03:31): Yeah. Actually, I don't think I do a very good job of this in Open Sauced, but ButchJS is a project I first heard about this structure from, where they have basically a ladder. I'm staff developer advocate at GitHub, I was senior and I was regular before. When it comes to open-source community, you can be a triage person, you can be a committer, you can be a maintainer. With the ButchJS project, I think it's in their ReadMe, they actually have a structure of a hierarchy of how you can advance yourself in a community and contribute.

Brian Douglas (04:05): It's built on trust. If you show up and are positive and respond to issues or discussions, and you get whatever the first level of their badge is, and then if you start committing code, then you get access to commit rights after a couple times. Then if you're directing cool parts and corners of the framework, then you get it up to maintainer status. Having, which is kind of interesting to have that applied from open source, because that's how our day jobs are, we have actual, what do you call it, promotion paths. Actually having a promotion path has been, I've seen actually be very successful, for projects that do it right.

Patrick Woods (04:43): Yeah. It's really great talking to clear expectations and the paths for leveling up. Do you think, it seems like a lot of the things that come to mind for you when you think about a healthy community, it's setting these clear paths, it's making it clear who to ask whom about which questions, where to go, things like that. Are there other things too, do you ever look at quantitative things like number of commits or contributions, do you think that's an important mark, or is that orthogonal to the real discussion here?

Brian Douglas (05:13): Yeah. Specifically for open source, because that's what the top of the conversation is, sometimes you get lost in the sauce with all that stuff, pun intended, because for example, to pick on a project that took very well, Gatsby really started off contributions, and you get a t-shirt and socks, basically, contributions. Honestly, I don't even know if they're still doing that. I don't know if they walked that back a little bit. It became, the focus is, I just need to get a couple commits and I get a t-shirt. Same thing with Hacktoberfest. I get a couple PRs, and then I get a t-shirt.

Brian Douglas (05:47): Then after October, no one's around anymore. The same thing with the green squares of GitHub as well. I'm here for the green squares, but I'm not here to answer questions or do documentation. It really starts, that starts your culture that way. When you set up culture where it's like hey, it's okay to ask the dumb questions, which is why I have a Discord, I want you to come ask questions in a place that you don't feel like it's awkward to ask the simple question of hey, I don't even know how system-based dark mode works.

Brian Douglas (06:18): I bring that up because I didn't know how that works. Someone contributed dark mode to my project, and I'm like, oh, this is how you set this up on a Mac. I have dark mode everywhere. I was manually setting this up for every site. Things like that is being able to, me as a maintainer, being able to ask the dumb questions has been extremely helpful. The focus on quantitative and okay, three issues, closed, makes you a maintainer, or three PRs merge makes you a maintainer.

Brian Douglas (06:46): That can be a spiral to the wrong direction, where you have folks who're just coming in just to ... This is something I've seen on just my project and other projects on GitHub. I have eyes on a lot of different things. Folks will do the bare minimum, so that way they're part of the organization. Then they walk away forever, and then it's like, hey, do you think you could help out with this thing? They're like, oh, no, I'm busy, I'm successful now, I've got a job.

Brian Douglas (07:14): Which is totally fine, I'm happy for them, but it made me question, maybe I had the wrong stepping stones to get people successful. I had to pivot and reiterate how I approached the process. Which I'm happy to dive in more.

Patrick Woods (07:29): Yeah. That's actually good there, because it seems like there's some characteristics of a healthy community, open-source community related to the incentives that are put in place, and potentially the unintended consequences of those incentives, all wrapped up in the culture of, it sounds like what you want the culture to be about, and how the incentives support that or retract that.

Patrick Woods (07:50): Yeah, love to hear your journey with that, with either Open Sauced or [crosstalk 00:07:54] about how incentives, culture and stuff like that [crosstalk 00:07:57]

Brian Douglas (07:57): I would also present the caveat too as well, this is why foundations, open-source foundations are successful, and help provide that structure. The Russ Foundation, which was a recent conversation they had in the Russ ecosystem, they have a foundation now. It's very clear who's steering the ship, who's making decisions, who do I talk to about partnership with this other thing, or announcements. There's clear structures on how I can get things done.

Brian Douglas (08:23): With Open Sauced, my angle is, it's going to be much more of a smaller project up-and-coming-type of deal. We still have a triage team, and my original announcement for the triage team, actually, I took from Express.js. They have a triage team. I opened it up, I wrote a blog post on Dev2. It actually got really a lot of eyes, to the point we had a triage team of 12 people. We were cranking through issues, all 30 of them, because I only had probably 30 to 40 issues at the time.

Brian Douglas (08:53): They were triages. At that point, no one was, other than myself, was prepared to write code. I have a bunch of issue that were perfectly triaged, but I was the only one shipping code. It became a quick way to get to a bottleneck to then, I had to start ... I had a Discord, I created the Discord around that time, to then pitch folks in the Discord, like hey, we've got this issue, what would make this easy for you to approach, do you want to pair with this? Then it turned into me doing livestreams on Twitch, where I would just livestream myself approaching the issues, approaching the project. Then that would unblock folks, as they look over my shoulder, how I approach my project, which is a very old react app that's been slowly getting up to speed to modern react development.

Brian Douglas (09:38): People are now able to see, okay, this makes sense, this file that looked very scary to even touch, mind you, I wrote all the code over the course of four years, so it's not the best, it's mostly not tested. Now people have a context of how to approach it. To the point also, when I say shy away from things like processes and guides, you definitely want those, but I think what a lot of times, with open source, folks are really, they push you towards, find a good first issue and then good luck.

Brian Douglas (10:10): My whole thing is, no good luck, let's just create good first issues that have solutions in them. I legitimately go through the good first issue, I walk through the code and how I would fix it, and then I write that. I link the file exactly where the fix would be, the line where the fix is, and from there, it gives someone an opportunity to walk in there and jump in. I found the uptick of good first contributors really skyrocket in the last year, a ton.

Patrick Woods (10:41): Let's circle back to that specific tactic in a moment, because I think it's really special. Maybe we should talk a little bit, or you should talk a little bit about Open Sauced. What it is, what the goals are, and also, maybe speak to the channels that you have around that, the repo, the Discord, things like that.

Brian Douglas (10:59): Yeah. Open Sauced itself, it's a project to find your next open-source contribution. I've pivoted a little bit since we talked last year, we were more about open-source onboarding. I feel like that's a problem that is continuing to be solved by a lot of these projects. Just legitimately, just project sharing their process publicly. It's actually encouraged, things like the triage role, it's encourage other people to start doing that.

Brian Douglas (11:23): Now, this project itself, it's a React app, I built it when I was working at this company called Netlify. It was really, the goal was to use the GitHub API to do something, and then talk about Netlify while doing it. It's hosted on Netlify. It's actually the project that led me to work at GitHub, ironically. Anyway, I say, it's also built on the GraphQL API. That's it. The story ends at that point with Open Sauced and the project.

Brian Douglas (11:50): Actually, what it's grown out of is the things like the Discord community, and folks interacting and having questions and having conversation, especially during the pandemic and everybody being at home. I definitely picked up my Twitch streaming. A lot of folks who watch me on Twitch hang out in the Discord. Then a lot of people who just want to share their open-source projects or find contributors, they navigate to the Discord as well, and the drop ... We have a project share channel where people would just drop their project and tell us what you need help on, what you're working on, what language is it, how would you ...

Brian Douglas (12:25): We actually had a question a while ago about this project strategy and how do you maintain the project as far as organization. We have a lot of those conversations. It also is a place for us to sit and hang out too as well, and talk about what's happening in the tech world.

Patrick Woods (12:44): Jumping back to some of those tactics that you were just walking through around good first issues and getting people up and running in a project, are there other tools or tactics that you have seen work well to bootstrap or kickstart the culture of a project early on?

Brian Douglas (13:06): Yeah. This is something that a lot of ... I get a lot of questions around, how do I make my project successful? The irony is, you have to talk about your project. A lot of folks hope for the best and hope that the GitHub ... I don't know. I say the GitHub algorithm, which I'm doing air quotes right now, because there's no algorithm to help your GitHub project blow up. It's everything that happens off of GitHub at the moment. We do have a explore page, we do suggestions and we do have some up-and-coming projects and have lists like that. We also have the change log. We don't have it. Change log podcast does a change log nightly post, which is really good for finding training repos.

Brian Douglas (13:43): That is realistic, you can get trending that way. The way people get trending is by writing blog posts about your project, by tweeting about it, by getting talks about it. I think there is a disconnect between people who just want to ship code and people who want to be famous on GitHub or whatnot. I think it just comes down to, you just need to really just talk about what you're working on, and them make it easy for people to actually find out how to use it, how to try it.

Brian Douglas (14:10): I run into a lot of different projects, especially in the Twitch world, where folks will throw a project out there, and it's really great code and really interesting problem, but when you go to use it, there's no ReadMe. The bare minimum have a ReadMe, give me a quick two sentence of what this is. Folks will forget to do that, folks will not have a contributing MD, which is also super helpful. This is all in the maintainer side. There's a whole 'nother conversation when it comes to contributor side.

Brian Douglas (14:37): Yeah, at the end of the day, success comes with actually people knowing about it. I think when I started doing talks at Open Sauced, which I never did prior to 2020, actually, I did a couple talks in 2019, but really not too many until 2020. Most people never heard of Open Sauced. It's because I happen to just talk about it all the time, and have a pizza moniker that goes along with it. It's memorable.

Patrick Woods (15:01): How have you found the streaming to contribute to the project and the community more broadly, I guess?

Brian Douglas (15:08): Yeah. Behind the scenes, I actually started streaming as a necessity, because I was working at GitHub on projects that if I wrote some code at work, it was short-lived. Not short-lived as in the project dies, project lives on, but it's all code that doesn't need maintenance. I was finding that a lot of my code was just nonexistent. I needed something to basically write code on a consistent basis. That's what Open Sauced became. I chose to stream it because if I could make myself accountable to have people watch me do it, and also do it live on the air, and I get twofold, I get more speaking opportunity to grow my dev advocacy roles and being able to talk on screen and on camera, but two, I get the right code while people are watching. I get something to stay accountable with.

Brian Douglas (15:57): I didn't have any high arcing goals of, oh, Open Sauced is going to have 100 bazillion users, which we don't. Just by showing up every week and doing a thing, I've seen the project grow very slowly and steadily. It's helped me to stay interested, because a lot of times, we have these side projects where we build it, and it's like oh, that's cool, I don't want to actually maintain this, I'm going to walk away from it, archive the repo and that's the majority of my projects. Open Sauced has always been special to me, where even if I don't ship a new feature in three months, I'm still super down to fix bugs and talk about it and show the cool way I'm using GitHub as a back end and leveraging GitHub actions to keep all that updated.

Patrick Woods (16:39): Very cool. As a reminder for folks in the room, if you would like to ask a question, you can join us at discord.orbit.love, we've got a text channel going there, with conversation about this specific talk. We may do hand raising in a moment. In a meantime, feel free to join us at Discord for any questions you might have for Brian.

Patrick Woods (16:57): Brian, to zoom out and maybe get a little philosophical, what do you think community as a concept means in the context of open source?

Brian Douglas (17:07): Yeah. That's a good question. I think what community, and I've talked to ... One thing that we didn't mention upfront is I do another podcast called the ReadMe Podcast, and it's an opportunity to talk to open-source maintainers about the origin story of the project, as well as where their projects going in the forward. We have Rachel Nabors on this week to talk about React, and also the other stuff she did with Mozilla, and how she got to where she is today, which is a highly recommended and super interesting story.

Brian Douglas (17:33): As far as community goes, it's everybody having similar goals or similar opportunities and working towards something. I was talking to Paulus Schoutsen from Home Assistant, and his goal when he started Home Assistant, which I don't remember if that was what it was called when it started, was he got a light bulb, a Philips Hue light bulb back in the early 2010s, and he just wanted to make it turn on and off. At the time, the Alexa or the Echo device wasn't around. For you to actually set that up, it was actually pretty hard. You had to know what you were doing.

Brian Douglas (18:06): He built a thing to make it a little easier. Now, it's blown up to now have a community of folks who're now just one-upping him, and showing off other things they're doing to make their IOT devices work and turn on and off and blink and stuff like that.

Brian Douglas (18:20): I think community, when it comes to open source, even Open Sauced, what I love seeing is other projects thrive out of Open Sauced. There's a project who, one of my earliest moderators on Twitch who's Mark, he's Financingularity on GitHub, and he built a project to basically be an aggregator for Twitch APIs. Web hooks and subscriptions and et cetera. His project, it's taking off a little bit. It's solving a problem. I'm giving him a bit of my platform to share and help showcase what he's working on.

Brian Douglas (18:54): Now he's growing a community around that project. He still shows up in the Open Sauced, but you can tell that now, with his project being successful, and now he's got a community going, that success is actually seeing ... A lot of times, you'll see the larger projects spin off other smaller plugins or other parts of the ecosystem that supports the greater good. It's not about me as a maintainer, it's not about whoever's driving the ship. It's about actually seeing everybody be successful and if it's about solving IOT interactions, or if it's about doing devops deploy pipelines, everybody gets to win from it.

Brian Douglas (19:33): It's, yeah, again, not about me, not about Open Sauced, but about open source.

Patrick Woods (19:39): Yeah. One of the ideas we talk about a lot at Orbit is this distinction between trying to capture value versus trying to create it. That effective, and I think thriving communities are oriented around that second idea of creating value. It sounds like that's really a mantra you've adopted for your project, your community as well. It's really cool.

Patrick Woods (20:04): When we chatted about a year ago, you talked a lot about this idea of unintentional gatekeeping in open source. Could you tell us what that means? I'm curious if that's still top of mind for you, if you feel like society has evolved such where that's less of a concern? What's the status of that particular point of view for you?

Brian Douglas (20:25): Yeah. It's still very much a thing that I think people should be aware of. For example, there is, in my Open Sauced community, the folks that are active in Discord, I know there's quite a few people who are not active who chat with me privately, and either have questions, stuff like that, who're not as visible. I would say as the majority of my community is definitely of the male gender identity, I would say that it's something that I've always wanted to do other reach-outs and coauthor stuff together with other communities, to change that.

Brian Douglas (20:59): Haven't got to that yet. I struggle in the back of my mind is, if I am doing this thing to help people find open-source contributions, am I bettering open source moving forward, or am I just finding my friends? Am I attracting people with like mind to go along the path to do this thing? Which, for folks who're listening and maybe not seeing my avatar, I identify as a black male, and he/him and yo. I want to always make space for other people to come onboard and have conversations with me, which is why I do the other stuff outside of Open Sauced. I bring in folks to join me on the podcast or join me on the YouTube channel, so that way I can get other experiences and approaches to writing code, doing open source, that it inspires other people to also join us in the community, so we can have more, I guess, diversification or diversity in voice.

Brian Douglas (21:51): As far as the unintentional gatekeeping, to explain that more, it's intentional bias, unintentional bias or whatever, I forgot what they call it at Google, that blew up, and now we have trainings, HR trainings about it. It's basically, when I first joined a tech company in San Francisco, I found out really quickly, all the engineers on the team were from the University of Illinois. I started asking questions, I didn't go to Illinois, why am I here? It happened to be, they found me and they interviewed me and I got the job.

Brian Douglas (22:21): The cofounders of the company both went to the University of Illinois. When they hired people to join the company, first thing they did was go to their friend group and be like hey, who wants to work for us in San Francisco? People flew out, people were already in San Francisco, whatever, joined the company, and now they have more than half the company all came from the same school, within the same four years gap, all graduated the same couple years.

Brian Douglas (22:46): Again, it's an issue but also, I totally understand you want to work with your friends. Which is why I intentionally on Twitter, on GitHub, I intentionally follow people who're just not from the background that I come from. Which, once you start doing this, you realize it's actually pretty easy to find people with different backgrounds, once you start searching them out.

Patrick Woods (23:08): In addition to things like following folks that are outside of our echo chamber, what have you, what are some other ways that we can think about avoiding the unintentional gatekeeping in our communities and our open-source projects? Have you seen any tactics or ideas that've worked really well to overcome that?

Brian Douglas (23:26): Yeah. I'm speaking, specifically the people who run projects or adjacent to open source, or even if you work at a company doing Devro, the communities you reach out to and partner with to make your job easier, because if you're not reaching out to existing communities, and you're doing Devro, you're doing it wrong. It's going to be so much easier if we just reach out to Code Babies.

Brian Douglas (23:47): When it comes down to, and this is something I've actually talked to the node people about, and I've actually sat with the OpenJS Foundation, whenever there's, actually, better example, when React18 was announced, there was a tweet that went out, and was like, hey everyone, we're making some changes, we would love your feedback.

Brian Douglas (24:05): What I know firsthand is that very few people actually provide feedback, when people have new releases. Same thing with View, I saw View, was it View3 or was it ... I don't remember. Something Evan You tweeted was basically, hey, we need some feedback on this new feature, or whatever.

Brian Douglas (24:20): I do also know very few people respond to those. We'll say oh, I'm going to use this in my project, here's my feedback. The one thing that we could probably do is, there are all these "coding organizations," the setup of View project or React project, it can mostly be trivial at this point, because it's a lot of CLIs and boilerplate code, just out of the way. I could go to, let's just say Black Girls Code, and say hey, as me as a representation of View or React, I'm going to go to Black Girls Code, I'm going to volunteer or I'm going to spend my time with them and get to know them, but also when we ship new features on React, those are going to be the first people I reach out to. I'm going to say hey, build a project using View3 or with React18, and let's see if you have any problems, or hey, why don't you build it this way? What's different with this?

Brian Douglas (25:10): As part of your training, you're educating folks and bringing them along the path. Instead of leveraging your network and getting the same folks who, the people who do respond, tend to be the same 10 people. If you go to JS conf, or if you go to React conf, or one of the GitNation confs, you tend to see the same people on stage. Which is, I get it, those are the people who're submitting talks, same with meetup talks, you don't get a ton of people who're submitting meetup talks for your local meetup, because not everybody's willing to do that.

Brian Douglas (25:40): You're going to get the same 10 people showing up to your meetup. It's always going to be the effort as a community manager, open-source maintainer, to reach out to people who are not showing up consistently, and shepherding or mentoring them to come along for the right.

Brian Douglas (25:53): This comes down to also, a bit of problematic culture where it's just like, a lot of open-source maintainers, the reason that they get into code or get into their project, and think, they solve the problem with code, and they're enjoying it. Very quickly, once the project gets popular, is that you have to move into other roles, whether it's community management or it's marketing, or if it's running a Twitter account, or making sure release notes are updated, all that stuff's on the maintainer at this point. Or, they can delegate it to other people.

Brian Douglas (26:27): I think, there's a lot of nuance I guess in the question. That's why I'm talking circles around different ideas. It just comes down to, if I don't want to write release notes, I know 100 people who would love to be part of the NodeJS team, who would just write release notes. They have a release team too as well, which is why I brought them up originally. I can just find the community, find people who want to be up-and-coming, and have the time and bandwidth to do this, and create a path for them to test my releases, to ship my releases, and to get the documentation and notes all up to date for every time there's a release.

Brian Douglas (27:02): Yeah, I guess that's, to answer your question, roundabout way, talk about strategy, I think the release team at Node is great, and there's a lot of up-and-coming folks in there.

Patrick Woods (27:12): Yeah. That's great. It seems like, if I were to summarize that, I would say something like, you can overcome unintentional gatekeeping with intentional outreach and design. Really pushing yourself and your team to go beyond what's easiest and frictionless to get ahold of our creative, outside of your existing series of deployments.

Patrick Woods (27:35): What you're describing isn't necessarily difficult, it just requires forethought and intentionality.

Brian Douglas (27:42): Yeah. If I can speak of a counterpoint, because I'm looking at the Discord and there was a comment, the counterpoint is, there are projects that just cannot take contribution. I just learned today Obsidian is an open-source project, small team, they're not really in the position to take on contributions. They're all working towards a goal, which is totally fine, but setting up signals and saying hey, we appreciate the fact that you love this project, but at this time, we're not taking anymore outside contributors, but we'll let you know if we can open it up for more folks in the future.

Brian Douglas (28:12): That's their stance at the moment. I think OPS is another project that, it's driving a lot of adoption. It's changing the way we're doing remote conferences and doing livestreaming. It is a very specific people who know specific code of C+ and injecting JavaScript run times inside of it, and stuff like that, that it's not really welcoming ... Today, it's not welcoming to take new contributors. Having a signal and saying, hey, thanks for but not right now is also a really good signal to have, because it's okay to not take on people.

Brian Douglas (28:43): I think what really hurts around things like Hacktoberfest ... Hacktoberfest is a great event too. I just want to point that out. It's not having the signal of, I want to get involved in open source, I read a article about how to get involved in open source, I looked at all the libraries I use, so I'm just going to contribute to one of those. Then you find out really quickly, it's like, oh, these libraries are either dead or not taking on contribution, or they're part of some inside company. They're part of Google or whatnot. Then I have to learn Gerrit, or I have to learn something else to contribute. I'm just going to fall off.

Brian Douglas (29:14): I think what I'm trying to do at Open Sauced is make it very clear to people, what projects actually are taking contribution, and then signal them to come onboard.

Patrick Woods (29:24): Yeah. That's a fantastic point, and it reminds me a bit of some of the subject matter Nadia Eghbal covers in her book, Working in Public, around the different types of open-source communities and projects. They're not all created for the same outcomes or intentions. I think you're good to flag this distinction.

Patrick Woods (29:45): We had a question in Discord from somebody with the username Emreb or Emreb. The question is, I think it's really interesting. By the way, if you have a question, and you're in the Discord, feel free to drop it in there. We'll take a look, and our team will put a little eyeball emoji on it, so I don't miss it in the flow. If you want to raise your hand here in the space, feel free to raise your hand. If you've got a question, we may or may not get to it, but feel free to go ahead and raise it.

Patrick Woods (30:10): The question though from Emreb here is, if you were building a new open-source project or product today, what would be your very few first steps to starting to build your community and what tools would you be using for the different aspects of that?

Brian Douglas (30:26): Yeah. I would also, with the caveat, I built a couple projects ... I've built quite a few projects this year, and last year, I had a lot of time during the pandemic. I don't build every project with the intention of building a community around it. I think the question that you're asking is great, you should have that question upfront, because I definitely have projects that I'm just like, hey, if you want to forking clone this, look, beybot's my Twitch interaction. I have a whole, basically a blog post and a ReadMe on how to set this up yourself. I intentionally made it very simple, where there's no frameworks of it. It's just JavaScript, HTML and CSS.

Brian Douglas (31:01): That's clear that I will take contribution there, but just understand that this is not my main focus at the moment. Have at it. As far as community, having structure, contributing MD is great, because if that is there, then I have a good signal that this project cares about contributors and wants contributors. I also point out that if you go to the GitHub settings tab and tab of any repo, you can see, there's a community insight. It shows how far along you are of 100% of all the simple community things you should have in your repository. Have a ReadMe, have contributing MD, have a code of conduct. Have all those things, so that way you can get 100% and it's very clear that you want contributors.

Brian Douglas (31:43): Today, if I set up a project, what I've done this year is I set up a project, I make sure it works, and then I make sure the code is readable, which is something that I don't always do, but intentionally, if I know someone's going to read this code and want to use it, I make sure it's approachable. Then, what I really do is I write a blog post. I write a blog post, I write a tweet, I make sure in the settings, inside the social card, that there's a logo in there, which I have a sketch template for GitHub Social cards, and I make sure that if it's anything that has a social card, that I want people to pay attention to. If it doesn't have anything like that, it's a good signal that I just have not had the forethought to care as much about this project, and then out of the 522 repositories, this is another one I had a great weekend with.

Brian Douglas (32:30): Yeah, I would say have a blog post, take that blog post and then link it or add it to your repository or your ReadMe or your guides folder. Because a lot of times, if I'm excited about something, and I want to contribute to it, it's nice to find out the story, the intention, either through a Dev2 post or your own blog post. Then usually, the signals I usually start off with. Then, I do a lot of speaking. A lot of times, a lot of my side projects come from a need that I had to solve the problem for a talk.

Brian Douglas (33:03): Actually, I joke, I do conference-driven development. If I have a conference, I'll write code for it. A conference to speak at. From there, usually the conference talk tends to be a lot of those bullet points, of hey, here's some intention, here's how I approach a problem, if anybody else is excited about it, here's my GitHub profile or here's my Twitter account.

Brian Douglas (33:22): Then, a lot of times, people just don't really engage with the stuff I write, and that's totally fine. Those are all the projects, again, 522 repos, I haven't really touched, and then I move onto the other things that are getting me notification and mentions on.

Patrick Woods (33:38): You said something that's interesting to me, at least, which is, as you're thinking about, when you have a new project, if you want to invite contribution community, you write a blog post or give a talk, because I think you said, people want to know the story behind it. It seems like that's something that a lot of maybe community builders or open-source maintainers forget is that there's power in that origin story, and that that can be a compelling piece of the project as well, in addition to just the code itself. Would you agree with that?

Brian Douglas (34:10): Yeah. I think there is a lot of power in having an origin story. Even thinking through why does this code exist. I have a project I only created for the sake of a workshop, which is, it tells me the week number. As of today, there's 52 weeks in the year, today, week number, for 2021, we're in week, honestly, I didn't know how to find this. I should've had my terminal open, to actually see it live.

Brian Douglas (34:38): Anyway, we're at week 20 something, 28 or whatever. This is something I just use as an example. No one has contributed that project till this day. A lot of people have starred it ... Week 26, thank you very much, Emreb. Yeah, some people have starred a project, but there's no intention for anybody to contribute to that project, because it's about 12 lines of JavaScript. It really just powers a lot of my GitHub action work. Which is another thing, I have a bunch of GitHub actions that are open source, which I do a poor job of maintaining. Mainly because it's code that I've wrote intentionally to work for one reason, which is to solve a problem in a conference, and not really to build community around GitHub actions.

Brian Douglas (35:19): I don't think, the majority of GitHub actions that are out there are one-off solutions that don't really drive a lot of contribution. Could change in the future, maybe if we take a different direction in the future, but at the moment, you should be able to write 10 lines of JavaScript to power a GitHub action and not have to worry about the ongoing maintenance of it.

Brian Douglas (35:38): I trailed off, I already forgot the original question.

Patrick Woods (35:40): It was about the power of origin story and driving [crosstalk 00:35:45]

Brian Douglas (35:44): Oh, yeah. I'm a storyteller. I think if someone tells me how this was built, I was actually talking to Supabase, one of the cofounders, about how they solve ... It started as a open-source project, they ended up getting YC, another funded open-source project, which is a whole 'nother Twitter space. Their origin story is basically, they were solving a problem, and then they found out that it'd be cool if they could just use Firebase to do this. Firebase is now Google property. It's a different approach, it has different focuses. They decided to rebuild that, but on top of Postgres.

Brian Douglas (36:22): They talk about why Postgres instead of NoSQL or Amungo, which are both valued solutions. They have really good reasons why they would use Postgres and have the same sort of interactions you would have of Amungo or with a Firebase.

Brian Douglas (36:36): It was enough for me to be like, oh, yeah, I should use this. Now I use it for one of my projects.

Patrick Woods (36:41): That's really cool. We love that team as well. I want to spend some time maybe here, as we draw towards the end, by the way, if you all have questions, feel free to raise your hand or drop a question in the chat, discord.orbit.love. Brian, your Open Sauced Discord server and community is pretty awesome, there's lots of channels and you've got self-moderation, people tagging, the programming languages for their profile. There's a lot of cool stuff going on there.

Patrick Woods (37:08): Could you talk a little bit about how you think about using Discord in terms of the overall community? Any cool tricks or lessons learned? We're new to Discord and Orbit, a lot of folks are new too, but you seem to be a serious power user. What's the secret?

Brian Douglas (37:24): Yeah. I appreciate that, because I feel very much not like a power user. My secret was I asked somebody who knew more than I did, really early on. The reason we have a Discord is we had a contributor in Open Sauced who was like, hey, you should have a Discord. I was like, hey, cool, I thought Discord was only for cryptocurrencies and for gaming Twitch streamers. It turns out, I was really wrong, because if you go to discord.com/opensource, you'll see a bunch of projects that you've heard of that are pretty active.

Brian Douglas (37:54): My Discord, it's got a lot of folks, and as I mentioned, we have a couple hundred, close to 500 people in the Discord, but you probably see the same 20 people have conversations. I still struggle with how to engage community, I do have Orbit connected to it, but I haven't actually looked at Discord numbers, to be quite honest, since I connected it.

Brian Douglas (38:14): What I've done is I've segmented different areas in the Discord, so that it's very clear where you should be hanging out, which we have a chat called Hanging Out. We also have, which is not as clear, when you first join the Discord, you have to read the ReadMe. There is a chat called the ReadMe, and you need to read the code of conduct, and agree that you are legitimately going to follow with it.

Brian Douglas (38:37): We've only had to enforce the code of conduct once the entire history of the Discord, which is totally fine, and happy to ... I would be more happy if it was zero, but things happen. Very clearly, there's steps to join the Discord. Then we have some clear places, if you want to share your content, if you want to share your project, which, the project sharing is probably the reason most people drive through the Discord, and say hi. I want to encourage that it's okay to promote yourself in the Discord, because I think that's another value of having a Discord, being a part of any community, is being able to promote your stuff, or talk about stuff you care about.

Brian Douglas (39:12): Yeah. Then I funnel a lot of my announcements through there. Every time I'm live on Twitch or every time one of the Discord members are live on Twitch, it notifies people, everybody gets a badge that you're currently streaming. If you happen to be hanging out, you can click through and see oh, Jay's streaming, let me go and check out Jay.

Brian Douglas (39:30): I just create opportunities organically for people to connect, same thing I mentioned Financingularity, Mark earlier, people have, I had one individual come through my Discord and have questions about IOS programming, and I have no context. I haven't shipped an IOS app in over five years now. I don't know what's happening over there. I knew one person in Discord does know what's happening, so I mentioned them, and now they've connected. That person who came through my Discord is one of the top moderators in Mark's Discord.

Brian Douglas (40:00): Being able to do what I do in my day job, which is connect with folks and talk to open-source maintainers and have community, that's what I'm really trying to do with this Discord, is basically just have community, connect to people, if people are just passing through, that's totally fine. Make it okay where people can pass through. Then, honestly, I'm blown away at the idea of Twitter spaces in Discord, I mentioned this upfront, because I've been using Discord Stages.

Brian Douglas (40:30): I'd fallen off because mainly, because of GitHub copilot. I'm glad I can say this out loud now, because it's been a feature I've been testing, and it's been taking my time, a lot of time to test it and provide feedback and connect folks to. I've had to punt on my Friday Stages. Anybody who contributes to Open Sauced, we have an Open Sauced AMA, where if you have questions about the project, if you want to contribute, or if you just want to just meet with other people who know about React and GraphQL, that's what the Stage is.

Brian Douglas (41:00): Every Friday at 12:00, roughly 12:00 to 12:30, again, I've been pretty flexible in the time because of reasons, because it's an opportunity ... Open Sauced in the future.

Patrick Woods (41:12): Cool. Yeah. We've had I think reasonable success with Stages as well. Rosy and I cohost an event, I guess about every other week, talking to people who've built communities from the ground up. It's called Community Built. If anybody's interested in that, you can find more at communitybuilt.fm. Yeah, I think, Brian, your intentionality really comes through with the design of the Discord, I think is a very, very inspirational setup that you have over there.

Patrick Woods (41:38): Since we're all here, I think Copilot's really exciting to everyone. Love to get your view about that project or that feature, however you want to characterize it. Why are you personally excited about it? Assuming you are.

Brian Douglas (41:53): Yeah. It's funny, because I've seen very early iterations of this. Sorry, one sec, my wife is actually texting me. Sorry. I cut out because my wife started calling me, and then I had to text her back to tell her I'm on a call. Anyway. Sorry, about Copilot. This is my time to shine and sell GitHub, and I'm completely distracted.

Brian Douglas (42:22): What I'm getting at with Copilot, what I love about it is, and I think the approach to the people who've been really approaching Copilot is, the fact that it's not full automation of your code. It's not a no-code solution, but what I get a lot out of it is syntax. I just recorded a video which is going to go on the GitHub channel, GitHub YouTube channel hopefully before the end of the week. I am doing some interactions with the Twitter API. Those are things that I don't do very often. I do once in a while. I'm like, hey, I'm going to build a cool bot using Twitter API.

Brian Douglas (42:55): Instead of me going into the NPM docs or going into the GitHub repo and searching for the code for interactions, I can leverage Copilot to give me some suggestions on how I would write this. Essentially, what it is, you write comments and it will generate code for you. I can write a comment of, I want to find tweets that have #copilot on it, or GitHub Copilot, and it will send me a list of tweets with that hashtag.

Brian Douglas (43:21): Still there?

Patrick Woods (43:22): I think Brian's getting called again. Yep.

Brian Douglas (43:23): Yeah, sorry. With that, what I'm getting at is, it gives me an opportunity to write code faster, because I have someone I'm pair programming with, when I say someone, it's an AI. Similar to if me and you were writing some code together, we would get unstuck faster because we both have thoughts and ideas on how to approach it. Both of them are not 100% correct, every time, and I think if you approach Copilot that way, you're going to have a lot of fun with it, for sure.

Patrick Woods (43:49): Cool. Is that generally available yet, or is it still on a beta list?

Brian Douglas (43:55): It is on a limited beta at the moment. We just launched it yesterday. The intention is to have a X amount of folks get into the pilot, technical preview, and that's going to help to dictate what it looks like when we do launch it publicly for folks.

Patrick Woods (44:12): Cool. Awesome. All right. One wrap-up question here. You know, one great question in the Discord about imposter syndrome, when contributing to open source. What are some ways that you have helped your community members overcome that, or what are some ways that community leaders can help folks overcome that imposter syndrome to get to the point where they're ready to make their first contribution?

Brian Douglas (44:38): Yeah. This is what I do. It takes a little bit of energy, but it's something I alluded to earlier, when it comes to good first issues. A lot of times, folks will approach good first issues as a way of, oh cool, I don't have to do this, or I'm going to find people to help contribute eventually.

Brian Douglas (44:55): I intentionally, because a lot of times, my project's a little complicated. I know this. I create good first issues with the intention that you're going to have a solution written directly in the issue, so that way anybody can walk through this and be like, oh, this is the file that should be fixed, I can clone this repo, set this up with a quick couple commands, NPM commands, and I should be good to go.

Brian Douglas (45:17): I make sure that's the approach for all good first issues, specifically for my project, so that nobody goes into my project and says, you know what, this is supposed to be a good first issue and I was not up to par. Now, am I cut for open source? Have I basically opted myself out for any other future contributions?

Brian Douglas (45:34): That's something I keep in the back of my mind all the time is, I don't want someone to approach this project or any of my projects and say, oh, you know what, this thing is too smart for me, or open source is too hard for me. I'm going to walk away from this and just do my day job.

Brian Douglas (45:48): I guess what I'm getting at is, make everything approachable, and if you can't do it, find other people who can be part of your team that can help you along that path. As soon as you find someone who's a whiz on giving answers, take them aside in your Discord, be like hey, that was a great answer, if you could help me out with those answers in the future, whatever I can do to help support you, and what I do is, folks who contribute to a project, if they're part of GitHub Sponsor, I try to get them attached to the project for GitHub Sponsors, so that way, their name shows up first before me, when it comes to who's contributing and moving this project forward.

Patrick Woods (46:24): Wow. Amazing. Brain, as always, it's clear that you bring a lot of intentionality and empathy to this process. I was taking a lot of notes. I know there's a lot of notes in the chat. Really appreciate you coming on today, to have this conversation, sharing this wisdom. Folks as a reminder, this has been a conversation part of Community Camp. You can find more information on communitycamp.com. Join us in our server at Discord.orbit.love.

Patrick Woods (46:47): Thanks everybody in the Discord for hanging out and having conversations. Please keep the conversation going there. I'll be hanging out for the rest of the week of course, and ongoing. If you have any questions about community building, this talk or Orbit in general, feel free to ask us there.

Patrick Woods (47:01): In the meantime, Brian, thanks again for coming to talk with us today. It's been a real pleasure, as always.

Brian Douglas (47:07): Yeah. Thanks for the invite. Again, I'm super impressed with this setup, and with the community you're growing to grow other communities, which is a full-on inception.

Patrick Woods (47:19): It gets kind of meta around here, that's for sure. Cool. All right everyone. Thanks so much. Have a great week everyone.