> In truth the license doesn't matter. My accounting software might be open or closed. My supplier doesn't sell me based on the license. They sell me by convincing me that everything just works, and when it doesn't they'll be there to fix it.
The license matters indirectly: if it's open source, you know that as a fall-back other suppliers might be able to step up and take over, if your original guys fail or get too insufferable.
Moreover, if you have an issue with OSS software and have competent people in your own IT team, they could attempt to fix the problem and get results faster than going through the whole incident-report-blame-the-victim-finally-have-them-confirm-your-repro-wait-for-next-version-release-which-hopefully-includes-the-fix ordeal.
Then if you contribute the fix back to the project, the community of users benefits as well, with possible free publicity for your organization to boot.
That's the theory, but in practice that's not how it works.
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.
It might seem like "fall back insurance". And I guess it does happen sometimes. But it's of negligible value in the _purchasing_ decision.
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...
The license matters indirectly: if it's open source, you know that as a fall-back other suppliers might be able to step up and take over, if your original guys fail or get too insufferable.