3 ms·
> At which point I would never be allowed to contribute the fix back to the original project due to the no code export policy and airgapped network. I mean, pr
by derefr 5y ago
> At which point I would never be allowed to contribute the fix back to the original project due to the no code export policy and airgapped network.
I mean, presumably what you'd be getting approval to do is to take PTO to do the work off-hours for the upstream project as a volunteer, no?
That's the deal most "open-core upstream maintained in public, enterprise SaaS downstream maintained in private" companies offer: "we'll compensate you for the time you spend volunteering as an engineer/maintainer at the Foundation, shipping the code we depend on."
In such a case, the code would never start as work-for-hire as part of a confidential project; and so would never need to be exported from said confidential project. It'd start life as FOSS code living in your personal GitHub repo fork of the upstream.
- hughrr 5y agoProbably wouldn’t work in the end described. The only way to get it in would be to get the maintainers to accept the patch, then wait for redhat to pull it in, then wait for a stable OS release, then wait for the IT guys to approve that release for internal use, then wait for the other IT guys to install it on your nodes. Every time we had an issue the only option was to literally divert the flow of a river around it in some way. The positive outcome of this was the sheer amount of outside the box thinking practice genuinely lead to some of us gaining semi elite debugging and hacking skills. My own favourite was writing a tool to frig with the IAT in PE files on windows NT so you could inject a new function to wrap vendor DLL functions so we could patch bugs without involving the vendor.