A guide to hiring an open source developer
Open source software is code that anyone can read, use and, within the license, change. Databases, operating systems, web frameworks and many tools your team uses every day are built this way. Using these parts is easy. Working with them well is a skill of its own: reading a big codebase you did not write, getting a fix accepted by people you do not manage and keeping everything secure as new versions arrive. The sections below explain the work, the signs of a strong candidate and the habits that make remote work go well. They are written for founders and team leads who depend on open source and want someone who knows how to handle it.
What an open source developer does all day
The day often starts with reading. A bug appears in a library your product relies on, and the developer traces it through the project until the cause is clear. Then comes a small fix with a test. After that the change is either added to your own copy or sent to the project for review. Between those tasks, the developer checks for new releases, security notices and license changes. It is steady, careful work more than a flashy one.
Three kinds of open source work
The first is building on open source, where a product uses existing tools and the developer connects them. The second is contributing, where fixes and features go back to the project so you do not carry them alone. The third is running a project, where your company shares its own code and someone has to guide the community. Most hires cover the first two. Be clear which one you need, because the skills and the time involved are different.
Where an open source developer fits among other roles
A software engineer builds your product and uses open source along the way. A DevOps engineer runs the build, release and servers. A security tester checks the result, and our ethical hackers do that kind of authorized work. An open source developer is the person you add when the shared code itself is the problem or the opportunity, and sometimes one person covers more than one of these roles.
When an open source developer makes sense
- A tool you rely on has a bug that the maintainers have not fixed.
- You carry a private patch that breaks every time a new version comes out.
- Nobody can say which open source parts your product contains or under which licenses.
- Your old dependencies need an upgrade and the team is afraid to start.
- You want to share part of your code as an open source project.
If you only need an app built on common tools, a general engineer may be enough. A developer who tells you so before you spend money is a good sign.
Read the public record
One advantage of this role is that the evidence is often public. Look at the issues a candidate opened, the changes they sent and how they replied to review comments. Good signs are small focused changes, clear descriptions, tests and calm answers. Treat with care a profile that only counts stars or followers. Numbers on a profile say little about how someone behaves when a maintainer asks for a rewrite.
Questions to ask in interviews
- How do you approach a large project you have never seen before?
- What makes a pull request easy for a maintainer to review?
- How do you keep a private patch alive as the original project changes?
- What would you check before adding a new library to our product?
- How do you handle a maintainer who rejects your change?
Good answers are specific and include real cases. Be wary of anyone who only describes the case where everything works.
Try a paid mini project
Give each finalist one small piece of real work from your own project. Good examples are fixing a known bug in a library you use, reviewing your dependencies and listing their licenses, or upgrading one old package with tests. Pay for the time spent. Then compare how the person reads the code, how clear the change is and how well they explain their choices.
Plan for licenses and security
Two topics deserve attention from day one. First, licenses. Keep a simple list of every open source part, its license and where it is used, and ask a lawyer to review anything that looks unclear. Second, security. Agree how often dependencies are checked, who applies updates and how fast urgent fixes are released. Keep secrets such as keys and passwords out of any code that will be public. Write these rules down so they do not depend on one person.
Working with your team
Walk your developer through which tools your product depends on, what has hurt you before and who decides on a release. A brief weekly meeting and one shared list of tasks keep the whole team on the same page. Share the most fragile parts early, because they tend to set the real size of the job.
Common mistakes
- Copying code from a project without reading its license.
- Keeping a private fork for years and never updating it.
- Pulling in a new dependency for a task that needs only a few lines of code.
- Posting an issue or a change without a clear example or a test.
Looking at a wider role? Take a look at our software engineers for product work, or our DevOps engineers for builds, releases and servers.