3 ms·

I worked for a large defence contractor and getting approval for anyone to pay for that would have been more difficult than actually learning how to fix it myse

by hughrr 5y ago

I worked for a large defence contractor and getting approval for anyone to pay for that would have been more difficult than actually learning how to fix it myself and fixing it myself. 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 could of course have done a clean room patch at home based on my retained knowledge but quite frankly I probably couldn’t be assed with it by the time I’d got home and eaten dinner due to the depression of working in such a horrible place. That’s the reality of working for such folk.

dhosek 5y ago
I'm so glad that I never did that work when it was a possibility.
dathinab 5y ago
I wonder if they couldn't "just" put up a misc. software support money pool with a reasonable but in the huge picture small amount of money they can "low complexity" spend on such things?
- hughrr 5y ago
  Considering it took three tiers of management and three facilities department members to replace a coffee machine that had an actual service contract in place already, I think something of that administrative complexity would have been beyond them. Either that or like most SMEs I’ve worked for they’re actually only using the stuff because it’s “free” by their corrupted definition of “free” which is basically it didn’t have to go through a PO process.
  - deleted 5y ago
    [deleted]
bluGill 5y ago
I got around that one place by just writing up a bug report and a it seems like line x of file... this wasn't government and so they wouldn't have cared anyway so i just avoided figuring out the paperwork to contribute.
lmeyerov 5y ago
Sort of, in a depressing way: - It's pretty doable to get someone's hours for this, especially within the contractor or one of their DC buddies: there's already a customer and a contractor, and presumably, some sort of purchase vehicle & contract. The words "senior", "support", and "fee" are probably in there in multiple places. - By (backwards) design, it is much harder for a truly expert OSS dev not in the contractor circle, and even harder, an OSS product org offering maintenance contracts for events like this - The middle ground becomes sales/lobby-heavy orgs like IBM/RedHat, which introduces another multi-layer technical & political world of pain. I haven't worked with Cray (discussed in the thread), so no comment there. But as seen, we're seeing a chain of well-funded stakeholders being fine with not supporting for a prolonged period, which is cultural red flags.
- pinewurst 5y ago
  From 1st hand experience there’s a lot of (IMHO) confusion in these sorts of organizations between maintenance and new features driving this kind of entitlement.
vkou 5y ago
> I worked for a large defence contractor and getting approval for anyone to pay for that would have been more difficult than actually learning how to fix it myself and fixing it myself. 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. Unless your software was write-once, compile-once, 'fixing it myself' includes the time it takes to do the initial fix, add unit tests for it, and also the time it takes to patch that fix into every future version of GCC you use - and also ensure that the institution will remember to do so long after you get on the lottery bus. Given all of the above, it may in fact, be easier to figure out who in your org you can bug to just pay the vendor.
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 ago
  Probably 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.

by hughrr 5y ago

dhosek 5y ago

I'm so glad that I never did that work when it was a possibility.

dathinab 5y ago

I wonder if they couldn't "just" put up a misc. software support money pool with a reasonable but in the huge picture small amount of money they can "low complexity" spend on such things?

hughrr 5y ago
Considering it took three tiers of management and three facilities department members to replace a coffee machine that had an actual service contract in place already, I think something of that administrative complexity would have been beyond them. Either that or like most SMEs I’ve worked for they’re actually only using the stuff because it’s “free” by their corrupted definition of “free” which is basically it didn’t have to go through a PO process.
- deleted 5y ago
  [deleted]

bluGill 5y ago

I got around that one place by just writing up a bug report and a it seems like line x of file... this wasn't government and so they wouldn't have cared anyway so i just avoided figuring out the paperwork to contribute.

lmeyerov 5y ago

Sort of, in a depressing way: - It's pretty doable to get someone's hours for this, especially within the contractor or one of their DC buddies: there's already a customer and a contractor, and presumably, some sort of purchase vehicle & contract. The words "senior", "support", and "fee" are probably in there in multiple places. - By (backwards) design, it is much harder for a truly expert OSS dev not in the contractor circle, and even harder, an OSS product org offering maintenance contracts for events like this - The middle ground becomes sales/lobby-heavy orgs like IBM/RedHat, which introduces another multi-layer technical & political world of pain. I haven't worked with Cray (discussed in the thread), so no comment there. But as seen, we're seeing a chain of well-funded stakeholders being fine with not supporting for a prolonged period, which is cultural red flags.

pinewurst 5y ago
From 1st hand experience there’s a lot of (IMHO) confusion in these sorts of organizations between maintenance and new features driving this kind of entitlement.

vkou 5y ago

> I worked for a large defence contractor and getting approval for anyone to pay for that would have been more difficult than actually learning how to fix it myself and fixing it myself. 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. Unless your software was write-once, compile-once, 'fixing it myself' includes the time it takes to do the initial fix, add unit tests for it, and also the time it takes to patch that fix into every future version of GCC you use - and also ensure that the institution will remember to do so long after you get on the lottery bus. Given all of the above, it may in fact, be easier to figure out who in your org you can bug to just pay the vendor.

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 ago
Probably 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.