I want the source so I can fix bugs instantly instead of trying to convince some mid-tier product manager having gone through 5 tiers of support. That is a huge benefit over source-unavailable proprietary software, or (heaven help us) SAAS.
Would I be able to do that for the Linux kernel? Of course not. But the vast majority of software out there is nowhere close to that level of complexity. And there are specialized groups that are trustworthy that we pay enormous sums to handle that and have had good experiences with.
So it depends but it's definitely a selling point of open source for a lot of systems engineering and adjacent roles that need to glue together lots of disparate pieces of software in sometimes unusual and unsupported ways, and sometimes for platforms that are not technically supported, or that the vendor is not able to establish any confidence in us that they will be able to support it competently for the next 10+ years for any number of reasons. That often requires forking the codebase.
To summarize, as someone essentially in the business of insuring for fortune 500s that aren't software vendors against startups and other companies deemed non-trustworthy or risky in some other way...the vast majority of YC style companies inevitably fall into the category of company where their software would not pass risk management processes for enterprise wide deployment without a proper open source license. A lot of that is down to regulatory requirements as well. It isn't some sort of irrational FAANG company "not developed here" ego boost.
For those of you that are new to the startup world, or weren't around back in the before times of the 60s-around about the mid 2000s up until the financial crisis, this may not make much sense. But it's very much the case that this ecosystem of software startups would not exist in any significant way if it had not gone all in on open source. I'm not sure how I feel about that morally or ethically but its something to think about when you are deciding how to license your software.
As far as these weird source available licenses go...it's an option but it's risky. Those familiar with the history of computing will know that the old mainframe OS's and commercial Unix's were both once source available and that ended up burning a lot of people when they started to restrict access to the source (a lot of our companies had and still maintain custom operating system modifications to legacy platforms from back in those days). The institutional memory of source available licenses (or in the case of MVS, no concept of software licensing at all) being used to turn the screws on customers is still very raw in the much slower moving world of traditional industries. Enshitification is not a new idea, some industries have been through multiple cycles of that process and have developed defense mechanisms.
Some other patch that was written by someone else at my company is now part of postgres.
Most recent examples I can remember: polars data conversion errors, batch sizing in azure service bus sdk, some weird validation thing in pydantic and the performance monitoring in sentry not working as expected. The pydantic bug got a patch / note in the docs that was actually already merged.
The problem is that a lot of companies seem to want to have their cake and eat it; they want the public contributions and kudos from making open source software, while treating it like proprietary software where the source is (maybe) available to end users.