Open Source on its own is no alternative to Big Tech

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.

There are aspects of a State to function that MUST be ONLY fully public. Again it's simple, in conceptual terms, hard to get applied in reality.

If we're worried about the supplier now then we don't bu from them. If they suddenly change down the road (and most established ones don't) then the fallback is either "we don't need support anymore" or (more likely) we start looking for another system.

I've been on the other side of this. We sell a product into an established mature domain. We're the "newbie" on the block. Most of the sales we get in this space are from customers who are unhappy with their supplier. We offer better sales and service, and obviously a smooth transition from their existing data (which we import.)

Neither product is OSS - but even if it was that would be irrelevant to the user. (It would however have made our integration code a lot easier to write, so there is that...) A lot of the users we convert have "bought" their software. It's costing them nothing to use it. But they switch to us anyway (we have a subscription model) because our model can afford to fund full time support staff, whereas the sales model cannot.

So, I think this "choose another servicer" is more of a theoretical than practical feature for most OSS systems. Obviously there's really good support for the really big projects, but basically nothing from 99% of them...

This sounds just like a general argument against prenups and specifying any kind of contract penalties?

In any case: one way a supplier can make me less worried about them now is by open sourcing.

I mostly agree with most of your points.