Menu
Learn how to hire engineers and other critical roles for an open-source software company.
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.
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.
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.
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.
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.
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.
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:
This is the fifth and final part of the The Open Source Software Field Guide for Founders.
