1. Library
  2. Podcasts
  3. Developer Love
  4. Ep. #1, Unintentional Gatekeeping with Brian Douglas of GitHub
Developer Love
38 MIN

Ep. #1, Unintentional Gatekeeping with Brian Douglas of GitHub

light mode
about the episode

In this inaugural episode of Developer Love, Patrick Woods speaks with Brian Douglas of GitHub. They discuss the developer advocate role, leveraging open source knowledge, and improving inclusivity within communities.

Brian Douglas is a developer advocate at GitHub and the host of JAMstack Radio. He was previously a developer advocate at Netlify.


Patrick Woods: Awesome. Brian, thanks so much for coming on to Developer Love.

To kick us off, could you tell us a little bit about who you are and what you're working on?

Brian Douglas: Excellent, yes. I'm Brian Douglas, I go by BDougie on the internet, @BDougieYo on Twitter.

I'm a developer advocate at GitHub, which means-- If you're listening to this podcast you probably know what that means, but I get to relate with developers.

GitHub is 50 million developers worldwide, and I get to basically go to bat for them and listen to all their feature requests and then file those into an issue, because GitHub uses GitHub to build GitHub.

Patrick: Tell us about your path. How did you end up with GitHub doing what you do?

Brian: There is a long story and then I have a shorter story, but essentially I always pre-empt my explanation too.

If you want to get the beginning-beginning, I'm on episode two of CodeNewbies.

I was a career-changer, I did an online bootcamp which was called Block, I moved from sales into Rails. Literally, Ruby on Rails.

I started building side projects since I had this new skill, which was coding.

That's all in that podcast, but I ended up finding myself doing some Rails development here in San Francisco and randomly went to, actually at Heavybit, I went to a meetup and saw a talk on this tool called Netlify.

It was super interesting stuff. I didn't know that they actually had just shipped the entire product weeks before that talk.

And at the time Divshot, which I was a pretty heavy user for that, got bought by Firebase and then it became now Firebase Deploy or whatever it's called -- The static front end version of Firebase.

And during that time they said, "OK. You have a month. Everybody move your stuff somewhere else, we're going to go get absorbed into Google. Good luck."

Netlify had just came out and I was like, "OK. Netlify, I'm at this meetup, I'm just going to use this thing."

Matt Billman became a early user for a year, and then a year later Netlify got funding and they joined Heavybit in their seed round, and they reached out to me and said "You should work here."

And I said, "OK." Because I was looking for something new, I wanted to grow.

I joined as a front end engineer, and then I also wrote a ton of blog posts on React.

There was a direct correlation between the blog posts I wrote and the conference talks that I did , and user growth.

They were like, "You should do this full time."And I said, "No."

Then six months later they hired their second front end person, and they were like "You should do this full time."

I was like, "OK. Let me try this out." So, that's how I got into the developer relations as an advocate.

I did that full time for a year at Netlify and then got hired by GitHub and that's where I'm at today.

Patrick: That's awesome. You're pretty prolific when it comes to podcasting and streaming and conference talks.

Talk to me about your theory of media as it relates to reaching out and educating developers?

Brian: It's funny that you say "Theory," a lot of times I just do stuff that I really love.

Like we were chatting offline, I've been listening to podcasts since I had a iPod. 2004 is when I got my first one, so I've just been very familiar with the space and I always wanted to have my own podcast.

The website I actually deployed to Netlify was a podcast site, and I was just cranking through on a weekly podcast talking about this developing story, which is what the podcast is literally called.

I will pick that up again. I did an episode a couple months ago and I have not picked it up since.

But basically I just like doing stuff that I like listening to . If I like going to conferences, I want to be on stage too. Let me figure out how that works.

My very first conference talk was probably months before I joined Netlify and it was really just me--

Sorry, I had an idea to build an app on iOS, an while I was doing that React native came out.

So then I had the context of being able to compare React native and iOS or Swift at that time, because Swift also came out while I was still trying to build and iOS app.

I had a very interesting transition, not even transition, because I'm not an iOS developer. But experience in trying to learn how to do iOS while all this stuff was coming out.

So I gave a talk, my very first conference talk was comparing the three technologies.

I tried to bring a story to the stuff I talk about. I'm a big fan of learning and walking away from stuff. But I also realized that everything I say on stage you can just learn from a blog post, there's no reason to come to my talk. So if that's the case, you should at least be entertained.

I try to being bring some entertainment to it. I don't play-- I do play ukulele, but I don't bring it onstage because I forget how to form the chords.

But anyway, I do bring an interesting story.

One of my co-workers, past coworkers, they had mentioned that every time they go to one of my talks they learn something new that's not coding related, and that's usually my goal.

If I can get you to close the laptop with the first two minutes or get you to stop multitasking while listening to me on a podcast, then I've succeeded.

And if I'm not doing that, then what's the point of me doing it?

Patrick: It seems like that strategy is working.

I actually pinged our community and our Orbit Slack channel, I asked some folks what they would be interested to hear from you on, and your Beyonce talk at 2018 DevRel Con rose to the top.

More generally around, how you approach making your talks accessible? It sounds like storytelling is a big part of that.

Brian: There's a quote from Stan Lee, who's passed away since. But he was the creator of Marvel Comics, or founder.

The quote goes, "Imagine every issue is someone's first issue."

If someone's never heard of Beyonce I will give you, I'll give you the cliff notes.

I'm not going into all the details, and Girls Tyme, and how they left her dad as a manager and how they transitioned into Destiny's Child, into Beyonce who she is now, and how she's evolved her look and her feel and her content over the past, literally, 15 years.

I will go into all those details, but I'll give you a snippet to make you want to go learn about Beyonce.

That talk in particular was focused on growing developer communities and engaging, and how do you empower developers?

You just approach it the same way Beyonce does, where you have the Beyhive and you elevate people so they feel empowered to go to bat for you whenever somebody tries to drag your name through the mud.

Like, don't mess with Beyonce, because the Beyhives-- They're watching. Always.

Patrick: That's incredible. What would you say is your favorite trick of the trade?

Brian: The trick of the trade, I don't know if I have a certain thing. I tend to have-- If you listen to a couple of my talks you'll probably figure out my format, and I usually--

The context I try to bring, and the same thing in blog posts too, as well, w hich I haven't done a lot in the last year, is I try to jump right in.

I think a lot of times one of the things I really gripe against, I do a lot of cooking.

We're all staying at home and sheltering in place at the moment, and when you read a blog post online the first thing you get is a random story and it takes forever for you to get to the ingredients.

Like, I will give you a story but I'll give you the ingredients upfront.

So I think I'm a fan of doing that because I think I want you to be like, "What am I listening to?"

But also, "You got ten more slides or you've got three more slides before I'm opening up this laptop."

Being very conscious of when I'm going to lose the listener, but also stretch it as long as I can. I gave a talk around GraphQL and trying to compare that to hip hop.

GraphQL, a lot of people know GraphQL as a way for us to manage or consume data and present data for our clients and our front ends.

With GraphQL, you could do this cool thing where you have a GraphQL wrapper.

I spent a couple of talks speaking about rap and hip hop, but one of my more prolific talks for GraphQL is I gave a lighting talk on GraphQL wrappers, but I never actually called out the rap slides on the screen directly.

Every time I mentioned "Wrapper," you saw a rapper, an actual hip hop rapper on the screen.

But I forced the analogy of saying, "Everybody loves rapping, even the kids love rapping. So why not just try rap?" It's definitely prolific, people are using it.

I think my best slide was in my code I actually had Chance the Rapper and I explained Chance the Rapper as a wrapper in my code.

Things like that, it's bringing in my personality, but not overtly. Sometimes I can take it too far.

I did do a thirty slide talk on Serverless functions in the JAMstack about baseball, and I did spend 20 slides talking about baseball.

I might have went over the top on there, but that was for good reason, because I didn't really know much about Serverless functions roughly four years ago.

So, I only had three slides of content. I spent way more time speaking of baseball.

Sometimes you win, sometimes you lose, but I would tell you that a lot of people remember that talk for sure, because I talked about baseball very heavily.

Patrick: What I'm hearing is an intention to craft f rom the way you think about your work and execute the work.

That has been thematic across many of my conversations on Developer Love and beyond.

I'm interested in exploring what may or may not be a tension between, on one hand, the creativity and following one's personal interests with the need on the other side of the coin to measure the impact that the business value, if you will, of these activities.

How do you think about those together, or do you think about them at all? Is it a false dichotomy?

Brian: It's the biggest impact. I don't think about it too much. As a team at GitHub we do have goals, we have OKRs .

Which I highly recommend you should at least plan to plan at the very least.

We have some broader goals of "Let's grow this strategic area, let's present ourselves in this region."

We had those type of goals, but when we start talking about how many people signed up at your talk or how many filled out the survey at the end of it, those are nice to have.

But when that becomes the focus of "I can't leave your meetup until I've actually signed in to some form. That way, some sales person can reach out to me or whatever it is."

Are we losing the purpose of why we're actually throwing this meetup together? I think the goal should be--

People should enjoy being around me enough that they can DM me on Twitter and ask their questions later. I don't need to actually give them the 20 questions at the event. I don't need to give them the 20 questions on stage. I don't need that, actually.

Unless it's for me, my personal growth of the talk I'm giving, I don't really need to give a survey. It's more disengaging.

I try to sneak in things like that as part of my talk. I gave a workshop on GitHub actions and for getting involved in the workshop itself, you use an action to invite yourself to the org.

You open up the ReadMe and it tells you to go to this issue and type in this one command.

You're using a GitHub action to do it, and it's like the shock and awe of "I just used an action for the first time. Congratulations. Also, you're part of the org, so now I can follow up with you and be like--"

I haven't actually done this with that org, it wasn't really the goal.

It was more if we needed to tap into that because at the time we were reverse engineering some of our goals and I think a lot of DevRel would do that.

It's like, "I'm just going to give this conference down in Brazil, but I'll figure out the goals when I get back. So, stay tuned."

There was a bit of that, we knew we wanted to be there but we didn't know what we needed from there, which we figured out eventually. But I like to put the product on the forefront.

I did this a lot at Netlify as well, where we created the "Deploy to Netlify" button.

The very first thing you do when you engage my content is you're aware that there's a repo there.

You're aware the code is available, like "I'm going to go through all the stuff. But by the way, if you want to skip all this, go to the code here and there you can either follow the steps or click the button and you have your own version."

Giving people-- Like, we all learn different ways and we all love touching and test driving stuff like that very differently.

Giving a couple different options, if you can, is always going to do much better.

Not everybody likes podcasts, not everybody likes video.

Everybody who listens to this likes podcasts, but not everybody does YouTube videos or egghead videos or whatever it is.

You've got to come at it from different angles and then play to your strengths.

So, if you're not great on video don't do video. Lean into the blog posts.

There are people who are exceptional writers, but I'm not one of them. But as you can tell I can ramble as long as you'd like.

Patrick: One thing you said was "We knew we needed to be there, but we didn't know what we needed from there."

I think that's an interesting observation about the intuition of people in the front lines of DevRel and developers and community.

Brian: Yeah, some of the things I used to do in my reverse-engineered reporting OKRs is serendipity level.

And I think maybe y'all are figuring this out over at Orbit, but what's the serendipity of--

I was happen to give a talk in Austin about React at the React meetup, and the senior manager for a very large corporation doing the digital marketing is like "We do not want to do WordPress anymore. I like Netlify. Please give me contacts."

I connected them to the head of sales, which is-- I'm not doing sales, I'm just handing over leads if they happen to show up The serendipity level is ten out of ten at that point.

Like, "You went down to Austin, Texas for a small little 75 person meetup. That's huge for most cities. But anyway, you came back with an actual legitimate 'You're going to be funding an entire employee probably if this thing closes.'

I'm not doing sales, but the serendipity level is ten out of ten, so I should probably go to Austin more often.

Nurture that community connection to see who else is in Atlanta, who else is in New York, who else is in India? Because you're the point person for all those connections.'"

Patrick: Yeah, we think a lot about using data and telemetry, less for driving to decision making and more about driving the intuition of the practitioner and allowing that intuition to scale in that capacity.

Brian: I mentioned Serverless functions too, as well. That was another intuition thing that we did not really, when I worked at Netlify--

This is a couple of years ago, no one knew it while it was happening but we knew there was things happening.

So everybody started jumping on this weird-- Google cloud functions had just come out in Alpha and they were not great, but then you had the Serverless framework come out and it was like "This is actually super easy."

There was a thing happening, but not a lot of people were actually really bending the feature or the space, but we jumped on that pretty early.

Now, Netlify functions exist too, as well. Because that was in the works from long ago, and then they just built a thing that just fits perfectly in that situation and community.

I think if you're a front end tool or a developer tool and you see all this JavaScript frameworks and stuff like that, and libraries, there's a very clear pattern of React developers accepting the fact that frameworks are cool now.

You have the Next.js, which is almost batteries included. But then you have Blitz.js and you have Redwood.js, they're all building batteries included React frameworks.

If you want to double down and , enter a space, that would be something I'd be paying attention to if I was a Netlify or another company in that space.

I'm not today, because GitHub happens to-- We're selling tickets to the code wars and people are just creating accounts and new repos.

So it's a nice position to be in as we see all this shifting and change.

Patrick: One thing that I enjoy about your perspective is that you've got a, diverse interests-- pop culture, code-- the cutting edge of both of those fields.

You've got a lot of interests, including the ukulele. That's a new one for me, I didn't know that was in there.

So thinking about everything you're working on right now, I'm interested to hear what are you really excited about lately?

Brian: I'm actually really, truly excited about open source. We've come a long way since I believe Richard Solomon the whole life free, everything free Floss free as in Libre open source software.

That still exists, and we should go ahead and double down on the Linux servers and stuff like that and distros, and that sounds like a knock but I'm actually trying to transition to what I'm actually excited about.

But we're seeing a transition in funding in open source, like you have Open Collective and you have GitHub sponsors.

You've got people leveraging Patreon, so there's definitely eyes looking at open source.

Also, there's a VC firm, a couple of them, that are specifically geared at making open source libraries into actual products, which is also intriguing.

But also I find that one problem that I want to solve personally, this is outside of GitHub, is the onboarding experience for open source.

That's a problem that I'm really interested in solving, because I think even at times like today, we have so much unknowns.

Like, if we're going to have police departments in the future and who is actually gatekeeping society, and who is gatekeeping open source.

That's the question I have been asking myself for the past couple of years, which is--

"Why is it that certain people are just prolific at open source and know what they're doing, they can go from project to project and build company after company on the back of open source and just know basically what they're doing."

How come so many other people aren't taking advantage of that?

I think there's a barrier of entry, and I've been using this term called "Unintentional gatekeeping," where if I happen to work on a team with the guy who started Node.js or started some other framework or a library, I have so much more information and an advantage because I happen to be in the right room at the right time.

Then when your new developers in Wichita, Kansas coming out of an online boot camp, their access and to be able to have information and know that "If I just learned React five years ago I'd be a senior developer today. Who would have thought?"

I think a lot of people just don't have that information or have that knowledge and don't know where to find it, so I am personally passionate around just decentralizing open source information.

Which just sounds silly, because open source is open source, but I think there are a few people who are really succeeding on the backs of open source and there are lot more people who are just like, "I don't know. I just NPM installed this thing and magic happened, and now I just fix bugs for a living."

I think if there was an opportunity for anyone to actually give access to people for open source, I think it's today and I would love to see more companies and more bootcamps actually leveraging open source knowledge and how to contribute and how to level the skill.

Whether for free or for paid, because we do have full time open source contributors and maintainers, but I think if, as I mentioned React--

If you happen to know React five years ago then today you are a senior staff engineer because you just know way more than anybody else starting.

Patrick: So what's your view on unintentional gatekeeping? What do we do about that?

Brian: Gearing it more to what I'm doing at GitHub right now, I've been doing this thing called Open Source Friday.

For whatever reason, a ton of DevRel people are on Twitch right now, if you haven't noticed.

So I'm on Twitch, I just happen to like watching Twitch videos and saw a bunch of coders on there, and I could do that so I do it.

At first I had no idea what I was doing, I actually started two years ago and was just like "I am going to write code, some people are going to chop me up."

I knew some people at Twitch so they would show up and be like, "Cool. Great job." I was using my gamertag too, as well. Which was MeAteRobot which I chose years ago and it predates BDougie.

No one really knew I was there, I was just goofing off in the afternoons when everybody else was-- My team was on the East Coast, so I was just goofing off.

Two years later, which is literally January of this year, I'm like "There are so many people doing coding on Twitch, I should do this again."

So I started doing it and started live streaming myself doing this thing called MutualFun, which happened to be a name of another project that I forgot about or just stopped working on.

I was like, "I'll just grab this domain since I already have it," and then started doing coding and built a website.

MutualFun.live is the site, built that and then people were just like, "This is cool."

They built a community around literally just live streaming, and then started building this other project called--

Or, it's an open source project called Open Sauced, which is the reason why I'm interested in this onboarding.

But just live streaming is quite an intriguing space to be in right now.

Patrick: Tell us about Open Sauced. Is this your approach to challenging that unintentional gatekeeping that exists in open source right now?

Brian: Yeah, it is. And whether I have all the answers today or whether I have them later, I think I have some answers today.

Basically, to answer your question, the description is the path to your next open source contribution.

Whether you're skilled or whether you're just getting started, it's an opportunity for you to log in with your GitHub account, and all the back end is actually pretty JAMstack.

All the back end is a GitHub repo, so when you log in for the first time and they ask you to open up a repo or create a repo, it's called Open Sauce goals.

There you can track different projects, so very much like the CRM for open source.

I'm not sure how much of a CRM it is, but it will be more if I like it, hopefully in August when we have some schedules built in.

But essentially you want to track React. You want to see what the open issues are. This is all stuff you can already do in GitHub, but unless you know what you don't know, you don't know what you know.

And I know that's a lot of words using the same words over and over again, but my issue with contributing to open source is that I walk in there and someone told me that contributing MD is a first place to look, or the ReadMe.

I look at the ReadMe, there's all these screenshots and code snippets, I don't know what I'm looking at.

I've used React before, but I don't know what this parsing thing is or how JSX works.

So, I go into contributing MD and it's like, "Sign this CLA." "OK."

Signed it, and then "Grab an issue." "OK, which one?" "Grab the good first issue."

"This one's already taken." "Grab the next one." "This one's already taken." Grab the next one." "It's already taken."

React being a popular project, it's hard to understand what to do.

The irony is that if I were to join Facebook as an engineer, the first thing they do is give me two weeks of training. It's called the Facebook bootcamp.

They tell you exactly what to do, they give you the bugs to work on and they give you--

Depending on how early you are in your career you'll get a tour through the company on different engineering teams.

"Do you like this team? Do you like this team?"

You actually get onboarded as part of the experience, but with open source we're like, "Contributing MD is right there, grab an issue and open a PR. Let me know if you have any questions."

"OK. Let me just go into the Slack channel. It's not Slack, it's Discord."

You continue to fight hoops to jump through so that when you talk about now we're talking about diversity in an open source, how hard is it for someone who's branding engineer--

Which we know diversity is a thing that's not been around for a very long time, it's been around, but not in not in actual open source or in tech. Or specifically, engineering.

Now we're onboarding all these new engineers and we're telling them "This shits bugs, you'll do great."

And then they get stagnant and they don't actually level up in their career and they don't know why.

All the other people are just doing open source on the weekends or at work, or figuring out how to balance it.

If you're going to have to spend a full two weeks to just figure out how to contribute to the React project, you're not going to do it . What's the value in that?

I already worked hard just to get here, I changed my career from working at Wendy's to eventually getting my stable marketing job that ships a bit of React code and maybe a little bit of a PHP.

I don't have the time and the bandwidth to now go struggle through trying to figure out how React works, so what I'm getting at is Open Sauced is going to be the democratization of open source.

It's going to provide a strong onboarding component, so when everybody in a repo will have a YAML file that you can share in your project, that just gives you all the check boxes of what to do the first time you show up in the project.

If it's the contributing MD or if it's a secret Discord channel that's not linked into the repo, that should be listed right there.

It's as simple as just filling out the YAML, pointing people to the next steps and then everybody's good.

There's another component that we literally just launched this week for my project that I saw Express.js do it as well, which is the idea of a triage role.

GitHub has its whole role in an org called Triage, where anybody who has this role can label issues.

They can mark things as completed, they could mark things for ready to work on or good first issue.

That's something that a maintainer has to wake up every morning and look through 100 issues and try to figure out, "Are these ready to be worked on? Are these pie in the sky ideas, or are these things that we have to punt when we fix these vulnerabilities?"

That could be handed off to someone that literally just came out of bootcamp.

There's no reason that a maintainer has to take up that work, so now we're talking about leveling an open source.

Are you a maintainer, are you a contributor or are you a triager or a reviewer?

Reviewing pull requests is another thing that could be easily handed to anybody who wants to do it, but we don't think of open source in a corporation or a company, we think of it as a couple of guys doing cool things. Sometimes shipping code on the weekends or doing late nighters and then getting burnt out, and then wondering why we got burnt out from open source.

If we could spread the bandwidth by actually putting out our wings and bringing other people in the fold, there is a lot of opportunity and that's what I'm really striving to do, is when I talk to Black Girls Code and I talked to Hidden Genius Project which are all--

They have organization chapters here in Oakland and I talk about how open source is the best thing that ever happened to me.

They're like, "How do I get started?" I was like, "Look at this website and watch these couple of videos and then good luck, or look at your Package.json and you'll figure it out."

We should be a little bit more than that, rather than point people to long form blog posts, let's just give the checkboxes a check, and then hopefully they'll be able to unblock themselves.

But if they can't, end that onboarding checklist and join the Discord. Join the synchronous communication, because that's a secret little channel that a lot of people don't take advantage of.

I think we're inundated right now with Slack, where we have Slack channels for everything. If there's a possibility for you to take that to a now GitHub discussion or Discourse forum or somewhere else, that should also be listed in the ReadMe.

Which I found lots of projects that have these extra channels in places that they don't label them anywhere, because for whatever reason, they don't know how to manage the community.

So why not get an open source maintainer to be a community manager?

They don't ship code, but they're contributing. They're part of the org, they have the badge on their profile.

Patrick: I'm blown away. This is incredible.

Brian: I just exploded a lot of thought I've had, I've actually been pitching a lot of people on this just trying to get people on board.

I've done a couple of tweets and talked to a lot of people internally as well, just at GitHub, just to spread awareness around how like "We have a giant blind spot, we could be onboarding tons of people and make open source more sustainable, make people more engaged."

GitHub definitely wants you to use GitHub.com, so why not just build something to get people just to show up and check up on issues? Answer some questions?

I'm trying to organize my thoughts, we have a long road to 1.0, which will hopefully be in August.

At that point we'll have some cool things that we will announce, and all open source nothing is hidden.

I've got a whole discussion board and a Discord if anybody wants to jump in and provide feedback.

Patrick: Are you looking for contributors currently?

Brian: I am, actually. The triage role new this week, I will be doing some tweets.

I noticed that we have one female contributor at the seventeen contributors, we're doing great on POC.

I think it's natural because I happen to be a black male, I tend to attract other black males who are interested in contributing.

It's another eye-opening thing that I didn't realize until I became a maintainer or something, but we talk about females contributing or just to say that non-binary or female programmers, we are very much lacking in that realm.

I want to make sure that as I grow a project that this is not the dudebro center of hanging out and getting things done.

I want to make sure that everybody has an opportunity to level up, like I did a call out this week-- Like, we've gone through a lot of stuff.

Last week was a very hard week for me personally, being a black male in the US, and I woke up on a Saturday like, "What can I do?"

I'm not a protester. I do have a lot of-- A voice to share, but I'm not really into debating and stuff like that.

What can I do to actually engage the community I come from?

So I sent out a tweet saying, "If you're a black open source contributor or maintainer, give me your profile link. I will sponsor you for GitHub sponsors."

I was not expecting it to blow up the way it did, but it ended up blowing up.

We had a lot of notable people in open source who were just like, "This is really cool. We would love to participate, and we're going to double down."

The deal was first two people to respond, they get $50 dollars a month for the next year from me.

That's what I think, looking at my bank account that's what I could do. I'm happy to do it, but I sponsored everybody else and it just happened to not be $50 bucks a month.

I think everybody else matched me on my efforts, whether it was $50 or $5 or $1.

We had one individual who is a female POC, she identifies that way, and last time I looked she was at 30 sponsors going from less than 10.

Not even, because I was the third sponsor and I sponsored her a couple of weeks ago.

Just because she was on my profile, other people sponsored her.

So imagine me lending my privilege, which is working at GitHub and having access to a nice salary, now that privilege of me just sponsoring somebody has now brought awareness to other people of the existence of this one female engineer.

We do know, as a fact, female engineers are hard to come by when it comes to open source.

You could name them, but you might be scratching your head of "Who notable is doing open source today in this area?"

It's a conversation I have all the time, just trying to spread awareness to other people besides the same 10 people we see all the time.

Patrick: It's really inspiring because your work seems to operate on two levels. One, which you just described, is this interpersonal dynamic of lifting others up.

Then the work around the open source onboarding, and Open Sauced reminds me a little bit of what Ibram Kennedy talks about and how to be an anti-racist around policy as really the driver of racism, more so than the individual interactions.

It's almost as if through lowering the barrier of entry to onboarding for open source, it's a policy-level change.

Brian: Policy might be it. Going back to the original term, and I keep hammering on, which is unintentional gatekeeping. It's no one's fault.

Maybe it is some people's fault, but I'm not blaming anybody for "I look at this open source team and all I see is white dudes on their contributor page."

They happened to attract like- minded individuals, they might all be from the same college, they all hang out in the same circles. That's OK.

But I think one of the things that we can do is look at our Twitter followers, look at the people that we were following and sponsoring on GitHub or open collective or Patreon, and if everybody looks like us on that list then perhaps we need to start expanding out into other realms to meet new people.

I get that some people feel comfortable and hang out in certain groups and stuff like that. Myself, I feel comfortable in certain groups as well.

But I always try to challenge myself to say "I might not know much about what it's like to be non-binary and living in America or living in whatever. It's my duty, especially to the community that I'm leading and trying to grow, to actually make friends with people who are not like me and have a different walk of life and are growing in a different way and having different struggles."

Because if I don't know what their struggles are, I can go years, days, whatever, not understanding how to solve those problems or even be aware of them."

I don't have to solve all the problems, but being aware of it speaks volumes, because then your decision making of "I'm on the speaker review panel of big conference XYZ, and I'm looking through the list and t his name sounds female, this name sounds male. I want to go with the female."

But it turns out, I still ended up hiring 100% male. Or it turns out that I didn't know anything about names in the Middle East or Eastern Europe, so I made a judgment call based on my personal experience and how many people I've met from Eastern Europe.

Perhaps I need to actually bring more people from Eastern Europe or more people who know more than I do to the review panel.

That goes even if you happen to, like myself, who comes from a diverse background.

I'm not omitted from the conversation because I happen to already be a diverse voice, I personally always am looking backwards and trying to see "OK, who is trying to do what I did two years ago? I should either be writing the blog post or getting in that meetup or taking time to actually have those conversations."

I also realize and I respect that not everybody can be out there in the open and speaking and engaging community.

If it's not your job, it's not your job, it's fine. But I think if it's not for you, we should all make room for people who are doing good things and positive influence in our community.

So that's where I stand, and I'm happy to hear otherwise too, as well, if anybody wants to hit me up on Twitter.

Patrick: I appreciate your voice in all of these areas. I'm wondering, you shared a lot of really amazing vignettes today.

I'm wondering, what would you say has been your proudest moment as a developer advocate or someone working in this space?

Brian: That's a good question. I know I should have been prepared for this, but honestly, I tend to have--

Like, my proudest moments, I just recently came off of speaking at GitHub satellite and I got to really showcase GitHub satellite.

The online version was probably bigger than we probably could have imagined, so we're talking 4,000 plus at the time I was speaking.

I was the last slot, so I was the closer for the event.

But being able to take all my talents and everything I learned even recently with the streaming, because it was an online event, and actually showcase my skill set.

I gave a talk on this literally just talking through the features of GitHub that we shipped in the last year, and it was heavily toned towards Beyonce.

Which I have naturally been doing for the past two years and I am happy to do so and continue to do that.

I was able to just showcase me personally as a person of color who values different musics than other people or just different interests, and I was able to showcase that without being less of myself.

I think if I can continue to do that and just that GitHub satellite or in the podcast that I show up and encourage other people to be able to bring their full voice to the table, I will continue to be proud every time I have an opportunity to do that.

The most recent would be GitHub satellite, but I think I have countless times where I've just been able to do something like that and then have a bunch of DMs from people asking me and telling me "That was super inspirational. I'm super pleased to see you on stage and sharing your interests and helping your personality shine through the boringness of scheduled reminders and pull requests."

That's an awesome feature and you should use it, but I won't tell you how to use it and how Beyonce would use it to command the Beyhive too, as well.

Patrick: I love it. Brian, this has been awesome so far. One more question that we ask everyone that comes on the show, this podcast is called Developer Love, so I'm wondering what's one thing that you're loving right now?

Brian: Honestly, One thing I am loving right now is actually being at home.

As a developer relations or developer advocate we do a lot of traveling, and I've actually spent the last three months rediscovering the personality of my daughter who will be two next month.

It's been nice to be flexible enough to be able to transition to only being at home, but still being very impactful in the job I do.

I'm actually contemplating when things open up, travel opens up. "Do I really need to be on the road once a month or can I do it once a quarter and still host once a week live streaming? Providing very impactful content in growing communities from the comfort of my home?"

I think the answer is "Yes." What that looks like after the fact I think I'm still figuring it out, but I'm loving being at home and loving teaching my son how to ride a bike.

That was something that we could do off and on, but I had to get on a plane.

"Sorry, we're going to be a little inconsistent next month." That was an awesome thing to be able to do as well.

Patrick: Love it. Brian, thank you so much for your perspective on everything from open source to ukulele to Beyonce. A really informative and inspiring chat today.

If people want to learn more about what you're working on professionally, personally or otherwise, where should they look to connect with you online?

Brian: The easiest place is probably Twitter. I tend to make that the central point of failure, but also the command center for my life.

Whether it's my sourdough bread that I occasionally will tweet out-- I think it's sweeping over in the, in Sourdough in the last--

I've been doing sourdough before it was cool, but for some reason Covid-19 has made it popular.

I don't tweet a lot of photos of bread, but with that being said a lot of the code I write and a lot of the stuff I do is all linked in my description.

Also check out my GitHub, we've been doing some really cool stuff on GitHub.

I'm actually going to update my profile with some of the new features, so definitely check out BDougie on GitHub and @BDougieYo on Twitter.

Patrick: Right on. Brian, thank you so much. It's been a real pleasure.

Brian: Likewise.