Is it a good idea to ask a future employer whether or not I might be allowed to do open source development? [closed]

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
26
down vote

favorite

3

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.

interviewing software-industry

share|improve this question

asked Mar 3 '14 at 17:04

TooTone

1,69011130

closed as primarily opinion-based by IDrinkandIKnowThings, jcmeloni, jmort253♦ Mar 5 '14 at 6:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  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.
  – Andrew Bartel
  Mar 3 '14 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.
  – Bill Leeper
  Mar 3 '14 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 '14 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 '14 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 '14 at 23:19
  

  
  
  
  

 | 
show 3 more comments

up vote
26
down vote

favorite

3

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.

interviewing software-industry

share|improve this question

asked Mar 3 '14 at 17:04

TooTone

1,69011130

closed as primarily opinion-based by IDrinkandIKnowThings, jcmeloni, jmort253♦ Mar 5 '14 at 6:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  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.
  – Andrew Bartel
  Mar 3 '14 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.
  – Bill Leeper
  Mar 3 '14 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 '14 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 '14 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 '14 at 23:19
  

  
  
  
  

 | 
show 3 more comments

up vote
26
down vote

favorite

3

up vote
26
down vote

favorite

3

3

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.

interviewing software-industry

share|improve this question

asked Mar 3 '14 at 17:04

TooTone

1,69011130

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.

interviewing software-industry

share|improve this question

asked Mar 3 '14 at 17:04

TooTone

1,69011130

share|improve this question

share|improve this question

asked Mar 3 '14 at 17:04

TooTone

1,69011130

asked Mar 3 '14 at 17:04

TooTone

1,69011130

asked Mar 3 '14 at 17:04

TooTone

1,69011130

1,69011130

closed as primarily opinion-based by IDrinkandIKnowThings, jcmeloni, jmort253♦ Mar 5 '14 at 6:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

closed as primarily opinion-based by IDrinkandIKnowThings, jcmeloni, jmort253♦ Mar 5 '14 at 6:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  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.
  – Andrew Bartel
  Mar 3 '14 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.
  – Bill Leeper
  Mar 3 '14 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 '14 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 '14 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 '14 at 23:19
  

  
  
  
  

 | 
show 3 more comments

• 
  
  
  

  
  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.
  – Andrew Bartel
  Mar 3 '14 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.
  – Bill Leeper
  Mar 3 '14 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 '14 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 '14 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 '14 at 23:19
  

  
  
  
  

5

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.
– Andrew Bartel
Mar 3 '14 at 17:11

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.
– Andrew Bartel
Mar 3 '14 at 17:11

3

3

I have worked in places and know of places that either don't allow or discourage contributing to open source projects.
– Bill Leeper
Mar 3 '14 at 17:14

I have worked in places and know of places that either don't allow or discourage contributing to open source projects.
– Bill Leeper
Mar 3 '14 at 17:14

17

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 '14 at 1: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 '14 at 1:17

2

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 '14 at 5:17

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 '14 at 5:17

3

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 '14 at 23:19

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 '14 at 23:19

 | 
show 3 more comments

11 Answers
11

active

oldest

votes

up vote
3
down vote



accepted

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.

share|improve this answer

answered Mar 4 '14 at 16:57

La-comadreja

472212

• 
  
  
  

  
  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 '14 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.
  – La-comadreja
  Mar 5 '14 at 14:23
  

  
  
  
  

add a comment | 

up vote
27
down vote

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.

share|improve this answer

edited Mar 4 '14 at 7:50

user10042

answered Mar 3 '14 at 18:35

jareyes

57138

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I really like the cookie analogy and have never heard it before!
  – bethlakshmi
  Mar 3 '14 at 21:38
  

  
  
  
  

add a comment | 

up vote
16
down vote

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.

share|improve this answer

edited Mar 4 '14 at 23:37

answered Mar 4 '14 at 0:53

jmac

19.4k763137

• 
  
  
  

  
  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.
  – Simon O'Doherty
  Mar 4 '14 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 '14 at 23:36
  

  
  
  
  

add a comment | 

up vote
10
down vote

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.

share|improve this answer

edited Apr 13 '17 at 12:48

Community♦

1

answered Mar 4 '14 at 6:58

Simon O'Doherty

4,85111435

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '14 at 8:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Whoops! yes you are correct. Also I am happy to merge my answer into yours if you want.
  – Simon O'Doherty
  Mar 4 '14 at 8:27
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  My reason for the answer is you suggest "Ask for forgiveness" as a viable option, which I don't believe.
  – Simon O'Doherty
  Mar 4 '14 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 '14 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.
  – Simon O'Doherty
  Mar 4 '14 at 8:58
  

  
  
  
  

 | 
show 3 more comments

up vote
6
down vote

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.

share|improve this answer

answered Mar 3 '14 at 17:34

Dan Pichelman

24.7k116882

add a comment | 

up vote
2
down vote

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.

share|improve this answer

edited Mar 4 '14 at 15:25

answered Mar 4 '14 at 4:49

Aaron Hall

4,16312033

add a comment | 

up vote
1
down vote

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.

share|improve this answer

answered Mar 3 '14 at 17:17

Bill Leeper

10.8k2735

add a comment | 

up vote
1
down vote

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.

share|improve this answer

answered Mar 4 '14 at 20:27

Juan

1111

add a comment | 

up vote
0
down vote

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.

share|improve this answer

answered Mar 4 '14 at 14:27

Dennis S.

45555

add a comment | 

up vote
-1
down vote

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.

share|improve this answer

answered Mar 3 '14 at 22:23

WearyWanderer

211

• 
  
  
  

  
  

  
  
  
  
  
  

  
  @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?
  – IDrinkandIKnowThings
  Mar 4 '14 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 '14 at 18:59
  
  

  
  
  
  

add a comment | 

up vote
-4
down vote

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.

share|improve this answer

answered Mar 4 '14 at 7:27

R..

793712

• 
  
  
  

  
  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 '14 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.
  – R..
  Mar 4 '14 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.
  – La-comadreja
  Mar 4 '14 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.
  – R..
  Mar 4 '14 at 18:06
  

  
  
  
  

add a comment | 

11 Answers
11

active

oldest

votes

11 Answers
11

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
3
down vote



accepted

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.

share|improve this answer

answered Mar 4 '14 at 16:57

La-comadreja

472212

• 
  
  
  

  
  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 '14 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.
  – La-comadreja
  Mar 5 '14 at 14:23
  

  
  
  
  

add a comment | 

up vote
3
down vote



accepted

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.

share|improve this answer

answered Mar 4 '14 at 16:57

La-comadreja

472212

• 
  
  
  

  
  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 '14 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.
  – La-comadreja
  Mar 5 '14 at 14:23
  

  
  
  
  

add a comment | 

up vote
3
down vote



accepted

up vote
3
down vote



accepted

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.

share|improve this answer

answered Mar 4 '14 at 16:57

La-comadreja

472212

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.

share|improve this answer

answered Mar 4 '14 at 16:57

La-comadreja

472212

share|improve this answer

share|improve this answer

answered Mar 4 '14 at 16:57

La-comadreja

472212

answered Mar 4 '14 at 16:57

La-comadreja

472212

answered Mar 4 '14 at 16:57

La-comadreja

472212

472212

• 
  
  
  

  
  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 '14 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.
  – La-comadreja
  Mar 5 '14 at 14:23
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  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 '14 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.
  – La-comadreja
  Mar 5 '14 at 14:23
  

  
  
  
  

1

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 '14 at 11:45

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 '14 at 11:45

1

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.
– La-comadreja
Mar 5 '14 at 14:23

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.
– La-comadreja
Mar 5 '14 at 14:23

add a comment | 

up vote
27
down vote

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.

share|improve this answer

edited Mar 4 '14 at 7:50

user10042

answered Mar 3 '14 at 18:35

jareyes

57138

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I really like the cookie analogy and have never heard it before!
  – bethlakshmi
  Mar 3 '14 at 21:38
  

  
  
  
  

add a comment | 

up vote
27
down vote

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.

share|improve this answer

edited Mar 4 '14 at 7:50

user10042

answered Mar 3 '14 at 18:35

jareyes

57138

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I really like the cookie analogy and have never heard it before!
  – bethlakshmi
  Mar 3 '14 at 21:38
  

  
  
  
  

add a comment | 

up vote
27
down vote

up vote
27
down vote

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.

share|improve this answer

edited Mar 4 '14 at 7:50

user10042

answered Mar 3 '14 at 18:35

jareyes

57138

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.

share|improve this answer

edited Mar 4 '14 at 7:50

user10042

answered Mar 3 '14 at 18:35

jareyes

57138

share|improve this answer

share|improve this answer

edited Mar 4 '14 at 7:50

user10042

edited Mar 4 '14 at 7:50

user10042

edited Mar 4 '14 at 7:50

user10042

answered Mar 3 '14 at 18:35

jareyes

57138

answered Mar 3 '14 at 18:35

jareyes

57138

answered Mar 3 '14 at 18:35

jareyes

57138

57138

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I really like the cookie analogy and have never heard it before!
  – bethlakshmi
  Mar 3 '14 at 21:38
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I really like the cookie analogy and have never heard it before!
  – bethlakshmi
  Mar 3 '14 at 21:38
  

  
  
  
  

1

1

I really like the cookie analogy and have never heard it before!
– bethlakshmi
Mar 3 '14 at 21:38

I really like the cookie analogy and have never heard it before!
– bethlakshmi
Mar 3 '14 at 21:38

add a comment | 

up vote
16
down vote

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.

share|improve this answer

edited Mar 4 '14 at 23:37

answered Mar 4 '14 at 0:53

jmac

19.4k763137

• 
  
  
  

  
  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.
  – Simon O'Doherty
  Mar 4 '14 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 '14 at 23:36
  

  
  
  
  

add a comment | 

up vote
16
down vote

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.

share|improve this answer

edited Mar 4 '14 at 23:37

answered Mar 4 '14 at 0:53

jmac

19.4k763137

• 
  
  
  

  
  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.
  – Simon O'Doherty
  Mar 4 '14 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 '14 at 23:36
  

  
  
  
  

add a comment | 

up vote
16
down vote

up vote
16
down vote

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.

share|improve this answer

edited Mar 4 '14 at 23:37

answered Mar 4 '14 at 0:53

jmac

19.4k763137

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.

share|improve this answer

edited Mar 4 '14 at 23:37

answered Mar 4 '14 at 0:53

jmac

19.4k763137

share|improve this answer

share|improve this answer

edited Mar 4 '14 at 23:37

edited Mar 4 '14 at 23:37

edited Mar 4 '14 at 23:37

answered Mar 4 '14 at 0:53

jmac

19.4k763137

answered Mar 4 '14 at 0:53

jmac

19.4k763137

answered Mar 4 '14 at 0:53

jmac

19.4k763137

19.4k763137

• 
  
  
  

  
  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.
  – Simon O'Doherty
  Mar 4 '14 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 '14 at 23:36
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  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.
  – Simon O'Doherty
  Mar 4 '14 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 '14 at 23:36
  

  
  
  
  

1

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.
– Simon O'Doherty
Mar 4 '14 at 9:04

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.
– Simon O'Doherty
Mar 4 '14 at 9:04

3

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 '14 at 23:36

@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 '14 at 23:36

add a comment | 

up vote
10
down vote

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.

share|improve this answer

edited Apr 13 '17 at 12:48

Community♦

1

answered Mar 4 '14 at 6:58

Simon O'Doherty

4,85111435

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '14 at 8:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Whoops! yes you are correct. Also I am happy to merge my answer into yours if you want.
  – Simon O'Doherty
  Mar 4 '14 at 8:27
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  My reason for the answer is you suggest "Ask for forgiveness" as a viable option, which I don't believe.
  – Simon O'Doherty
  Mar 4 '14 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 '14 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.
  – Simon O'Doherty
  Mar 4 '14 at 8:58
  

  
  
  
  

 | 
show 3 more comments

up vote
10
down vote

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.

share|improve this answer

edited Apr 13 '17 at 12:48

Community♦

1

answered Mar 4 '14 at 6:58

Simon O'Doherty

4,85111435

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '14 at 8:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Whoops! yes you are correct. Also I am happy to merge my answer into yours if you want.
  – Simon O'Doherty
  Mar 4 '14 at 8:27
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  My reason for the answer is you suggest "Ask for forgiveness" as a viable option, which I don't believe.
  – Simon O'Doherty
  Mar 4 '14 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 '14 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.
  – Simon O'Doherty
  Mar 4 '14 at 8:58
  

  
  
  
  

 | 
show 3 more comments

up vote
10
down vote

up vote
10
down vote

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.

share|improve this answer

edited Apr 13 '17 at 12:48

Community♦

1

answered Mar 4 '14 at 6:58

Simon O'Doherty

4,85111435

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.

share|improve this answer

edited Apr 13 '17 at 12:48

Community♦

1

answered Mar 4 '14 at 6:58

Simon O'Doherty

4,85111435

share|improve this answer

share|improve this answer

edited Apr 13 '17 at 12:48

Community♦

1

edited Apr 13 '17 at 12:48

Community♦

1

edited Apr 13 '17 at 12:48

Community♦

1

1

answered Mar 4 '14 at 6:58

Simon O'Doherty

4,85111435

answered Mar 4 '14 at 6:58

Simon O'Doherty

4,85111435

answered Mar 4 '14 at 6:58

Simon O'Doherty

4,85111435

4,85111435

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '14 at 8:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Whoops! yes you are correct. Also I am happy to merge my answer into yours if you want.
  – Simon O'Doherty
  Mar 4 '14 at 8:27
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  My reason for the answer is you suggest "Ask for forgiveness" as a viable option, which I don't believe.
  – Simon O'Doherty
  Mar 4 '14 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 '14 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.
  – Simon O'Doherty
  Mar 4 '14 at 8:58
  

  
  
  
  

 | 
show 3 more comments

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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 '14 at 8:19
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Whoops! yes you are correct. Also I am happy to merge my answer into yours if you want.
  – Simon O'Doherty
  Mar 4 '14 at 8:27
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  My reason for the answer is you suggest "Ask for forgiveness" as a viable option, which I don't believe.
  – Simon O'Doherty
  Mar 4 '14 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 '14 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.
  – Simon O'Doherty
  Mar 4 '14 at 8:58
  

  
  
  
  

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 '14 at 8:19

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 '14 at 8:19

Whoops! yes you are correct. Also I am happy to merge my answer into yours if you want.
– Simon O'Doherty
Mar 4 '14 at 8:27

Whoops! yes you are correct. Also I am happy to merge my answer into yours if you want.
– Simon O'Doherty
Mar 4 '14 at 8:27

My reason for the answer is you suggest "Ask for forgiveness" as a viable option, which I don't believe.
– Simon O'Doherty
Mar 4 '14 at 8:29

My reason for the answer is you suggest "Ask for forgiveness" as a viable option, which I don't believe.
– Simon O'Doherty
Mar 4 '14 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 '14 at 8:36

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 '14 at 8:36

1

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.
– Simon O'Doherty
Mar 4 '14 at 8:58

"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.
– Simon O'Doherty
Mar 4 '14 at 8:58

 | 
show 3 more comments

up vote
6
down vote

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.

share|improve this answer

answered Mar 3 '14 at 17:34

Dan Pichelman

24.7k116882

add a comment | 

up vote
6
down vote

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.

share|improve this answer

answered Mar 3 '14 at 17:34

Dan Pichelman

24.7k116882

add a comment | 

up vote
6
down vote

up vote
6
down vote

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.

share|improve this answer

answered Mar 3 '14 at 17:34

Dan Pichelman

24.7k116882

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.

share|improve this answer

answered Mar 3 '14 at 17:34

Dan Pichelman

24.7k116882

share|improve this answer

share|improve this answer

answered Mar 3 '14 at 17:34

Dan Pichelman

24.7k116882

answered Mar 3 '14 at 17:34

Dan Pichelman

24.7k116882

answered Mar 3 '14 at 17:34

Dan Pichelman

24.7k116882

24.7k116882

add a comment | 

add a comment | 

up vote
2
down vote

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.

share|improve this answer

edited Mar 4 '14 at 15:25

answered Mar 4 '14 at 4:49

Aaron Hall

4,16312033

add a comment | 

up vote
2
down vote

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.

share|improve this answer

edited Mar 4 '14 at 15:25

answered Mar 4 '14 at 4:49

Aaron Hall

4,16312033

add a comment | 

up vote
2
down vote

up vote
2
down vote

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.

share|improve this answer

edited Mar 4 '14 at 15:25

answered Mar 4 '14 at 4:49

Aaron Hall

4,16312033

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.

share|improve this answer

edited Mar 4 '14 at 15:25

answered Mar 4 '14 at 4:49

Aaron Hall

4,16312033

share|improve this answer

share|improve this answer

edited Mar 4 '14 at 15:25

edited Mar 4 '14 at 15:25

edited Mar 4 '14 at 15:25

answered Mar 4 '14 at 4:49

Aaron Hall

4,16312033

answered Mar 4 '14 at 4:49

Aaron Hall

4,16312033

answered Mar 4 '14 at 4:49

Aaron Hall

4,16312033

4,16312033

add a comment | 

add a comment | 

up vote
1
down vote

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.

share|improve this answer

answered Mar 3 '14 at 17:17

Bill Leeper

10.8k2735

add a comment | 

up vote
1
down vote

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.

share|improve this answer

answered Mar 3 '14 at 17:17

Bill Leeper

10.8k2735

add a comment | 

up vote
1
down vote

up vote
1
down vote

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.

share|improve this answer

answered Mar 3 '14 at 17:17

Bill Leeper

10.8k2735

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.

share|improve this answer

answered Mar 3 '14 at 17:17

Bill Leeper

10.8k2735

share|improve this answer

share|improve this answer

answered Mar 3 '14 at 17:17

Bill Leeper

10.8k2735

answered Mar 3 '14 at 17:17

Bill Leeper

10.8k2735

answered Mar 3 '14 at 17:17

Bill Leeper

10.8k2735

10.8k2735

add a comment | 

add a comment | 

up vote
1
down vote

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.

share|improve this answer

answered Mar 4 '14 at 20:27

Juan

1111

add a comment | 

up vote
1
down vote

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.

share|improve this answer

answered Mar 4 '14 at 20:27

Juan

1111

add a comment | 

up vote
1
down vote

up vote
1
down vote

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.

share|improve this answer

answered Mar 4 '14 at 20:27

Juan

1111

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.

share|improve this answer

answered Mar 4 '14 at 20:27

Juan

1111

share|improve this answer

share|improve this answer

answered Mar 4 '14 at 20:27

Juan

1111

answered Mar 4 '14 at 20:27

Juan

1111

answered Mar 4 '14 at 20:27

Juan

1111

1111

add a comment | 

add a comment | 

up vote
0
down vote

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.

share|improve this answer

answered Mar 4 '14 at 14:27

Dennis S.

45555

add a comment | 

up vote
0
down vote

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.

share|improve this answer

answered Mar 4 '14 at 14:27

Dennis S.

45555

add a comment | 

up vote
0
down vote

up vote
0
down vote

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.

share|improve this answer

answered Mar 4 '14 at 14:27

Dennis S.

45555

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.

share|improve this answer

answered Mar 4 '14 at 14:27

Dennis S.

45555

share|improve this answer

share|improve this answer

answered Mar 4 '14 at 14:27

Dennis S.

45555

answered Mar 4 '14 at 14:27

Dennis S.

45555

answered Mar 4 '14 at 14:27

Dennis S.

45555

45555

add a comment | 

add a comment | 

up vote
-1
down vote

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.

share|improve this answer

answered Mar 3 '14 at 22:23

WearyWanderer

211

• 
  
  
  

  
  

  
  
  
  
  
  

  
  @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?
  – IDrinkandIKnowThings
  Mar 4 '14 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 '14 at 18:59
  
  

  
  
  
  

add a comment | 

up vote
-1
down vote

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.

share|improve this answer

answered Mar 3 '14 at 22:23

WearyWanderer

211

• 
  
  
  

  
  

  
  
  
  
  
  

  
  @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?
  – IDrinkandIKnowThings
  Mar 4 '14 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 '14 at 18:59
  
  

  
  
  
  

add a comment | 

up vote
-1
down vote

up vote
-1
down vote

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.

share|improve this answer

answered Mar 3 '14 at 22:23

WearyWanderer

211

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.

share|improve this answer

answered Mar 3 '14 at 22:23

WearyWanderer

211

share|improve this answer

share|improve this answer

answered Mar 3 '14 at 22:23

WearyWanderer

211

answered Mar 3 '14 at 22:23

WearyWanderer

211

answered Mar 3 '14 at 22:23

WearyWanderer

211

211

• 
  
  
  

  
  

  
  
  
  
  
  

  
  @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?
  – IDrinkandIKnowThings
  Mar 4 '14 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 '14 at 18:59
  
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  @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?
  – IDrinkandIKnowThings
  Mar 4 '14 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 '14 at 18:59
  
  

  
  
  
  

@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?
– IDrinkandIKnowThings
Mar 4 '14 at 18:56

@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?
– IDrinkandIKnowThings
Mar 4 '14 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 '14 at 18:59

@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 '14 at 18:59

add a comment | 

up vote
-4
down vote

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.

share|improve this answer

answered Mar 4 '14 at 7:27

R..

793712

• 
  
  
  

  
  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 '14 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.
  – R..
  Mar 4 '14 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.
  – La-comadreja
  Mar 4 '14 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.
  – R..
  Mar 4 '14 at 18:06
  

  
  
  
  

add a comment | 

up vote
-4
down vote

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.

share|improve this answer

answered Mar 4 '14 at 7:27

R..

793712

• 
  
  
  

  
  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 '14 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.
  – R..
  Mar 4 '14 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.
  – La-comadreja
  Mar 4 '14 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.
  – R..
  Mar 4 '14 at 18:06
  

  
  
  
  

add a comment | 

up vote
-4
down vote

up vote
-4
down vote

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.

share|improve this answer

answered Mar 4 '14 at 7:27

R..

793712

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.

share|improve this answer

answered Mar 4 '14 at 7:27

R..

793712

share|improve this answer

share|improve this answer

answered Mar 4 '14 at 7:27

R..

793712

answered Mar 4 '14 at 7:27

R..

793712

answered Mar 4 '14 at 7:27

R..

793712

793712

• 
  
  
  

  
  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 '14 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.
  – R..
  Mar 4 '14 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.
  – La-comadreja
  Mar 4 '14 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.
  – R..
  Mar 4 '14 at 18:06
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  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 '14 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.
  – R..
  Mar 4 '14 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.
  – La-comadreja
  Mar 4 '14 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.
  – R..
  Mar 4 '14 at 18:06
  

  
  
  
  

4

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 '14 at 8:17

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 '14 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.
– R..
Mar 4 '14 at 9:07

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.
– R..
Mar 4 '14 at 9:07

1

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.
– La-comadreja
Mar 4 '14 at 17:03

You also need to make sure you can intelligently discuss any Open Source projects you worked on and their technologies. That's important too.
– La-comadreja
Mar 4 '14 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.
– R..
Mar 4 '14 at 18:06

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.
– R..
Mar 4 '14 at 18:06

add a comment |