Recruiting for an Open Source Project

Disclaimer: Opinions are my own and not the views of my employer

Open source is a large part of my current job. I participate in a specific project along with most of my team. Beyond development, we do also participate in planning, advancing, evangelizing the project. The project is fun, my fellow contributors are smart and kind folks, and we have lots of users making it a rewarding experience. I could write more about it someday however this post is not about my experience.

Another large part of my current job is to recruit people to work on this project. I had a chance to talk about the benefits and drawbacks of working on open source with many candidates. They had different backgrounds, varying amounts of previous experiences with open source, and different opinions of such an opportunity. Each conversation helped me clarify my thoughts on the matter. I want to share those here with you.

There is less risk in joining a team working on an open source project.

• Culture: Teams develop their own cultures over time, and for better or worse they tend to consist of like-minded people. Being productive in a team requires some level of cultural fit between a new hire and the team ¹. Almost all job opportunities will mention a few things about company culture. And with a few exceptions ² they will be vague and hard to verify. In the case of an open source project, a prospective candidate could verify the claims about the team’s culture. After all, open source projects have more than just source code in the open. They will have public mailing lists, open discussions, open roadmaps, open events. It is easy to find answers for questions like: how do people interact with each other, how are decisions made, how are junior engineers mentored. I am not claiming that all open source projects will have great cultures, but whatever the culture is it will be there to see before accepting a job offer.
• Impact: Similar to the above point it is possible to get a sense of how much an open source project is used. A prospective candidate would be able to see existing user feedback, download numbers, website analytics, and other data points that would allow them to estimate what is the impact of this project and how much opportunity there is. And they could estimate how much they could learn, grow and contribute as a result.
• Lock-in: People change jobs for various reasons, but the reality is eventually there will be greener pastures for everyone. Changing jobs means changing your coworkers and usually means changing projects, no longer being at peak productivity, and ramping up on a new team with a new stack to get back there. Open source projects, at least the more robust ones, generally have more than one commercially interested party and the project serves as a job network. An existing contributor could change companies while keeping both their co-workers and their project. They do not need to lock their career on a specific company and a project ³.

There are more rewards in joining a team working on an open source project.

• Most prospective candidates I talk to mention that they wanted to contribute to an open source, but they never got the chance. This is understandable because most people do not have enough time to volunteer. A job offer to work on an open source project addresses that dilemma of wanting to work on open source but having the time for it. And there is great joy in taking a job that allows folks to do what they want to do in the first place.
• People spend a great deal of time at work and in general, they cannot talk about it publicly. On an open source project, team members will be encouraged to talk about their projects openly and share their work as much as possible. This freedom is not only fun, and it also makes one’s resume much stronger with a clear list of evidence-based accomplishments.
• Open source projects could be more diverse with contributors across the world, working for different companies, with different goals, different backgrounds, different working hours. This has multiple benefits:
  • First, it gives contributors access to a large pool of experienced folks with a common goal to advance the project. This results in a better product that everyone can be proud of. And it allows people to learn and understand different cultures out there beyond their company’s monoculture.
  • Second, communicating and working with such a diverse group requires excellent communication skills. Communication is a very valuable skill for software engineering and probably for most other jobs. It is a skill as any and people develop it over time by practicing. Working on open source is a great way to regularly practice and develop that skill.
  • Last but not the least, open source communities have been running efficiently as remote communities from the beginning. They have built tools, processes, cultures around remote and offline interactions. This makes open source projects great candidates for being remote jobs.

There are not many drawbacks to joining a team working on an open source project.

That said I have seen folks not liking certain aspects and moving on to non-open source projects. These are valid reasons and it is worth considering before joining an open source project:

• Not everyone finds the idea of doing work in the open appealing. Opening one’s self to critique from the whole world could be daunting. “The whole world” sounds like an exaggeration and oftentimes it would be hard to find even a few people to look at new work; but there are instances of contributors getting outsized comments from “the whole world”. ⁴
• An open source project might be less a productive environment for a few reasons:
  • First, larger companies invest in tooling that is efficient, works seamlessly together with other tools, and offers a better user experience overall. Open source projects usually do not benefit from these improvements and could be behind in terms of their infrastructure.
  • Second, an open source community will have its processes on top of the processes of one’s company. This added bureaucracy could result in slower development cycles although I think this is a solvable problem. As long as the goals of the open source project and the company are aligned it is possible to align those processes as well.
  • Lastly, a small co-located small team will have higher communication bandwidth and could move faster compared to a small but distributed set of contributors working on an open source project.

To sum up, I find working on an open source project rewarding, purposeful, and less risky. These make open source jobs appealing for talented folks. As a result, the opportunity to work on open source projects becomes an effective recruitment tool for companies. ⁵

I would love to hear your feedback, thoughts, and comments on this.