Field Guide
ToolsButton Text
Open source

Part 5 of the Field Guide addendum for founders building a new open-source software company.

Learn how to hire engineers and other critical roles for an open-source software company.

Tab 1
Tab 2
Tab 3

  • TL;DR: Hiring for an OSS company
  • Engineers should be able to engage with the project's users, contributors, and external maintainers.
  • Early adopters want to see the founders provide leadership and a strong voice.
  • As the user base grows, hire people in roles that amplify community-building activities, such as technical writers, developer relations specialists, and developer advocates.
  • Technical writers are essential for creating quality documentation and educational content, ensuring users can easily get started and realize the value from the OSS project.
  • Developer relations specialists/developer advocates focus on the end user's experience and building the community. The ideal candidate should be an engaging engineer who enjoys connecting with others on technical topics, giving talks, and being a champion for open source.

There are some key considerations to keep in mind when hiring for an OSS company. Finding the right people to build and operate in the open is just as much about the quality of their technical skills as their culture fit and mindset, including their enthusiasm for your project. For open-source companies, the core engineering team will be project contributors and community leaders early on. Additional roles are needed to support an early community focus, which results in an organizational structure that looks different for an OSS company.

<Whatsthebestwaytohireengineersforanopensourceproject>What's the best way to hire engineers for an open-source project?<Whatsthebestwaytohireengineersforanopensourceproject>

A few important criteria for hiring engineers for an open-source company are:

Genuine enthusiasm about open source

During the interview process, ask them about how they’ve participated in other open-source projects. Check out their previous involvement with open-source communities and any work publicly available on GitHub.

The ability to actively engage with early adopters

For example, Cockroach Labs didn’t have to look too far when they were ready to hire staff engineers. They hired a number of early contributors to the CockroachDB project who they believed would be able to enthusiastically engage with a growing base or users, contributors, and external maintainers of the project.

Get more advice for hiring engineers here in our Field Guide: How the best founders recruit their first engineers.

<Inadditiontoengineerswhatotherrolesareimportanttohire>In addition to engineers, what other roles are important to hire?<Inadditiontoengineerswhatotherrolesareimportanttohire>

Early on, you and your engineers will have to be responsible for directly engaging with your first users, helping to kickstart your burgeoning community by discussing your project, collecting feedback, publishing a roadmap, and so on. This role should not be “outsourced” — early adopters especially want to see the founders of an OSS project provide leadership and a strong voice. 

As your user base starts to grow, though, you should look to bring on people in roles who will amplify your community-building activities. These key roles focus on developer relations and technical writing, resulting in an organizational structure that looks different from a traditional B2B company.

Technical writer 

Documentation, tutorials, and educational content are key to a frictionless self-service onboarding experience in open source. Hiring a technical writer to create quality documentation and educational content ensures that your users can get started more easily and quickly realize time to value from your OSS project. 

For example, Cockroach Labs hired their first docs writer within its first year as a company, and the one-person operation has since grown into a thriving education team. “CockroachDB is incredibly technical and the documentation must be top-notch,” Peter Mattis, co-founder–CTO of Cockroach Labs shared, adding that technical writers play an important role in producing docs. “Documentation is a technical writing skill — distributed systems and database engineers aren’t necessarily good technical writers.” At Grafana Labs, in addition to hiring a technical writer, their engineers write on their blog, and many of the people who work in the business — typically engineers — write a lot of their content to make sure it’s technically correct.

Developer relations / Developer advocate

A developer relations specialist/developer advocate focuses on the end user’s experience and building your community. In this external-facing role, the ideal candidate is often described as an “engaging engineer.” They’ve previously worked as an engineer and enjoy connecting with others on technical topics, giving talks and demos, and being a champion for open source. This role serves as a conduit for communicating the company’s mission and project value while relaying community feedback to help inform decisions related to your product roadmap (both OSS and commercial). Ideally, the person who fills this role represents your target persona — as in, a developer who also understands and empathizes with the problems that need to be solved. When interviewing a candidate for this role, it’s essential to evaluate whether the person has sufficient technical knowledge to be credible with your user base and has strong, clear communication.

The founders of Temporal — the company behind the open-source workflow engine project of the same name — found it critical to bring on DevRel folks who could meaningfully engage with their customers. “Developer relations is about driving awareness that your product exists. But you have to find people who can engage with engineers on a detailed technical level — there’s not always that many of them,” says Maxim Fateev, Co-founder and CEO of Temporal.

Read more expert insights for hiring engineers here in the Field Guide.

<Leadershipandpeoplemanagement>Leadership and people management<Leadershipandpeoplemanagement>

Running an OSS company presents a unique set of organizational leadership challenges because, over time, your company will transition from only building OSS and serving its community to additionally building a commercial product and serving paying customers. Along the way, you’ll bring on different people and functions to accomplish each of those efforts. Aligning these parts of your organization is necessary to grow both your OSS adoption and commercial business in tandem, otherwise without proper attention, they can come into conflict with each other.

How do I align my organization to pursue both OSS and commercial objectives at the same time?

When you first start an open-source company, the singular focus for your entire team is clear: drive adoption of your OSS project and grow your user community. Early employees who join at this stage are often enthusiastic about OSS and some may not have any interest in ever working on anything commercial. 

As you eventually launch your commercial offering and start to ramp up traditional GTM, you’ll bring on salespeople, marketers, and other roles, many of whom may not necessarily care about OSS. The company now has two objectives: grow adoption and grow revenue. This can result in teams operating in a siloed fashion, vying for resources that only further the objective they immediately care about. Employees who perceive that one objective is being favored over the other may become disgruntled. For example, the engineer who is enthusiastic about OSS may depart if he/she feels the company is only prioritizing commercial objectives. Similarly, salespeople will be unhappy if features they need to close deals are deprioritized in favor of too much OSS development. To avoid this, it’s critical for you to communicate early and often to set expectations in two important respects:

  1. First, set expectations that both OSS adoption and revenue are necessary for your company to succeed and that they serve each other. For example, sales must recognize that the company’s GTM depends on significant, continued OSS adoption. Engineers building OSS must recognize that the company exists in the first place because of its ability, and the need, to generate revenue. Beyond communication, it’s imperative to ensure that activities across your company — product development, marketing activities, etc. — balance priorities to meet both objectives. 

  1. Second, it’s necessary to establish a culture that appreciates OSS but recognizes it is a means to an end, namely to build a large, revenue-generating, profitable business. Employees who are dogmatic, rather than pragmatic, in their views of OSS, can contribute to friction within your organization and in some instances, become toxic to building a productive culture that values the roles of both OSS and monetization. Since leadership starts with hiring, we recommend you spend time giving thought to the organizational culture you want to instill from the time you start your company.

This is the fifth and final part of the The Open Source Software Field Guide for Founders.

No items found.
Open-source hiring