For example, Microsoft may be changing their image, but their core software is closed source. <cloud provider> may be great, but can you pull off something like this when you've got an issue? The importance of being able to debug and patch your mission critical systems is hard to overstate.
Please encourage your employer to fiscally support the open source code that they rely upon!
Not OSS != no source access. A cloud provider on top of the MS stack would most likely have Shared Source Initiative licenses.
Licensees may use the source code as a reference or view within a debugger,
but may not modify the code or use it to create derivative works.Furthermore, no source access != no way to fix problems.
People have been fixing things with no source for ages, EULAs be damned. If the fix is literally flipping a single bit, the decision is easy. Just do it. The vendor doesn't need to know nor care what we did to fix it, but often giving a detailed description to them of the problem --- one that comes out of the process of fixing it --- will help them fix it quickly and distribute to their other customers too. I've had this experience a few times.
Obviously, "the byte at 0x73F441 of somefile.dll should be 31, not 32" is not how you should communicate such things to the vendor, but they do appreciate your effort in debugging the issue instead of immediately blaming it on a fault in their software. ;-)
(And relatedly, no source access != no way to find problems either, as the security community shows quite plainly...)
`git clone` is an incredible power. Companies should reward those who are generous with their code.
Careful with those goalposts, you're tearing up the pavement.
> Companies should reward those who are generous with their code.
So companies "should reward those who are generous with their code" but not compensate them for it?
No, they absolutely should compensate them for it. Buy OSS.
This issue didn't get solved particularly quickly, either. Nor was "source to the whole stack" required -- kernel source made for a illustrative blog post but was not really part of the process.
Do you have source files for the CPU? The motherboard? Your DRAM controller? At some point you draw the line and make shit work. Tools plus docs plus code is great, but you can make do with just one of 'em in a pinch.
When this works well, it's great. You've got the experts on the problem. Not all support is good though, obviously, and if you have a mission critical problem that you need to fix overnight, nothing beats the 'self-support' that you can do with open source software.
Reminds me of the heroku shaming posts that (then) rap genius had to do regarding dyanamo scaling and performance - http://genius.com/James-somers-herokus-ugly-secret-annotated They had no other way forward, even though they were paying the "experts"
This is why companies should pay open source contributors more frequently :-)