The Open Source Developer Who Doesn’t Fit In Your Company

The work in Open Source is different from a Closed Source project.

The OSI logo, which is the trademark of the Open Source Initiative.

It’s prevalent nowadays for recruiters to look at candidates who contribute to Open Source as potential hires, regardless if the candidate actively participates on an Open Source community or not. The recruiters assume they should at least have a Github account.

There are many things wrong with that mindset. The primary problem is the assumption Open Source developers are more likely to be the best fit to work in any company with closed source code.

That’s not true.

A candidate’s work in Open Source proves they can code, but it doesn’t prove they are a good fit for a company. An Open Source community has different incentives and communication models than that of a Closed Source project.

This post talks about the differences between Open Source Development, where the developer individually undertakes the work in their free time; and Closed Source Development, where the developer is paid to take the work as a team and the source code is not freely available.

Note: There are further differences between Open Source and Github Open Source. This post uses both terms interchangeably. If you want to know more, take a look at the post Let’s Implement The Open Source Model! But… Which Open Source?.

Participation in an Open Source community doesn’t prove you’re a good fit for a company.

Here are the main differences between both:

In Open Source, the communication is mostly done asynchronously using Github comments or mailing lists. Everybody may live in different countries with different culture and time zones. It’s imperative for the contributors to have writing skills to communicate effectively; otherwise, their message may not go through.

In an office, everybody works near each other. They can use body language to communicate. When the information and intent are mostly clear through body language, learning writing skills becomes an improvement, not a requirement. If somebody works remotely, they can make use of video calls.

Note: Please, don’t assume these differences are valid for all developers who work in Open Source.

In Open Source culture, you mostly communicate through text. In a company, you have the option to chat face to face.

In Open Source, it’s your right to over-engineer a piece of code for fun.

That's ok!

You can work on whatever you want. After all, you’re coding in your free time. Some people have no other reason to participate in Open Source other than having some fun outside work. That was my case as an author of js-cookie!

Here's another example: the “global this” polyfill. It has to fit many environments and constraints to polyfill efficiently. While the development effort makes sense in the context of Open Source, it doesn’t make much sense in the context of a company.

In a company, you are paid to create economic value. That’s your primary objective. The most efficient code is the one that can solve a problem with the minimum amount of effort and assumptions. Over-engineering goes directly against that.

As a developer, there’s also fun in a Closed Source company. The difference is that in Open Source the fun is doing what you want; in a company, the fun is in the sense of achievement when you push the boundaries of the better cost-effective solution for a problem.

In Open Source, over-engineering is ok. In a company, it’s not.

Say a dependency twenty levels deep from your dependency tree is causing problems. In Open Source, you are the one responsible for debugging, raise the issue with an SSCCE, and provide a solution or workaround for yourself. Given you didn’t pay for that piece of software, nobody owes you their time to fix your issue.

In a company, a bug in a dependency might escalate if it’s causing critical economic impact. Somebody may have the power to move the sticks and get it done, even if that means negotiating priorities with other departments.

In Open Source, you are responsible for fixing all your dependencies. In a company, you are not.

Many popular Open Source projects are maintained by one or two people, and millions of applications use them. However, Open Source maintainers don’t scale. If you ask a maintainer for help via direct message, it’s unlikely you’ll get a response on time. It makes more sense for them to prioritize the project, their personal life, or the work that pays the bills over providing support.

To find support and assistance, you need to go for websites such as StackOverflow, Github issues, or mailing lists. The effort of the community overcomes the scaling limitations of the individual.

For projects within a company, though, you have better options. Everybody is supposed to work towards the company goals. If you need support or assistance to achieve that goal, you can reach out to your colleagues for help. That support or assistance can come on the form of Pair Programming, Mob Programming, or a direct face to face knowledge sharing tech talk.

In Open Source, it’s harder to get help. In a company, it’s easier.

If you are in a company which tends to prioritize Open Source developers in the hiring process over those who don't have Open Source code, you may run the risk of getting people who can only do Open Source development.

As a company, you don't want to end up in a situation where most developers only have the skills to communicate by text. Nobody wants to get people who tend to over-engineer a problem instead of looking at economics and a better cost-effective solution. Nobody wants to work with people who try to fix everything by themselves, instead of someone who knows the limit of their skills and when it makes sense to ask for help.

As a company, you can still hire Open Source developers. It shows they’re so passionate for their craft that they want to continue coding outside working hours. However, it doesn’t make sense to hire those who have minimal experience in anything else. It’s better to hire developers who understand the economics behind a business and have some Open Source experience.

If you hire too many Open Source developers, you’ll also pay the negative costs of an Open Source project.

In other words, if you hire developers with experience in only one thing, you’ll get a project which uses that, even if that’s not a good fit for the project. If you hire a contributor from a trendy project, it's very likely you're going to end up with that project inside your company, even if it doesn't make sense.

Developers with Open Source experience help to increase the diversity of thought in a company. They are precious and well capable of occupying engineering jobs at for-profit businesses. However, Open Source communities and Closed Source companies have different internal work environments with different incentives. They require different ways of hiring, working, and thinking.

If you are a free Open Source developer, don’t stop there. If you want to make a living, seek to understand monetary incentives. Perhaps you can develop the skills to transform your Open Source project in profitable business. Remember, you can abandon a non-profit Open Source project without negative consequences; if you leave a for-profit project, you run the risk of getting fired and lose money.

If you’re a hiring manager, what you need is a developer who works with Open Source, not merely an Open Source developer. A developer who doesn’t have only one kind of characteristic, but a myriad of them.

It’s up to you to find those traits and choose the best candidate, for that an Open Source developer doesn’t fit in your company.

A developer who works in Open Source does.