Looking For a Job As an Open Source Maintainer

Building your open-source presence can be a deciding factor when looking for your next job. Despite some unobvious dark sides, participating in or building open-source communities is a great way to practice continuous delivery, developer product culture, and, above all, learn to code. All of those skills come into play when negotiating the offer. But there's also a couple of things to watch out for if you are an active open-source author or maintainer looking for a job. As usual, nothing is truly simple.

Here are some challenges I constantly face as someone who codes a lot "on the side" whenever I apply for a job.

Very short and very important: I'm not a lawyer. This post is not a legal guide. When in doubt, hire a professional.

Context

I've been an active open-source contributor for almost a decade now, although the peak of my activity coincides with the public announcement of Mock Service Worker, which I still actively work to this day. Open source has long become the way to post my engineering ideas, and I would often publish new things if they helped me develop or test in the past. I wouldn't be the engineer I am today without my open source involvement. It matters to me and so it automatically matters to my next employer.

Being transparent

It's a good habit to disclose your open source involvement during the very first interview. That kind of involvement can easily boost you compared to other candidates for the role but it's equally important to let your potential employer know that you are practicing that culture and you wish it to remain so. It doesn't matter if you've been building the next React for the past years or sharing a bunch of smaller pet projects with the world. You put in the effort and you certainly learned a thing or two. This is a great chance to let that knowledge shine. You earned it. Be comfortable with mentioning that, especially if what you cook is related to the job offer.

It's essential the company understands that your open source involvement is a responsibility. By opening your projects to the world, you are responsible for their state. If others depend on your projects, you are twice as responsible. This is why you bringing this up and opening a discussion is not your whim, it's a sign of you taking your responsibilities seriously.

Being transparent here sets up the conversation leading to other aspects of how your open source activity may co-exist (or not) with your job.

Intellectual property

As the rule of thumb, companies want to own all the code you write while working for them. That's not a big deal for a person who clocks his working hours and goes home to rest and relax. But you aren't quite that person, are you? I know all too well what a great idea does to the engineer's mind. It throbs and itches, swallowing your evenings, weekends, and often you, too.

This is where things get tangled.

Common grounds

First, you have to understand one truth:

More to that, some places omit the "working hours" part in the contract. Suddenly, all the code you produce belongs to them once you sign. And yes, that includes the open source code you author during your employment. Companies have this tendency of not being quite comfortable with their code lying anywhere but under their org. This is a certain recipe for losing your project that you poured your heart into.

So, whay can you do to protect yourself from that happening?

Negotiate

Agreements aren't written in stone. I haven't had a single job for the last five years that didn't adjust something in the contract for me. The interview and the agreement phases of the hiring are there for you to establish the conditions of your employment.

A lot of companies will make the negotation phase feel impossible. I've heard all sorts of things in response to asking for a change in the contract:

• It's a standard contract, it's fine, no need to change anything;
• We have to bounce this off our lawyer first, it may take an extra week;
• No, we won't be changing this. Period.

Rest assured, this is a power struggle. The company has the company's best interests in mind at all times, and the contract is there to assure just that. Although the viability of this may vary depending on the country, the safest option for any company is to own everything by default. This prevents any legal dispute regarding intellectual rights because you don't really keep any.

Such an aggressive approach to intellectual property does make sense sometimes. Although you will likely hear it's there to prevent you from (accidentally) building a direct competitor, I tend to believe this is a misleading and unrealistic example.

The company must own the code you write for them because that's what they hire you for. If you keep the right to that code, then you may also have to right to revoke it once you leave. No company wants to find themselves in that situation.

Depending on the response, the negotiation strategy will differ. If the main argument against my proposed change is the "standard" nature of the contract, I emphasize that I understand how that works for standard hires but let's be honest—engineers with an active open source profile are not the standard hires. It's an exception, and the company knows that. They are getting a well-rounded engineer with experience across the entire software delivery cycle, as well as your public presence and promotion by association, depending on what it is you're doing in the wild. It's a good deal for them. It's more than your right to make sure it's also a good deal for you.

If they have to bounce the changes off their lawyer, let them do so. Sometimes the companies would use this as a diversion tactic to trick you into signing faster. This can be especially effective if you need that job right now. We all have to pay bills, it's understandable. But you have to trust me on this one: even a month spent discussing the intellectual rights topic will save you a ton of time and mental health if you rush through it and things go awry.

Of course, if the company refuses to meet your demands, this is a good time to shake hands and go looking for another company. There is no hard feelings in that.

The changes

Okay, but what changes should you propose? It's hard to give you a template here because it will vastly depend on what's already written in the contract. I will do my best, using the statements I found in most working contracts out there.

Important notice: if you have trouble reading legal speech or unsure about anything, hire a lawyer. It may cost you but the cost of misunderstanding is far greater.

Remember that all the changes you propose must be present in written form directly in the contract that you sign. No over-the-email promises, no addendums after the trial period, etc.

1. Prior inventions

Before you even start thinking about the code you may write in the future, protect the code you have already written. This may not be that obvious, but certain clauses in agreements imply ownership transfer of the existing code (bananas, I know). That code has nothing to do with your employment and the agreement must explicitly state that.

That addendum is usually accompanied by a paragraph in the intellectual rights section of the agreement that states that you retain and the rights to your prior inventions. Make sure it says that.

2. Ownership conditions

Carefully read through the entire intellectual rights clause of your agreement.

Good ownership conditions refer to you giving the company all the intellectual rights to the code you write:

• During your employment period;
• While performing your duties;
• Using the company's equipment.

Those are the good conditions to have. Once again, the company should be safe just as you. I've also seen contracts that go and include an explicit parapgraph that "you retain IP rights to any work you produce outside of the working hours." That is a fantastic statement to have but even having clearly defined ownership conditions is already good.

Bad ownerhsip conditions don't explicitly state either of the above criteria. They may also be intentionally vague and permissive, stating things like "any intellectual property that arises over the time of the employment is considered the company's intellectual property." Be cautious about those, and if you are unclear about any of the phrasing, ask the company representative to explain them. If afterward you are still unclear, hire a lawyer.

I will stress that the IP rights section must explicitly exclude any IP ownership transfer of your prior inventions. Just having a list of prior work does nothing. It has to state you keep the rights to all the prior inventions you listed in the addendum.

3. Ownership by usage

Even if you've listed your prior inventions and have clear ownerhsip conditions before you, that doesn't necessarily mean your projects are safe. They may be safe in isolation but sometimes the company would take the ownership of the code if you introduce it to the product. Sometimes, it doesn't even have to be you who does that.

This is a gray area. The company will likely require you to give them all the rights to your software if it gets used as a part of the company product's development or runtime. Be extra careful what kind of rights you would have to grant them if that happens.

A good scenario is granting them the rights to use and modify the code. It can also be an exclusive and irrevocable license (it'd be a shame if you decide to pull the license rag from under the running product after you leave).

A bad scenario is granting them the rights to redistribute, resell, and sublicense your work. Being a user is fine. Being an owner is too much. It's okay to ask them to remove particular permissive rights from the respective paragraph.

Generally, the company should abide by any license your open-source projects already have. But some of those licenses don't guarantee them safety, and so explicit statements are made in the contract. Be careful, since those statements take priority.

Tone

Keep an ear open to the tone of the conversation in the room. If there's too much pushback or the company representatives are being aggressive, that is a red flag. Even if they reluctantly agree to meet you halfway, it illustrates they have very little understanding about open source. Consequentially, that means little understanding about what you love and do. If you aren't on the same page, don't be afraid to turn it down and move on.

Other tips

Open-source companies

Finding the company with a strong background or investment in open source can be a huge benefit. You would have fewer things to explain and fight for, and more often than not, those companies will already have proper OSS-friendly agreements in place. Note that this doesn't negate you being watchful and only putting your signature on the agreement that works for you.

New projects

You should iterate and extend the prior inventions list whenever you create a new project. Naturally, be mindful about working on the things too close to what you are doing at your job. Some companies may be fine with that but most will not be. Reach out and ask before open-sourcing something remotely related. Better safe than sorry.

Mindfulness

No amount of legal precaution is a substitude for being mindful about what you do. This sounds obvious but I will still mention this. Don't build the company's competitor. Don't open source the code you write for work without prior explicit written agreement from the company. Demonstrate that you also keep the company's interests in mind so to encourage them to keep yours.

Separate accounts

I generally feel more comfortable with using different accounts (email/GitHub) for my open source and my daily work. You don't rest where you work, and that is a good thing.