I think this is an important point that is often overlooked.

When we release code under a free software license, we are giving the software to the user, entirely. If you're using software that you own, not just merely have a license to, it is yours, be prepared to maintain it, and if you're not prepared to maintain it, maybe relying on free-as-in-freedom software is a bad decision for you.

Code released under MIT and BSD licenses should really be thought of not as free, as in speech, or free, as in beer, but free, as in mattress on the side of the road.

One I've heard is "free, as in puppy"

ie good, but comes with responsibility

It's easier to blame a nebulous 3rd party than to take responsibility.

"reminding colleagues that using OSS means we have to own and maintain the software whether the original community/author does or not"

No, we do not have to do this. We wouldn't get anything done, if we tried to maintain our full oss stack. Where would you start? In the linux kernel and move your way up to chromium/firefox? Have fun out there.

"There seems to be a hesitance to fork abandoned or slow moving software to update/fix issues "

And it is often easier to reimplement something from scratch, than taking up some underdocumented mess and trying to make sense of it.

So I would rephrase that to

" using OSS means we can own and maintain the software whether the original community/author does or not."

>No, we do not have to do this. We wouldn't get anything done, if we tried to maintain our full oss stack. Where would you start? In the linux kernel and move your way up to chromium/firefox? Have fun out there.

Seems a little disingenuous to assume that GP meant that everyone should fully maintain their own OSS stack, when their comment could be read far more reasonably as a solution for when those processes aren't serving your needs entirely.

" could be read far more reasonably as a solution for when those processes aren't serving your needs entirely"

Yeah, that is why I rephrased it, to with OSS you can own and maintain your full stack.

Op said "must".

It's much simpler: if you run into a missing bug/feature, report it to the maintainers and ask them to assign it to you.

If each individual licensee is itching their own scratches, then there's a really good chance the entire codebase gets love.

Absolutist approaches are the death of all good things. "Some" is better than "none."

"Absolutist approaches are the death of all good things"

Agreed. Hence "can" and not "must".

>No, we do not have to do this. We wouldn't get anything done, if we tried to maintain our full oss stack. Where would you start? In the linux kernel and move your way up to chromium/firefox? Have fun out there.

People (sysadmins) have been doing this for years--it's nothing new. Software doesn't break that often. You generally start with wherever you're hitting the bug. Maintaining, running, and operating software is significantly different than writing from scratch (and generally less labor intensive)

What do you do when you hit a bug in production caused by some OSS? Throw your hands up and tell management you opened an issue on the issue tracker?

Eh, I've submitted patches for everything from the kernel to bash scripts because of bugs I've run into at work that really affected us which we needed to fix ASAP.

Sure I didn't have to but isn't that the point of open source?

There is a big cost of context switch. If you are such a genious, that you can just jump around in entirely different codebases fixing entirely different set of problems, in a way that actually improves things, than hats of to you, because I can't. I am not bored and I am fully occupied maintaining my own OSS codebase and I doubt some random dude could just come and fix a problem there (unless it is a really trivial one).