Interview Intro

‍

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

‍

Our guest in this podcast is Brian Douglas and he's quite a guy. Brian has taken his experiences, being there right at the start of the professionalization of GitHub's developer relations activity, and turned them into an amazing startup, opensauced.pizza, which has the most awesome domain name I've ever come across for a startup. This interview has lots of really good insights, including the importance of timezones for your UX. As an open source maintainer myself, I'm pretty impressed with what Brian is doing, but let us let the man speak for himself. Here we go. [0:00:55]

‍

Main Interview

Brian Douglas

‍

Richard Rodger:  [0:00:56] Brian, welcome. It is great to have you here today on the Fireside with Voxgig Podcast, talking about developer relations. And let's start; let's get straight into it, talking about opensauced.pizza. Amazing TLD, I have to say; I never thought anybody would find a way to have .pizza as the TLD for a software company. Well done. [0:01:16]

‍

Brian Douglas:  [0:01:18] My pleasure. It's a long time coming. I actually got the .pizza back in 2016-2017. [0:01:24]

‍

Richard Rodger:  [0:01:25] That's foresight. 

‍

Brian Douglas:  [0:01:25] And it's one of those domain driven developments. So, you put a domain in and then you find a place to put it. [0:01:32]

‍

Richard Rodger:  [0:01:34] Okay. So, for those in the audience who don't know what opensauced.pzza is, because they're looking at that domain name going, 'What on earth? What sort of a startup has a name like that?' Why don't you take us through what it is and what you're trying to do and the vision the origin story? How did you get to do the startup? [0:01:57]

‍

Brian Douglas:  [0:02:00] The origin of the story is, I used to work at a company called Nullify, as employee number three. And my role was developer. So, I was a full stack developer, but I was doing developer experience as well as a half-time in each role. Sort of fell into that because I was the only engineer that was consistently writing blog posts. 

‍

And one of the engagements I was doing was going into open-source projects and contributing to – contributing random features and stuff like that. But I'd always add a document update and then share Nullify as a deploy preview, Nullify was like GitHub pages, but a little more advanced at that time. 

‍

So, because I was doing that, I built this little CRM tool to track all my PRs that I was opening up, in different various open-source projects. And that tool I ended up naming opensauced.  It was a more of a tongue in cheek opensaucedd.pizza and it was – that was just about it. And that was the same project that I spoke at GitHub Universe in 2018 – or sorry, 2017 – on. 

‍

And that was about how do you leverage a GitHub GraphQL API to build our CRM tool. So, that talk actually is what got me introduced into Kyle Daigle, who's now the Chief of Staff for the CEO at GitHub, who eventually got me to interview for the first developer advocate at GitHib. [0:03:24]

‍

Richard Rodger:  [0:03:25] You were the first developer advocate officially at GitHub. [0:03:27]

‍

Brian Douglas:  [0:03:28] Yeah, officially. At the time – prior to that, there were other engineers that did the role, and there was also the open-source team, like with Mike McQuaid and [Nani Iqbal?] 0:03:39. Those were the folks who interviewed me and eventually hired me into GitHub. So, that was the trajectory. It was an amazing experience, 2018, prior to Microsoft acquisition. 

‍

But I did want to take a step back, and opensauced itself, it is to discover engineering contributors, grow contributions in projects, and that was the ultimate goal. Once I moved away from the CRM tool that I was using, I wanted to contribute more to open source in general. So, that's what – that became the goal for me and then the folks who eventually signed up for it. [0:04:15[

‍

Richard Rodger:  [0:04:18] Let's say I'm an open-source maintainer and I click open projects on GitHub. Do I use opensauced? How does – what does it do for me? [0:04:26]

‍

Brian Douglas:  [0:04:27] Yeah, that's a good question. And the exploration to find out if this could be a viable startup and what the product could be. There's a lot of tools out there that are helping maintainers maintain projects. A lot – most maintainers usually have their own secret sauce in how to maintain (inaudible) 0:04:45 projects, or maybe they don't. And we did set out to solve that problem for maintainers last year, but what we found is a harder problem which is the companies organized to help maintain projects. 

‍

We wanted to try to swing as hard as we could at a problem that would solve it for the majority of the folks, folks like Stripe and folks like even GitHub and even Microsoft, they all have their own approach to maintaining open-source software. And we wanted to centralize getting information around contributions, contributors. 

‍

So, if you're an open-source maintainer today, you could use opensauced. You can – as you go to the onboarding, you land onto the Insights pages. And there you would add your own projects to a list. You could also add your own projects to – your own projects alongside of other projects as well. So, I imagine there's a related project that you also want to track contributions and contributions around. We provide that ability today as well. [0:05:45[

‍

Richard Rodger:  [0:05:47] Okay, so I'm just thinking there's – if I'm a company, there's different types of open-source engagement that I'm going to do. So, there's an obvious one, which is I have my own set of SDKs and they're open source and I need to maintain those. And then there's also stuff that I would have done in this company and previous ones where we encourage developers to actively participate in third-party projects. Maybe they're core Node contributors, this type of thing. So, do you do both? Do you differentiate? Which one is more important, the SDK stuff? The semi-verse open source or- [0:06:27]

‍

Brian Douglas:  [0:06:28] Yeah, I'd probably take even a step above in –understand the goals of the company. Some companies have SDKs where they're just trying to drive engagement for their product upstream, so having those SDKs interactions to grow community and contributions. 

‍

Other ones are example repos. I pick on Stripe again, where they have a bunch of Stripe examples, where you can just walk into a repo and have an idea of how to use the product pretty quickly. And those are to drive more user and customer engagement, but then they're also the companies that do contribute upstream to projects like a react or a markdown, MDX. 

‍

So, those companies might want to see where their engineers are contributing and try to keep track of contributions for the sake of – when folks do sponsorship, identifying where should I put sponsorship dollars to? So, we don’t actually have that live in the product yet, and hopefully partnering with other tools like Scarf that are already doing things like that already. 

‍

But the goal is – what's the goal? And then there are also other projects where the company itself maintains a large open-source repository. Electron was a good example for GitHub a couple of years ago, where Electron came out of Atom. Atom spun out Electron as an open-source project that was under the GitHub umbrella. It was under the Git Electron organization eventually, but it started as a GitHub repo at first. And the goal there was to share a thing with the community. 

‍

And a lot of companies have this sort of setup, but a lot of time what happens is that these sort of setups, they're either unmaintained or not maintained consistently, or there's no oversight or insight to understand the maintenance of these projects, especially if they're not driving the main business goal, which Electron wasn't. Electron was a cool idea that went out into the ether. There are also companies that put open-source – throw it over the wall and hope for the best. A lot of enterprises will do this, will add an open-sour project, with no contribution. 

‍

And the real goal that I set out a couple years ago was, I wanted to make it easier for people to onboard into open source and find projects. And if you have a project that has no contribution, it'd be easier to see that high level. So, when you walk into the dashboard at opensauced, you do – if you don't pick your interest, you default to JavaScript, and you can see all contributions across JavaScript. 

‍

If you choose the repos you want to put onto a page, then you can see all contributions based on the repos in your insights page. But the idea is, can I see if this is an active project pretty quickly, and that's the goal that we've solved already. So, the next step is, how do we drive adoption and contribution to places that need it. 

‍

So, in the future, we'll have place – ways for folks to – in companies to raise their hands and say, 'Hey, I want to contribute to a project. This is my interest.' Or, 'I'm a company,' or maintainer of a free open-source project that says, 'Hey, I'm looking for these types of contributors,' whether it's documentation or if you're looking for specific test or factoring or new features. [0:09:43] 

‍

Richard Rodger:  [10:09:43] Interesting. I went to the site and the first thing I did is put on the startup founder investor hat, and you do have a pricing tab, which I love. That's so – I run open-source and code and all that sort of stuff, but I clicked on pricing straight away. So, just explain; who's the customer? Who pays? [0:10:11]

‍

Brian Douglas:  [0:10:12] Yeah, it's a good question. And the pricing – I'll be upfront; the pricing is something we threw together in December as a – knowing that the number-one page that people click through, including yourself, is the pricing page. So, our pricing today is $99 per user per seat. Currently, we don't have a Teams functionality. And the folks who are paying are the folks who want to find more insights and discovery into their projects. 

‍

So, far, it's been around sourcing talent. We're working with a company that is 100% open source and also VC funded, a series V. And they specifically want to go through their repositories to see who's contributed to their projects and how they can drive engagement, but also increase their hiring pipeline specifically. [0:11:02]

‍

Richard Rodger:  [0:11:02] Awesome. That is really interesting. So, I've – just from personal experience, I'm a maintainer of a microservices framework. It's been around for 10 years in Node; has about 200 plugins; has a little ecosystem, a little developer community. And we hire many people from that community. What tends to happen is, somebody end up doing quite a few contributions and they bubble up in terms of, we notice them, and then eventually they end up working for us. 

‍

And it's a great way to find really cool people, but it's all random, ad-hoc. So, that's really interesting, because we could – and then other times we need people and we don't have enough people. And then – but it's almost impossible to search 200 plugins to find good contributors, right? [0:12:01] 

‍

Brian Douglas:  [0:12:04] Yeah. It's out of sight, out of mind too, because for example, there's an SDK that – it's maintained now. Well, it's been maintained by GitHub for the longest time, but one of the biggest contributors was a non-GitHub employee. And just to understand, as GitHub's gone through its changes, where like now, post-Microsoft, the company's way bigger than it was before. A lot of institutional knowledge around how things were set up and why open-source projects exist are lost as soon as someone leaves the company or moves onto the next thing. 

‍

So, that being said, there's like, an opportunity to have a high-level understanding of what's going on and who's contributing and where they're coming from. And one of our onboarding experiences is choose your timezone. Because when you go to organize engagements or invites. [0:12:55]

‍

Richard Rodger:  [0:12:53] Yeah. I wanted to ask you that; I'm curious about it. So, just in case you haven't seen the site when you onboard, which is unusual, opensauced.pizza asks you for your timezone. Walk us through that. [0:13:07] 

‍

Brian Douglas:  [0:13:09] The timezone, it came out a conversation I had with the OpenJS Foundation, when they want to go – and this happened numerous times on the company side as well. We want to engage contributors and pick a time to have a remote meeting, or have an understanding of, hey, why is no-one responding to my PR after two hours, and chances are maybe they're sleeping. 

‍

So, we wanted to have location as part of the onboarding experience, but it felt like that was a little too personal, identifying information, especially if you're only going by handle and you don't have an avatar. But better fit would be, let us know what your UTC is and – your offset, so that people can have better expectation setting. 

‍

And this is something that – on GitHub profiles also, you can show your local time as well. And I find this to be helpful, especially if you're looking to source contributors encourage synchronous communication through Slack and Discord. Eventually, you'll have a connection to Discord, but this is a better understanding of where contributions are coming from. 

‍

And this is something that we also put a lot of time into when I was working at GitHub, which was, how do you decide what conferences to go speak at. And when you got to hose conferences, who do you reach out to for maybe some in-person meetings or some engagement. It becomes a valuable insight to say, 'There's a bunch of people in this timezone. Maybe we could set up either a meeting at this time, or if we're in your country, put out the feelers if people want to connect and collaborate in person.' [0:14:45] 

‍

Richard Rodger:  Yeah. I haven't seen anybody else doing that or focusing on it as much; it's really valuable. So-

‍

Brian Douglas:  Yeah, I was going to say that the – well, it was really valuable. Because I did this at GitHub. One of the – the fourth largest markets for GitHub as far as user growth was Brazil. And prior to going to Brazil, because I worked at GitHub, I had access to this data – I would just go and search for highest contributors in XYZ language or framework and set up invites to say, 'We're going to be doing this event. Would you like to come to your local town/city and talk about open source with other maintainers in the area?' 

‍

And it became an easy engagement opportunity, to grow adoption, but also, when you're not on the West Coast or you're not in San Francisco, it feels isolating when you're the only one writing code and the only one that knows what you're doing. But to also connect with folks in person and have that ah-ha moment or the rah, rah, rah, of these people are doing something just  like me. I didn't know there were other JavaScript devs or there were other Python devs here in my city. So, we do a lot of engagements like that prior to doing conferences and doing travel for dev rel. [0:16:11]

‍

Richard Rodger:  [0:16:12] Yeah, that is wonderful. Having been exposed to both worlds – I'm speaking to you from a small city on the edge of Europe, in Ireland, but I've spent a lot of time in San Francisco and LA and engaged in the developer scene there. And yeah, it's kind of weird, because normally, when I'm engaging with open source, it's very far away from the center of things. 

‍

So, it's easy for the people involved in the San Francisco Bay Area to seem almost untouchable, God-like, you know. You can't – they're hard to access. They seem 10 times better than you. So, that's really empowering, I think, to do that, to let people understand that there's actually a guy two doors down; he's coding as well. That's amazing. [0:17:09]

‍

Brian Douglas:  [0:17:11] Yeah. That's my introduction into writing code, because – so, my background is, I've a finance degree; graduated in the last recession here in the US, in 2008, and had no job. [0:17:22]

‍

Richard Rodger:  [0:17:22] Good time. 

‍

Brian Douglas:  [0:17:22] So, I spent four years – yeah, I spent four years doing sales. And then from there, I decided I wanted to build an app. So, first thing I did was I started Googling how to build an app, found out Ruby on Rails. And then I – by a stroke of luck, I discovered that there was a local meetup in my city with other Ruby developers, so I started attending that. 

‍

And I know first-hand what it's like to find people who know a little bit more than you, to ask questions to, to understand what the job market is, and get all this insight into – wow, there's more than just copying and pasting code from Stack overflow or installing repos onto your local machine. There's a whole community around there. 

‍

And once you understand that – open source itself, it is the – every time you install a project into your project, you're just installing the code; you're installing an entire team. So, when you understand how the human dependency graph exists – and that's the high level we're trying to do with opensauced, is understand the humans behind the software. That is super empowering and super eye opening. [0:18:32]

‍

Richard Rodger:  [0:18:33] Yeah. Learning that you're not the only nerd in town is wonderful. [0:18:38]

‍

Brian Douglas:  [0:18:39] Exactly. 

‍

Richard Rodger:  [0:18:41] So, that's really interesting. You studied finance and then you were working in sales. [0:18:45] 

‍

Brian Douglas:  [0:18:45] Yes. 

‍

Richard Rodger:  [0:18:47] And then you taught yourself to code, specifically to do with – you wanted to build an app, so you taught yourself to code. [0:18:53]

‍

Brian Douglas:  [0:18:54] Yeah. I had a goal ahead. This is – I recommend anybody who's career switching or getting into code the first time, have a goal in mind so that way you know what you're heading towards. And then that experience unlocks just-in-time learning. Because a lot of folks will spend a lot of time in books and hypotheticals, but if you can spend some time into hands on – I need to solve this problem. I tend to – well, I can speak for myself, but I tend to learn faster that way encourage most people to – even if it's not a great idea. 

‍

And a lot of times being a follow over and – this has to be the next Facebook or the next DoorDash, whatever it is. Instead, pick an idea and build it, whether you like it or not, because ideas are – they're a dime a dozen; they're cheap. And you can just Google cool ideas to building code. Start there, and then that way you can have some sort of guard rails, of – I could go down a weird AI route. But instead, I'm going to build this login functionality to my application so I can learn how the authentication works instead. [0:20:03]

‍

Richard Rodger:  [0:20:04] Exactly. And I assume that original app is lost to the mists of time now. [0:20:08]

‍

Brian Douglas:  [0:20:10] Yeah. The original app I ended up building took 17 weeks. It was Yelp! for churches. And it was – at the time in 2012, 2013, finding a church in the US, it seemed like an insurmountable feat, because you couldn't just Google a church. So, instead, I created a place where you could post your church online with details. 

‍

It was like – there's a whole other – it was a little before its time, to be quite honest; not many churches wanted to be online present and active. And then there was also a review element, and the reviews seemed like they would need a lot more moderation than I expected. [0:20:54]

‍

Richard Rodger:  [0:20:54] Oh, wow, yeah. [0:20:55]

‍

Brian Douglas:  [0:20:55] I ended up opting for a fulltime role at an influencer marketing company to build out their dashboard. [0:21:03] 

‍

Richard Rodger:  [0:21:05] And of course, you'd legitimate your capabilities by building the app. And let me ask you – you hadn't studied computer science. Had you done coding before as a kid or was it totally new? Did something just click? Did you go, 'I really enjoyed doing this?' [0:21:20] 

‍

Brian Douglas:  [0:21:21] Yeah. My generation is, I'm the elder millennial based on that trajectory, so late – I guess I'm in the latter part of my thirties at this point. It doesn't feel like it; I'll be honest, but I am. [0:21:33] 

‍

Richard Rodger:  [0:21:33] It gets worse; trust me. [0:21:33]

‍

Brian Douglas:  [0:21:35] Looking forward to it. But no, I was always computer literate; we had a computer at our local apartment complex growing up, and we eventually got a computer in the house. And I was a Script kiddie, copy and paster. In order to mod games, you'd copy and paste code from SourceForge. 

‍

So, I was literate in that sense growing up, and then I was also – went into Myspace generation where you edit CSS to make your page as custom as possible. So, I was – yeah, I had an understanding of how web and html worked; I was able to build basic html sites. But I was knowledgeable to know that it was possible to learn without a proper degree. 

‍

And then that was the other half of it is, I didn't choose computer science even though I was interested in it, because I didn't know computer science was the actual degree that you would go for to get a role in tech. So, it was more of – just didn't have a lot of role models or a lot of examples to look forward to, so I ended up going with a finance degree because that was – it was more stable and for- [0:22:42] 

‍

Richard Rodger:  [0:22:43] For security, yeah.

‍

Brian Douglas:  [0:22:44] Yeah, at the time, way more secure. But if I learned how to make – or sorry, if I learned how money works, I could learn how to make money, so that was the reason for that degree. But it turns out it wasn't my passion, to be quite honest; it was more a means to an end. And then- [0:23:00] 

‍

Richard Rodger:  [0:23:00] It comes in useful now, right, with the startup. I bet you can do outscale models, no problem. [0:23:05] 

‍

Brian Douglas:  [0:23:06] Yeah. I was able to throw together a cap table and try to bring on investment, and definitely have financial models pot together for the business itself. We talk about pricing, but we have a business model of how this becomes a commercially viable business, so that's all been modeled out. And I've learnt – I picked up a lot of that also relearning it recently. But it's like getting on a bike, so it's nothing. 

‍

It's not – a lot of founders, you have really good technical sense or you have really good business sense, but you don't have both. But I can stand here and say in confidence, I've got a strong sense in my technical, my sales and my product ability. Not all of them are perfect, but I think I'm a jack of all trades and a master in some. [0:23:55]

‍

Richard Rodger:  [0:23:56] You have worked in sales, and at the end of the day, that is the only thing that counts. [0:24:01]

‍

Brian Douglas:  [0:24:03] Yeah, being able to have a conversation. Which is – honestly, that's how I got pushed into doing more dev rel at the startup I was working at in Nullify. It's because I had the business background; I had the sales background, and I had the technical background. Even though none of them were extremely skilled skills that I had developed over the years, I'd just learned how to code a couple years prior. But I was able to combine those into what is developer advocate today, which is being able to talk to developers; convince them that your solution is viable, and it's worth taking a look. 

‍

And I found a lot of enlightenment to be able to go through that process of getting folks in the epiphany of, wow, I didn't know this existed before. Which I spent a lot of times doing GitHub Actions, because I joined GitHub right before that launch. And when you see a moment of seeing folks using GitHub Actions, I'm like, 'Wow, this makes a lot of sense. Why am I still using the other tool?'' So, it was nice to go through that process with folks. [0:25:04]

‍

Richard Rodger:  [0:25:05] I think GitHub Actions got – you did get a little bit of luck with Travis being a travesty. [0:25:10]

‍

Brian Douglas:  [0:25:12] Yeah, Travis, their implosion and acquisition made the market's super ripe for a new tool. [0:25:20] 

‍

Richard Rodger:  [0:25:21] Totally. Let's talk about GitHub a little bit, because I'm just going to go back to something you said earlier, which was that you were the first of the official developer advocates in GitHub in 2018, which sounds crazy. That's not that long ago. It's easy to forget that this whole career path, this whole activity, is actually really new. I'm sure GitHub was doing developer relations before then, but it was probably ad hoc, right? [0:25:51]

‍

Brian Douglas:  [0:25:52] Yeah, the – and this is a common occurrence for companies in the last 10 years, where your first couple hires, everyone's an advocate. You're hiring people to double down on building a product, but also talk about the product. So, some of your early employees, they'll be the ones that stand on stage and talk about – this – did you know you can do this cool thing with this new product itself. 

‍

That was how GitHub operated; engineers super excited about the product they were building. So, with that being the case, I ended up joining at a time that GitHub was going through this transitional phase where four years prior, they had no managers. So, they had managers at this point but the CEO had stepped down two years prior, so there was no orchestration. 

‍

And GitHub had this thing where if you got accepted to speak at a conference, they'd pay for you to travel and your lodging. There were a few employees that took advantage of this, where they just spent their entire time travelling and living abroad, which is an amazing experience. But they had to cut that down to only two times a year, to only once a year, to only once a year if it is tangential to your day job or whatever. 

‍

And they had to constrain this because it was getting a little expensive to have people live abroad and travel to Israel for random conferences. Just not picking on a particular person, but there were random conferences in APAC, and folks who were living in Wichita, Kansas. It's expensive- [0:27:25]

‍

Richard Rodger:  [0:27:25] Let's go! 

‍

Brian Douglas:  [0:27:26] Yeah. So, they brought on developer advocates to be the point people to manage the engagement and be the public face of GitHub. I was hired and immediately Don Goodman-Wilson was also hired in [SRM?] Time: 0:27:42 shortly after I joined. And our role was to build more awareness and adoption around high-impact features. High impact features are like the GitHub API. At that point it was GraphQL API as well, web hooks, GitHub Marketplace interactions. 

‍

Build more awareness around the possibility of integrating with GitHub and be that point person to be onstage or be at GitHub Universe to talk about these products. The way we got t off the ground running was, we would scale our experience. So, pretty quickly, we created this internal platform to have any GitHub engineer request to speak on our behalf. And if you – we still had the – if you got your talk accepted, we'd support you. 

‍

But the goal was, the dev rel team would support engineers speaking at conferences. And then we'd also sponsor conferences and have a request internally to have folks speak on our behalf. So, if I got a spot, say, at a Ruby on Rails Conf, I'd put out a callout internally to say, 'Any engineer that is going to be in Chicago, or wants to be in Chicago, we've got 10 tickets. The only requirement is that you book yourself to stand at the booth for 2-4 hours.' 

‍

We built that internal system, which we called IRL, which the goal was, not only do we want to get high-impact features in front of people so that they're educated that they exist. But we also want to put real-life GitHub employees in front of people so they know that GitHub is a real company. 

‍

Not that people had doubts, but the opportunity to meet GitHub employees at a conference was high-value, high impact. The reason why we'd two developer advocates first 18 months is because we were scaling through the engineering team and have them at the conferences and representing GitHub alongside of us. [0:29:37]

‍

Richard Rodger:  [0:29:37] Brian, do you think many companies do that, or do you think a lot of the companies just have – here are the developer advocates; they do that stuff. And all the other engineers stay in the back room. [0:29:46] 

‍

Brian Douglas:  [0:29:47] Yeah. 

‍

Richard Rodger:  [0:29:48] You can see that or… [0:29:49]

‍

Brian Douglas:  [0:29:50] Yeah, and I'd say that's – for smaller companies, I think it's a big miss if you don't have your earliest employees advocating your product. Because – especially if you work in a developer tool. If your tool was to serve developers and you have developers at a company, the biggest – the easiest limit test is asking your developers that they use the product. Because the people you're hiring, if they're not using the product, then chances are people that you're trying to pitch to are probably not using the product. 

‍

And this becomes a really easy filter for early employees of, if you're excited about the product, you'll probably build something that you're excited about, that other people would be excited about. Which also, it can be a snake eating its tail, and you don't get enough feedback because you're too excited about it and you don't take feedback well. 

‍

So, that's besides the point, but I'd say most companies, they hire a developer advocate probably too early and it's one of the first 10 employees. And it's the first 10 employees that tend to pretty much do everything public facing and engagement. So, it's a big miss a lot of earlier companies. And what we're seeing in the last year is, we're seeing a lot of layoffs, and there's not a good alignment between dev rel or the developer advocate and the rest of the company. 

You're seeing a lot of those folks get cut. 

‍

And the best thing you can do as an advocate as well is not to just advocate the product externally, but also advocate the product internally. So, drive adoption; find out features that's are not getting a lot of looks, and figure out either a way to either cut the feature or improve the experience overall for the developer who's using the product. [0:31:22] 

‍

Richard Rodger:  [0:31:24] That's a really interesting insight. And there's a lot of people who are just starting out in dev rel; are trying to find their feet, trying to understand what to do. And that's – I haven't come across that piece of advice before; I think that's really interesting. Speaking of a snake eating its own tail and letting your own developers use your stuff, should a startup always have an API? Should you do the API first and then the UI? Do you guys have an API? [0:31:58] 

‍

Brian Douglas:  [0:31:58] Yeah, so we do have an API. [0:32:01]

‍

Richard Rodger:  [0:32:01] How do you find that strategically? 

‍

Brian Douglas:  [0:32:04] We have an API, and this is – we started with the API first. We – I built this tool. I built this tool as a CRM tool, was the original platform, and out of that experience, we built this recommendation engine, which we now have as hotopensauced.pizza as the URL. And this is a recommendation- [0:32:25]

‍

Richard Rodger:  [0:32:24] Sounds kind of (inaudible) 0:32:25. 

‍

Brian Douglas:  [0:32:26] Yeah, the recommendations is really early trending projects, so, less than 100 stars usually. There's either – there's usually going to be a blip where a ton of people are now engaged with this through – usually stars. And we can recommend up and coming project.s And as we were building this, we also built an API alongside of it. We had an API prior as well, but this became the basis of the new product, which is – how do you discover new projects. 

‍

So, API.opensauced.pizza is now our live API, and this has some light data on voting and repo data. And we do have a private API as well, so we do have it gated off; that includes all of our insight data. So, we're only about – since September only, we've all been – had a live product for opensauced – sorry, the new version of the live product – since September. We've been slowly developing the API alongside of the actual product that people will be paying for. So, we're looking forward to shipping more things and building more ways for people to integrate with opensauced, either in their tools or built on top of opensauced. 

‍

But as far as the question of should companies have an API, it depends. If you're a developer tool and you have developer advocates, there should be some sort of interaction that developers can take some advancement to. And like I say, GitHub's a really good model where folks can look at where GitHub's API was shipped one month after the public launch at GitHub. 

‍

And GitHub's approach has always been, build integrations on top of GitHub, and make the experience where you can build alongside of GitHub or into GitHub and enhance your experience. So, for that reason, you see the adoption of GitHub hit to – in the last couple of months, we – I say we, but GitHub's announced 100 million developers on the platform worldwide. 

‍

And you don't get to that point unless it becomes – GitHub becomes the water for developers, where everyone – if you're doing any open source, you're probably touching GitHub in some way, even if you're not even contributing through GitHub day to day. And that's mainly because now it's become the synonymous tool for developers to collaborate through. [0:34:39]

‍

Richard Rodger:  [0:34:40] Yeah, you absolutely have to have it. I do feel GitHub could do a little bit more for maintainers in general; it's still very individual repo focused. And this is where you come in. This is my- [0:34:55]

‍

Brian Douglas:  [0:34:56] Yeah, this.  And this is- [0:34:57]

‍

Richard Rodger:  [0:34:56] And this is the beginning. [0:34:57]

‍

Brian Douglas:  [0:34:57] Yeah, this is 100% something that brought up a ton. When I was at GitHub it was a constant conversation. And the team itself – Abby and Cara are doing a great job of maintaining the open-source engagement for maintainers themselves. So, there's a lot of behind the scenes that happens in meetings and collaborations with top open-source projects. But the way GitHub's structured is, you only see what's in your organization, or you only see what's in your repos. 

‍

And what opensauced is looking to set out and help with is that you can see insights into repos across industry. So, not only see your repos, but alongside of that, you can see the repos of similar projects and projects you look up to and projects that you don't look up to. If you consider yourself a competitor, if that's a thing in open source. 

‍

But the idea there is, if we can see insights across the board, we start levelling the playing field. And the mantra of rising tide raises all boats. It's an opportunity to say, okay, if this Python project is doing XYZ and they're attracting ZYX-type contributors, perhaps there's something there that I can learn from. 

‍

So, what it is, how do I reach out and collaborate? And eventually, we'll have a collaboration feature that we've been working on. And mind you, everything we're doing in opensauced is open source, so there's no surprise on our roadmap. Because everything an issue and our Figma is mostly open. I think we've- [0:36:29] 

‍

Richard Rodger:  [0:36:29] Wow, okay. 

‍

Brian Douglas:  [0:36:29] -flagged down stuff that we're actually working on, but stuff that you want to see historical record on or go through figma files, that's all open to the (inaudible) Time: 0:36:38 , or, at least for now. I don't think there's – I'm still learning Figma, so I don't know how open it should be, but we're figuring this out. And with that being said, the goal there is, jump in and learn something, but also get insights and awareness around what's happening across industry as well. [0:36:57] 

‍

Richard Rodger:  [0:36:58] So, you believe in the whole build in public strategy. [0:37:01] 

‍

Brian Douglas:  [0:37:01] Yeah. I do believe in the build in public. We didn't have a splashy public launch when we launched our product. I think I tweeted it in December we had a new landing page. But at the end of the day, the most die-hard users are the ones that can follow along and join our discord and jump on issues. And we do take contributions outside as well for the main product as well. 

‍

But the reason for that, it's – I don't know – I've done marketing; I've done sales. I've done it all. And a lot of times we get really over-indexed and we have to have a splashy launch date to ship the product, to get all the adoption we can. And what it really comes down to is, the adoption happens slowly. You're collecting new users, more adoption and drops. And every now and then, you'll have a big hit, either on Hacker News – maybe you got a blog post or some awareness happened through a conference. 

‍

But the real goal is always be shipping, and as long as you're always showing forward progress, you don't have to put a stake poll in; it's like, this is our launch date. It becomes way more aware when you have high-impact users or some of the advocates of your user base advocating on your behalf. So, maybe I eat those words in a few months when we have a big splashy launch and we go on Hacker News and hit the front page. So, now- [0:38:29] 

‍

Richard Rodger:  [Product launch?] Time 0.38.28, and you're number one or whatever. [0:38:30] 

‍

Brian Douglas:  [0:38:31] Yeah, exactly. We'll definitely do a ProductCon launch, but at the end of the day, what we'll end up launching is everything that's already been open and available. And a lot of folks have spent – in the dev rel space have spent a lot of time copying what Supabase is doing. 

‍

And Supabase is open-sourced PostgreS. Open-source Firebase is I guess what they were calling themselves, but instead of NoSQL, it's actually PostgreS. They're also 100% open source. And they 100% ship everything as part of normal releases and actual methodology. But what's interesting is, when they do the launch week, they're rounding up everything they've shipped already, that's already been launched, and then it's put into one blog post for the week. So, we'll probably end up adopting a similar announcement strategy. [0:39:17] 

‍

Richard Rodger:  [0:39:17] Yeah, well. But it's not. [0:39:19] 

‍

Brian Douglas:  [0:39:19] Yeah. But the goal is if you're hardcore and you want to pay attention to what opensauced is doing, you could do that by hitting Subscribe on the repo. But if you want to catch up on a blog post, we have a newsletter that we ship, at the moment monthly. We're trying to get it to every other week, but it's a lot to invest in that. [0:39:39] 

‍

Richard Rodger:  [0:39:40] I know; I know; it's – yeah, consistent content production is tough. I've got one last question. At the moment, your – opensauced focuses on GitHub and repo interactions and that sort of stuff. Are you guys going to expand out into the wider ways that maintainers, commercial and open source, interact with their users and their contributors? I don't know; understanding how your discords are going, understanding how your socials are going, that type of stuff. And maybe that's going into the territory of people like Orbit.love and people like that. Or is that on- [0:40:27] 

‍

Brian Douglas:  [0:40:27] Yeah, that – it comes up a lot. Especially Orbit is a particular company that we get compared to a lot. And Orbit does a great job in having a broader ecosystem around your community-led growth. And we introduce some community-led growth features, where maybe we connect the discord, which we'll – we're planning on doing. 

‍

But less on trying to understand GitHub – discord messages and likes on tweets, and even stars on GitHub. Our goal is to understand the code that's contributed. And when I say code, it's anything that is attached to a Git commit. So, there's also documentation if you choose to commit your docs; they're markdown. So, our focus will always be around pool requests, where tools like Orbit can do a really good job at understanding where stars are coming from. We want to take this story from stars to PRs, PRs as in pool requests. [0:41:23] 

‍

Richard Rodger:  [0:41:21] PRs, pool requests. 

‍

Brian Douglas:  And so- [0:41:23] 

‍

Richard Rodger:  [0:41:23] That's a good one. [0:41:23] 

‍

Brian Douglas:  [0:41:24] Yeah. So, that's our goal, is to understand where contributions come from, as opposed to where comments and stars are coming from. I could say maybe we expand or we partner with Orbit in the future. Happy to – I'm already connected with the Orbit team, so we've had conversations already. But where we see ourselves in the space is, we can get deep insights in the code contributions. 

‍

And when I say code, I really mean Git commits, because I totally understand that contributions are not just code. And we have some interesting things, where to do a blog post as well. Because I personally think the best good first issue or the first contribution is an intro to XYZ library blog post. [0:42:06] 

‍

Richard Rodger:  [0:42:07] Wow, okay, yeah. Focus on code is definitely one of your key differentiators, amazing. Brian, thank you so much. This has been super interesting. I'm – as a maintainer, I'm definitely going to be having a go, because I can see it being super useful for me personally. [0:42:29] 

‍

Brian Douglas:  [0:42:29] Keep the feedback coming as well. If there's anything you want to see in the product, we're more than happy to open up a GitHub discussion or issue. We can help triage that to see if it works within our roadmap. But the goal is, we want to support open source. At the start, we're supporting companies that are doing open source. 

‍

Eventually, we'll have an open-source plan where folks who want to get more on their open source project. We'll do that soon. But – and then we want to focus on developers as well. How do we get developers doing more open source and contributing? The one thing I didn't even mention is the 0.01%. 

‍

So, the – out of all open-source repos – at the time I was doing the data last year, and it's 372 million, but I was looking at 280 million years prior. Only 200,000 repos have more than five contributors. So, the way we approach this is having the understanding that most projects don't even have five contributors. 

‍

So, if the goal for anybody who's launching open source is get five contributions as soon as possible and now you have an open-source community. So, that's what we're trying to – for folks who want to grow engagement, we want to start focusing on how do we grow engagement through increasing contributors to projects? [0:43:44]

‍

Richard Rodger:  [0:43:44] That's the critical watershed, the North Star number, five contributor or more. Interesting. Brian, thank you so much, this has been fabulous, really interesting. Definitely go check out opensource.pizza, guys; it's fabulous. Thank you so much. [0:44:01] 

‍

Brian Douglas:  [0:44:01] Yeah, my pleasure. 

‍

Endnote

‍

Richard Rodger:  [0:44:02] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at Voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:44:29]

‍