Comment by eslaught

> It's probably too much to ask corporations to dump money into it as it would not be a legitimate business expense.

Um, excuse me?

Ok, let's suppose you've got a product that depends on open source project X. For simplicity let's say it's a direct dependency, though I think everything here applies to indirect ones as well.

Let's consider the options.

Option 1: never pay a dime for it. This works in so far as someone else picks up the bill. So really there are two sub-cases:

Option 1(a): the project is successful enough that it's self-sustaining. What this really means is that someone else (or multiple someone elses) picked up the bill. Congrats, you lucked out.

Option 1(b): the project is insufficiently funded and either dies or has a major security breach. Now you end up paying either for the security breach fallout and/or to replace the component, possibly on short notice, with something else. Or you maintain it yourself and start paying that cost, again possibly on short notice.

Is that really worth it? Do you think so? I'm betting all those costs are higher than it would have cost to maintain it in the first place. Because anything you do in an emergency is more expensive, and you're paying the cost of losing all the context in the development of the project itself (if someone leaves before you start maintaining it).

Option 2: pay for the software in the first place, making the cost predictable and avoiding a low-probability high-impact failure mode. Honestly, given all the risk management companies do, this seems worth it to me. At least if the dependency is critical enough.

Obviously you won't do this with any random open source project. But that's sort of the point: companies are making economic decisions all the time about what they really care about. If they aren't paying, that means they're happy with the inverse lottery[1] of the failed open source project model.

[1]: An inverse lottery is one where most of the time you get nothing, but rarely you lose big.