DevRel for Open-Source Businesses Explained

Developer Relations (“DevRel”) has never been more important. DevRel enables dev tools businesses to collect input from their users. This input helps direct the vision of the product from the very people experimenting with it every day. It is an absolutely essential function for businesses looking to build best-in-class products for developers. Founders and fellows frequently ask us when to hire a DevRel and what kinds of activities they should be doing. We interviewed Brian Douglas and Lee Robinson at Primary’s NYC Founders Fellowship, where we worked closely with 20 open source entrepreneurs in the early days of starting their businesses, to learn more about developer advocacy in open source.

Brian Douglas is the Director of Developer Advocacy at GitHub, where he focuses on engaging open source users. Lee Robinson is the VP of Developer Experience at Vercel, a platform for building and deploying frontend applications.

Our fellowship founders learned best practices directly from Brian and Lee. The conversation was so impactful that we decided to open source their advice.

Brian Schechter: What’s one thing we should be sure we take away from you in this conversation?

Brian Douglas: Know why you’re open sourcing your product. It might have to do with community, staffing, or collaboration. It could be because you don’t have all the ideas.

Lee Robinson: Make a decision early about how you want to manage your community, where it should live, and the audience you want to target.

BPS: Share where you are now and how you got there.

BD: To be a good advocate is to make other advocates. In open source, you can find folks who are excited about your library. If you can turn that fire into content, then that helps because others see the excitement. I only started coding 10 years ago. I had a lot of questions about how Node worked, and I leveraged GitHub to get answers to my questions. I got my hands dirty at Netlify, where I was shipping React code. I got heavily involved in open source and React, and then GitHub reached out.

LR: I’ve been coding since 2011. Before I was at Vercel, I spent my career as a frontend engineer. I actually helped my previous company move over into Next.js. At the time, there wasn’t that much content in the community. I started content and resources I wished I had when getting started with those tools. I joined Vercel as employee 34 and we now have over 300.

BPS – Let’s talk about the very beginning. How can open-source founders get going?

BD: GitHub is a natural ecosystem for getting exposure to your project. People always ask about how to show up on GitHub Trending: If you get enough people to use your project, you will show up on trending. How?

• Focus on your README. The README should be very clear on the purpose of the project and how to participate. You should have good structure around releases, core review, pull requests, etc.
• A best practice is to provide a description of what you’ve done – how you changed the file, why you changed the file, how long it took you, etc. Sometimes, someone hires a new engineer and there’s no context. If you make a natural change from Javascript to Typescript, write a blog post to tell people what the issues were and why you made the change.

On GitHub, there are ~253,000 open source projects that have more than five contributors. Very few of them follow these best practices. The algorithm is very naïve. If you convince 100 people to star your repo today, you’ll probably show up on Trending tomorrow.

BPS – what are the big buckets that OS contributors fall into? What are the persona types that people look out for?

BD: GitHub has buckets built into the platform: Committers, Maintainers, and Triagers. The quicker you can figure out the buckets that members of your community fall into, the easier your project will be to maintain.

Shawn (@swyx) Wang is heavily involved in DevRel and did a blog post on community management. He coined a term called the “Tummler,” a person that asks questions in a Discord or Slack. That’s all they do. They live in the community just to get the conversation going.

If there is no one to maintain the conversation, then it’s always going to be an uphill battle. With a Tummler, when it's time to start a team, you’ll already have folks to spark the conversation. Start bucketing your community into Triagers, Maintainers, Tummlers, and Committers. If you bucket early, you’ll find out quickly whether there’s interest.

BPS – It’s not everyone that engages this way. Who are the types of people that are going to engage at all? Contractors versus people who are inside of a company?

LR: It depends on the type of open source project. With Next.js, we see a large bucket of hobby users. They might open a PR to fix or might open an issue for a bug that they ran into.

Then, there are others who use the tools for their job. Because of that, they have different requirements than others in the community. They want to contribute to fix certain bugs that are coming up in their teams.

Finally, for open source projects backed by companies, there’s people who contribute to try and get hired.

BPS – We had Liam Randall, who is an entrepreneur, come in and speak about the idea of empowering your community. You want people to feel like the community is theirs.

LR: Great founders of open source businesses are in it – in the community, in the problems. Supabase is a great example here of founders who understand the community, who are in it.

CEOs will often hire folks directly from the community.