When interviewing for a software position, is it a good idea to ask whether or not they would be willing / supportive of employees participating in open source projects? Some employers have contracts that prohibit employees working on software outside their day job.

There's a particular project I have in mind, which I haven't yet committed code to, that isn't related to the potential employer's business, so there wouldn't be any conflict of interest. However I'm worried that it might appear that I want to do spend my time doing some other development work immediately after joining the company, instead of concentrating on developing their software.

In fact I'd imagine only committing a few bug fixes etc in the first six months of any new job. This is simply something I've been wanting to do for a long time and I've already spent about one to two weeks setting up a machine, compiling the software etc, in preparation.

This isn't a deal-breaker for me; it's just a nice-to-have. So I'm tempted to think there are no advantages to asking now, and possible disadvantages, and I should simply bring it up later if I get the job, once I've established myself.

  • 5
    I've never worked anywhere that minded if you worked on OS stuff as long as you didn't do it on the clock/at the office/etc. Mar 3, 2014 at 17:11
  • 3
    I have worked in places and know of places that either don't allow or discourage contributing to open source projects. Mar 3, 2014 at 17:14
  • 17
    I'd suggest telling, not asking - at the interview, mention that you are doing it and will be doing it. The difference is that by asking permission a "don't care" would turn out to "no, just in case"; and by telling "don't care" would turn out "ok, whatever".
    – Peteris
    Mar 4, 2014 at 1:17
  • 2
    Others have answered this better than I could, so I will just throw my advice out there. Always read the fine print when it comes to non-compete and IP ownership. Depending on your jurisdiction and how strict they are, either or both may range from easy to impossible for the employer to enforce. Regardless of the legal aspect, it is always best to be informed. Personally, I want to make the world a better place in my spare time and I have contributed a few bug fixes to open source. I would not work for an employer that cracked the whip and asserted ownership over my free time.
    – user16626
    Mar 4, 2014 at 5:17
  • 3
    I would mention your involvement in Open Source as one of the indicators that you love programming. Put it on your resume if you can. Bring it up in answering the interviewer's questions, maybe even in the "tell me about yourself" part. Then, when it come so the "do you have any questions?" part, ask if it would be a problem to continue working on open source projects as long as you make sure it's not any kind of conflict with work. That way, you totally avoid your fear that they'll misinterpret your involvement.
    – Wayne
    Mar 4, 2014 at 23:19

11 Answers 11


To me, this part of your question is key:

This isn't a deal-breaker for me

If you WOULD work for the company in spite of a more restrictive policy about open-source, there's no reason to take risks in the interview.

With an offer in hand, this is a great question to ask and depending on the company, one that might even be negotiable. You'd probably learn not only about the larger policy, but also about the specific group's culture. I would also like to mention that I think it's great you're so interested in Open Source. Having that kind of culture in a workplace does seem to improve the quality of engineers, the rate at which they learn and their engagement in the development process.

Maintaining a foothold in Open Source also tends to increase your employability medium- and long-term. Many employers, including mine (a giant company you might not expect is like that) prefer someone like you and might even take interesting, recent Open Source experience over specific experience with their technologies.

  • 1
    You're right, this is a nice to have for me and not critical. There are some great answers here, that would probably be better answers for people who are further down the open source road than I am. I've found those answers very helpful in deciding what to do, but this answer is the best at addressing my concerns at the current time.
    – TooTone
    Mar 5, 2014 at 11:45
  • 1
    One possibility is to just make the fixes before your contract starts, if the company has a problem. It seems that with what you're describing, there should be enough time before your contract starts to do this. Mar 5, 2014 at 14:23

I have always been taught that fit is the most important criterion for job/opportunity selection. In fact, my business school follows a "broken cookie" or the "Darden Cookie" method, in which you attempt to know yourself and find the job that completes you like a broken cookie and it's other half .

Thus, under that method, if an important part of you and your joy in life is participating in and contributing to open-source projects then a company that would restrict or prohibit that activity would not be a good fit for you.

Therefore, to find out whether that will be an issue, you should likely tell the company that you intend to participate in those projects. A company that would not hire you because of that would likely be a bad fit, and thus they sorted that fit issue out for you. Leading you to a potentially happier experience in the future, an outcome only possible by being open and sharing that intention/asking that question.

  • 1
    I really like the cookie analogy and have never heard it before! Mar 3, 2014 at 21:38

There are three routes you can take.

  1. Assert your intention ahead of time
  2. Ask for permission ahead of time
  3. Ask for forgiveness if you get caught

Each has its benefits and drawbacks depending on how you weigh the importance of getting that job vs. working on open source projects.

Assert Your Intention

During the interview process, you should be asked if you have any questions. One way to broach the topic is just to state your intent and toss the ball in their court:

One of the reasons I have the skills I do are from working on side projects. While working here, I intend to work with open source projects like A, B, or C outside of work hours that don't compete with the software we're creating and will help me hone my skills. Does this company have a problem with that?

On the plus side, this states that working on open source projects is a benefit, and gives the company an option on how they want to respond. Even if the standard is to prohibit folks from working on side projects, if they like you they may be willing to make an exception on the spot to make sure they get you.

On the downside, they may view this as a deal-breaker and cut ties then and there. If you really care about working on side projects, this may not be a bad thing.

Ask for Permission

If you are a bit more hesitant, you can phrase the question differently:

What is company policy regarding side projects like contributing to open source software?

If the response is positive, you can ask for explicit permission. If not, you can make your decision based on how negative their response is.

On the plus side, this will give you more information on what their policy is in general because you aren't stating a strong desire to do it, just asking a general question about it. Since you get to hear their stance prior to deciding how to proceed, it has less risk than just asserting your intention flat-out.

On the downside, while it may not be as strong as asserting, if the workplace is strongly opposed to working on side projects, they may still see the question as an intent to work on them.

Ask for Forgiveness

If you have a feeling either from asking for permission, or from other information that the company may be less-than-supportive, you can always just do it and feign ignorance of company policy if you get caught. As the adage goes, "It is easier to ask for forgiveness than permission". If you do decide to go this route, make sure that your contract/the law will not cause serious issues for you or for the side project you work on if you do get found out.

On the plus side, you will be able to work on open source projects regardless of company policy.

On the downside, your employment or professionalism may be called in to question when/if you get caught.

  • 1
    The last option is not a good one (and I wouldn't even recommend suggesting it). It has nothing to do with your employment contract. OpenSource projects have strict licensing rules that have clear implications for you as a developer and the company you work for. Mar 4, 2014 at 9:04
  • 3
    @Simon, I understand your concern and have extended the caution from just your contract to the law/guidelines governing contribution to an open source project. Whether it is a good option depends on the priorities/ethics of the person making the decision, not us.
    – jmac
    Mar 4, 2014 at 23:36

While JMacs answer covers most of what I was going to say, I would have to say never go for the "Ask for Forgiveness" route.

The main reasons.

  • Code contamination
  • Conflict of interest
  • Licensing issues

You run the risk of submitting code which may be related to the companies code. Or it could be the company could be working on a competing product.

This at best could preclude you from working on the companies project.

At worst it can delay/cancel the product as they have to review and modify/remove code that may be competing. In some cases this would even be grounds for dismissal/damages.

Also not all Open Source licenses are created equal. Some are not written by lawyers, which is why something trivial as "Use this software for good" can kill a product stone dead.

It normally requires a lawyer to review the license and sign off on it.

Conclusion: I would recommend to ask up front their policy.

Major software companies will often have people working on Open Source projects, and the framework to doing this without damaging the companies intellectual property.

  • Sorry, the ask for permission route was the one that suggested asking about the policy in general, and then specifically requesting if they were positive. I believe you mean don't go the ask for forgiveness route, in which case I already pointed out that there could be significant issues for you or for the project depending on the contents of your contract.
    – jmac
    Mar 4, 2014 at 8:19
  • Whoops! yes you are correct. Also I am happy to merge my answer into yours if you want. Mar 4, 2014 at 8:27
  • My reason for the answer is you suggest "Ask for forgiveness" as a viable option, which I don't believe. Mar 4, 2014 at 8:29
  • There are times when it may be best to ask for forgiveness rather than for permission (for instance, sometimes companies will always say no if asked, but turn a blind eye if you keep your cards close to the chest and use good judgment). Not saying this is always the right choice, and that it can't have horrible consequences, but depending on the company, the employee, and your priorities, it could be the best choice. My goal is not to explain what the best choice is (it depends), but rather how to weigh the options to come to a decision.
    – jmac
    Mar 4, 2014 at 8:36
  • 1
    "There are times when it may be best to ask for forgiveness". There are never times when it relates to OpenSource projects. You are walking into a legal minefield in doing that, and risk your employment if you work as a developer. Mar 4, 2014 at 8:58

You should definitely ask. Some start up companies will take a rather draconian approach that says "we own everything you write, even if done on your time & equipment".

They do this because they need to ensure clear title to their software (so they can sell the company) and this can be the easiest way to do it.


OK, so there's lots of go-for-it advice here, so for balance, I'll give you more of the cautionary side, although I'm a big fan of open-source.

It depends on your bargaining strength. If you feel like you're lucky to get your feet in the door, and you don't know the company culture on this, you don't want to screw up your chances by giving them what they potentially might see as a negative. You'll find that a lot people don't contribute to open-source, and they've mentally justified it by deciding it's not worth their time to do free work. They could look down on you for suggesting it.

Play it smart and learn about the culture up front, see if its generally encouraged for people to work on open-source. If you're a bad fit for the culture, you might prefer to spend more time looking for a better fit.

If you say, "Do you encourage participation in open-source projects?" and they say, "We'd rather know you're working on our software at any given point in time that you're working," you may have learned enough to make a decision.


I don't see any harm in asking, I would preface it similar to what you have said here.

I would say that you enjoy working with software and occasionally work on things that are unrelated to work and do so with the open source community occasionally. Do the guidelines here prevent me from doing that? I would also say that you understand that anything done for the company is still property of the company, including open source enhancements/bug fixes and you would always get prior permission before committing something work related.


Talk to an IP protection attorney. They may be willing to talk to you in a free initial consultation.

In my case, my employer had me sign an IP disclosure, as they do for all employees. All they wanted was a short (very short) disclosure of IP (patents, technologies) that I possessed.

Never use company resources for your open source work.


Yes, you should bring it up, but not during the interview. After you have an offer (meaning they have already decided they want you) is the time for this kind of question. If the answer is one you don't like and they won't negotiate, you can decline the offer.


Some companies will offer a 'time2innovate' scheme, or at least that's our local area's name for it. The basic principle for one example company in my area is that you'll have 2 hours on the Friday of every fortnight to work on a completely new idea, however you wish using your tools, and it's entirely credited to you. After a month or two of working on something, every employee gets to pitch it to the whole company and has the potential to take it forward with the company if the idea seems sellable. The two hours each fortnight are paid work hours, but it doesn;t have to be related to the company.

In fact, asking about something like that in an interview is probably going to show initiative and some entrepreneurial flair, so I'd say go for it.

  • @TooTone - then it seems the problem is your question was not properly focused because this seems relevant to me... How is it not relevant to you? Mar 4, 2014 at 18:56
  • @Chad Relevancy is just a personal opinion and it's hard to debate. I apologise, this has got to the point where my comments on this post, far from being helpful, are getting to the point where they are detracting from meaningful discussion. This was not my intent with my initial comment (I added a comment as I often do when I see downvotes from other people in an effort to provide some feedback) and I'm going to delete it and the subsequent ones as clearly whatever I was trying to achieve by commenting in the first place has not being achieved.
    – TooTone
    Mar 4, 2014 at 18:59

A good way to avoid getting in this situation would be to have any major open source projects you're involved in as items on your resume. Then any employer who offers you employment has tacitly accepted that you are working on them; they would look foolish later claiming they didn't know, and didn't approve, if claiming so meant they had failed to read your resume. If you're interviewing and it's not already on your resume, you could achieve the same effect just casually mentioning your open source work during the interview, at a point where it flows rather than coming across as intentional/forced. You want to project confidence in your right to do what you do in your own spare time, not a feeling that you think what you're doing is in any way transgressive or out of the ordinary.

  • 4
    Placing something on a resume that some interviewer read does not trump a contract specifically forbidding you from participating in open-source development. Do not assume that just because they didn't say anything when you sent your resume, that assumes that you have carte blanche to participate in open source projects in the future, or that your contract will allow such participation. That is a recipe for disaster.
    – jmac
    Mar 4, 2014 at 8:17
  • What's with the downvotes? Of course you also read a contract you're offered before signing it, and if there's a problem with it, you work that out with the employer before you sign. But assuming there's nothing in the contract one way or the other about things you do on your own time, I think my advice is good for establishing a reasonable basis for believing that the employer has no interest in trying to run your private life in ways that aren't even covered in the employment contract. Mar 4, 2014 at 9:07
  • 1
    You also need to make sure you can intelligently discuss any Open Source projects you worked on and their technologies. That's important too. Mar 4, 2014 at 17:03
  • Indeed. Ability to discuss them, especially things you've learned from them or design or implementation aspects you found poor in them and would change if you had it to do over, would be great ways to demonstrate your skills/experience to your prospective employer. Mar 4, 2014 at 18:06

Not the answer you're looking for? Browse other questions tagged .