"This isn't a moral issue, it's simple economics."

I'm going to modify that a bit to say it's mostly economics but also barrier to entry. Wirth's Oberon etc work was designed to be easy to understand from language to architecture to tools. Students with little experience regularly ported it, redid it, and so on. I've seen similar in FOSS projects well-designed for easy understanding. I think many of these popular projects were not designed that way to the point the real and incidental (i.e. implementation) complexity is to high for most to justify time in. I know it is for me for several, major projects.

So, we need to remember that. More FOSS being designed for contributors as much as users might increase number of contributions.

Profoundly true. Toolsets change so frequently these days that the bare minimum of instructions you often see on the homepage of a project are absolutely useless unless you already know that particular segment of the development arena intimately. Oberon is an absolutely spectacular example of the alternate universe you propose.

True. I would expect most of the outsider contributions to an open source project to come from organizations that use the product heavily, to the point of having an internal support group responsible for it. That group is likely to have the expertise, time, and motivation to make actual updates to the product.

That is very hard to do.

Usually you have to fight for the right to contribute back, which in big companies means lots of fun with upper management layers and legal department before you get the green light to do that little pull request.

So in my career I have seen lots of open source being used at Fortune 500, sometimes with internal forks of bug fixes and zero contributions being done back.

> That is very hard to do.

Yes it is.

But once you start making serious changes to the source-code, it's probably less painful than trying to deal with all the merge conflicts from your own fixes every time you upgrade to a new version. At some point it's just easier to push all of that stuff to the common version.

In all those cases I was aware of, the versions were never upgraded, they were frozen to the one used when the project started.

I don't know the details, but the teams at Google responsible for supporting their version of Linux and their C++ compiler sometimes mentioned making contributions to the common codebases. I got the impression they didn't make all of their fixes public, though.

Sure, but companies like Google, Facebook and others are the outliers anyway.

What matters are all those companies that no one heard of, or whose business has nothing to do with producing software.

Totally agree with you here.