EPISODE 1575

[INTRODUCTION]

[00:00:00] ANNOUNCER: The open source coding philosophy has enormous appeal to many software engineers and with good reason. Open source libraries, applications, and operating systems are now essential to the overall technology ecosystem, and the number of open source projects is only increasing. But many developers don't know how to get involved in open source, or they may have even faced resistance when trying to make a pull request to their favorite open source codebase. 

OpenSauced is a platform to help developers get involved in open source development. While the number of GitHub stars on a project is often seen as a metric of success for a codebase, OpenSauced focuses on the number of new contributors on a project. This number serves as a signal to help drive the platform's recommendation system which pairs its users with open source projects in need of developers. 

Brian Douglas is a former Developer Experience Lead at Netlify, and he was the Director of Developer Advocacy at GitHub. He is also the Founder and CEO of OpenSauced, and he is our guest in this episode. 

[INTERVIEW]

[00:01:12] JG: Hello and welcome to Software Engineering Daily. I'm Josh Goldberg, and I'm real excited to introduce Brian Douglas. Brian, do you want to tell everyone about yourself?

[00:01:19] BD: Hey. I’m Brian Douglas. I go by bdougie on the Internet. I am the Chief Sauce Officer at OpenSauced. Yes, I’m happy to be here. I’m based in Oakland, California. 

[00:01:27] JG: Can you tell us a little bit about what OpenSauced is in the first place?

[00:01:31] BD: Yes. So OpenSauced is – the easiest way, it's like three words; insights for open source projects. Actually, that has four words. On GitHub, there's an insights tab, and what we're trying to do is provide a better experience to get insights into the projects that you maintain. But also, the projects you might want to contribute to. It started years ago. In 2020, I was building a little side project where I was maintaining a couple different things, but also contributing in other places, and I need a place to track my contributions. So, so I created like this little CRM tool called OpenSauced at the time. 

But I found out that a lot of folks wanted to also participate in open source and tried to solve the problem with the whole good first issues, finding places to contribute. But what I found was an opportunity for folks who – companies or maintainers of projects, to also set their project up for success. If they want to take contribution, they can draw that signal outside of like Hacktoberfest, just like day-to-day operations. Raise flag. Be recommended for contributions. 

[00:02:24] JG: Well, that sounds great. How did you first get into open source, though, back in the day?

[00:02:28] BD: Yes. So I learned how to code through I guess what eventually became a boot camp called Bloc. It was acquired by Thinkful and then eventually by Chegg. Back in 2013, I started coding for real. I'd always been like a really good copy and paster and could like copy stuff off Stack Exchange and Stack Overflow and SourceForge. And so, I learned how to code. Build Ruby on Rails apps. I needed to solve a problem using WebSockets and Node, and found a solution on GitHub. 

I cloned the repo. It worked for me sort of. I needed to like – I couldn't run it locally, so I ended up reaching out to the maintainer. By just looking at their GitHub profile, I had their email right there. I emailed them. They walked me through the harmony flag in io.js. It was like a weird split in the node community at that time. And kind of like walked me through exactly what was happening in the community. I learned all about that and was able to solve my problem. Since then, I'd always been reaching out to maintainers and opening up issues and contributing. Yes, because it's like easy way to get mentorship pretty quickly. 

[00:03:27] JG: That's great. In a sense, one could consider that experience lucky because sometimes open source can be a little less friendly and welcoming than what you've just described. Have you ever had instances where it has been less than stellar?

[00:03:38] BD: Oh, yes, 100%. I always empathize. Because I do know on the other side the maintainer could be overworked, or could be a side project, or a thing they, honestly, frankly, might not care about anymore. We put stuff out in the world, move on. We have new jobs. We have new opportunities. 

For that reason, like I remember reaching out to a popular build tool in the JavaScript ecosystem and to make a few changes on their doc site. And was met with like basically 100%, “No, we're not doing this. Close issue.” 

I think for a long time, I internalized that. But when I met that actual maintainer years later, totally understood where they were coming from and where they were. Now, I’m actually involved with another tool that help sponsorship for maintainers. So I think that healing comes with time. But I think a lot of folks, a lot – there’s a saying with Stan Lee. Imagine everyone's issue is the first issue. I think imagine someone's interaction with an open source project could be the first ever interaction open source in general. 

I approach anybody's issues, or anybody's comments, or anybody's PR as, “Oh, this could be the first time." Because I experienced that multiple times where I wasn't met with like good mentorship or even interest. I don't think – I don't hold it against any maintainer or any other project. I just think timing is also a valid variable as well. 

[00:04:54] JG: That’s a very empathetic way of looking at open source. I've actually picked up a tip from you in particular that I really like, which was for a good first issue, don't just post the issue and say what needs to be done. You once gave me the good advice of also include some sort of getting started guide of this is where you might want to look in code or this is how you get stuff set up locally. So, thank you for that. 

[00:05:14] BD: Yes. I mean good first issues. It’s a whole meme, and it's a world. Actually, funny enough, I was at GitHub and asked the question of like where the good first issues come from. It was an internal GitHub thing where they applied that label. They're seeing the community kind of work around this first times only or – Kent C. Dodds and Scott Hanselman had a whole first- timers-only site in like identifying places for first timers to make contributions. 

The good first issues is evolution of [00:05:41], where it's not specifically just first-timers. But it's like if you wanted to have an onboarding experience, an on-ramp for somebody to introduce themselves into your project, that's a good first issue. So the introduction is met with, "Wow, this is actually kind of hard. You want me to do what with the compiler?"

That needs a little bit of like some handholding or some explanation or like link to a blog post, link to the lines that you think someone could triage into or at least the file, and that sets everyone else for success. Otherwise, don't apply the label, and it’s making a regular issue, and someone else might be able to triage that and make it a good first issue. 

[00:06:15] JG: Sure. There's an argument to be made also that not everything should be a good first issue that you want to have good second issues, third, and so on for maintainers. Yes? 

[00:06:23] BD: Yes, 100%. If you're only doing good first issues and you go for project-to-project, looking for good first issues, you're never growing. I think there was a quote from – it was Mike Tyson, but it was actually misquoted to Mike Tyson. It was actually Muhammad Ali who said it first. He doesn't count sit-ups until it starts hurting. I think if you're doing like 100 sit-ups, 150, it doesn't actually start working until you start feeling your muscles working. I think with good first issue, it's the same thing. 

If you're only doing good first issues because that's the check the box to get the green square to do whatever, you're not really learning. You're not really advancing your experience. You're just doing it for the sake of doing something. 

[00:06:59] JG: That's a really good quote. I really like that. I’m currently processing that. 

[00:07:03] BD: Yes. I only heard it, well, in the last couple months. Yes. That's like applying that to just like my approach to life and also my own personal workouts as well. It’s not about just getting 10 reps in. Maybe just do as many reps as you can and then call it a good workout. 

[00:07:17] JG: Let's switch topic a little bit to DevRel. Because despite talking quite a lot and having done a lot within core software development, you've also done a lot in the space of developer relations. How would you describe what you've done so far in DevRel or similar?

[00:07:31] BD: How would I describe? It’s funny because like it's common question around like DevRel's purpose and its value. And a lot of DevRel teams are being laid off. My introduction to DevRel was very similar to like me just doing open source. I just kind of did it because I needed to solve a problem. Solve my way into just like Node or WebSocket community and like to sort of swim. I eventually learned how to swim and then start swimming in there. 

DevRel came out of a need. I worked at a company called Netlify as employee three pretty early. And I worked on their dashboard as an engineer, but I was learning React pretty early. 2016 is when I started doing React professionally. I did it a couple years prior. And I just love writing blogposts about the React that I was learning and the stuff that we were solving within a production-grade dashboard. 

That correlated to user growth. Every time I wrote a blog post or got on stage. Because one of my goals back in 2016 was to get on stage, talk at a conference, there was user growth. The founders actually asked me to switch from full-time engineering to a developer experience, developer relations role as an advocate. I actually told them no. Then six months later, they sort of agreed to like give me like a sort of like half-and-half. It was like 80-20. Probably 20%, I'd write code. 80% I would go plan a talk in conference and do some traveling. That was my introduction to developer relations. 

From like the point where I went full-time, six months later, I ended up getting a job offer to join GitHub. I took that role and spent about five years working at GitHub, which like arguably is like one of the best developer tools companies out there. We never had a challenge of like awareness. At the time I was there, I never had a challenge of like gaining awareness. But it was more about engaging community and like continuing to provide value within the broader developer ecosystem. 

I did a lot of cool things like help launch the Stars at github.com or the Stars Program. I did like the first GitHub Actions Hackathon. I also helped get adoption for GitHub Actions in the JavaScript ecosystem and as well as Rust. Yes, I did a lot of other things at every new feature that came out up until Copilot. I was involved in some sort of go-to market activity or engaging community in certain ways, where I found that DevRel really works, especially at GitHub. 

GitHub's at a level where everything they do succeeds. Like, "succeeds". But with two and a half million Twitter followers or X followers and tons of other folks on their social platforms, when you talk about something from GitHub, people listen. We started focusing on other things, which is not likes and a bunch of other stuff, like stars and hearts, but instead looked at engagement. Like how often does the community interact with our content? 

I was able to sort of like polish a proper develop relation strategy that actually pretty much scales anywhere else and like removes itself away from the ra-ra-ra. Get a bunch of stars, likes, and et cetera. I super appreciated that experience at GitHub. 

[00:10:12] JG: Fascinating. So there's a significant difference you'd say between the strategy of employee number three, stage company, and say a GitHub stage company?

[00:10:20] BD: Oh. Yes, definitely, for sure. Like GitHub's already hit their product market fit. They hit a stride in like having massive adoption across ecosystem for being the collaboration tool for developers. Now, definitely, other tools that no one's ever heard of. Or there's other tools that people do use. But GitHub just had the hearts and minds. And the way they did it was the bottom-up strategy. Very similar to what I did at Netlify. 

Former co-workers of mine worked at GitHub. So, we modeled the same sort of strategy, bottom-up, which is like get the hearts, and minds and love from developers. Eventually, as those developers move into management or move into being a director or a founder, they already know what they're going to use, which is going to be your product. It's less about selling and more about like solving a pain point in the grand scheme of things. 

I think a lot of approaches for DevRel teams is they try solving the problem incorrectly, which is grow a huge Slack community. If you have 5,000 people in your Slack, that's great. But like what are you doing with that? That’s a lot of overhead and a lot of interaction. Your day-to-day, if your communication is in Slack, that's great. But how are you really growing community when everyone just sort of waits for you to come and wake up at 9am to then respond to their massive amount of requests and conversations? 

Really just taking a step back. Kind of understanding like where impact can be made. I’d probably go to way more detail about my DevRel strategy. but I don't know where the conversation's going. But happy to take a follow-up question. 

[00:11:41] JG: Sure. I do want to hone in a little bit on how you're phrasing the roles and responsibilities here. A lot of folks in DevRel use nice terminologies such as we're trying to help users. We're trying to explain what the platform is. I'm detecting a little bit more of a metrics skew in how you describe things of having more of an impact. Is there a particular way that you look at measuring impact for DevRel or even justifying the existence of the team role department?

[00:12:05] BD: Yes. I can start with like the way we measure impact even at GitHub was less about, again, how many people showed up at your live stream or how many downloads listened to this podcast? It was more about how many people commented or replied, or how many people forked the project and built something that was unique to them in their situation. As we were measuring, we're measuring engagement really. It’s the easiest way. 

You looked at LinkedIn or you looked at like impressions to actual clicks in conversation, that's convergence to the engagement that we're always aiming for, which on a YouTube, at GitHub, like 2%, which is pretty low in most standards of YouTube. But 2% for a developer-focused company is pretty high. Because the majority of the stuff that's out there, it's usually low engagement. You might get 100 views on a conference talk. It's less about how many views are on a conference talk, but more what's the engagement. Engagement drives views. As long as you're doing things that will help engage. 

The other things that we – I use this saying all the time internally at GitHub, which is like be in the right place at the right time all the time. It was the relationship to the network that you would build. I used to do this thing called Open Source Friday, which previously is like run by Rizel Scarlett and then now is run by Andrea Griffiths, I believe. It might be picking up. Rizel has moved over to another company after I left. 

But what I'm getting at is the goal for Open Source Friday was never about how many people showed up. It was who the person that we were sitting next to in their community. When I had that conversation with open source maintainers and provide a platform for them, they're bringing the community along for the ride to see this conversation, to have a conversation with me or whichever, whoever the host was. 

And then, at that point, that's a relationship that we can establish and say, “Okay. Well, we have GitHub Universe. Who should we have speak at GitHub Universe?" And every year, I had 52 people because I did that thing every week. Fifty-two people that I could pitch for doing conference talks at GitHub Universe. 

Then, when you look at that, okay, 52 people to conference talks. These conference talks happen. What happens after the conference talk? Well, we're going to launch things like GitHub Copilot. Who do you reach out to make sure people can like leverage this thing? It works in their community. That we've covered the basis. Well, I've got 52 people that I had to do conference talks. They were on my stream. Why don't we just reach out to these folks and give them a quick dual demo? 

That relationship consistently progresses, but a lot of times as like a DevRel, which we should be identifying relationships and building relationships. A lot of times, it's like transactional. You have the conversation and you never talk to them ever again. You get a bunch of likes. You're super happy about that and just like continue to move on. 

I think we're seeing a trend of that not working, eventually. We're seeing a lot of teams being dismantled. Seeing a lot of companies questioning if they need a DevRel person. We're seeing a lot of teams actually being constrained. At GitHub, for the first couple years, we're two people. Two people in the DevRel team. 

The way we would do that is that we could scale ourselves through other engineers to go and convince them to go speak instead of us. But we'd also scale through other communities as well. I think that we probably need way more of that than a bunch of DevRel influencers. 

[0:15:01] JG: There's a lot of good soft benefits you've mentioned here such as building those relationships, good sourcing for the keynotes, the conferences. Have you seen good ways to measure the positive impact on the product itself such as bug finding, review feedback, and so on?

[00:15:16] BD: Yes. It's I think – and this is something that also we had spent a lot of time with with the GitHub discussions team at GitHub when you can drive engagement where you have some champions within your community. I always called myself the party planner. I didn't want to be the person always on stage. I’m one of the people person who I could also find other people to talk to and connect with and network. 

So when someone asked me, “Hey, I've got a problem in the .NET ecosystem with GitHub Actions. How do I solve this?” I’m like, “Oh, you know what? I've got someone at GitHub you can talk to. Why don't you open a GitHub discussion, propose your question there in public, and then I'll find the people to go respond to you.” But if I took that answer into email, and I did all the sort of like orchestration, or I answered the question directly, that person benefits, but no one else does. 

So the value that I was always trying to provide is like can you ask this in the open? Can you go produce in public? Can we get added DMs? So that way, someone else can benefit from this this resolution, and the benefit there is that I never had to answer the question again. Because I already had a whole list of solutions to solve the problem. 

I'm a big fan of reusing content as well. So like I don't just write a blog post for the sake of writing a blog post. It's a script for my future video. The video is my future talk at a conference. The conference in video and blog post is a future workshop that I give, eventually, if I get to that level. 

So every time someone DM me, and I got them to ask a question about GitHub Actions, I would then take that. And what I did is I did 28 days of GitHub Actions back in 2021 on Devpost. Every day, I would just do an answer that I already answered as a blog post. I’ve limited myself to 500 words. Because 500 words is very obtainable to do every day. It was just like a ritual of me just waking up, doing the question. And then, at night, I would record a video of that same question that I answered. 

Usually, like Thursday, Fridays, I batch a bunch of videos. So, I'd have a bunch of videos for the next week. But on my current YouTube channel, I've got 28 days. 28 tips for GitHub Actions at Devpost. And what that did, as far as like impact of the product itself and me forward facing, is we had a bunch of intro action interest. And we kept getting more and more intro content. but what I needed to do is build a base layer to then all the intro contents done. Now we can start looking at more advanced content. 

And the push was always reaching out the folks I was sitting next to. The Vue, the JavaScript, the React communities and asked them, "Can we do actions 201?" I did all the 101 stuff out of the way. Let's do 201, 301-type content. Because all the beginner stuff is done. 

I end up like moving into like eventually going to write a book with O'Reilly. Sorry. It wasn't O'Reilly. It was Manning. But I ended up bowing out of it because of this bandwidth. But the goal was ultimately to create a book in a series with all the content I built for the intro to then walk away and like stop doing intro stuff. And then move over to like the more advanced things. But I found that really quickly I don't have the tenacity to build an entire – I can do a course. Writing a book is like a little bit outside of my scope and skill set.

[0:18:11] JG: Writing a book is a lot of work. Take it from me. But speaking both on the video production aspect and the longer form, say, book production aspect, things move pretty quickly. GitHub actions has been evolving since it was released. Do you find that there's a certain cost associated with having material already out in the open for multiple years? 

[0:18:28] BD: No. Because for the most part, the intro and the beginner content doesn't really change. And we were already two years into the feature. The majority, it's still relevant and valid. And what I was really focused on is like for work phone dispatch or repository dispatch, like able to call an action on-demand within your repository or call an action from a webhook somewhere else. Those are two things that were constantly my solutions to so many problems for everyone I was reaching out to me. That we needed to like talk about this thing. Because, unfortunately, it was just named weird. People didn't really know what a repository dispatch was. 

I had to explain repository dispatch. And that's the structure that still exists today. But now there's like a central place that people continue to hit my YouTube, hit my blog post, hit the documentation that we expanded based on that two other forms of content to then, "Okay. You can call webhooks into GitHub Actions. This is how you do it." 

Security, same deal. Permission-based actions. Stuff that was like a little more dense, but still intro, that had constantly people had concerns around security in GitHub Action. We had this basically solve the problem. We already had the documentation, but no one's reading it. How do we get people to the documentation? 

And as long as they get to the documentation, that's Evergreen. And a lot of my call to action in every video was go read the docs. Because if the video is out of date before at the intro or in the ending, you go to the docs anyway. And the video itself is only usually one to two minutes long. Get in and get out. So that way, it's trivial for me to go do another voiceover or re-record the demo and do like a part two, or unabridged, or updated. 

But I don't work at GitHub anymore. And I'm not as active in day-to-day coding. I probably won't go and update those videos. But it's up for anybody who wants to replace me. You can create part two of this or the 2023 version. 

[0:20:11] JG: I'll get right on that. It is remarkable how many parallels there are between what you've described within the DevRel and what we've also seen in the staff software or senior software developer role. Things like cheerleaders. Creating content for videos that in some ways essentially lead to the docs. 

You've decided to describe yourself as DevRel. And I'm curious, where do you see that overlap or why you've chosen one career path in some ways over or along with the other? 

[0:20:37] BD: DevRel versus engineering? 

[0:20:39] JG: Yeah. Or even, what is that difference? What's the difference between a DevRel, versus a staff developer, versus ... 

[0:20:45] BD: Yeah. To be clear, I didn't choose DevRel. I was asked to do DevRel. I said no. And then, eventually was asked again. It was very clear that if I were to accelerate my career, I could go at the time from mid-level to senior engineer. And that was like a viable path. I wasn't progressing as engineer as fast as I could if I just said, "Okay, I'll do DevRel. I'll do community. I'll do engagement." 

My background also previously is I got a finance degree in 2008 at the last recession. Well, currently, we're not in a recession. At me at that. Because the definition, recessions are very clear. But then I couldn't get a job in finance because of that current market down turn. Instead, I went to sales. 

And so, I learned – as an introvert, I learned how to talk on the phone. I learn how to engage prospects. But also, I learned when to stop talking as well before sales actually had 10 months of collections. And that's how I got my first start. And I'd call my list. Because you had like 20 to 30 people to call every day. And ask the question, "Hey, your payment didn't go through the last few months. We've made changes to your card." And I would just stop talking. 

because what I learn is that I do really well in frameworks. My framework was ask the question and stop talking and get the reaction. 60% of the time, your reaction was, "Oh, my card expiration changed." Let me give you a new one." I was like closing collections without being abrasive. Because I'm not an abrasive person. I'm introverted as well. I was just learning how to talk on the phone. That's how I could use a framework to my advantage. 

When I approached engineering or I approached DevRel, I just need a framework. My framework for devil has always been 101, 201, 301, 401. If I can explain the base layer like what is – for TypeScript, what is a type? Or what are generics? Or what is this? If that exists, then I can always move to the next thing. And if anybody asked a question when I'm talking about advanced content and like, "What's a generic?" "Oh, go look at my 101 content." And then you get to move up the stack a bit. 

And it's like, "Oh, let's look at some more complex types." Or let's look at how types improve testing. Don't replace it. You can start really getting to like a weird, like more advanced and then more esoteric. Or even like talk about how types are leveraged in other languages and other frameworks. But like you always have to have a bass layer. Or else you're sort of floating around in space. 

And I think the biggest miss for a lot of early-stage developer tools companies is they – well, it's not the case anymore. But when I was doing DevRel, everyone on the building would be super advanced. Talk to like the architects. Get the architects to buy your enterprise-grade software and like keep every other developer out in the dust. 

But then what you're losing is you don't in longevity, and engagement and community. If you talk to a junior engineer today, a junior engineer is probably to become senior eventually. The senior engineer might become lead staff, might become manager. If you invest in early career developer information and content, you can expand your footprint. 

As all the other engineers that are like basically phasing out, or going to VC, or going into starting their own company, you need to replace them with somebody. If you never talk to the first step, you'll never get to the massive scale or adoption that you really are looking to accomplish.

Yes. In comparison, it's like it doesn't matter. It's just all about frameworks. If you can just walk in, if you like frameworks, use a framework. If you like building your own framework, document your framework. But eventually, everyone should be doing some sort of engagement, or DevRel, or documentation as an engineer.

[0:24:00] JG: The concept of frameworks, or checklists, or similar I think has been very helpful for a lot of people and gets brought up once in a while, especially when it comes to networking, which I also am an introvert and had to adopt some frameworks for. But let's switch back to you for a little bit. Because this is a great segue. You also moved on. You left GitHub. You started a company. You're a Chief Sauce Officer. What happened there? What was the story? What made you make the decision? How's stuff going?

[0:24:25] BD: Yes. I mean, the real story is I joined GitHub six months before their acquisition announcement. Got acquired by Microsoft. Got to where most employees of early-stage startups don't ever get to see their stock turned into real money. It did for me. I stuck around to fully vest. Because that was like life-changing opportunity. Hit my four-year vesting in 2022. 

I joined 2018. 2022 February. Kind of like wanted to stretch my wings. Spread my legs out a bit. I find out what was next. And like it could have been something next at GitHub. It could have been something next outside of GitHub. Ultimately, I took a sabbatical in June of 2022 to explore. If I were to take OpenSauced as a side project, seriously, what would it be? 

We ended up rebuilding what we have now as the Insights Platform app at opensauced.pizza. And it's insights into all of open source. What we found is – and this is like all knowledge that I learned as I was at GitHub. The best things you can do as an engineer at a larger company is look at pain points and problems that you know the company itself won't solve. And that's your opportunity if you wanted to go off and spread your wings and solve a problem, you have a connection to a pain point. You've seen like the answers, or the failures, or just like the non-starting to be able like approach a problem. 

I was meeting with open source maintainers every quarter. Finding out all their pain points on whether it's GitHub or just collaboration. And the thing that I discovered was the insights tab. It was always underwhelming. It had like some data. But it's hard to get insights across organization. It's hard to get insights repo the repo. It's hard to get insights on your contributions versus my contributions, which is not about like a leaderboard. But like I just want to know if you're making contributions. Maybe I can make contributions in those places too and without pestering you and asking, "Hey, where did you make contribution last week?" Or hitting the GitHub search API, which is super expensive to use. We wanted to build a platform to make this easier. 

2022, reached out to DigitalOcean. We built a dashboard for them to identify spam, identify contributions across the entire Hacktoberfest ecosystem. And that was like our first look at like what we could do with OpenSauced as far as providing insights across industry. 

And then we've since started a conversation with design partners, with foundations and enterprises to provide that same power, but also provide that same sort of insight across and compare against ecosystems. We'll have a public announcement in next couple months about like what our approach is. Stay tuned. But definitely, check out our check out our blog.

[0:26:41] JG: Great. There are two OpenSauced areas then. There's the public open source space that you're working in and then there's the company space? 

[0:26:49] BD: At the moment, today, OpenSauced is all open source. That's our focus. But there is a concept of inner source. We do have a solution for inner source. It's not quite as well thought as our open source side. But we're currently a team of seven. We've actually just added two more engineers in the last couple – actually, last month. Our engineer and a designer. And this is now giving us a sort of space to start really thinking through like what the next level of our software. 

Think of it as a way to see what's happening across the open source ecosystem. But if you're a company itself and you want to see what's happening internally within your contributions in your team, we do have a solution for that as well.

[0:27:25] JG: I've got a few user personas I'd like to run by you. Let's say that I'm a contributor. I've done a few first-time or good first issues in a few repositories and I'm not completely sure where I want to go next. Is there anything OpenSauced can do for me to help me get to that next step? 

[0:27:39] BD: Yes. OpenSauced, you're onboarding experience, you connect your GitHub up account and then you choose – one is your time zone. Because one thing that's usually hard about open source is knowing where everyone's coming from. We don't ask your location. You can share your location if you want. But like required is time zone. So, we know how to interact with you and what time you're waking up basically. Or if it's like 1am your time. Responses at 1am are very different than 1pm. 

We also ask you your interest. We have a range of topics, languages, frameworks and we just ask you to choose a couple. So then, we can then do some recommendations based on contributions. If you choose React, we can recommend other react projects for you to contribute. 

The notion of like making contributions to react, it's possible, but it's usually not the place you want to start. If you want to make a contribution to React, it probably would have been like 10 years ago. Well, not 10 years ago. Maybe five, six seven years ago. But if you want to make a contribution to the React ecosystem, there's so many other projects that could use your help. 

What we've been doing is focusing on things like new contributors is one of the insights that we're hyper-focused on. New contributors is better than stars. Stars is a metric that people all centralize around. But if somebody gets 100 new contributors in one month, that's a better signal than someone who gets 10,000 stars in one month. Because if you want to truly make a contribution, go to places that people are making contributions at. 

The other thing is like a new contributor is another good inflection point where, if it's a newer project, there's probably way more stuff you can probably make impact on day one than if you go to an established project that has already systems, and a team and basically have a lot of filters for making your contribution. We have recommendations for that reason. but also, we give a place for you to then showcase your contributions. As you start leveling up, you make interactions. 

OpenSauced as highlights. And these are places we – this is a place where you can share your contributions in the community. Issues, PRs opened, closed. Your interactions, you highlight and showcase how you interact in the open source. Because we don't believe that green squares is the only place to do it or make contributions. 

We do have a thing that I think is overlooked a lot in open source, which is blog posts. Right now we're centralizing on one blog post. We probably end up doing some expand outside of it. But if you write like a Dev post intro to TypeScript or intro to some random state management library. That is super helpful for especially the newest projects. Because now everyone can see, "Okay, there's docs. There's the code. But also, I can like see a story of somebody else making a contribution. And like we encourage our community to write content that is an intro-based, tutorial-based, but also helpful for people to make contributions to other projects. 

We've just added those. And we'll eventually add things like Milestones. Highlighting your first contribution to X project or someone else's first contribution to X project. That's an opportunity for everyone else to say, "Okay, someone is leveling up. Let me look at their situation, their road map, their journey and see if I can mimic that in my personal journey." 

Because like the challenge I've had – I have a finance degree. I knew how to use computers. I knew how to copy and paste. I knew how to write even code in CSS and JavaScript and – it just wasn't a path that someone told me I could go down. Because I assumed – even the school I went to, they didn't have a proper CS program. It was super small. I assumed, "Let me just go in like a degree field I could actually get a job. I didn't think computer science, you can get a job in." But if I could show other people there's a path and we could show other journey, that's the goal eventually for OpenSauced, is there're, at the moment, almost four-and-a-half thousand people who use the platform that we can show journeys of that we can showcase, but also we can attract companies also talk to those folks for the purpose of perhaps recruiting, hiring, hackathons, what have you. 

[0:31:13] JG: That's great. I believe skimming through your front page and your most recent blog post, you do have an actual user testimonial or two of someone who went on OpenSauced. Showed off their contributions and got a job somewhere. Is that right?

[0:31:24] BD: Correct. We've had quite a few of those actually. One of our hires, Sunday, he's based in Nigeria. His interaction was the summer that I took my sabbatical. He showed up, made a contribution to our project. And then made like three more in the same week. At that point, it was like enough for me, which usually doesn't happen. 

Usually, you get one contribution. The person disappears for a while. They come back, do another contribution. They disappear for a while. But Sunday was different where he made the contributions and it was consistent and seeking out the problems for us. Super brand-new. I was like, "Hey, Sunday, would you like to work on contract with us on a more permanent – or not even permanent. Full-time basis. Let's just get more hours out of you." 

At the time, he was looking for his next career. He did a boot camp. First job out of the boot camp is OpenSauced for him. And we were able to provide a mentorship and show him how to like properly interact in GitHub and interact with community. And now he's like one of our top contributors at OpenSauced right now. 

[0:32:16] JG: Well, congratulations to him and you. That's wonderful. Switching to a different user segment. Suppose, I'm a maintainer. And I am on your side here. And I'm seeing there are the occasional people who do a first issue and never come back. Or maybe once in a while I get someone who's really good. What would I use OpenSauced for here? How could I grow those folks? 

[0:32:34] BD: Yes. This is an opportunity. This is the thing we're actually currently working on as a maintainer journey now. As a maintainer, there's a persona. We use these terms like as maintainers. So, you kind of throw them around. One term being like the typo hunter. This might be somebody who goes and finds specifically typos in a number of projects. 

The challenge is like you don't always see that. If someone does a typo in your project, chances are they're probably doing typos in other projects or they're super invested. But like how do you gauge if someone's like actually super invested or is really just like earnestly trying to solve a problem, which is like this thing was spelled wrong? Or are they going to every single project like yours and doing the same sort of type of fixing on a white space hunting? 

Off the bat, OpenSauced, we could show all contributions that this person has made across the ecosystem. If it's the latter and that someone actually is typo hunting, then you how to interact. And there's a product that was called block party. Block party is a way to – if I block somebody on X or on Instagram and they're like a bad actor, there's a chance that my other followers and my other sort of influencers also want to know who I block, so we can all like protect ourselves against bad interactions. 

With GitHub, they have like some pretty good spam tooling. But it's kind of disjointed. And unless you know, you don't know about it. The opportunity we're looking for is like being able to build spam tooling into a platform. That's another thing we're sort of approaching. As a maintainer, you also probably just want to see where contributions are, and like statuses and like what to interact with next. We don't have that problem solved, but we actually have a maintainer survey that we'll be sending out pretty soon to like a select folks to start really discussing what other things we can provide value in maintainers. 

And I guess the last thing I'd probably mention is everyone's doing AI right now. And I think they're real easy. If you want to learn AI, it's like take a repo and then build a tool, semantic search to ask questions to it. We have that, which opensauced.ai is like the tool we built with GitHub Octerns over the summer. And never intentional to be like the tool we build in AI. But it was like the easiest thing for an intern to throw together. 

The real goal was actually to build something where we can actually identify up-and-coming contributors within the ecosystem. If you want to take a 100 repos and find out who are the top Python contributors within this span of repos, that's what we're working on right now. 

Let's be able to find the trends of the contributors before they sort of get sniped up into Google and disappear in the cloud. We're actually building out a solution for this. As a maintainer, if you're looking – another problem that we're actually looking to solve as well is like the lonely maintainer problem. 

If you're looking as a lonely maintainer or a solo maintainer persons keeping the thing alive, like you might want to look for somebody with a similar persona. Not sort of like matchmaking or dating or anything like that. But more of like there's somebody who also is in the same space as you. How can we showcase that and provide comparisons but also give you notifications of like, "Hey, I know you're doing TypeScript. Maybe you want to talk to Matt Podok about his TypeScript interactions." Or talk about this person – sorry. I'm like picking on you because I know your background. But it's basically how do you classify and personify like different types of contributors and contributions in a way that makes sense, but it's also a way that's not gamified? 

It's great to like participate in hackathons. but the real goal is like how do we build longevity and open source and how we help maintainers build community in long-lasting relationships? Like the one I got when I first contributed to the socket library. 

[0:35:47] JG: There's an interesting problem I think with lonely maintainers. There's also the concept of a lonely package. Just to pick on a package arbitrarily, all contributors has had maintainers come and go over the years. And it's got a lot of interest. And that one in particular, there's a very high interest to maintainer ratio. It would be lovely to have some sort of matcher to help people on board and contribute to that one.

[0:36:06] BD: Yeah. Yeah. And we're actually working with that team as well coincidentally. We do have a solution for being able to provide more exposure in what's happening with all contributors, but also insights. And there's a lot of like non-code contributions that get shouted out within all contributors. Like we were actually starting to index a bit of that and be able to shout out folks who are consistent champions. 

And I can't share too much. But we're working with a large institution university about recognizing mentorship and recognition, and the value of recognition in mentorship and how that builds longevity with an open source. And also, builds more strategic ways for people to get funded. But also, for people to get notoriety and also embedded into large ecosystems as well, which is not the goal for every open source project. But if you do get a project that gets adopted by a large enterprise, obviously, that gives you – well, it's not even obvious. But it gives you an opportunity for longevity either through financial or contribution, code contributions.

[0:37:01] JG: That's lovely. One of the reasons I bring up all contributors, in addition to it, being an excellent project with excellent maintainers, is that it's kind of I think trying to in some ways apply a hard solution of just these are the roles, these are the contribution types to a soft problem. Where there are, as you stated, a bajillion different ways someone could contribute. Whether it's mentorship, code, docs, helping on a blog and so on. Do you think that that's a solvable problem? Do you think that there's some direction you can take long term to help surface those more soft nebulous contribution types? 

[0:37:31] BD: Yes. And this is the thing that we were attempting with the highlights. To be able to highlight things like blogs and indexing things like all contributors as well, is that the opportunity there is like to be able to – again, like I didn't know there's an opportunity for me to even go into the tech world. 

Okay. Let me just get a job to learn about money so I can make money. Because that was my best way up the social class or the social ladder. And I think a lot of folks hyper fixate on a green square because like that's the thing that we fixate on is looking at green squares. But if you build an entire course on a framework, or you build a YouTube video, or you engage in community and answer questions in Core on in Stack Overflow, that's the sort of unseen. Because like there's no green square. 

I guess Stack Overflow, you do get sort of reputation score in metrics. But it's not the place you think of first. Because like I'm going through my boot camp. I'm graduating college. I saw on Twitter that I should be shipping code. I should get in green squares. I should make a contribution to some big project because like that's my only way out.

And there's so many other opportunities as a way up and out or up and level up. And I think that as a – I think as open source, we're super disingenuous or we haven't really supported up-and-coming, next-level contributors very well. And the reason for that is like people are burnt out. People don't have the bandwidth. I don't have the bandwidth to mentor every single person that comes through OpenSauced, which is why we have a community, which is why we have moderators. But not every maintainer has that bandwidth. 

What we want to do is – I spent a lot of time at GitHub sitting alongside Nadia Eghbal at the time and Mike McQuaid. And Nadia was working on the work in public book. And I remember specifically in Berlin, [inaudible 0:39:09]. We were all in the same circle, talking to the same maintainers, answering the same questions. Or you don't answer questions. It's more of a conference. You just throw a bunch of ideas. 

And the beauty of that is like I learn basically a maintainer what they need. They need like all the tools that normal businesses have without being a business. Maintainers need DevRel. They need community management. They need product management. They need customer support. But it's all the things that maintainer has to do all of their own until they can scale a core team. The core team always becomes just more people writing code. So then, it's still that maintainer doing the same stuff. Because no one who joins a core team does the other non – the soft skills. 

And to tell like the projects like a Rust or projects like – even Vue. Yave the non-coding core team to help like dictate and provide more future, longevity and roadmap planning to the project. But, again, I'm going for the green square. Why would I join the core team to not write code? It's an opportunity that we can help expand the footprint by just providing more opportunity for folks to slide into places to contribute in a non-code way. 

[0:40:13] JG: I'd also like to take this opportunity to shout out the book Working in Public. It's excellent. Highly recommend. In our last few minutes, I do want to touch a little bit on the business side of things. Because you have now embarked on this journey of starting a company. How is that different in your experience than say being DevRel, senior Dev, et cetera? 

[0:40:32] BD: I would joke through all my DevRel friends that, truly, developer advocates eventually become like future CEOs. Because like if you're technical and you can engage with community, and you can engage with customers, you can engage with engineers, you kind of have the skill set to be able to start a company. It hasn't been actually too quite different. 

The one thing that I think I expected is I would write way more code than I am right now. But like once you got the first – the base product up, there was no need for me to continue to write code. I think one of the easier things I could do is hire an engineer to write code. The harder thing to do is go talk to a customer and go talk to a community or go talk to a foundation. 

My day-to-day in DevRel – not even DevRel. In doing OpenSauced and running this company is very similar to DevRel. A lot of meetings. A lot of engagement a lot of these types of podcasts, and workshops and conferences. Not a lot of conferences. But I think the difference is that I get to do it on something I love, which is I really, really hyper-fixate on this pain point of scaling open source is hard. Growing community, helping maintainers, that's all stuff that's like thankless stuff. 

And I've been lucky enough to have quite a few people who believe in me who invested in this opportunity. Wo we did take VC funding recently to provide longevity for us to solve this problem. And I don't think every open source project, every company needs to take VC funding. But I'm invested in seeing this problem solve. I'm not invested in like making lots of money. Taking a little bit of funding and like hand handing over some ownership to other people gets me the place where I can solve the problem faster. That's the goal and that's the reason why I decided to go and take venture capital. But for the most part, I'm solving a problem that I really want to see solved and I want to see expand. 

If OpenSauced is not the place that gets it solved, I highly recommend everyone use the other thing as well. And whatever the other thing is, definitely let me know. I'm super available on LinkedIn and in Twitter/X and happy to like have the conversations on future podcasts and future conferences and stuff like that.

[0:42:26] JG: Lovely. You're not worried about long-term – the implications of having VC funding and being tied to needing to profit off that? 

[0:42:34] BD: No. I think what it really comes down to is I think a lot of folks – I've learn a lot about VC funding. There's a really good book called Venture Capital by Brad Feld and a few other authors. And I think the challenge that most technical founders have is that they just want to build. And between VC funding rounds, 18 months is the standard. 

If you go heads down for 18 months and then come up and say, "Hey, we're ready. We built the thing." But you never talk to a customer, you never engage with a community, you never found out if you're building the right thing, then the pressure is on. But from day one that I decided to go on sabbatical, I started a podcast called The Secret Sauce and started talking to future customers. Started talking to people in the industry to validate should I even quit my job to do this? Should I take funding? 

And I've asked these questions to everyone who's been on the podcast. And I've confirmed that like what we're doing is the longevity is not even a problem to me. Having metrics – I already had metrics at GitHub. I made up our OKRs. Having metrics and like trying to hit a goal and try to get on a phone or get on an email and talk to people and convince them to talk to you about the thing that you're solving, I did that. I did collections. I did sales for four years and sold networking equipment to NFL stadiums to do Wi-Fi. 

Again, I'm an introvert. But like I totally understand the scale of confidence to hubris. And like sometimes you get too far in the sort of the pride side. But I have super confidence in like how we're approaching this problem. And we are the correct team to be solving this. And whether it's – I don't think it's going to be an issue of us trying the scale. Because I think I've really honed in on a pain point. We plan on never charging individual developers. We don't want to charge maintainers. We have an opportunity to charge companies, and foundations and folks who are making really big impact in open source that should make impact in open source. But no one's presented – sorry. I know we're like towards the end. But the challenge with open source funding today is everyone takes off their hat and begs for the next monthly GitHub sponsors contribution. And I think we've built an entire system that you donate and you beg. Or we create a religion basically. 

Look at like what's happening with Bun. Or look what happened to React a couple years ago. You have to create the religion where people offer 10% to then donate to make sure this thing continues to strive. And I think that's been also kind of a broken piece of the open source industry. Where if people are truly providing value, you should pay for the value. 

And I think these companies realize that are getting value, but they're not paying for it. There's a whole other podcast we can have about this. But, yes, no concerns in the longevity piece.

[0:44:57] JG: Yes. I agree. We could do a whole other hour of funding explorations and what it's like to be a full-time maintainer. But this has been lovely. Brian, is there anything else you think that the audience should know or would want to hear from you in the last couple minutes? 

[0:45:11] BD: For the next couple minutes? Honestly, I would love to chat with folks. Hit me up on LinkedIn. Weird enough, LinkedIn's becoming my go-to social platform. I just find that the conversation is a little more engaging and inspiring. I'm still down on X. So, bdougie on X. Hit me up. And happy to always chat. Yeah, honestly, that's about it. Stay saucy. 

[0:45:31] JG: Stay saucy. How long have you been using that phrase? Where did that come from? 

[0:45:35] BD: I think I started using it because we needed a closing tag for the podcast back last June. Yes. We went through a couple different like closing tags of like – I think Jamstack Radio, I say keep spreading the jam. And I think Open Source Friday – I forgot what – basically, it's like how do I stop talking? It's, again, frameworks. Stay saucy became the framework of, "Okay. We're done."

[0:45:57] JG: Well, on that note, we're done. Thank you so much, Brian. This was absolutely lovely to chat. It's always a pleasure.

[0:46:02] BD: Likewise. 
[END]