Firstly, of course, most customers don't have any programming skills at all, so the point is moot. But let's limit ourselves to customers that do have IT departments.

It's worth noting that IT departments are already busy. Deploying resources because you found a bug in PostgreSQL is unlikely.

But ok, you found a bug. And we happen to have a highly paid C programmer on staff. Let's ask him to take a look.

He's not familiar with PostgreSQL architecture- do it'll take a few days to download the source, make a build, hope the build is close to our version, and deploy to production. (This has already cost the business more than a enterprise support contract from Postgres but whatever...)

He then spends a month working through various subsystems to determine the exact flow that leads to your bug. (I'm gonna ignore all the cases where the "bug" isn't a bug.) He makes a tweak, merges it into the current build, and deploys.

He even submits the PR which may or may not be accepted. Until it is he's regularly pulled from his task to update the PostgreSQL source and rebuild.

Everyone else plagues him either PostgreSQL questions twice a week now. His manager gives him a 'poor' rating at the next review because the thing he was actually hired to do is not getting done.

Unless the company is selling to other PostgreSQL developers, there's no "free publicity". That's not how publicity works.

So yes, your scenario is possible, but its simply not how things happen. You complain to the IT department - they add PostgreSQL enterprise support to the next budget. They're not looking to take on extra load unnecessarily.

Yes, the major contributers to big OSS projects are tech companies contributing full time programmers. And that's a good thing. But customers do not have the time or resources (or inclination) to go down this road.

Frankly, it's too hard (in most cases) to just build the software, much less understand the code to make changes.