4 ms·

My employers have generally been fine giving me blanket permission to contribute to specific open source projects. The framing matters: don't say "can I please

My employers have generally been fine giving me blanket permission to contribute to specific open source projects. The framing matters: don't say "can I please do some charity work because it makes me feel good". Say, "can I have your permission to get free rigorous review from experts in my field, and zero out all future maintenance costs for your company by contributing my fixes to the upstream open source project?" Because that's really how it is. No employer of mine has ever said no to that. It is entirely in their interest for you to do this, you just have to help them see it.

throw1234567891 5mo ago
“Sure, let me run this through the compliancy team. Just to make sure there’s no intellectual property infringement. Which repository and issue, exactly?”
- lqstuart 5mo ago
  it hurts how true this is
- deleted 5mo ago
  [deleted]
tombert 5mo ago
I'm a little sad that I got laid off from a previous job for a variety of reasons, but one big one was that there were discussions of letting me open source some very big changes I had made to the Kafka Streams library. I rewrote a lot of stuff while keeping the API mostly compatible, focusing on emphasizing non-blocking IO with backpressure semantics available if necessary. It was really cool and enabled a lot of interesting stuff involving the state store and mixing+matching blocking and non-blocking IO in a way that was still relatively performant. I think it was really neat and it's one of the projects I am most proud of because I was able to squeeze out performance in a lot of places that were non-obvious. I was pushing to allow us to release it to Github and/or make a PR to the upstream Kafka Streams project, but sadly they did layoffs before that was completed and afterwards there was really no "champion" to do that, so it's stuck in proprietary land. I might still do it from scratch and FOSS it, it's been long enough to where I think I wouldn't get in trouble if I rewrote it and released it (there weren't any patents or anything attached to it), and there are a few things I'd like to change anyway (like getting rid of the dependency of Vert.x). Maybe if I ever get a week off I'll do that.
- sheepscreek 5mo ago
  Fixing a bug in something open-source should be acceptable to most employers. However, if new functionality is being added, then it becomes an entirely different conversation. I think it is good that you were taking the legal + compliance sign-offs before pursuing it.
  - tombert 5mo ago
    When I worked at Apple, they were extremely strict about contributions to FOSS stuff, even on your own time, even for simple stuff like bugfixes or opening a Github issue. I am sure they have their reasons even if I don't agree with them, but it's made me very cautious about making PRs and the like while working at BigCos and making outside contributions to FOSS stuff. This even more so, though, because of course I was doing it on company time, so I wouldn't really blame them for wanting to audit stuff to ensure I'm not divulging company secrets and the like.
    - wiether 5mo ago
      > even on your own time, even for simple stuff like bugfixes or opening a Github issue During a recruitment process with a company a few years ago, they quite early asked for my GH profile and complained that I hadn't much content available. Later, they asked me to do a small exercise and put it on my GH account. When they sent me the contract, there was a clause telling that I would work for them exclusively and would not be allowed to contribute to anything else than company projects, even in my own time. I didn't signed, and every person in the process seemed unable to understand what was wrong.
      - em-bee 5mo ago
        fortunately that's illegal in many jurisdictions, but i still would not sign unless they removed that passage. i had one contract where i was able to replace the standard "we own all your work" passage into: "all your work will be released under the GPL"
- vibbix 5mo ago
orthogonal_cube 5mo ago
I miss working at a place which allowed this. Some employers get tangled up in just the legal review process. Once I asked permission to submit a patch to a project and it had quite an interesting email trail. It came down to a single question: if the patch was written during hours billed to a customer for the purpose of fixing a bug in a deliverable product, and the library being patched had to be recompiled and delivered with the source code, and the contract states that all work and intellectual property associated to the product would be transferred to the customer, do we have authority to release the patch in the public domain? Legal didn’t want to answer it.
- bandofthehawk 5mo ago
  [dead]
- bluGill 5mo ago
  The customer would probably prefer that you released it - that would mean next time they need a change the previous is up streamed. Note that the resulting patch is almost assuredly not public domain and you should never use that term.
h4ny 5mo ago
I think that's a generally good approach and a fantastic example of framing things professionally but also doesn't fix the core of the problem, which I see problematic if leadership of an engineering-focused company doesn't understand immediately. Luck with your employer also plays a big part in how you approach this too.

throw1234567891 5mo ago

“Sure, let me run this through the compliancy team. Just to make sure there’s no intellectual property infringement. Which repository and issue, exactly?”

lqstuart 5mo ago
it hurts how true this is
deleted 5mo ago
[deleted]

tombert 5mo ago

I'm a little sad that I got laid off from a previous job for a variety of reasons, but one big one was that there were discussions of letting me open source some very big changes I had made to the Kafka Streams library. I rewrote a lot of stuff while keeping the API mostly compatible, focusing on emphasizing non-blocking IO with backpressure semantics available if necessary. It was really cool and enabled a lot of interesting stuff involving the state store and mixing+matching blocking and non-blocking IO in a way that was still relatively performant. I think it was really neat and it's one of the projects I am most proud of because I was able to squeeze out performance in a lot of places that were non-obvious. I was pushing to allow us to release it to Github and/or make a PR to the upstream Kafka Streams project, but sadly they did layoffs before that was completed and afterwards there was really no "champion" to do that, so it's stuck in proprietary land. I might still do it from scratch and FOSS it, it's been long enough to where I think I wouldn't get in trouble if I rewrote it and released it (there weren't any patents or anything attached to it), and there are a few things I'd like to change anyway (like getting rid of the dependency of Vert.x). Maybe if I ever get a week off I'll do that.

sheepscreek 5mo ago
Fixing a bug in something open-source should be acceptable to most employers. However, if new functionality is being added, then it becomes an entirely different conversation. I think it is good that you were taking the legal + compliance sign-offs before pursuing it.
- tombert 5mo ago
  When I worked at Apple, they were extremely strict about contributions to FOSS stuff, even on your own time, even for simple stuff like bugfixes or opening a Github issue. I am sure they have their reasons even if I don't agree with them, but it's made me very cautious about making PRs and the like while working at BigCos and making outside contributions to FOSS stuff. This even more so, though, because of course I was doing it on company time, so I wouldn't really blame them for wanting to audit stuff to ensure I'm not divulging company secrets and the like.
  - wiether 5mo ago
    > even on your own time, even for simple stuff like bugfixes or opening a Github issue During a recruitment process with a company a few years ago, they quite early asked for my GH profile and complained that I hadn't much content available. Later, they asked me to do a small exercise and put it on my GH account. When they sent me the contract, there was a clause telling that I would work for them exclusively and would not be allowed to contribute to anything else than company projects, even in my own time. I didn't signed, and every person in the process seemed unable to understand what was wrong.
    - em-bee 5mo ago
      fortunately that's illegal in many jurisdictions, but i still would not sign unless they removed that passage. i had one contract where i was able to replace the standard "we own all your work" passage into: "all your work will be released under the GPL"
vibbix 5mo ago

orthogonal_cube 5mo ago

I miss working at a place which allowed this. Some employers get tangled up in just the legal review process. Once I asked permission to submit a patch to a project and it had quite an interesting email trail. It came down to a single question: if the patch was written during hours billed to a customer for the purpose of fixing a bug in a deliverable product, and the library being patched had to be recompiled and delivered with the source code, and the contract states that all work and intellectual property associated to the product would be transferred to the customer, do we have authority to release the patch in the public domain? Legal didn’t want to answer it.

bandofthehawk 5mo ago
[dead]
bluGill 5mo ago
The customer would probably prefer that you released it - that would mean next time they need a change the previous is up streamed. Note that the resulting patch is almost assuredly not public domain and you should never use that term.

h4ny 5mo ago

I think that's a generally good approach and a fantastic example of framing things professionally but also doesn't fix the core of the problem, which I see problematic if leadership of an engineering-focused company doesn't understand immediately. Luck with your employer also plays a big part in how you approach this too.